必须开启主库binlog并设置唯一server-id；创建专用repl用户授权REPLICATION SLAVE；记录SHOW MASTER STATUS的File和Position；从库执行CHANGE REPLICATION SOURCE TO配置连接参数；启动START REPLICA后检查Replica_IO_Running和Replica_SQL_Running均为Yes。
确认主库是否开启 binlog 并设置唯一 server-id
MySQL 主从复制依赖于主库的二进制日志（binlog），如果没开，从库根本无法获取变更事件。执行 SHOW VARIABLES LIKE 'log_bin'; 确认返回 ON；若为 OFF，需在主库配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）中添加：
log-bin = mysql-bin server-id = 1
注意：server-id 必须是 1–4294967295 范围内的整数，且主从不能重复；主库设为 1 是常见做法，但不是强制——只要全局唯一即可。
修改后必须重启 MySQL（systemctl restart mysql 或 service mysqld restart），仅重载配置不生效。
创建专用复制用户并授权
从库连接主库时，需要一个具备 REPLICATION SLAVE 权限的账号。不要复用 root 或应用账号，避免权限过大风险：
CREATE USER 'repl'@'%' IDENTIFIED BY 'StrongPass123!'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES;
常见错误包括：
- 漏掉
FLUSH PRIVILEGES，导致授权不生效 - 账号绑定过于严格（如
'repl'@'192.168.1.10'），而从库 IP 动态变化或走 NAT，建议用'repl'@'%'+ 防火墙控制访问源 - MySQL 8.0+ 默认认证插件为
caching_sha2_password，部分旧客户端不兼容，可显式指定：CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'StrongPass123!';
获取主库当前 binlog 位置并配置从库
主库执行 SHOW MASTER STATUS;，记录 File 和 Position 值（例如 mysql-bin.000003, 154）。这是从库启动复制的起点。
从库上执行 CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或 CHANGE MASTER TO（旧版本）：
CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.1.5', SOURCE_USER='repl', SOURCE_PASSWORD='StrongPass123!', SOURCE_LOG_FILE='mysql-bin.000003', SOURCE_LOG_POS=154;
关键点：
- MySQL 8.0.23 起命令名变更，旧写法会报错
Unknown system variable 'master_host' -
SOURCE_LOG_FILE和SOURCE_LOG_POS必须与SHOW MASTER STATUS输出完全一致，大小写、空格、数字都不能错 - 若主库已运行一段时间，建议先
FLUSH TABLES WITH READ LOCK;再查位点，锁表期间禁止写入，确保一致性；但生产环境慎用，可用mysqldump --single-transaction --master-data=2替代
启动复制并验证状态
从库执行 START REPLICA;（8.0.22+）或 START SLAVE;（旧版）。然后立刻检查：
SHOW REPLICA STATUS\G
重点关注两行：
-
Replica_IO_Running: Yes—— 表示从库能连上主库并读取 binlog -
Replica_SQL_Running: Yes—— 表示从库能解析并执行 relay log 中的事件
若任一为 No，看 Last_IO_Error 或 Last_SQL_Error 字段。典型问题有：
-
Could not find first log file name in binary log index file：主库 binlog 文件被清理，SOURCE_LOG_FILE已不存在，需重新做全量同步 -
Slave failed to initialize relay log info structure：从库relay-log.info损坏，可停复制后删掉该文件再重启（MySQL 8.0+ 默认用表存储，影响较小） - 主从时间不同步导致 GTID 冲突（若启用了 GTID），此时需跳过事务或重置复制
GTID 模式下，CHANGE REPLICATION SOURCE TO 不要指定 SOURCE_LOG_FILE/SOURCE_LOG_POS，改用 SOURCE_AUTO_POSITION = 1。
主从延迟和数据一致性不是配完就完事的事，Seconds_Behind_Master 的波动、网络抖动、大事务、从库硬件性能都会持续影响复制质量，得盯住监控，而不是只看启动那一刻的 Yes。
