提问：作为DBA运维的你是否遇到过这些烦恼
1、容灾复制的数据同步链路突然中断，出现监控告警信息？
2、主备数据突然出现分歧，导致复制SQL线程异常停止？
心中有章，遇事不慌
作为DBA的你，遇到问题无从下手，除了在问题面前徘徊，还能如何选择？如果你一次或多次遇到该问题还是无法解决，又很懊恼，该如何排忧呢？关注公众号，关注《包拯断案》专栏，让小编为你排忧解难~
一整套故障排错及应对策略送给你，让你像包拯一样断案如神：
遇到此类问题后，我们要做到心中有章（章程），遇事不慌。一定要冷静，仔细了解故障现象（与研发/用户仔细沟通其反馈的问题，了解故障现象、操作流程、数据库架构等信息）
我们要根据故障现象进行初步分析。心中要想：什么情况下，会导致容灾数据同步出现中断？例如：是遇到了主键冲突，还是备库缺失了关键数据？又或是触发了某个隐藏的问题？
针对上述思考，我们需要逐步验证并排除，确定问题排查方向。
确定了问题方向，进行具体分析。通过现象得出部分结论，通过部分结论继续排查并论证。
针对问题有了具体分析后，再进行线下复现，最终梳理故障报告。
真刀实战，我们能赢
说了这么多理论，想必实战更让你心动。那我们就拿一个真实案例进行分析——某运营商客户的开发测试环境，在进行容灾数据同步时，突然出现中断，现场DBA立即登录环境检查复制链路，查看报错信息进行分析。
故障排查分析
1.1初步定位：表字段类型差异
现象：事务回放失败，报错提示-不能执行 int 到 varchar 类型的转换
初步判断：通常此报错源于主备表结构不一致（如字段数量、类型、默认值等）
1.2深入排查：发现表结构差异
对比表结构：立即对比主备集群中的故障表结构，发现主集群比备集群多一个新增列。
确认变更：与业务方核实，确认在该表上执行过ALTER TABLE ... ADD COLUMN ... AFTER ...的DDL操作，主集群的task任务表也记录了此次操作。
关键疑问：为何DDL操作没有同步到容灾集群？
1.3根因分析：复制过滤规则的“坑”
解析Binlog：
解析主集群binlog，可见完整的ALTER TABLE DDL语句；
解析备集群binlog，发现该DDL事务被替换为空事务（BEGIN; COMMIT;），导致DDL未实际执行；
调查配置：检查复制链路配置，发现使用了 replicate_ignore_db = db_ignore 参数，旨在忽略特定的运维或测试库；
本地复现：搭建测试环境，完美复现了该问题：
场景还原：业务方在执行ALTER TABLE时，连接的是被忽略的运维库(db_ignore)，而非业务库(business_db)，执行的语句为：
-- 当前默认数据库为被忽略的db_ignoreUSE db_ignore;-- 操作了需要同步的业务表ALTER TABLE business_db.target_table ADD COLUMN new_column INT AFTER xx_column;
复制机制：MySQL的复制过滤规则（包括replicate_do_db和replicate_ignore_db）是基于当前默认数据库（USE database;）而非语句所操作的数据库，此过滤的精确效果取决于是正在使用基于语句还是基于行的复制。
基于语句的复制（SBR）：如果配置 replicate_ignore_db=test ，即不复制那些当前默认数据库（即USE test）是 test 的 SQL 语句，它的判断只依赖于 USE 语句选择的默认数据库，而不是语句实际操作表所在的数据库。
基于行的复制（RBR）：如果配置 replicate_ignore_db=test ，即不复制任何对数据库 test 表中的更新，其判断基于行数据实际所在的数据库，与 USE 选择的默认数据库完全无关，行为更加精确且符合预期。但对于 DDL 语句的处理，即使在 RBR 模式下，也通常会使用基于语句的格式来复制。
故障原因：复制线程发现，当前默认数据库db_ignore位于replicate_ignore_db的忽略列表中，因此过滤（忽略）了整个DDL语句，将其替换为空事务。尽管语句实际修改的是需要同步的business_db.target_table，但依然被错误丢弃。
故障解决方案
2.1 应急恢复
手动同步DDL：立即登录容灾备库，手动执行被过滤的ALTER TABLE ... ADD COLUMN ... AFTER ...语句，确保主备表结构一致；
恢复复制：重启复制链路（或跳过错误），观察同步是否恢复正常，监控延迟直至为零。
2.2 彻底修复
彻底替换复制过滤方案：
立即行动：将数据库级过滤规则（replicate_do_db/replicate_ignore_db）替换为基于表名的过滤规则replicate_wild_ignore_table。
新配置示例：
replicate_wild_ignore_table = db_ignore.%replicate_wild_ignore_table = other_ignore_db.%
优势：replicate_wild_ignore_table基于表名进行过滤，无论DDL在哪个库执行，只要基于表名匹配规则就会被过滤或不过滤。例如，以上配置会忽略db_ignore库下的所有表，但不会影响对business_db.target_table的操作，从根本上避免了跨库DDL被误过滤的问题。
复盘总结与改进措施
1.根本原因
使用基于数据库名的过滤规则(replicate_ignore_db)，在跨库执行DDL时（USE db_ignore），因默认数据库在忽略列表内，导致整个ALTER TABLE ADD COLUMN 被错误过滤，从而使主备表结构不一致，同步此表相关的DML时报错。
2. 改进措施
使用replicate_wild_ignore_table代替replicate_ignore_db ，将此经典案例进行整理并分享，避免其他人再遇到此类问题。
