副本损坏 / 需要重新同步
副本/备库与主库之间的同步已中断。确定复制是否已停止、落后多少，以及位点/GTID 链是否断裂；然后在跳过错误、等待或重建（reseed）中选择正确的路径。包含脑裂警告。
复制的总体状态如何？
先读取复制健康状况：应用线程是否在运行，延迟有多大，是否有错误？同时确认两个节点没有都在接受写入（脑裂）。
SHOW REPLICA STATUS\G
-- Check: Replica_IO_Running, Replica_SQL_Running, Seconds_Behind_Source, Last_Error, Retrieved/Executed_Gtid_Set- 复制已停止 / 正在失败
- 正在运行但落后很多（延迟大）
- GTID/位点断裂、不一致 — 重建
- 两个节点都作为主库在写入（疑似脑裂）
错误能修复，还是需要重建？
检查应用错误。有些错误（重复键、缺失行）可以通过安全地跳过单个事件来解决；但如果存在数据不一致/损坏，唯一正确的路径是重建副本。
SHOW REPLICA STATUS\G
-- Check: Last_SQL_Errno, Last_SQL_Error, Last_IO_Errno, Last_IO_Error- 单个/少量应用错误（可跳过）
- 无法修复的不一致 / 损坏
延迟是暂时的还是持续的？
观察延迟随时间的趋势。它是在暂时的负载峰值之后逐渐缩小（追上），还是持续增长，导致副本永远追不上主库？
SHOW REPLICA STATUS\G
-- Measure Seconds_Behind_Source several times: is it decreasing or increasing?- 暂时的负载峰值；延迟正在缩小
- 持续增长；无法追上
解决方案：谨慎跳过应用错误
如果复制因单个应用错误（例如重复键）而停止，并且你确定数据确实一致，可以跳过该事件并继续复制流。这是最后手段；盲目跳过会造成静默的数据漂移。
解决方案：重建副本（reseed / rebuild）
如果位点/GTID 链断裂、数据已经漂移或存在无法修复的错误，唯一可靠的路径是用从主库获取的全新副本重建副本。
根本原因：暂时的负载峰值（延迟正在缩小）
复制是健康的；由于主库上暂时的写入突增或网络波动，出现了延迟，但副本正在追赶。
根本原因：副本跟不上主库
应用（apply/redo）端跟不上主库产生变更的速率；延迟持续增长。通常是单线程应用、副本硬件较慢或网络瓶颈所致。
警告：脑裂（两个主库）— 有数据丢失风险
如果两个节点都以主库角色接受写入，冲突的变更会在两侧累积；这是最危险的情况，可能导致数据丢失。首要任务是将写入收敛到单个节点。