Failover之后，原主库要重新加入集群需要付出全量数据同步的代价

Failover发生（Master意外故障、Slave被promote成新Master）之后，如果Master故障时确实存在还没来得及复制给Slave的数据，会出现一个棘手的后果：假设原Master的最后一个事务号是1001，但Slave只同步到了999号事务，这时Slave promote成新Master后，所有后续的新操作都是以999号事务的结果为基础继续往下推进的——这意味着原Master里1000号和1001号事务处理过的数据，永远都不可能被恢复了（因为已经提交的事务在数据库里不支持直接回退）。更麻烦的是，如果之后想把这台原Master重新恢复、以Slave身份加入到这个新的主备结构里，它没有办法通过增量复制的方式简单地”补上”缺失的1000、1001号事务再继续同步，因为它自己的事务历史（走到1001号）已经和新Master的事务历史（从999号之后走了一条完全不同的路径）产生了分歧——常规增量复制的前提是双方共享同一段连续的事务历史，一旦这个前提被打破，唯一的解决办法就是把这台机器当作一台全新的节点，对它执行一次完整的全量数据重新初始化，如果数据库达到TB级别，这个全量恢复过程可能需要六七个小时。这个案例揭示了一条关于分布式系统”脑裂”或”分叉”场景的重要认知：一旦两个原本共享同一段历史的副本，因为故障切换而各自走上了不同的后续演进路径（一个停在999号事务、另一个继续推进到新的事务序列），要重新让它们”合流”，几乎不可能通过简单的增量对齐来实现，因为增量同步的本质依赖双方在某个共同的历史节点上完全一致，一旦这个共同历史节点之后双方的内容已经分道扬镳，唯一可靠的合流方式就是舍弃其中一方已经产生分歧的那部分历史，让它完全对齐到另一方最新的状态——这个代价（全量重建）往往远高于增量同步，是设计和评估任何主备切换机制时必须提前纳入考量的隐性成本。