MySQL主从复制配置实战：从库搭建与复制延迟排查

MySQL 主从复制是读写分离的底座，首次搭建常卡在三处：从库找不到 binlog 事件、快照位点与实际不符、1062 冲突让复制线程停摆。

一、复制原理与参数准备

1. 三个线程的分工

主库 dump 线程推送事件，从库 IO 线程写入 relay log，SQL 线程按序回放。因此主库必须把 binlog_format 设为 ROW，STATEMENT 下带 NOW() 的语句在主从可能算出不同结果；从库 server-id 必须全局唯一。

2. 两端配置文件

主库 my.cnf 增加以下段落，重启 mysqld 生效。

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

从库只需换 server-id，read_only 可防误写，但对拥有 SUPER 权限的账号无效。

server-id         = 2
relay-log         = relay-bin
read_only         = ON

二、从库初始化与位置定位

1. 用一致性快照灌数据

拿正在写入的主库做从库需先有一致性快照。--single-transaction 开启可重复读事务，导出结果为一致性视图；--master-data=2 把当刻位点以注释写进 dump 头部，该选项在 8.0 后改名 --source-data。

mysqldump -uroot -p --single-transaction --master-data=2 --databases appdb > appdb.sql

2. 建立复制链路

传统模式需手工指定位点，主库账号只需 REPLICATION SLAVE 权限。

CHANGE MASTER TO MASTER_HOST='10.0.0.11', MASTER_USER='repl',
  MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=157;
START SLAVE;

开启 GTID 后不必手工填位点：两端设 gtid_mode=ON，初始化用 SOURCE_AUTO_POSITION=1 让从库自行对齐。

三、延迟排查与常见报错

1. 定位复制延迟

SHOW SLAVE STATUS 的 Seconds_Behind_Master 是回放时间与 relay log 最后事件时间戳之差。IO 线程断开时它可能显示 0 从而掩盖故障，故需同时确认 IO 与 SQL 线程状态都为 Yes。

拖慢回放的多是 SQL 线程单线程执行。5.7 后可将并行 worker 调到 4 至 8 并启用 WRITESET。

2. 处理 1062 主键冲突

从库报 Duplicate entry 的 1062 多因被手工写过或恢复时多跑了数据。非 GTID 模式可跳过一个事务再重启：

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

GTID 模式下该变量不再生效，要把冲突事务的 GTID 标记为空事务跳过再恢复自动定位，否则会一直重试同一事务。

STOP SLAVE;
SET GTID_NEXT='5d4e11ee-9a7b-0242ac11:41';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLAVE;

关键配置提示

• 主从 server-id 必须唯一，binlog_format=ROW 是并行复制前提，配错会直接中断链路。
• 从库恢复用 --single-transaction --master-data=2 快照，否则位点对不上会丢数据。
• 跳过 1062 前先解析 binlog 确认影响范围，GTID 模式下必须用 SET GTID_NEXT 空事务写法。