目录
背景
数据库作为连接底层硬件基础设施和业务系统的公共基础软件，是业务系统稳定运行重要的一环，随着国产化推进，国产化数据库开始大规模在生产系统运行。在推广和试用过程中，国产化数据库的稳定性和成熟度与传统关系型数据库有一定差距，尚未充分暴露出产品和使用的不足。混沌工程通过模拟和主动制造数据库运行中的故障和不稳定因素，验证数据库对这些故障的反应和恢复能力，以期提前发现问题和薄弱点，防范于未然，实现降低运行风险和成本的目的。
愿景
架构层面，充分验证架构高可用性，及时发现架构面对基础设施故障的潜在隐患和不足，通过架构优化提升基础设施故障免疫力。
内核层面，暴露内核缺陷，促进原厂及时修复闭环，回归测试构建长稳版本。
运维层面，通过验证告警能力、完善指标体系等方面，提升故障定界应急处置能力，不断优化应急预案，提升运维自动化。
应用层面，探索基于通用国产化硬件基础设施上数据库的性能差异和性能极限，识别真实业务场景下的优势与不足，持续优化开发规范，提升应用与数据库的适配度，指导数据库资源池规划与分配。
国产数据库混沌测试思路
以传统关系型数据库的运维经验和实际运行过程中的数据为基础，以应用程序视角获取数据库可用性数据，结合分析处理后的数据进行可用性数字化，梳理影响数据库健康的薄弱点，进而针对性进行故障注入和混沌工程爆破实验。
以传统关系型数据库的运维经验对影响数据库可用性的问题根因做初步分类，一二级维度根因按类别类型划分如下：
- 基础设施因素
- 服务器硬件
- 操作系统
- 存储资源
- 网络资源
- 网络安全
- 应用程序因素
- 发布过程
- 程序缺陷
- 性能极限
- SQL性能效率
- 应用其他原因
- 数据库计划内变更
- 运维变更
- 切换演练
- 数据库计划外异常
- 数据库运维误操作
- 数据库运维管理
- 数据库软件缺陷
- 数据库计划外其他原因
实际运维过程中影响数据库可用性运营数据统计（保密因素暂不公开具体数值）：
一级维度根因统计
| 一级维度根因 | 频次占比 | 损失时间占比 |
|---|---|---|
| 基础设施因素 | xx% | xx% |
| 数据库计划内变更 | xx% | xx% |
| 应用程序因素 | xx% | xx% |
| 数据库计划外因素 | xx% | xx% |
二级维度根因统计
| 一级维度根因 | 二级维度根因 | 频次占比 | 损失时间占比 |
|---|---|---|---|
| 基础设施因素 | 存储资源 服务器硬件 网络资源 |
xx% xx% xx% |
xx% xx% xx% |
| 数据库计划内变更 | 运维变更 | xx% | xx% |
| 数据库计划外 | 根因无法确认 数据库计划外其他原因 数据库软件缺陷 |
xx% xx% xx% |
xx% xx% xx% |
| 应用程序因素 | SQL性能效率 程序缺陷 发布过程 性能极限 |
xx% xx% xx% xx% |
xx% xx% xx% xx% |
从可用性运营数据可以看到，基础设施因素、数据库计划内变更、应用程序因素占比较高。基础设施因素出现的频次占比是最高的，这就需要数据库架构的优化来保障基础设施故障的免疫，提升整体可用性；数据库变更和应用程序因素对损失时间占比最高，对可用性影响最大。
-
数据库作为连接底层硬件基础设施和业务系统的公共基础软件，是业务系统有状态数据持久化的关键一环，对可用性要求高，在底层基础设施故障的情况下，必须通过软件能力实现快速业务恢复。
-
应用程序因素主要是SQL性能效率问题比较多，应用发布过程也比较容易导致问题。
-
数据库计划内变更导致的可用性损失比较多，这就需要通过验证告警能力、完善指标体系等方面，提升故障定界应急处置能力，不断优化应急预案，提升运维自动化。
国产数据库混沌测试实践
三级维度根因为具体根因类别，分类较细，我们据此为基础设计数据库混沌测试场景。
一、基础设施故障模拟
基础设施因素对数据库可用性影响的频次最高，我们通过模拟基础设施故障验证国产数据库分布式架构对基础设施故障的“免疫力”，进而对薄弱环节通过故障自愈脚本、基础设施故障三板斧等自动化能力建设来降低基础设施故障对数据库可用性的影响。
基础设施故障模拟从四个方面展开混沌测试：服务器硬件故障、操作系统故障、网络故障、外部存储故障。
| 故障分类 | 故障类型 |
|---|---|
| 服务器硬件故障 | 服务器掉电 单颗CPU故障 内存故障 磁盘坏 磁盘坏块 |
| 操作系统故障 | 主机reboot CPU打满 存储空间满 IO打满 OS时钟跳变 时区调整 |
| 网络故障（网络亚健康多增加几档测试） | 单网卡异常 bound 网卡故障 AZ级网络中断 单网卡网络断连 bound两个网卡网络断连 网络丢包 网络时延 网络抖动 网络打满 |
| 外部存储故障 | NAS存储无法读写 NAS存储丢失 |
二、数据库故障模拟
数据库故障模拟主要用于验证国产数据库分布式架构本身的高可用性，提前暴露内核缺陷，促进原厂及时修复闭环，验证告警能力，补充丰富告警指标体系。
数据库故障模拟从八个方面展开混沌测试：关键进程异常、关键线程异常、数据库破坏性测试、数据库连接、空间容量、性能极限、DB亚健康测试、管理组件专项测试。
三、运维操作测试
数据库计划内变更导致的可用性损失时间比较多，我们重点验证常用的日常运维操作，验证并补齐相关操作的自动化能力，不断优化应急预案，提升故障定界应急处置能力。
运维操作测试主要聚焦常用的六个方面的操作：数据库重启、节点切换（switchover、failover）、数据库参数修改(静态参数、动态参数)、杀会话、大事务回滚、数据库备份。
四、性能测试
实际生产运行中，SQL性能问题对数据库的可用性影响极大，重点验证极限性能场景的数据库表现，以及相关的告警指标体系是否准确全面。通过极限场景提前识别国产服务器底座基础上的国产数据库性能“天花板”，指导后续的数据库资源规划。
性能测试从四大方面开展：DML（亿级分区表插入、亿级分区表查询、不同分区插入和查询并行、多事务处理、高并发查询、大字段宽表操作、大批量业务）、DML&DDL（当前分区的DDL操作对其他分区DML、在线重建索引对查询影响、在线重建索引对表DML影响、主库做离线DDL操作，对读库的影响、主库做在线DDL操作测试，对读库的影响）、内存资源打爆（打爆共享池、打爆数据缓存）、工具组件测试（大数据量导入导出）。
五、生产故障模拟
生产故障模拟主要目的是对历史故障进行回归测试，确保已知故障已完成缺陷修复或是有相应的自动化处置手段。
生产故障模拟常见的七个场景：绑定变量过多、删除语句的执行计划、JDBC驱动连接操作LOB字段、JDBC连接高TPS插入、UNION ALL 多个表、大量数据变化统计信息未及时更新、索引二义性选择场景。
六、关键特性测试
关键特性测试主要聚焦国产数据库的亮点特性，通过测试结果来评估引入及使用相关特性的可行性。
关键特性测试主要进行优化器特性测试，包括：慢SQL诊断、索引推荐、趋势预测、SQL限流、SQL执行计划向好演进等。
结束语
数据库向上支撑应用，向下连接硬件基础设施。作为中间环节，数据库的可用性对业务连续性影响极大。数据库可用性损失不可避免，但可以通过合理的措施降低发生的概率及影响，包括架构优化、自愈能力建设、故障应急预案制定及自动化建设等，均可以提升数据库的可用性。混沌工程测试通过尽可能多的制造故障场景，通过反复爆破和迭代，建立起稳定、高效、可控的故障免疫力和快速恢复能力。国产化数据库混沌工程的开展将持续驱动国产化数据库不断优化，为业务连续性建设提供强有力的保障，推动国产化转型。
