主库和从库的 server_id 必须全局唯一
跨地域复制本质仍是标准 MySQL 主从，但网络延迟、丢包、带宽限制会让配置稍有不同。最基础却最容易翻车的点是
server_id—— 它必须是整数，且在所有参与复制的节点中唯一。同城部署时可能随手设成 1/2，异地多机房场景下若未统一规划，极易出现两个从库
server_id冲突，导致复制中断或日志错乱。
实操建议：
用机房+角色编码规则，比如sh_master_101→
server_id = 101，
bj_slave_202→
server_id = 202避免使用 0、1 这类默认值，尤其不要让多个从库都设为 2 修改后必须重启 mysqld 或执行
SET PERSIST server_id = 202（MySQL 8.0+），仅
SET GLOBAL不持久
binlog_format 必须设为 ROW，且主库开启 binlog_checksum
跨地域链路不稳定，语句级复制（
STATEMENT）在从库重放时极易因函数、临时表、非确定性操作失败；而
MIXED在跨版本或跨配置环境下行为不可控。ROW 格式能确保变更内容精确传递，是异地复制的事实标准。
同时，必须启用
binlog_checksum = CRC32（MySQL 5.6.6+ 默认开启，但部分旧配置会关掉）。否则网络传输中二进制日志损坏无法被检测，从库可能静默应用错误数据。
检查与设置：
确认：SELECT @@binlog_format, @@binlog_checksum;—— 两者都应为
ROW和
CRC32配置文件中写死：
binlog_format = ROW、
binlog_checksum = CRC32不推荐运行时动态改
binlog_format，需重启生效且会清空当前 binlog
CHANGE REPLICATION SOURCE TO 的连接参数要加超时和重试
异地网络波动大，从库连主库时容易卡在 TCP 握手或认证阶段。默认的
CHANGE REPLICATION SOURCE TO没有连接超时控制，可能 hang 住数分钟才报错，影响自动化部署或故障恢复。
解决方法是显式指定网络参数：
SOURCE_CONNECT_RETRY = 60：失败后每 60 秒重试一次（默认 60，但建议显式写出，便于维护）
SOURCE_RETRY_COUNT = 86400：最大重试次数（默认 2^32−1，但设个合理上限防无限等待） 配合
SOURCE_SSL = 1（强烈建议异地启 SSL 加密传输，哪怕自签名证书） 避免用域名做
SOURCE_HOST，优先填主库公网 IP 或内网穿透后的固定端口地址
从库务必关闭 binlog 并设为 read_only=ON
异地从库通常只读，但 MySQL 默认仍可能写入（比如 SQL 线程自身写入 relay log 对应的 event）。若意外开启
log_bin，又没设
read_only，可能造成循环复制、GTID 冲突或数据污染。
关键配置项：
skip_log_bin或
log_bin = OFF（5.7 可用
skip_log_bin，8.0 推荐注释掉
log_bin行）
read_only = ON：阻止普通用户写入（注意：对 SUPER 权限用户无效，所以要严格管控账号）
super_read_only = ON（MySQL 5.7.8+）：进一步锁死 SUPER 用户的写权限，上线前必开
真正麻烦的不是配置本身，而是「以为配了，其实没生效」——比如
read_only被动态 SET 过但没写进配置文件，重启后失效；或者
super_read_only在低版本 MySQL 中不存在，误配导致启动失败。
