如何保障数据库的稳定性

介绍稳定性指标RTO与RPO

首先讲起稳定性都会提到两个指标RTO与RPO：

• RTO：恢复所需的时间指标。是反映业务恢复及时性的指标。表示业务从中断到恢复正常所需的时间。RTO值越小，代表容灾系统的数据恢复能力越强。各种容灾解决方案的RTO有较大差别
• RPO：能够恢复到的最新状态。反映恢复数据完整性的指标，在同步数据复制方式下，RPO等于数据传输时延的时间;在异步数据复制方式下，RPO基本为异步传输数据排队的时间。

更详细的内容可参考文章：https://www.yisu.com/zixun/36388.html

数据库的稳定性涉及到产品需求设计、数据库架构设计、客户人员能力、测试的测试维度等，因此数据库的稳定性不仅仅是由测试人员通过测试手段来保障，这也是测试人员无法做到的部分。我们把保障数据库的稳定性分为几个阶段，详见如下：

部署前
1、部署前：要开展对研发技术相关人员的培训，避免人为因素导致的数据库运行不稳定；
2、技术架构：高可用、容灾遇难(两地三中心)；
3、充分的压力测试：挑选核心的业务功能，通过一定的业务压力，让系统能够持续的运行一段时间，检测系统是否可以稳定运行；
4、充分测试：(1)做数据库的可用性测试。(2)版本上线前可以试用行新版本一定的周期，如：2个月，观察情况。

5、会议沟通：明确版本部署的服务器配置及配置参数的要求，因不同的公司根据自己的场景会有不同的参数配置要求。可以已开会的方式沟通并同步给大家

运行中
1、完善不同纬度的数据库指标监控，包括：存储层、网络层、服务器指标、top的sql优化和监控，如果有条件的话，需要进行常态化的性能监控及优化
2、制定特殊场景下的应急预案

RPO的解决
1、及时进行数据备份，并及时验证数据备份恢复后的数据可用性。
2、同城异地、备份机制、可用性的测试等来确保

如何实现数据持续稳定的运行？
大促场景，流量上升场景中数据库在性能提升上可以做哪些事情？
1、增加硬件资源，但有时发现增加硬件资源在性能提升上有限，此时涉及到了人员能力。
2、人员能力的提升，例如：一条sql的优化。写法不一样对性能的影响也不一样。
3、要做到能找到问题的根因
4、根据历史数据及特殊场景，提前预估业务量做压力测试，找到系统的性能瓶颈。如：内存不足、CPU不足、还是存储性能不好、还是SQL写的不好、还是写的sql数据库没有用好。