MySQL 8.0异步主从复制成功的关键是：server-id全局唯一、log_bin启用、复制账号权限到位且认证插件为mysql_native_password、CHANGE REPLICATION SOURCE TO参数准确；任一缺失均导致START REPLICA报错或静默失败。
server_id 和 binlog_format 必须严格对齐
跨版本同步（如 MySQL 5.7 → 8.0 或 8.0.33 → 8.4）时，server_id 和 binlog_format 不匹配是首批失败点。MySQL 8.0.23+ 默认禁用 STATEMENT 格式，若源库仍为 MIXED 或旧版 STATEMENT，下游解析器（如 go-mysql、canal）会直接跳过事件或报 Sanity check failed。
必须确保：
- 源库
server_id是非 0 整数，且在整个拓扑中全局唯一（哪怕只有一主一从） - 源库
binlog_format = ROW（动态执行SET GLOBAL binlog_format = 'ROW'即可，无需重启） - 源库
binlog_row_image = FULL（MySQL 5.6+ 默认值，但升级后可能被重置） - 目标端工具所用的
mysqlbinlog客户端版本，需与源库主版本一致（例如源为 8.0.33，本地解析工具也得是 8.0.x，不能混用 5.7 客户端）
起始位点不能靠 SHOW MASTER STATUS 直接取
跨版本补录常用于修复历史数据偏差，此时“从哪开始追”比日常同步更敏感。直接执行 SHOW MASTER STATUS 拿到的 Position 是当前写入偏移，不是已提交事务的终点——尤其在高并发下，极易漏掉正在 COMMIT 的事务。
安全锚定位点的两种方式：
- 若业务可短暂停写（秒级）：
FLUSH TABLES WITH READ LOCK;→SHOW MASTER STATUS;→ 记下File和Position→UNLOCK TABLES; - 若不可停写，且源库已启用 GTID（MySQL 5.6+）：
SELECT @@global.gtid_executed;，下游从该 GTID 集合起拉取；注意：GTID 模式下，CHANGE MASTER TO必须指定MASTER_AUTO_POSITION = 1
对 RDS/PolarDB 等托管服务，优先走控制台导出「指定时间点」的 binlog 快照，而非实时远程拉取——它们自带事务边界对齐和 CRC 校验。
mysqlbinlog 远程拉取必须带 --raw 参数
跨版本环境里，mysqlbinlog --read-from-remote-server 命令卡住、无输出、或输出乱码，90% 是因为漏了 --raw。不加它，客户端会尝试用本地元数据解析远程流，而远程 MySQL 不提供表结构上下文，导致字段映射失效。
完整可用命令示例（MySQL 8.0 源库）：
mysqlbinlog \ --read-from-remote-server \ --raw \ --host=192.168.1.100 \ --port=3306 \ --user=repl \ --password='xxx' \ --base64-output=DECODE-ROWS \ -v \ mysql-bin.000001 > output.sql
注意：
-
repl用户需有REPLICATION CLIENT和REPLICATION SLAVE权限 - 远程库必须开启
log_slave_updates（若本身是中继节点） - 输出的
output.sql是伪 SQL（含###注释），不能直接执行，仅用于调试或喂给解析库
幂等写入是补录阶段的生死线
补录不是首次同步，而是“把过去漏掉的变更再塞一遍”。如果下游不做幂等控制，同一行 UPDATE 可能被执行两次，导致数据错乱（比如金额翻倍、状态回滚）。
推荐做法：
- 用主键或业务唯一键做 UPSERT（
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO） - 在目标表加
updated_at时间戳字段，写入时只更新updated_at > event_timestamp的记录 - 避免用
DELETE + INSERT模式，它无法区分“逻辑删除”和“真删除”
最易被忽略的一点：补录期间源库仍在写入，所以位点/ GTID 范围必须闭合（起始明确、终止可控），不能边拉边跑——否则永远追不平。
