跨地域MySQL主从复制需确保server_id全局唯一、binlog_format=ROW且binlog_checksum=CRC32、CHANGE REPLICATION SOURCE TO显式配置超时重试参数、从库关闭binlog并启用read_only与super_read_only。
主库和从库的 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+ 默认开启，但部分旧配置会关掉）。否则网络传输中二进制日志损坏无法被检测，从库可能静默应用错误数据。
检查与设置：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 确认：
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 中不存在，误配导致启动失败。
