MySQL 主从复制搭建与常见故障排查（延迟 / 断同步 / 报错）

主从复制（Replication）是 MySQL 高可用和读写分离的基石。本文给出一主一从的最小可用搭建，以及最常见的三类故障处理。

一、复制原理

主库把数据变更写入 binlog，从库 IO 线程拉取 binlog 到本地 relay log，SQL 线程回放。核心状态就在 SHOW SLAVE STATUS\G。

二、搭建一主一从

主库 my.cnf：

server-id = 1
log_bin = mysql-bin
binlog_format = ROW

创建复制账号并获取位点：

CREATE USER 'repl'@'%' IDENTIFIED BY 'ReplPass!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
SHOW MASTER STATUS;   -- 记录 File 和 Position

从库 my.cnf：server-id = 2（必须不同）。然后：

CHANGE MASTER TO
  MASTER_HOST='主库IP', MASTER_USER='repl', MASTER_PASSWORD='ReplPass!',
  MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;
START SLAVE;

三、健康检查

SHOW SLAVE STATUS\G

关注三项：

• Slave_IO_Running / Slave_SQL_Running 都应为 Yes
• Seconds_Behind_Master：主从延迟秒数，0 为理想
• Last_Error：SQL 线程报错信息

四、常见故障

1. 主从延迟大

大事务、从库性能差、网络抖动都会造成延迟。优化方向：拆分大事务、提升从库硬件、开启 slave_parallel_workers 并行回放。

2. 报错 1062（Duplicate entry）

从库已存在该主键。可临时跳过：

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

使用 GTID 模式时，用 SET GTID_NEXT='<uuid>:N'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; 跳过，更安全。

3. 报错 1032（找不到行）

主库更新的行在从库不存在，通常是主从数据已不一致。根治方式是重新做全量备份重建从库，而非一味跳过。

小结

主从复制的健康看 Slave_IO/SQL_Running 和 Seconds_Behind_Master；报错不要无脑 skip，先判断是数据不一致还是偶发冲突。