如何快速搭建MySQL 8.0主从复制架构并验证成功？-mysql教程-PHP中文网

能跑通的主从复制核心是三步：主库开binlog并建专用复制用户，从库配唯一server-id、执行change replication source to，再start replica并验证replica_io_running、replica_sql_running为yes且seconds_behind_master稳定为0。

如何快速搭建mysql 8.0主从复制架构并验证成功？

能跑通的主从复制，核心就三步：主库开 binlog + 建复制用户，从库配 server-id + CHANGE REPLICATION SOURCE TO，最后 START REPLICA 并确认状态。中间任何一环出错，SHOW REPLICA STATUS\G 里必有明确错误信息。

主库必须开启 binlog 并创建专用复制用户

MySQL 8.0 默认已启用 binlog，但必须显式确认格式和权限——binlog_format = ROW 是安全底线，避免语句级复制（STATEMENT）在函数、时间戳、自增等场景下数据不一致；log-bin 路径无需手动指定，默认即可，但 server-id 必须唯一且非 0。

复制用户不能用 root，也不能只给 REPLICATION SLAVE 权限就完事：

必须用 mysql_native_password 插件认证（MySQL 8.0 默认是 caching_sha2_password，从库连接时会报 Plugin caching_sha2_password could not be loaded）
需显式授权远程访问：CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'ReplPass123!';
权限要完整：GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES;
执行 SHOW MASTER STATUS; 记下 File 和 Position，后续从库要用

从库配置 `server-id` 后必须重置复制位点

从库的 my.cnf 中只改 server-id 不够，还必须确保 relay-log 路径可写、read_only = 1（防误写），且不能残留旧的复制状态。常见错误是跳过这步直接 START REPLICA，结果报 Could not initialize master info structure 或 Client requested master to start replication from position > file size。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

正确做法是：

先停复制：STOP REPLICA;
清除旧状态：RESET REPLICA ALL;（MySQL 8.0.23+ 推荐，清空 master.info 和 relay-log.info）

设置源信息（注意命令名已从 CHANGE MASTER TO 改为 CHANGE REPLICATION SOURCE TO）：

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='192.168.1.100',
  SOURCE_USER='repl',
  SOURCE_PASSWORD='ReplPass123!',
  SOURCE_LOG_FILE='mysql-bin.000001',
  SOURCE_LOG_POS=157;

启动：START REPLICA;

`SHOW REPLICA STATUS\G` 里这三项必须为 Yes

验证是否真正跑通，别只看 Replica_IO_Running 和 Replica_SQL_Running，还要盯住 Seconds_Behind_Master 是否稳定为 0（初始同步可能有延迟，但持续增长就说明卡住了）。

典型失败信号：

Replica_IO_Running: No → 多半是网络不通、用户密码错、或主库 require_secure_transport = ON 拦截了非加密连接
Replica_SQL_Running: No → 通常是主从表结构不一致、从库写了数据触发 read_only 冲突、或 DDL 在从库执行失败（如 DROP TABLE 找不到表）
Seconds_Behind_Master: NULL → I/O 线程根本没连上，查 Source_IO_State 字段内容，比如 Connecting to master 就该去 ping 主库 IP 和 telnet 3306 端口

最易被忽略的是时间同步——主从服务器时间差超过 30 秒，可能导致基于 GTID 的事务解析异常，或 binlog 时间戳错乱；即使不用 GTID，某些 timestamp 类型字段在复制中也会行为诡异。务必在部署前跑一次 ntpdate -u pool.ntp.org 并启用 systemd-timesyncd 或 ntpd 持续校准。