云计算之数据库

一、RDS产品介绍及排障思路

1.1 云RDS数据库及其特点

1.2 云RDS数据库-规格

1.3 云RDS数据库-存储

1.4 云RDS数据库-安全

1.5 云RDS数据库-整体架构

1.6 RDS常见问题排查

1.6.1 如何解决无法链接RDS实例的问题

1.6.2 RDS实例存储空间使用率高，怎么排查

1.6.3 RDS Mysql主从延迟问题

二、Redis产品介绍及排障思路

2.1 Redis介绍

2.2 产品架构

2.3 性能指标与监控

2.4 备份与恢复

2.5 Redis实例CPU使用率高的问题

2.6 排查Redis实例内存使用率高的问题

2.7 Redis常见问题

三、PolarDB产品介绍及排障思路

3.1 PolarDB介绍

3.2 PolarDB连接信息和方式

3.3 产品架构-PolarDB MySQL企业版

3.4 产品架构-PolarDB MySQL标准版

3.5 集群白名单&账号管理

3.6 诊断与优化

3.7 PolarDB MySQL版CPU使用率高问题

3.8 空间问题

3.8.1 集群的存储空间占用突然升高，如何进行排查？

3.8.2 为什么新创建的数据库中没有任何数据，就已经产生了磁盘使用量？

3.8.3 为什么从其他异构数据库导入数据时会占用更多的存储空间？

3.8.4 集群的存储空间是否包含备份空间？

3.8.5 InnoDB引擎中使用DROP命令删除索引后，是否会释放磁盘空间？

3.9 PolarDB死锁

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实例的问题

传送门：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。
在基本信息页面的数据库分布式存储区域，查看数据库存储用量
在左侧导航栏，单击诊断与优化>一键诊断，在空间概况页面的空间变化趋势区域，查看是因为哪个空间使用量升高导致存储空间升高。

传送门：阿里云登录 - 欢迎登录阿里云，安全稳定的云计算服务平台欢迎登录阿里云，全球领先的云计算及人工智能科技公司，阿里云为200多个国家和地区的企业、开发者和政府机构提供云计算基础服务及解决方案。阿里云云计算、安全、大数据、人工智能、企业应用、物联网等云计算服务。https://polardb.console.aliyun.com/overview

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结合了传统数据库的稳定性和云数据库的弹性，支持多种数据库引擎，特别适合大规模数据处理和企业级应用。这三者均提供了详尽的监控和排障指南，帮助用户高效管理和优化数据库性能，确保业务稳定运行。