做容灾这件事，有点像买保险——花了钱但希望永远用不上。可一旦真出了事，容灾方案靠不靠谱就是生与死的区别。很多团队的容灾方案写在文档里很好看，切换步骤清晰、RTO标称几分钟，但真正切换的时候各种意外接踵而至：DNS缓存没刷新、连接池没更新、数据同步有延迟、应用配置不一致。这篇文章通过一次真实的容灾切换演练，记录了TeleDB容灾方案从准备到切换到恢复的全过程，用计时器量出来的数据比文档上的数字更有说服力。

容灾架构说明

测试使用的是TeleDB的主从容灾架构，部署在两个天翼云可用区之间。主可用区运行生产集群，备可用区运行容灾集群，两个集群之间通过异步复制保持数据同步。选择异步复制而不是同步复制，主要是考虑到同步复制会引入跨可用区的网络延迟，对写入性能影响较大。异步复制的代价是在故障切换时可能有少量数据丢失，需要在RPO和性能之间做权衡。

容灾集群的规模与生产集群保持一致，包括相同数量的节点和资源配置。这一点很重要，如果容灾集群规格缩水，切换后可能扛不住生产流量。部署完成后，日常通过复制通道持续同步数据，备集群处于只读状态，不直接承载业务流量。

演练前的准备工作

容灾切换演练不是想切就切，需要提前做好充分的准备。准备工作主要包括以下几个方面。

第一是数据同步状态检查。确认主备之间的复制延迟在可接受范围内，没有积压的未同步数据。如果复制延迟较大，切换前需要等待同步追平，否则会丢失更多数据。演练前检查了复制延迟，基本在秒级，状态正常。

第二是切换流程梳理。把整个切换过程拆解成步骤，每个步骤有明确的操作人和验证标准。主要包括：停止应用写入、确认复制追平、切换主备角色、更新应用连接配置、启动应用、验证业务功能。这些步骤写成检查清单，演练时逐项打勾。

第三是回滚预案准备。万一切换后发现问题，需要能够快速回滚到原主集群。回滚方案包括如何将新主集群的数据反向同步回原主集群，以及如何回退应用配置。虽然希望用不上，但必须有。

切换过程实测

演练正式开始。计时从执行切换操作算起。

第一步，停止应用写入。通过调整应用配置，将所有写请求拦截在前端，返回友好提示。这个过程大约花了30秒，主要是等待在途请求处理完毕。

第二步，确认复制追平。检查备集群的复制状态，确认所有事务已同步。由于之前延迟就在秒级，停写后很快就追平了，这一步花了大约15秒。

第三步，切换主备角色。在TeleDB管理工具中执行切换操作，备集群提升为主集群，原主集群降级为备集群。这个操作本身很快，大约10秒完成。但接下来需要做一些后置检查，包括确认新主集群的读写状态正常、复制通道方向已反转等，总共花了约1分钟。

第四步，更新应用连接配置。应用的数据库连接地址需要指向新主集群。这里用了天翼云的内部DNS服务，通过修改DNS记录来切换连接地址。DNS生效需要一定时间，加上应用连接池的旧连接需要自然过期重建，这个过程大约花了2分钟。

第五步，启动应用并验证。逐步放开流量，观察业务功能是否正常。先放了10%的流量做灰度验证，确认无误后逐步放量到100%。这个过程约3分钟。

从开始到业务完全恢复，总耗时约7分钟。这个RTO比预期的15分钟要好不少。如果进一步优化DNS切换和应用重启流程，还有压缩的空间。

数据一致性验证

切换完成后，最重要的事情是验证数据一致性。通过对比切换时间点前后的数据，确认有没有数据丢失或重复。由于使用的是异步复制，理论上在切换时间点可能有极少量未同步的事务。实际检查发现，有两条事务在切换时尚未同步到备集群，这两条事务对应的业务操作需要人工补录。RPO约为3秒，在异步复制容灾方案中属于正常水平。

演练总结

这次演练的结论是：TeleDB的容灾切换方案在实际操作中是可靠的，RTO控制在10分钟以内，RPO在秒级。但有几个经验值得分享。

一是DNS切换是整个流程中最耗时的环节，如果有条件使用更快的连接切换机制（比如通过代理层透明切换），RTO还能进一步缩短。二是应用配置要支持快速切换，不要把数据库地址硬编码在配置文件里，用配置中心或者DNS来做动态切换。三是演练要定期做，很多问题只有真正切一次才能发现，纸上的容灾方案和实际操作之间往往有差距。四是回滚预案要演练，不能只测切换不测回滚，万一切换后新集群出问题，能不能回退到原集群同样重要。