mysql主从复制的配置文件修改与参数设置

mysql主从复制必须设置唯一server-id并显式配置log-bin路径；主库需设binlog_format=ROW且禁用sql_log_bin=0；从库应启用read_only=1和log-slave-updates=1，并通过SHOW REPLICA STATUS验证状态。

my.cnf 中必须设置的 server-id 和 log-bin

主从复制启动失败，90% 是因为 server-id 未设或重复。MySQL 要求每个实例有唯一整数 ID，且主库必须开启二进制日志——仅靠 log-bin 开关还不够，得指定基础文件名（否则默认用主机名，跨环境易出错）。

• server-id 必须是 1–4294967295 范围内的非零整数，主从不能相同；建议用 IP 最后一段（如 192.168.1.10 → server-id = 10）
• log-bin 推荐显式写全路径和前缀，例如 log-bin = /var/lib/mysql/mysql-bin，避免因 datadir 变动或权限问题导致日志无法生成
• 从库也建议开启 log-bin（非必需但利于级联复制），同时必须加 log-slave-updates = 1 才能将同步来的事件再写入自己的 binlog

主库需启用 binlog_format=ROW 并禁用 sql_log_bin=0 的误操作

如果主库用 STATEMENT 格式，遇到 NOW()、UUID()、自增主键冲突等场景，从库执行结果会不一致；而 MIXED 实际仍可能退化为 STATEMENT 模式，隐患难排查。线上生产环境应强制设为 ROW。

• binlog_format = ROW 是安全底线，修改后需重启 MySQL 或用 SET PERSIST binlog_format = 'ROW'（MySQL 8.0+）
• 开发或运维人员有时在主库执行 DDL 前临时关闭日志：SET sql_log_bin = 0，但忘记恢复，导致后续所有变更不写 binlog，从库彻底断连——这类操作必须配监控告警
• 确认生效：连接主库执行 SHOW VARIABLES LIKE 'binlog_format'; 和 SHOW VARIABLES LIKE 'sql_log_bin';

从库关键参数：relay_log、read_only、skip_slave_start 的取舍

从库误写数据是最常见事故源，read_only = 1 能拦截绝大多数非 SUPER 权限用户的写操作，但它不防 root 或 SUPER 用户，也不能阻止 SQL 线程自身写入（这是正常的）。真正要防的是人为 INSERT/UPDATE 到从库表。

• relay_log 建议显式指定路径和前缀（如 relay-log = /var/lib/mysql/mysql-relay-bin），避免与主库 binlog 文件名冲突，也方便定位 relay 日志位置
• read_only = 1 必开，但注意：若从库还承担只读查询，需额外授权 select 给应用用户；SUPER 用户仍可绕过，所以生产环境应收回 SUPER 权限
• skip_slave_start = 1 已被弃用（MySQL 5.7+ 不识别），新版用 skip_replica_start = 1；但除非调试需要，否则不应跳过启动，否则每次重启都要手动 START REPLICA;

配置生效后验证 replication 连接与延迟的关键命令

改完 my.cnf 重启只是第一步，MySQL 不会自动建立主从连接，必须手动执行 CHANGE REPLICATION SOURCE TO ...（MySQL 8.0.23+ 语法）或旧版 CHANGE MASTER TO ...。很多故障源于这里参数填错，尤其是 SOURCE_LOG_FILE 和 SOURCE_LOG_POS 对不上。

• 主库上执行 SHOW MASTER STATUS; 获取当前 binlog 文件名和 position；从库执行 CHANGE REPLICATION SOURCE TO SOURCE_HOST='xxx', SOURCE_USER='repl', SOURCE_PASSword='xxx', SOURCE_LOG_FILE='mysql-bin.000001', SOURCE_LOG_POS=156;
• 启动后立刻查状态：SHOW REPLICA STATUSG（注意不是 SLAVE），重点看 Replica_IO_Running 和 Replica_SQL_Running 是否都为 Yes，以及 Seconds_Behind_Master 是否稳定为 0 或缓慢增长
• 常见卡点：IO Thread 连不上主库（网络、防火墙、账号权限）、SQL thread 报错（如主键冲突、表结构不一致），此时 Last_IO_Error 或 Last_SQL_Error 字段会给出具体错误信息

mysql> SHOW REPLICA STATUSG *************************** 1. row ***************************              Replica_IO_State: Waiting for source to send event               Source_Host: 192.168.1.10               Source_User: repl               Source_Port: 3306           Connect_Retry: 60         Source_Log_File: mysql-bin.000002     Read_Source_Log_Pos: 194          Relay_Log_File: mysql-relay-bin.000003           Relay_Log_Pos: 320   Relay_Source_Log_File: mysql-bin.000002      Replica_IO_Running: Yes     Replica_SQL_Running: Yes Seconds_Behind_Master: 0

配置项之间存在隐式依赖，比如没开 log-bin 就设 log-slave-updates 会静默失效；server-id 为 0 时整个复制线程直接拒绝启动。这些细节不会报错，但会让后续排查变成盲猜。