数据库和缓存稳定性保障-扩容及升级规范

背景

数据库和缓存是系统的核心组件，保障其稳定性是确保整个系统稳定运行的基础。通过制定本规范以便在在数据库及缓存相关指标及资源达到一定阈值时，参考本规范提前进行硬件升配、扩容或数据库及缓存升级，帮助减少故障和数据损坏的可能性，增加系统的可靠性和可用性。本规范分别对数据库及缓存硬件扩容、软件升级的前置条件进行说明并期望后续按照此规范进行优化、硬件扩容及软件升级，保障升级操作规范、升级过程平稳。

数据库软、硬件扩容及升级规范

2.1 磁盘空间扩容

在磁盘使用率接近70%到80%时就开始考虑扩容磁盘空间。这是因为当磁盘使用率接近满时，系统的性能可能会开始下降，并且可能出现磁盘空间不足的情况，导致数据库无法正常登录及写入数据，甚至可能导致数据库崩溃。

因此在数据库服务器磁盘使用率接近70%~80%时采取以下措施：

归档及清理数据：定期清理不再需要的数据，如日志、历史数据等，以释放磁盘空间。
压缩及优化表数据：对于适合压缩的数据类型，可以考虑使用数据库内置的压缩功能，节省磁盘空间。
分区管理：将数据库表按照数据的逻辑关系进行分区（分表分库等）管理，这样可以将数据均匀分布在不同的磁盘或数据库实例上，解决数据库磁盘不足问题并提升数据库读写效率。
扩展磁盘容量：如果因业务需要，数据不能通过归档等方式处理，则需要增加现有磁盘的容量或者添加新的磁盘处理。

如需在当前机器上进行扩容，则可按照如下步骤执行：

1）临时修改数据库防火墙指向，便于相关人员查询线上数据

2）通知大数据相关人员注意数据同步任务，如有业务访问从库，则需提前调整连接至主节点

3）关闭从节点数据库，并关闭服务器

4）扩容服务器磁盘，完毕后开机并检查是否运行正常

5）按需修改数据库配置，以适配扩容后的磁盘性能及目录

6）启动数据库、开启主从数据同步并检查数据库运行情况

7）运行正常后，切换数据库防火墙指向，并指向当前从节点

8）观察数据库运行情况及数据同步情况并测试相关慢SQL在从节点运行情况，建议观察3天以上

9）从库正常运行一段时间后（3天以上），通知应用准备切换至已升配的从节点

10）进行主从切换，将升配后从节点切换为新主节点，原主节点切换为新主节点的从节点

11）数据库切换后观察应用运行的情况，如应用持续连不上数据库，则需要重启应用

12）观察数据库切换后应用及数据库运行情况，建议观察3天以上，如有性能问题则切换回原节点

13）如主库运行正常，关闭原主库（现从库）数据库并关闭数据库

14）原主库数据库扩容磁盘，完毕后开机并检查是否运行正常

15）按需修改数据库配置，以适配扩容后的磁盘性能及目录

16）启动数据库、开启主从数据同步并检查数据库运行情况

17）运行正常后，切换数据库防火墙指向，并指向当前从节点

18）通知大数据修改数据同步任务至新从节点，并观察任务运行情况。如有业务访问从库，则调整连接至新从节点

2.2 磁盘IO升级

数据库为IO密集型操作的软件，因此当磁盘IO负载高时，将会引起数据库读写性能极速下降，进而影响业务操作。

通常频繁出现以下现象时需升级磁盘：

磁盘IO负载高：当磁盘IO频繁出现高于70%到80%以上，表示磁盘的读写速度已经达到极限
慢查询增多：高磁盘IO负载可能导致查询速度变慢，频繁出现慢查询，而走索引且扫描数据量较小的查询也频繁出现变慢的情况
写入延迟：如果写入操作的延迟很高，可能是磁盘写入速度跟不上数据库写入需求，此时需要考虑升级磁盘
性能优化无效：如果在经过性能优化后，IO负载仍然很高，可能是IO已达到瓶颈，需要考虑升级

升级磁盘IO步骤及措施：

