能跑通的主从复制核心是三步：主库开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。
能跑通的主从复制，核心就三步：主库开 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 structureClient requested master to start replication from position > file size
正确做法是：
面向 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（拒绝连接），根源就在网络策略层。
