确认 MySQL 版本兼容性再动手
主从复制不是“装上就能跑”，版本不匹配会导致
CHANGE MASTER TO失败或复制中断。MySQL 5.7 和 8.0 之间不建议跨大版本搭建主从；同为 8.0 时，主库版本不能低于从库（例如 8.0.33 主 → 8.0.30 从会报错
ER_MASTER_VERSION_TOO_NEW_FOR_SLAVE）。查看版本用：
SELECT VERSION();或
mysql --version。
主库必须开启 binlog 并设 server-id
没开 binlog，主库根本不会记录变更，从库自然无从复制。在主库
my.cnf的
[mysqld]段中至少配置：
server-id = 1 log-bin = mysql-bin binlog-format = ROW
注意：
binlog-format = ROW是推荐值，避免语句级复制（STATEMENT）在函数、临时表等场景下的不一致；
log-bin路径默认写在 datadir 下，确保 MySQL 进程有写权限；改完必须重启 MySQL（
systemctl restart mysqld），且重启后执行
SHOW VARIABLES LIKE 'log_bin';确认为
ON。
从库配置 server-id + CHANGE MASTER TO 要核对参数
从库的
server-id必须与主库不同（如设为 2），且不能与其他节点重复。执行
CHANGE MASTER TO前，先在主库执行
SHOW MASTER STATUS;获取当前
File和
Position；然后在从库执行：
CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='repl', MASTER_PASSWORD='your_secure_password', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;
常见错误包括：
MASTER_LOG_FILE写错（比如漏掉前导零）、
MASTER_LOG_POS超出主库当前 binlog 范围、网络不通导致连接超时、用户
repl没有
REPLICATION SLAVE权限。验证是否成功：运行
START SLAVE;后，立即查
SHOW SLAVE STATUS\G，重点关注
Slave_IO_Running和
Slave_SQL_Running是否都为
Yes，以及
Seconds_Behind_Master是否稳定为 0 或小数值。
复制延迟和 GTID 开启时机要谨慎
默认基于 binlog 文件+位置的复制，在主库频繁切换 binlog 或从库重启后容易配错位点。GTID 模式能简化故障恢复，但要求主从都开启且配置一致：
gtid_mode=ON、
enforce_gtid_consistency=ON。不过，已运行的非 GTID 主从环境，不能直接在线开启 GTID——必须停主停从、重置 binlog、清空从库数据并重新导入（或使用
mysqldump --set-gtid-purged=OFF），操作成本高。日常测试可开，生产环境切 GTID 前务必做完整回滚演练。