调研需升配的磁盘：数据库服务器磁盘IO升配建议升级为SSD盘，并根据不同的业务及现状进行评估升级至对应的磁盘，对磁盘进行型号及成本调研
磁盘测试：选择对应型号的磁盘后，需对磁盘进行基准测试、压力测试及业务测试，以确保升级后的磁盘能解决现存问题
升级从库磁盘：先升级从库服务器磁盘，并调整相关数据库参数，并进行测试
进行主从数据库切换：将升级后的从库切换为主库，相关应用也切换至新主节点进行操作
升级原主库磁盘：将原主库服务器的磁盘进行升级，完成后作为新主库的从节点运行

详细的步骤参考磁盘扩容步骤。

2.3 CPU升级

部分业务场景需要从数据库获取基础数据后再进行计算等场景进而获取需要的结果，另外，在数据分布不均匀而无法使用索引等情况下，CPU资源消耗高，随着业务不断发展，如果出现以下情况时，需要考虑升级CPU：

持续CPU使用率高：如果CPU负载持续高于70%到80%以上，可能表示 CPU计算能力已经达到瓶颈，需要考虑升级CPU或增加CPU核心数。
响应时间延长：当CPU资源不足时，可能导致数据库查询和事务处理时间延长，影响系统的响应速度。
并发连接数增加：随着并发连接数的增加，CPU的负载也会相应增加。当连接数达到MySQL的最大连接数配置时，可能需要升级CPU。
性能优化无效：如果在经过性能优化后，CPU利用率仍然很高，可能是CPU性能不足，需要考虑升级。

因升级物理机CPU需要通过替换服务器的方式进行，主要替换步骤如下：

调研新服务器：重点关注CPU主频及核心数等
性能测试：借调或采购服务器，并进行基准测试、性能测试及结合业务慢SQL的测试
升级从库：如新服务器满足性能需求，则添加2台服务器作为从节点加入集群中
主从切换：进行数据库主从切换，将主库切换至其中的1个新加入的节点上，其余节点作为其从节点，同时相关应用也切换至新主库
下线原先主从节点：将原先不满足性能需求的服务器下线回收，以备其他业务使用

2.4 内存扩容

内存在数据库中扮演着关键的角色，对于提升数据库性能、保障数据完整性、提高并发处理能力等方面都至关重要。另外业务对于数据库的连接、读写数据等均需要消耗数据库服务器内存，而当数据库或业务出现如下现象时，需要考虑扩容内存：

性能下降：如果数据库查询响应时间明显增加，业务处理速度变慢，慢SQL增加明显等，可能是因为数据库内存不足，导致频繁的磁盘读写操作
内存使用高：数据库服务器的内存使用率持续高于90%以上，尤其是在高峰时段，可能意味着内存资源不足，需要扩容
缓存失效频繁：如果数据库中使用了缓存，但缓存命中率下降，缓存失效频繁，可能是因为内存不足，无法维持有效的缓存
长时间的锁等待：如果数据库中存在大量的锁等待，可能是由于内存不足导致的，数据库无法高效地处理并发请求
频繁使用SWAP：当数据库服务器开始频繁进行内存和磁盘之间的交换操作（Swap），性能会显著下降，这通常是内存不足的标志
应用程序崩溃或错误：如果应用程序频繁崩溃、出现错误或无法连接到数据库，可能是因为数据库内存不足，无法为应用程序提供足够的资源
数据库内存不足宕机：当数据库出现内存不足而宕机时，如果通过优化手段处理后依旧出现或不满足业务需求，则需要对内存进行扩容

扩容数据库服务器内存主要步骤如下：

调研需升配的内存：选择适配当前数据库服务器内存或机型的内存
扩容从库内存：先扩容从库服务器磁盘，并调整相关数据库参数，并进行测试
进行主从数据库切换：将升级后的从库切换为主库，相关应用也切换至新主节点进行操作
升级原主库内存：将原主库服务器的内存进行升级，完成后作为新主库的从节点运行

详细操作步骤可以参考磁盘空间扩容步骤

2.5 数据库软件升级

当数据库在使用过程中出现如下情况时，需要考虑升级数据库版本：

