触发器无法可靠实现跨库/跨实例数据同步，因其仅限本库事务内操作，不支持远程写入且失败会导致业务回滚；推荐基于ROW格式binlog+解析工具（如canal、debezium）的准实时同步方案。

触发器不能可靠实现跨库/跨实例数据同步

MySQL 触发器（TRIGGER）只能在当前数据库实例、同一事务上下文中操作本库表，无法直接写入远程 MySQL 实例、其他数据库（如 PostgreSQL）、消息队列或 HTTP 接口。试图用 INSERT INTO remote_db.t1 ... 会报错 ERROR 1418 (HY000) 或权限拒绝——因为触发器不支持外部连接，且开启 log_bin_trust_function_creators 也解决不了根本限制。

• 触发器执行在事务内，若同步逻辑失败（如网络超时），整个事务会回滚，导致业务写入失败，违背“异步解耦”原则
• 无法处理主从延迟、断连重试、幂等写入、冲突检测等生产必需能力
• DDL 变更（如字段改名、表拆分）会直接让触发器失效，且无告警机制

替代方案：用 binlog + 解析工具做准实时同步

真正可行的 MySQL 自动化同步，依赖二进制日志（binlog）+ 外部消费者。核心链路是：MySQL 启用 ROW 格式 binlog → 工具监听 binlog 流 → 解析为事件 → 转发到目标系统。

• 必须设置 binlog_format = ROW（STATEMENT 或 MIXED 无法精确捕获行变更）
• 需赋予专用账号 REPLICATION SLAVE 和 REPLICATION CLIENT 权限
• 推荐轻量级工具：maxwell（输出 JSON 到 Kafka/Redis/Stdout）、canal（阿里开源，Java 生态友好）、debezium（Kafka Connect 插件，支持下游多种 sink）

CREATE USER 'sync_user'@'%' IDENTIFIED BY 'strong_pass';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'sync_user'@'%';
FLUSH PRIVILEGES;

简单场景下可用事件轮询 + 存储过程兜底

如果只是同实例内两张表的弱一致性同步（例如记录操作日志），可结合 EVENT 定时扫描 + INSERT ... SELECT，但要注意事务隔离与重复执行风险。

• 避免用 AFTER INSERT 触发器直接更新另一张表——这属于强耦合，违反单一职责
• 用 EVENT 每 5 秒执行一次，只同步 status = 'pending' 的记录，并更新为 'synced'
• 必须加 SELECT ... FOR UPDATE 或唯一索引约束，防止并发重复处理

CREATE EVENT sync_log_to_archive
ON SCHEDULE EVERY 5 SECOND
DO
  INSERT INTO archive_log (id, content, created_at)
  SELECT id, content, created_at FROM log_table
  WHERE status = 'pending'
  ORDER BY id LIMIT 100;
UPDATE log_table SET status = 'synced'
WHERE id IN (
SELECT id FROM (
SELECT id FROM log_table WHERE status = 'pending' ORDER BY id LIMIT 100
) AS tmp
);

同步失败时的关键防御点

所有自动化同步方案都绕不开失败处理。最易被忽略的是：没有独立的错误追踪表和人工干预入口。

• 在目标写入逻辑中捕获异常，把失败的 binlog position、原始事件 JSON、错误信息插入 sync_error_log 表
• 不要自动跳过错误（skip-error 在 canal/maxwell 中默认关闭，切勿开启）
• 监控项必须包含：binlog lag（seconds_behind_master）、error_log count / hour、last_success_timestamp

同步不是“设好就完事”，而是持续校验和修复的过程。哪怕用了最成熟的 debezium，也要定期比对源表和目标表的 CHECKSUM TABLE 结果。