故障切换和演练切换

故障切换和演练切换

核心区别在于触发原因和目的不同：故障切换是因真实故障（如宕机）而被迫启动的应急响应，以恢复业务为首要目标；而演练切换是为验证容灾能力而主动发起的计划性测试，以发现问题和锻炼团队为目的。

核心区别整理成了下面的表格：

维度	故障切换	演练切换
触发场景	被动应急。由真实的硬件故障、网络中断、进程异常等意外事件触发。	主动计划。由DBA或运维人员根据计划，通过管理平台或命令行手动触发。
核心目标	快速恢复业务。目标是最小化停机时间（RTO） 和避免数据丢失（RPO=0），确保业务连续性。	验证与演练。目标是验证灾备机制的有效性、RTO/RPO达标情况、以及团队的应急熟练度。
操作主体	系统自动执行。管理节点（如CM）检测到故障后，根据预设策略（如一致性优先）自动完成切换。	人工控制。DBA通过Insight运维平台或dbtool等命令行工具，指定目标节点（如同城/异地机房）执行切换。
执行流程	严格的保一致流程。系统会经历停服、设只读、选新主等标准步骤，确保数据不丢失。例如，会优先在同机房内选择数据最新的备机升主。	可控的验证流程。可模拟各类故障（如断网），构建“孤岛”数据库系统。演练后可按预案进行回切，将角色恢复原状。
数据一致性	严格要求（RPO=0）。通过“快同步”机制和严格的选主策略（如同城优先），确保故障后数据零丢失。	可配置延迟。在灾备集群演练时，甚至可以配置数据同步的延迟时间，用于模拟和演练“误操作”后的数据恢复场景。

RPO 和 RTO 是衡量一个系统在遇到故障时，其容灾能力和恢复能力的两个核心指标。简单来说，它们回答了“故障后数据会丢多少”和“需要多久才能恢复”这两个关键问题。

结合你之前问的GoldenDB切换场景，这两个指标也是检验故障切换和演练切换效果的关键标准。

1. RPO（Recovery Point Objective，恢复点目标）

• 通俗解释：你能容忍丢失多长时间的数据？
• 核心关注点：数据丢失量。
• 比喻理解：想象你每晚12点都会给重要文件做一次备份。如果下午4点硬盘突然坏了，那么从昨晚12点到今天下午4点这16个小时内修改或新增的文件就全丢了。在这个场景下，你的RPO就是 24小时。
• 在GoldenDB中：对于金融级的应用，通常要求 RPO=0，这意味着数据零丢失。这也是GoldenDB“故障切换”场景中最优先保证的一点——即使发生故障，通过“快同步”机制，确保主库提交成功的事务已经同步到了备库，不会丢失任何一笔交易数据。

2. RTO（Recovery Time Objective，恢复时间目标）

• 通俗解释：你需要花多长时间才能把业务恢复过来？
• 核心关注点：停机时长。
• 比喻理解：接上面的例子，硬盘坏了之后，你从货架上拿来新的硬盘，找到昨晚12点的备份文件，并把数据全部恢复进去，直到业务可以重新访问，这个过程花了2个小时。那么你的RTO就是 2小时。
• 在GoldenDB中：这衡量的是从故障发生（比如数据库主节点宕机），到系统自动切换完成、备用节点升级为主节点并提供服务的这段时间。GoldenDB的故障切换流程会尽力将RTO缩短到秒级，以最小化业务中断的影响。

总结一下两者的区别：

• RPO 是问你数据能丢多少（丢失的量）。

• RTO 是问你多久能恢复（恢复的速度）。

• 故障切换：目标是严格按照设计指标来执行，即追求 RPO=0（数据不丢），同时尽可能缩短 RTO（快速恢复）。

• 演练切换：目的就是验证在实际操作中，系统是否真的能达到预设的 RPO=0 和 RTO≤XX秒 的目标，确保理论指标在实战中同样有效。