安全性：新版本数据库通常会修复已知的漏洞和安全问题，提供更高的安全性保障。如果当前版本存在安全隐患，升级可以增强数据库的安全性
支持与维护：当前版本的数据库即将EOL，不再得到官方支持和维护。升级到较新的版本可以获得更长时间的支持，避免因为安全问题或其他原因造成无法维护的风险
功能需求：当前数据库版本不支持所需的新功能或功能更新，而新版本提供了这些功能。因业务需要，且通过升级库可以更简单地满足业务需求，提供更好的功能支持时,可以考虑升级
性能优化：新版本可能针对性能进行了优化，提供更快的查询速度、更高的并发处理能力等。如果当前版本的性能不能满足业务需求，可以考虑升级以获得性能改进
兼容性：如果计划升级硬件设施，可能需要升级数据库以适应新的硬件环境
业务扩展：随着业务的扩展，数据库的负载可能会增加。升级到新版本可以提供更好的性能和扩展性，以支持业务的发展

升级数据库软件步骤如下：

调研待升级的数据库软件版本、新特性及向下兼容性等，并进行部署、测试
将测试结果进行总结并与研发、测试人员进行分享并制定升级计划
在开发及测试环境部署新版本数据库，并将新建应用及计划内升级的业务数据库库部署在新版本数据库上
开发测试环境测试一个月以上（经过回归测试），如测试正常，则进行预发布及线上环境升级
线上环境先升级从库，调整相关参数，DBA进行压力测试及基础的兼容性测试
从库测试完毕后，数据库进行主从切换，应用连接切换至新主库，原主库作为从节点加入集群，但原主库暂不升级（用于异常回退）
如新主库运行正常2周以上，则进行原主库升级

2.6 数据库架构升级

因数据库版本的迭代及新架构方案的出现，在当前数据库架构出现如下问题时，需要考虑升级数据库架构：

影响数据库稳定性：如正在使用的数据库架构方式存在BUG，导致数据库集群无法正常切换、异常切换、不满足数据库可用性及稳定性要求时，需升级软件版本或替换数据库架构方案
部署及维护成本高：如当前架构方案在部署及维护成本均较高，且存在可以替代的降本增效的架构时，可以考虑替换方案
存在安全隐患：如使用的架构方案不再迭代且存在安全隐患，则建议立即进行替代方案调研并进行架构升级
新版本数据库需要：当新版本数据库投入使用后，原架构方案不适用新版本的数据库时，则需升级至新的架构方案

架构升级步骤：

调研阶段：调研新架构方案的优缺点，并对比当前方案存在哪些优劣势，并进行调研阶段的部署及测试，整理出包含部署要求、部署步骤、常见运维操作手册等方面的调研报告
方案评审：对新架构方案进行内部及公司级评审，评审通过后制定详细的升级步骤
测试阶段：在测试环境部署新架构，并对其进行3个月以上的测试
线上部署：从新建集群入手进行新方案部署，如平稳运行3个月以上再进行其他现有集群的方案升级

缓存软硬件扩容及升级规范

因业务在登录、高并发场景、业务锁等场景对缓存（Redis）依赖性较强，因此当Redis出现性能瓶颈时，需提前对Redis的硬件资源及软件版本进行升级，以保障Redis及业务的平稳运行。

影响Redis性能的主要因素在于内存、CPU及版本，因此本规范将从以下三方面进行说明。

3.1 内存扩容

当Redis出现以下情况时，需对Redis内存进行扩容：

数据量增加：当 Redis 中的数据量逐渐增加，原有的内存容量可能不足以存储所有数据，导致性能下降或无法满足需求。因此建议在内存使用量达到最大内存的 80%时需进行扩容
持久化要求：如果你正在使用 Redis 持久化功能（如RDB快照或AOF日志），随着数据的增长，持久化操作可能需要更多的内存来缓冲写入操作。
新业务需求：在引入新的业务功能或数据处理需求且需要共享相同Redis实例，经评估，新业务的引入将导致内存不足时

注意：
主库通常不做持久化，如确定Redis数据不可丢失时，可开启持久化
新业务的引入建议使用独立的Redis实例进行隔离，如必须共享则考虑共用
在经过性能调优之后均无法满足需求的情况再考虑扩容

