Blackhole表能作复制中继因其“吃数据但吐binlog”：INSERT被解析提交并写入binlog，但跳过磁盘写入；需主库binlog_format=STATEMENT，中继节点启用log-bin、server-id，下游指向该节点。
Blackhole表为什么能当复制中继用
因为它的核心行为是“吃掉数据但吐出binlog”——所有 INSERT 语句都会被正常解析、事务提交成功、返回影响行数，但底层跳过任何磁盘写入；只要主库启用了 log-bin，这些语句就照常写进二进制日志，下游从库就能拉到并执行。
关键点在于：它不存数据，却完整参与复制链路。这让你能在中间节点做“逻辑过滤”，比如只让特定库/表的变更继续往下传，而其他流量在这一层就被“静默丢弃”。
- 必须确保主库的
binlog_format设为STATEMENT——ROW或MIXED下，UPDATE/DELETE对 Blackhole 表的操作会被跳过，不记入 binlog，导致下游收不到 - Blackhole 从库仍需配置
server-id、开启relay_log，并运行START SLAVE；它和普通从库一样拉日志、写中继日志、回放 SQL，只是回放时数据没落地 - 它不支持外键、不维护自增值（重启后重置）、不能建临时表——这些限制不影响中继功能，但如果你试图在上面加触发器或联合查询，会直接报错
怎么配一个Blackhole中继从库
不是简单建个表就行，得把它嵌进复制拓扑里：Master → Blackhole Slave → Real Slave。中间这台要既当从库（拉 Master 的 binlog），又当主库（供下游连）。
- 在中继节点上关闭
skip_slave_start，确保重启后自动恢复复制 - 配置文件里加：
log-bin = mysql-bin（必须启用 binlog 才能被下游连）、binlog_format = STATEMENT、server-id = 2（不能和主库或其他节点重复） - 建表时指定引擎：
CREATE TABLE filter_table (...) ENGINE = BLACKHOLE；后续用replicate-ignore-db或replicate-do-table控制哪些语句实际写入该表（即哪些会进 binlog） - 下游 Real Slave 的
CHANGE MASTER TO指向这个中继节点的 IP 和端口，而不是原始 Master
常见错误：数据突然“断流”了
现象是下游从库停在某个位置不动，SHOW SLAVE STATUS\G 显示 Seconds_Behind_Master: NULL，Slave_SQL_Running: No，错误信息里出现 Table 'db.t' doesn't exist 或 Unknown table。
根本原因往往不是 Blackhole 表本身，而是你忘了：它只对显式写入它的语句生效。如果上游 Master 是通过 INSERT ... SELECT、存储过程或事件调度器间接操作数据，而目标表名没被 replicate-do-table 明确放行，那这条语句根本不会落到 Blackhole 表上，也就不会进 binlog，下游自然收不到。
- 检查
SHOW BINLOG EVENTS IN 'mysql-bin.000001'，确认你期望的语句是否真的出现在中继节点的 binlog 里 - 避免用
replicate-wild-ignore-table这类模糊规则——Blackhole 中继对匹配精度极其敏感，宁可用多个replicate-do-table - 如果 Master 启用了 GTID，中继节点也必须开
gtid_mode = ON并设enforce_gtid_consistency = ON，否则复制会卡在初始化阶段
别把Blackhole当“万能假表”滥用
它确实能接住 INSERT 脚本、绕过数据污染，但一旦涉及主键冲突检测、唯一约束、触发器上下文或事务可见性判断，就会暴露本质：它不参与存储引擎层的任何校验。
- 往 Blackhole 表插重复主键，不会报
Duplicate entry错误——它压根不查索引 -
INSERT INTO bh_table SELECT * FROM real_table在ROW格式下不会进 binlog，但语句本身执行成功，容易让人误以为“转发成功” - 高并发写入时，虽然不刷盘，但解析、构建 event、写 binlog 缓冲区仍占内存和 CPU，监控
Threads_running和Binlog_cache_use指标比看磁盘 I/O 更重要
真正难处理的从来不是“怎么让它工作”，而是“怎么证明它按你设想的方式过滤”——建议每次上线前，用 mysqlbinlog 抽样解析中继节点的 binlog，逐条对照业务变更是否如预期透传或拦截。
