目录
3.8.2 为什么新创建的数据库中没有任何数据,就已经产生了磁盘使用量?
3.8.3 为什么从其他异构数据库导入数据时会占用更多的存储空间?
3.8.5 InnoDB引擎中使用DROP命令删除索引后,是否会释放磁盘空间?
一、RDS产品介绍及排障思路
1.1 云RDS数据库及其特点
1.2 云RDS数据库-规格
根据业务选型:
1.3 云RDS数据库-存储
本地盘计算与存储一体,因此I/O时延很低,性能很好。而云盘存储采用的计算与存储分离,因此灵活性较大,I/O时延相对较高。
1.4 云RDS数据库-安全
通过设置安全组来控制哪些ip可以访问通过,哪些ip访问不通过。
1.5 云RDS数据库-整体架构
1.6 RDS常见问题排查
1.6.1 如何解决无法链接RDS实例的问题
传送门:https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/what-do-i-do-if-i-fail-to-connect-to-an-apsaradb-rds-instance?spm=a2c4g.11186623.0.0.385f6d29lDsbVO
1.6.2 RDS实例存储空间使用率高,怎么排查
传送门:https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/faq-about-storage-capacity?spm=a2c4g.11186623.0.0.18966314WRlr14
1.6.3 RDS Mysql主从延迟问题
传送门:https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/what-do-i-do-if-my-read-only-apsaradb-rds-for-mysql-instance-synchronizes-data-from-its-primary-instance-at-a-latency?spm=a2c4g.11186623.0.i9
二、Redis产品介绍及排障思路
2.1 Redis介绍
云数据库Redis版(ApsaraDB for Redis)是兼容开源Redis协议标准的数据库服务,基于双机热备架构及集群架构,可满足高吞吐、低延迟及弹性变配等业务需求。
2.2 产品架构
标准版 | 采用主从模式搭建。主节点提供日常服务访问,从节点提供HA高可用。当主节点发生故障,系统会自动在30秒内切换至从节点,保障业务平稳运行。 |
集群版 | 由代理节点、数据分片和配置服务器组件构成,可通过增加数据分片的方式实现横向扩展。每个数据分片均为双副本(分别部署在不同机器上)高可用架构,主节点发生故障后,系统会自动进行主从切换保证服务高可用。 |
读写分离版 | 由代理节点、主从节点和只读节点构成。只读节点采取链式复制架构,扩展只读节点个数可使整体实例性能呈线性增长。 |
2.3 性能指标与监控
2.4 备份与恢复
2.5 Redis实例CPU使用率高的问题
Redis CPU使用率升高可能是由于以下三种原因:
- 高并发、高吞吐的业务消耗较多CPU资源,如果CPU资源未达到瓶颈,属于正常业务场景
- 业务运行超预期,Redis实例的CPU资源无法满足业务需求,可通过增加分片数、副本数或者升级为企业版来解决资源瓶颈
- 使用不当,例如高消耗命令、热Key、大Key等,导致CPU使用率异常升高
当平均CPU使用率高于70%、连续5分钟内的CPU平均峰值使用率高于90%时,需要及时关注并排查该问题,以保障应用的稳定运行。
哪些因素会导致CPU使用率异常升高
- 高消耗命令:即时间复杂度为O(N)的命令,其中N为较大值,例如KEYS、HGETALL或使用MGET、MSET、HMSET、HMGET一次操作大量Key等。通常情况下,命令的时间复杂度越高,在执行时会消耗越多的资源,从而导致CPU使用率上升。由于命令执行单元为单线程的特性,Redis在执行高消耗命令时会引发排队导致应用响应变慢。极端情况下,甚至可能导致实例被整体阻塞,引发应用超时中断或流量跳过缓存层直接到达后端的数据库侧,引发雪崩效应。
- 热Key:某个或某部分Key的请求访问次数显著超过其他Key时,代表此时可能产生了热Key。热Key将会消耗Redis的大量CPU资源,从而影响其他Key的访问时延。并且,在集群架构中,如果热Key较为集中地分布在部分数据分片节点,可能会导致CPU使用率倾斜(个别分片的CPU使用率远超其他分片)。
- 大Key:大Key会占用更多的内存,同时,对大Key的访问会显著增加Redis的CPU负载和流量。大Key在一定程度上更容易形成热点从而造成CPU使用率高。如果大Key较为集中地分布在部分数据分片节点,可能会导致CPU使用率倾斜、带宽使用率倾斜及内存使用率倾斜。
- 短连接:频繁地建立连接,导致Redis实例的大量资源消耗在连接处理上。
- AOF:阿里云Redis实例默认开启了AOF(append-only file),当实例处于高负载状态时,AOF的写盘行为将会导致CPU使用率升高及实例整体的响应时延增加。
2.6 排查Redis实例内存使用率高的问题
Redis内存不足时,可能导致Key频繁被逐出、响应时间上升、QPS(每秒访问次数)不稳定等问题,进而影响业务运行。如果发现Redis内存占满或收到内存告警,可参考帮助文档判断内存占用是否长期过高、内存占用是否突然上升、是否发生内存倾斜,并通过拆分大Key,设置过期策略,升级规格等方法解决问题。
内存使用率高的现象分类:
内存使用率在较长一段时间内一直处于较高水位。通常,当内存使用率超过95%时需要及时关注。
内存使用率一直较低,但从某个时间点开始突然上升至较高水位,甚至达到100%。
实例整体的内存使用率较低,但某个数据分片节点的内存使用率接近100%。
传送门:https://help.aliyun.com/zh/redis/user-guide/troubleshoot-the-high-memory-usage-of-an-apsaradb-for-redis-instance
2.7 Redis常见问题
三、PolarDB产品介绍及排障思路
3.1 PolarDB介绍
PolarDB是一个关系型数据库云服务,目前已在全球十多个地域(Region)的数据中心部署,向用户提供开箱即用的在线数据库服务。PolarDB目前支持3种独立的引擎,分别可以100%兼容MySQL、100%兼容PostgreSQL、高度兼容Oracle语法,存储容量最高可达100 TB。详情参考:什么是PolarDB MySQL企业版、什么是PolarDB MySQL标准版。 PolarDB MySQL版企业版和标准版在功能上有很多差异,可分为集群管理、弹性管理、高性能、备份与恢复、高可用性、高安全、连接管理、高性价比、监控与优化、DB for AI、数据迁移&同步等11个类别。
3.2 PolarDB连接信息和方式
可以通过以下方式管理PolarDB My SQL版集群,包括创建集群、创建数据库、创建账号等。
- 控制台:提供图形化的Web界面,操作方便。
- CLI:控制台上所有的操作都可以通过CL!实现。
- SDK:控制台上所有的操作都可以通过SDK实现。
- API:控制台上所有的操作都可以通过AP1实现。
创建PolarDB MysQL版集群后,可以通过以下方式连接PolarDB MysQL版集群:
- DMS:您可以通过DMS连接PolarDB集群,在Web界面进行数据库开发工作。
- 客户端:您可以使用通用的数据库客户端工具连接PolarDB MysQL版集群。例如MysQL-Front. HeidisQL等
3.3 产品架构-PolarDB MySQL企业版
云原生数据库PolarDB基于Cloud Native设计理念,既融合了商业数据库稳定可靠、高性能、可扩展的特征,又具有开源云数据库简单开放、快速迭代的优势。产品架构如下:
PolarDB MySQL版的产品架构具有如下特点:
一写多读:
PolarDB采用分布式集群架构,一个集群版集群包含一个主节点和最多15个只读节点(至少一个,用于保障高可用)。主节点处理读写请求,只读节点仅处理读请求。主节点和只读节点之间采用Active-Active的Failover方式,提供数据库的高可用服务。
计算与存储分离:
PolarDB采用计算与存储分离的设计理念,满足公共云计算环境下根据业务发展弹性扩展集群的刚性需求。数据库的计算节点(Database Engine Server)仅存储元数据,而将数据文件、Redo Log等存储于远端的存储节点(Database Storage Server)。各计算节点之间仅需同步Redo Log相关的元数据信息,极大地降低了主节点和只读节点间的复制延迟,而且在主节点故障时,只读节点可以快速切换为主节点。
读写分离:
读写分离是PolarDB集群版默认免费提供的一个透明、高可用、自适应的负载均衡能力。通过集群地址,SQL请求自动转发到PolarDB集群版的各个节点,提供聚合、高吞吐的并发SQL处理能力。
高速链路互联:
数据库的计算节点和存储节点之间采用高速网络互联,并通过RDMA协议进行数据传输,使I/O性能不再成为瓶颈。
共享分布式存储:
多个计算节点共享一份数据,而不是每个计算节点都存储一份数据,极大地降低了用户的存储成本。基于全新打造的分布式块存储(Distributed Storage)和文件系统(Distributed Filesystem),存储容量可以在线平滑扩展,不会受到单个数据库服务器的存储容量限制,可应对上百TB级别的数据规模。
数据多副本、Parallel-Raft协议:
数据库存储节点的数据采用多副本形式,确保数据的可靠性,并通过Parallel-Raft协议保证数据的一致性。
3.4 产品架构-PolarDB MySQL标准版
PolarDB MySQL版的标准版是PolarDB全新推出的数据库集群类型,采用阿里云全新一代高性能低成本的计算和存储基础设施,用户使用较低的成本即可享受到PolarDB的核心能力。
采用计算与存储分离的架构,数据库代理和计算节点分别采用独立的ECS进行部署,共享存储层使用ESSD云盘,极大的降低了用户使用PolarDB的成本。
PolarDB MySQL版的标准版采用通用的基础设施,用户使用较低的成本即可享受到PolarDB的核心能力:
- PolarDB MySQL版的标准版和企业版共用一套内核。多年深度优化的PolarDB数据库内核,相对开源的内核大幅提升了数据库性能。
- 采用最新一代阿里云高性能计算和存储基础设施,客户使用成本大幅下降。
- 云原生的计算和存储分离架构,一写多读,灵活弹性,配置升降级和增加节点分钟级生效。
- 多个计算节点共享存储,新增只读节点时只需支付计算节点费用,大大降低了扩容成本。
PolarDB MySQL版提供基于X86和ARM两大主流CPU架构的集群:
- X86:X86架构搭载英特尔处理器,配套高性能网络,综合性能及稳定性全面提升,满足对业务稳定性及计算性能要求较高的企业级应用诉求。
- ARM:ARM架构底层采用阿里云自研倚天710处理器芯片及25 GE智能高速网卡,提供强劲的计算能力。配套高性能网络,能更好地满足政府、互联网等各类企业对云上业务的高性价比、安全稳定等诉求。
3.5 基本功能-控制台
可以看到实例所有的信息,地域、VPC、计算付费类型、可用区、交换机、创建时间、兼容性、可维护窗口、系列、到期时间、内核版本等等的信息。
第二部分是白名单于账号,可以点击蓝色的字体直达对应的部分。
第三部分是数据库连接,包含主地址、集群地址以及是否有自定义地址。
可以点击查看对应的集群地址配置,里面会有集群地址的路由策略。
3.5 集群白名单&账号管理
创建PolarDB MySQL版数据库集群后,您还需要设置集群的IP白名单,并创建集群的初始账号,只有已添加到白名单中的IP地址或安全组中的ECS实例才能访问该集群。
PolarDB支持高权限账号和普通账号这两种数据库账号,您可以在控制台管理所有账号。出于安全原因,PolarDB不提供root账号。其中,云上的实例没有super权限。如果只支持库级别的权限设置,更细的权限需要命令行的方式。
3.6 诊断与优化
主要涉及有一键诊断,里面包含一些异常事件、会话管理、实时性能、所分析、空间分析、诊断报告和性能洞察。比较常见的是 异常事件以及会话管理。
日志管理:主要是一些运行日志
慢SQL: 执行时间超过long_query_time的SQL
日志与审计:属于洞察部分,可以用于记录查看客户执行的SQL。
3.7 PolarDB MySQL版CPU使用率高问题
CPU作为数据库最核心的资源,是日常运维中需要重点关注的对象。CPU用满,会导致应用RT增高、业务卡顿,更严重会导致数据库实例hang死、发生HA等问题,严重影响现网业务。正常情况下,对于CPU的监控需要设定安全水位,超出安全水位时要及时进行处理,否则会引发不可预期的严重后果。
随着业务的增长,数据库集群的规格可能已经不能满足业务流量的上涨需求。此时由于流量的不断增长,数据库集群的使用率逐渐提升,CPU使用率也逐渐升高。如果从性能曲线进行观察,必然存在某个指标(如QPS/IOPS)呈上涨趋势,与CPU使用率上涨趋势相似。如下图所示:
cpu使用过高分为业务增长导致cpu打高和非预期内的cpu打高,具体排查参考:https://help.aliyun.com/zh/polardb/polardb-for-mysql/high-cpu-utilization-of-polardb-for-mysql-clusters
3.8 空间问题
3.8.1 集群的存储空间占用突然升高,如何进行排查?
按照以下步骤进行排查:
- 登录PolarDB控制台。
- 在控制台左上角,选择集群所在地域。
- 找到目标集群,单击集群ID。
- 在基本信息页面的数据库分布式存储区域,查看数据库存储用量
- 在左侧导航栏,单击诊断与优化>一键诊断,在空间概况页面的空间变化趋势区域,查看是因为哪个空间使用量升高导致存储空间升高。
3.8.2 为什么新创建的数据库中没有任何数据,就已经产生了磁盘使用量?
数据库初始化时,会创建相关的系统表用于存储账户、权限等。此外,数据库系统日志(Redo log、Undo log等)也会占用磁盘空间。
3.8.3 为什么从其他异构数据库导入数据时会占用更多的存储空间?
不同的数据库存储引擎处理数据的方式不同。例如,是否有压缩功能、某些字段上是否有索引等都会影响存储空间的占用量。
3.8.4 集群的存储空间是否包含备份空间?
包含,PolarDB备份和恢复功能均免费使用,但备份文件会占用一定的存储空间。根据备份存储位置,备份文件占用的空间分为一级备份、二级备份和物理日志备份。
3.8.5 InnoDB引擎中使用DROP命令删除索引后,是否会释放磁盘空间?
由于索引和数据存储在同一个文件中,因此,在使用独立表空间时,在InnoDB引擎中使用DROP命令删除索引后,并不会释放存储空间。
3.9 PolarDB死锁
死锁是关系型数据库系统中最为常见的错误,出现在不同事务中同时对某些数据访问加锁时,都要等待对方请求中的数据而无法获取锁。数据库系统会自动牺牲回滚代价最小的事务,从而导致对应的写请求失败。更严重的情况是在大量死锁发生时,会导致数据库系统效率低下,大量进程堆积进而引发性能问题。正常情况下,死锁都是由于逻辑加锁的顺序导致的,也就是我们常说的ABA死锁。
利用DAS的锁分析功能与SQL洞察功能进行死锁定位的方法见传送门: https://help.aliyun.com/zh/polardb/polardb-for-mysql/resolve-deadlocks-in-polardb?spm=a2c4g.11186623.0.0.d8a130cfX7b3A9
3.10 PolarDB MySQL常见问题
总结
1、RDS、Redis和PolarDB分别是阿里云提供的关系型数据库、键值存储数据库和高性能分布式数据库服务。
2、RDS简化了数据库的部署和管理,提供了高可用性和安全性;Redis则适用于需要高吞吐量和低延迟的应用场景,支持多种架构以满足不同的业务需求;PolarDB结合了传统数据库的稳定性和云数据库的弹性,支持多种数据库引擎,特别适合大规模数据处理和企业级应用。这三者均提供了详尽的监控和排障指南,帮助用户高效管理和优化数据库性能,确保业务稳定运行。