目录
[1.1 云RDS数据库及其特点](#1.1 云RDS数据库及其特点)
[1.2 云RDS数据库-规格](#1.2 云RDS数据库-规格)
[1.3 云RDS数据库-存储](#1.3 云RDS数据库-存储)
[1.4 云RDS数据库-安全](#1.4 云RDS数据库-安全)
[1.5 云RDS数据库-整体架构](#1.5 云RDS数据库-整体架构)
[1.6 RDS常见问题排查](#1.6 RDS常见问题排查)
[1.6.1 如何解决无法链接RDS实例的问题](#1.6.1 如何解决无法链接RDS实例的问题)
[1.6.2 RDS实例存储空间使用率高，怎么排查](#1.6.2 RDS实例存储空间使用率高，怎么排查)
[1.6.3 RDS Mysql主从延迟问题](#1.6.3 RDS Mysql主从延迟问题)
[2.1 Redis介绍](#2.1 Redis介绍)
[2.2 产品架构](#2.2 产品架构)
[2.3 性能指标与监控](#2.3 性能指标与监控)
[2.4 备份与恢复](#2.4 备份与恢复)
[2.5 Redis实例CPU使用率高的问题](#2.5 Redis实例CPU使用率高的问题)
[2.6 排查Redis实例内存使用率高的问题](#2.6 排查Redis实例内存使用率高的问题)
[2.7 Redis常见问题](#2.7 Redis常见问题)
[3.1 PolarDB介绍](#3.1 PolarDB介绍)
[3.2 PolarDB连接信息和方式](#3.2 PolarDB连接信息和方式)
[3.3 产品架构-PolarDB MySQL企业版](#3.3 产品架构-PolarDB MySQL企业版)
[3.4 产品架构-PolarDB MySQL标准版](#3.4 产品架构-PolarDB MySQL标准版)
[3.5 集群白名单&账号管理](#3.5 集群白名单&账号管理)
[3.6 诊断与优化](#3.6 诊断与优化)
[3.7 PolarDB MySQL版CPU使用率高问题](#3.7 PolarDB MySQL版CPU使用率高问题)
[3.8 空间问题](#3.8 空间问题)
[3.8.1 集群的存储空间占用突然升高，如何进行排查？](#3.8.1 集群的存储空间占用突然升高，如何进行排查？)
[3.8.2 为什么新创建的数据库中没有任何数据，就已经产生了磁盘使用量？](#3.8.2 为什么新创建的数据库中没有任何数据，就已经产生了磁盘使用量？)
[3.8.3 为什么从其他异构数据库导入数据时会占用更多的存储空间？](#3.8.3 为什么从其他异构数据库导入数据时会占用更多的存储空间？)
[3.8.4 集群的存储空间是否包含备份空间？](#3.8.4 集群的存储空间是否包含备份空间？)
[3.8.5 InnoDB引擎中使用DROP命令删除索引后，是否会释放磁盘空间？](#3.8.5 InnoDB引擎中使用DROP命令删除索引后，是否会释放磁盘空间？)
[3.9 PolarDB死锁](#3.9 PolarDB死锁)
[3.10 PolarDB MySQL常见问题](#3.10 PolarDB MySQL常见问题)
一、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实例的问题
1.6.2 RDS实例存储空间使用率高，怎么排查
1.6.3 RDS Mysql主从延迟问题
二、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%。
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。
- 在基本信息 页面的数据库分布式存储区域 ，查看数据库存储用量
- 在左侧导航栏，单击诊断与优化>一键诊断 ，在空间概况 页面的空间变化趋势区域，查看是因为哪个空间使用量升高导致存储空间升高。
https://polardb.console.aliyun.com/overview3.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结合了传统数据库的稳定性和云数据库的弹性，支持多种数据库引擎，特别适合大规模数据处理和企业级应用。这三者均提供了详尽的监控和排障指南，帮助用户高效管理和优化数据库性能，确保业务稳定运行。