在生产环境中如何从零搭建MySQL 8.0主从复制架构？-mysql教程-PHP中文网

能跑通的主从复制核心是三步：主库开binlog并建mysql_native_password认证的REPLICATION SLAVE用户；从库设唯一server-id后执行CHANGE REPLICATION SOURCE TO并RESET REPLICA ALL清理旧状态；最后START REPLICA，通过SHOW REPLICA STATUS\G检查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_format = ROW 且创建 mysql_native_password 用户

MySQL 8.0 默认开启 binlog，但默认格式可能是 MIXED 或 STATEMENT，这两种在含 NOW()、UUID()、自增字段或触发器时极易导致主从数据不一致。必须强制设为 ROW：

SET PERSIST binlog_format = 'ROW';

复制用户不能用 root，也不能只给 REPLICATION SLAVE 权限就完事——关键坑点有三个：

认证插件必须是 mysql_native_password（MySQL 8.0 默认是 caching_sha2_password，从库连接时会报 Plugin caching_sha2_password could not be loaded）
必须显式授权远程访问，比如 'repl'@'%' 或更精确的 'repl'@'192.168.1.101'
权限要完整：GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES;

执行 SHOW MASTER STATUS; 记下 File 和 Position，后续从库要用。

从库配置 server-id 后必须重置旧复制状态再执行 CHANGE REPLICATION SOURCE TO

从库的 my.cnf 中只加 server-id = 2 不够，常见错误是跳过清理直接启动，结果报：

Could not initialize master info structure
Client requested master to start replication from position > file size

正确做法是：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

先停复制：STOP REPLICA;
清空旧状态（MySQL 8.0.23+ 推荐）：RESET REPLICA ALL;（它会删掉 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;

验证时重点看 Replica_IO_Running、Replica_SQL_Running 和 Seconds_Behind_Master

运行 SHOW REPLICA STATUS\G 后，只盯这三个字段：

Replica_IO_Running: Yes → 表示从库能连上主库并持续拉取 binlog
Replica_SQL_Running: Yes → 表示中继日志能被正常解析和执行
Seconds_Behind_Master: 0（或稳定在个位数）→ 表示同步基本实时；如果长期 > 10，说明 SQL 线程卡住，常见于大事务、DDL 或从库磁盘 I/O 瓶颈

别被 Slave_IO_Running 这类旧字段名迷惑——MySQL 8.0.22+ 已统一改为 Replica_* 前缀。另外，Retrieved_Gtid_Set 和 Executed_Gtid_Set 若启用 GTID，二者必须完全一致才算真正同步完成。

时间同步、防火墙和 SELinux 是最容易被忽略的底层依赖

主从延迟高或连接失败，80% 的情况不是配置问题，而是环境没理干净：

时间不同步会导致 GTID 复制失败、慢查询日志时间错乱，必须用 ntpdate 或 chronyd 对齐（建议指向同一 NTP 源）
防火墙默认拦 3306，CentOS 7/8 要么关掉：systemctl stop firewalld，要么放行：firewall-cmd --add-port=3306/tcp --permanent
SELinux 在 CentOS 上默认启用，会阻止 mysqld 访问网络或写 relay log，临时关：setenforce 0；永久关需改 /etc/selinux/config

这些不解决，CHANGE REPLICATION SOURCE TO 可能静默失败，或者 SHOW REPLICA STATUS 显示 IO 线程为 Connecting 卡住不动——这时候查 mysqld.err 日志，往往第一行就是 connect() failed with errno 113（拒绝连接），根源就在网络策略层。