MySQL主从复制配置全流程：从零搭建到状态验证

MySQL主从复制配置的核心，是让主库把数据变更写进二进制日志（binlog），从库读取这些日志并在本地重放，从而保持数据一致。
下面按主库配置、从库配置、建立复制连接、状态验证四步展开，假设你已装好两台MySQL，版本一致或从库版本不低于主库。

先确认环境与前提条件

开始前先核对三件事，能避免大部分复制失败：

• 两台服务器能互相ping通，从库能访问主库的3306端口。
• 主从MySQL的大版本尽量一致，比如都是MySQL 8.0，避免语法和认证插件不兼容。
• 主库已有数据量不大，或你愿意先锁表导出；数据量大的场景建议用mysqldump或XtraBackup做一次全量同步。

检查主库当前是否已开启binlog：

SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'server_id';

如果log_bin是OFF，就需要修改配置文件并重启MySQL。

主库：开启binlog并创建复制账号

编辑MySQL配置文件，Linux下通常是/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf，在[mysqld]段落下加入：

[mysqld]
server-id=1
log-bin=mysql-bin
binlog-format=ROW
expire_logs_days=7

说明：server-id在复制拓扑里必须唯一，主库设为1，从库不能再用1。binlog-format=ROW是推荐格式，能减少主从数据不一致。
改完重启MySQL：

systemctl restart mysqld

重启后登录主库，创建专门用于复制的账号，不要直接用root：

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

如果只允许从库IP连接，把%换成从库的实际IP更安全。
接着记录主库当前日志位置，后续从库要用：

SHOW MASTER STATUS;

记下File和Position两列的值。
如果启用了GTID，则记下Executed_Gtid_Set。

从库：设置server-id并指向主库

从库的配置文件同样在[mysqld]段落下设置，server-id给一个和主库不同的值：

[mysqld]
server-id=2
relay-log=relay-bin
read-only=1

read-only=1让从库普通账号只能读，防止误写导致数据分叉；
有super权限的账号仍可写，这是预期行为。
重启从库后，执行复制指向命令。

使用日志位置方式：

CHANGE MASTER TO
  MASTER_HOST='主库IP',
  MASTER_USER='repl',
  MASTER_PASSWORD='你的强密码',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154;

如果主库开启了GTID，用GTID方式更省事，不用记日志文件名：

CHANGE MASTER TO
  MASTER_HOST='主库IP',
  MASTER_USER='repl',
  MASTER_PASSWORD='你的强密码',
  MASTER_AUTO_POSITION=1;

然后启动复制：

START SLAVE;

MySQL 8.0.22以后也可以用START REPLICA;，两者等价。

用SHOW SLAVE STATUS判断是否真的同步

启动后立刻查看状态：

SHOW SLAVE STATUS\G

关键看三项：

• Slave_IO_Running和Slave_SQL_Running都必须是Yes。
• Seconds_Behind_Master为0或很小，说明延迟低。
• Last_Error为空，有内容就说明出错。

验证同步效果最直接的办法：在主库建一个测试库或表，插入一行数据，再到从库查询是否出现。
能查到说明复制链路已经通了。

常见报错与避坑要点

IO线程连不上主库：多半是复制账号密码错、防火墙没放行3306、或主库没授权从库IP。
先在从库用mysql -h主库IP -urepl -p手动登录试一次。

server-id重复：两台都设成1，复制会报错或行为异常，务必保证唯一。

从库已存在同名数据：如果从库不是空库，重放日志会报主键冲突。
正确做法是先做主库全量备份，导入从库后再记录对应位置开始复制。

修改配置后忘记重启：server-id、log-bin这类参数改完必须重启MySQL才生效，只执行SQL不会改变。

从库被写入：即便设了read-only，有super权限的账号仍可写。
生产环境建议用普通账号访问从库，避免人为制造不一致。

收尾与监控建议

搭建完成后，定期查看Seconds_Behind_Master，延迟持续升高通常意味着从库硬件不足或有大事务阻塞。
日志保留天数expire_logs_days不要设得太短，否则从库断连太久会因日志被清理而无法追平。
如果后续要做读写分离或故障切换，主从复制只是基础，还需要配合中间件或高可用组件来实现。

常见疑问

复制账号必须用root吗？

不需要，也不建议。
单独建一个只有REPLICATION SLAVE权限的账号即可，权限越小越安全。

主从延迟一直是0，说明完全实时吗？

不一定。Seconds_Behind_Master是估算值，短时间大事务或网络抖动都可能让它瞬间跳动，判断健康度要结合业务写入量和多时段观察。

从库可以对外提供查询吗？

可以，这也是读写分离的常见用法，但要接受一定延迟。
对一致性要求高的查询仍应走主库。