扩容步骤：
扩容从节点：停止主从复制、关闭从节点实例，扩容从节点内存
启动主从同步：调整主从数据库参数，将从节点部署为原主节点的从库
主从切换：调整从节点参数，设置为读写模式，并将主从进行切换，将应用连接切换至新主库
升级原主库：停止主从复制、关闭从节点实例，扩容原节点内存
启动主从同步：调整主从数据库参数，将原主库节点部署为新主节点的从库

3.2 CPU 扩容

Redis 在如下场景下需要考虑扩容CPU资源：

CPU核数不足： Redis通常部署为单线程操作，加之主从数据同步及持久化等场景，CPU核心数建议为2，当CPU核数为1时，建议进行扩容
版本需要：因新版本的Redis可以支持多线程，如使用新版本且业务并发量较大时，需考虑扩容CPU核数

扩容步骤：
扩容从节点：停止主从复制、关闭从节点实例，扩容从节点CPU
启动主从同步：调整主从数据库参数，将从节点部署为原主节点的从库
主从切换：调整从节点参数，设置为读写模式，并将主从进行切换，将应用连接切换至新主库
升级原主库：停止主从复制、关闭从节点实例，扩容原节点CPU
启动主从同步：调整主从数据库参数，将原主库节点部署为新主节点的从库

3.3 版本升级

当Redis在使用过程中出现如下情况时，需要考虑升级Redis版本：

安全性：新版本Redis通常会修复已知的漏洞和安全问题，提供更高的安全性保障。如果当前版本存在安全隐患，升级可以增强Redis的安全性
支持与维护：当前版本的Redis即将EOL，不再得到官方支持和维护。升级到较新的版本可以获得更长时间的支持，避免因为安全问题或其他原因造成无法维护的风险
功能需求：当前Redis版本不支持所需的新功能或功能更新，而新版本提供了这些功能。因业务需要，且通过升级版本可以更简单的满足业务需求，提供更好的功能支持时，可以考虑升级
性能优化：新版本可能针对性能进行了优化，提供更快的查询速度、更高的并发处理能力等。如果当前版本的性能不能满足业务需求，可以考虑升级以获得性能改进

升级步骤：

调研待升级的Redis软件版本、新特性及向下兼容性等，并进行部署、测试 • 将测试结果进行总结并与研发、测试人员进行分享并制定升级计划
在开发及测试环境部署新版本Redis，并将新建应用及计划内升级的业务Redis 库部署在新版本Redis上
开发测试环境测试一个月以上（经过回归测试），如测试正常，则进行预发布及线上环境升级
线上环境先升级从库，调整相关参数，DBA进行压力测试及基础的兼容性测试
从库测试完毕后，Redis进行主从切换，应用连接切换至新主库，原主库作为从节点加入集群，但原主库暂不升级（用于异常回退）
如新主库运行正常2周以上，则进行原主库升级

3.4 架构升级

因Redis版本的迭代及新架构方案的出现，在当前Redis架构出现如下问题时，需要考虑升级Redis架构：

影响Redis稳定性：如正在使用的Redis架构方式存在BUG，导致Redis集群无法正常切换、异常切换、不满足Redis可用性及稳定性要求时，需升级软件版本或替换Redis架构方案
部署及维护成本高：如当前架构方案在部署及维护成本均较高，且存在可以替代的降本增效的架构时，可以考虑替换方案
存在安全隐患：如使用的架构方案不再迭代且存在安全隐患，则建议立即进行替代方案调研并进行架构升级
新版本Redis需要：当新版本Redis投入使用后，原架构方案不适用新版本的 Redis 时，则需升级至新的架构方案

架构升级步骤：

调研阶段：调研新架构方案的优缺点，并对比当前方案存在哪些优劣势，并进行调研阶段的部署及测试，整理出包含部署要求、部署步骤、常见运维操作手册等方面的调研报告
方案评审：对新架构方案进行内部及公司级评审，评审通过后制定详细的升级步骤
测试阶段：在测试环境部署新架构，并对其进行3个月以上的测试
线上部署：从新建集群入手进行新方案部署，如平稳运行3个月以上再进行其他现有集群的方案升级