在从库配置 MySQL 主从复制，核心是让从库连接到主库、获取二进制日志（binlog），并重放其中的事件。关键步骤包括：主库开启 binlog 并创建复制用户，从库执行
CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或
CHANGE MASTER TO（旧版本），再启动复制线程。
主库准备：启用 binlog 并授权复制用户
确保主库已启用二进制日志，并记录当前 binlog 文件名和位置（用于从库起点）。同时创建专用复制账号，限制仅允许复制连接：
检查主库配置文件（如/etc/my.cnf或
/etc/mysql/mysql.conf.d/mysqld.cnf），确认含以下参数： log-bin = mysql-bin
server-id = 1
binlog-format = ROW # 推荐，兼容性与一致性更好
重启 MySQL 生效后，登录主库执行：
FLUSH BINARY LOGS;（可选，生成新 binlog 文件便于定位）
SHOW MASTER STATUS;记下
File和
Position值（例如
mysql-bin.000003,
154） 创建复制用户：
CREATE USER 'repl'@'%' IDENTIFIED BY 'your_secure_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
从库配置：设置复制源并启动同步
从库需有唯一
server-id（不能与主库冲突），且建议关闭 binlog（除非要级联复制）。编辑从库配置文件，加入： server-id = 2
# log-bin = mysql-bin # 如不作中间主库，可注释掉
重启从库后，执行复制源配置（以 MySQL 8.0.23+ 语法为例）：
CHANGE REPLICATION SOURCE TO<br> SOURCE_HOST='主库IP',<br> SOURCE_USER='repl',<br> SOURCE_PASSWORD='your_secure_password',<br> SOURCE_LOG_FILE='mysql-bin.000003',<br> SOURCE_LOG_POS=154;启动复制：
START REPLICA;（旧版本用
START SLAVE;） 查看状态：
SHOW REPLICA STATUS\G（旧版为
SHOW SLAVE STATUS\G），重点关注：
– Replica_IO_Running 和 Replica_SQL_Running 是否均为
Yes
– Seconds_Behind_Master 是否逐渐归零
常见问题排查要点
若复制未正常运行，优先检查这几项：
网络连通性：从库能否 telnet 主库 IP + 3306 端口？防火墙是否放行？ 账号权限与密码：从库连接测试：mysql -h 主库IP -u repl -p，确认能登录 binlog 位置是否有效：主库上执行
SHOW BINARY LOGS;，确认指定的
SOURCE_LOG_FILE仍存在；若主库已 purge，需重新导出全量数据+新 binlog 位点 GTID 模式差异：若主从启用了 GTID（
gtid_mode=ON），则不能用
SOURCE_LOG_FILE/POS，应改用：
CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION = 1;
补充建议：提升稳定性与可观测性
生产环境建议增加基础防护和监控习惯：
从库设为只读：SET GLOBAL read_only = ON;（不影响复制线程，但阻止普通写入） 定期校验主从数据一致性，可用
pt-table-checksum工具 监控
Seconds_Behind_Master波动，突增可能预示 SQL 延迟或主库压力过大 避免在从库执行 DDL（如
ALTER TABLE），尤其未加
SQL_LOG_BIN=0时，可能引发复制中断
