summary
2019 年，Razorpay 的 RDS 实例遭遇底层硬件故障，触发自动故障切换。切换过程中，一个长期存在却被忽视的错误 MySQL 配置（使特定窗口内的写入未能按预期持久化/复制）被暴露出来，导致部分交易数据在故障窗口内丢失或处于不一致状态，金融系统的对账与清算受损。
timeline
RDS 底层硬件告警，系统自动发起 failover；在旧主下线、新主接管的间隙，错误配置使得一部分已确认写入未被正确保留或同步。事后团队通过日志与对账发现缺口，启动数据修复与用户沟通。
root_cause
硬件故障本身是诱因，真正的问题是潜伏的 MySQL 配置错误（如复制/持久化相关参数不当），它在正常时不被察觉，却在 failover 的关键窗口放大为数据丢失。
amplifiers
① 配置错误长期潜伏：常态下不显现，故障切换时才暴露。② 缺乏端到端数据完整性校验：切换后未立即发现缺口。③ 金融场景零容忍：少量丢失也需大规模对账。④ 监控覆盖不足：未对复制滞后/持久化异常做强告警。
mitigation
修复错误配置并重建复制链路；通过离线对账修复受影响交易；对关键表增加数据完整性校验与告警。
lessons
金融系统的数据库配置必须按零数据丢失目标评审；failover 前后强制一致性校验；对复制滞后/持久化异常设硬告警；定期演练故障切换并验证数据完整。
checklist
① 复核并固化 MySQL 持久化/复制参数。② failover 流程增加一致性校验闸门。③ 关键交易表增加对账与告警。④ 定期演练切换并验证无丢失。