每日一句正能量

“不要为明天而烦恼，因为明天自有明天的烦恼。”
我们常常为尚未发生的事预支痛苦。每个时刻有它自己的难题与应对资源。

1. 背景与问题

很多企业已经建设了数据库主备架构，但真正发生故障时，仍然无法回答三个问题：

1. 主库不可用后，需要多久业务才能恢复？
2. 故障期间最多允许丢失多少数据？
3. 切换后如何证明新主库数据可靠？

这些问题分别对应灾备体系中的两个核心指标：RTO（Recovery Time Objective，恢复时间目标）和RPO（Recovery Point Objective，恢复点目标）。

本文以生产级主备数据库环境为背景，通过一次完整演练验证主库故障、备库提升、应用切换、数据校验全过程，记录每个阶段耗时和数据差异，形成可重复执行的灾备演练方法。

2. 环境与数据

测试环境：

• 主库：生产写节点
• 备库：同步复制节点
• 应用层：连接池访问数据库
• 业务模型：订单交易系统

核心测试表：

CREATETABLEorders(order_idbigintprimarykey,user_idbigint,amountnumeric(12,2),statusvarchar(20),create_timetimestamp);

为了模拟真实业务，演练过程中持续产生订单写入：

INSERTINTOorders(order_id,user_id,amount,status,create_time)VALUES(100001,20001,99.50,'PAID',now());

3. 复现过程

3.1 故障注入

演练不能只验证正常切换，还需要模拟真实故障：

• 数据库进程异常退出
• 网络隔离
• 磁盘空间不足
• 主节点无法提供写服务

记录故障开始时间：

T0 = 主库停止提供服务时间

随后观察：

• 备库是否持续接收日志
• 回放延迟是多少
• 是否满足提升条件

3.2 RPO计算

RPO不是理论数字，需要通过数据验证。

计算方法：

RPO = 主库最后提交事务时间 - 备库可恢复时间点

例如：

• 最后成功提交订单：10:00:00.850
• 备库恢复点：10:00:00.500

则：

RPO = 350ms

需要进一步通过业务流水表确认是否存在缺失订单。

4. 方案实施

4.1 主备切换流程

标准流程：

1. 停止故障节点流量
2. 确认备库同步状态
3. 提升备库为新主库
4. 更新应用连接地址
5. 执行业务健康检查
6. 恢复写入

切换过程中必须记录时间：

RTO：

RTO = T4 - T1

4.2 数据一致性验证

切换后执行：

SELECTcount(*)FROMordersWHEREcreate_time>=:failure_time;

同时检查：

• 最大订单号
• 最新时间戳
• 金额汇总
• 状态分布

避免只检查数据库可连接，而忽略业务数据完整性。

5. 结果对比

一次完整演练建议输出：

重点不是追求一次演练结果，而是建立持续优化闭环。

6. 风险与复盘

风险一：旧主未隔离

最危险的问题是双主。

必须保证：

• 网络隔离旧主
• 禁止旧节点重新写入
• 清理旧连接池

风险二：应用没有自动恢复

数据库切换完成不代表业务恢复。

需要验证：

• 连接池重连
• 服务健康检查
• 超时参数
• 重试策略

风险三：RPO统计不准确

不能只看复制延迟，需要结合业务流水。

建议建立：

• 订单流水表
• 消息表
• 对账任务

演练检查清单

• 主备状态正常
• 复制延迟监控正常
• 故障注入脚本准备完成
• 应用切换方案确认
• 数据校验完成
• RTO记录完成
• RPO记录完成
• 回切方案验证完成

总结

主备架构真正的价值，不是“有一个备用节点”，而是面对故障时能够稳定恢复。

一次合格的灾备演练，需要同时回答：

• 能不能切？
• 多久恢复？
• 丢多少数据？
• 数据是否可信？

只有通过持续演练、指标记录和问题复盘，数据库高可用体系才能真正达到生产要求。

转载自：https://blog.csdn.net/u014727709/article/details/163270844
欢迎 👍点赞✍评论⭐收藏，欢迎指正