MySQL 主从复制搭建记录与一次同步中断排查

公司业务量上来之后，老板拍板要上主从：一台写、一台读，顺便当备份。我之前只在自己虚拟机里玩过，这次是第一次在测试环境正经搭，把步骤和后来踩的坑都记下来。

主库配置

# /etc/my.cnf [mysqld] 段
server-id = 1
log-bin = mysql-bin
binlog-format = ROW

重启后建同步账号，权限只给复制用的：

CREATE USER 'repl'@'192.168.%.%' IDENTIFIED BY '强密码';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.%.%';
FLUSH PRIVILEGES;

然后 FLUSH TABLES WITH READ LOCK; 拿到一致性快照，记下 SHOW MASTER STATUS; 的 binlog 文件名和位点，mysqldump 导出后解锁。从库导入数据，再指向主库：

CHANGE MASTER TO
  MASTER_HOST='192.168.1.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='xxx',
  MASTER_LOG_FILE='mysql-bin.000012',
  MASTER_LOG_POS=154;
START SLAVE;

SHOW SLAVE STATUS\G 里两个线程都是 Yes 就算成了。

运行一个月后：同步断了

某天开发同事直接往从库插了条测试数据，之后从库就报错停摆：Slave_SQL_Running: No，Last_Error 是 1062 重复键——主库随后同步过来同一条主键的数据，撞了。

当时的处理：

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;

跳过这条事务恢复正常。但要注意 skip_counter 是按"事件"跳的，如果一条事务里有多个事件会跳得不干净，生产上更稳的做法是把 slave_exec_mode 设为 IDEMPOTENT 或者用 GTID 指定跳过具体事务。这次是测试环境，数据可重放，就简单粗暴了。

几个经验

• 从库必须设 read_only = ON（有 SUPER 权限的账号照样能写，所以配合权限一起管），从制度上禁止直连从库写数据
• 上 GTID 比文件位点好维护得多，复制关系一目了然，后来升级 5.7 就切过去了
• 加个监控：定时检查 Slave_IO_Running / Slave_SQL_Running / Seconds_Behind_Master，任何一项异常就告警。主从延迟这个问题早晚要面对，等你从报表数据里发现"昨天的数不对"就晚了