如何搭建mysql主从环境_mysql复制环境搭建

mysql主从复制需主库开启binlog并设唯一server-id；从库须用主库当前binlog文件名和position手动配置同步起点；启动后必须检查IO/SQL线程状态及延迟。

主库必须开启 binlog 且设置唯一 server-id

MySQL 主从复制依赖 binlog 记录写操作，如果 my.cnf 中没启用 log-bin，从库连日志都拉不到，复制必然失败。同时，server-id 必须是整数且主从不能相同——哪怕只是临时测试，设成 1 和 2 最稳妥。

常见错误：只加了 log-bin=mysql-bin 却漏掉 server-id，或两个实例用了同一个 server-id=1，此时执行 START SLAVE 会静默失败，SHOW SLAVE STATUSG 里 Seconds_Behind_Master 为 NULL，Slave_IO_Running 显示 No，但错误日志里可能只有一行 Could not find first log file name in binary log index file，容易误判为日志文件丢失。

建议配置段示例：

[mysqld] server-id = 1 log-bin = mysql-bin binlog-format = ROW skip-slave-start = 1

从库需用主库的 binlog 文件名和 position 手动指定同步起点

不是所有场景都能用 mysqldump --master-data 自动带出位置信息；如果主库已有数据、又没锁表导出，就得靠 SHOW MASTER STATUS 查当前日志名和偏移量，再在从库执行 CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或旧版 CHANGE MASTER TO 手动对齐。

关键点：

• SOURCE_HOST 填主库可被从库访问的 IP 或域名，不是 127.0.0.1
• SOURCE_LOG_FILE 和 SOURCE_LOG_POS 必须严格匹配 SHOW MASTER STATUS 输出的 File 和 Position
• 账号需有 REPLICATION SLAVE 权限，不能只给 select

执行示例（MySQL 8.0.26）：

CHANGE REPLICATION SOURCE TO   SOURCE_HOST='192.168.1.10',   SOURCE_USER='repl',   SOURCE_PASSword='p@ssw0rd',   SOURCE_LOG_FILE='mysql-bin.000003',   SOURCE_LOG_POS=154;

启动复制后务必检查两个线程状态和延迟

START REPLICA（或旧版 START SLAVE）只是发起指令，不代表复制已正常运行。必须立刻查 SHOW REPLICA STATUSG（MySQL 8.0.22+）或 SHOW SLAVE STATUSG，重点盯住三项：

• Replica_IO_Running：对应拉日志的 I/O 线程，Yes 才说明网络通、账号对、日志可读
• Replica_SQL_Running：对应回放日志的 SQL 线程，Yes 表示解析和执行无阻塞
• Seconds_Behind_Master：非 NULL 且数值稳定下降才算真正追上；若长期为 0 但 Replica_SQL_Running 是 No，大概率是某条语句执行报错卡住了

遇到 SQL 线程停摆，先看 Last_SQL_Error 字段，常见如主从表结构不一致、从库有写入导致主键冲突、或者启用了 read_only=1 但忘了给复制账号加 SUPER 权限（MySQL 5.7 及以前）。

ROW 格式比 STATEMENT 更可靠，但要注意主从版本兼容性

用 STATEMENT 格式时，像 NOW()、UUID()、INSERT ... SELECT 这类非确定性语句，在从库重放可能结果不同，引发数据不一致。默认选 ROW 能规避这类问题，但要注意：

• MySQL 5.6 从库无法识别 5.7+ 写入的 row-based 日志（因新增字段），主从版本差一个大版本就可能同步中断
• binlog-row-image=FULL（默认）会记录整行变更，安全但日志体积大；MINIMAL 节省空间，但要求主从表结构完全一致，否则从库解析失败
• 如果主库开了 innodb_autoinc_lock_mode=2（交错模式），而从库是 5.7 以下，AUTO_INCREMENT 值可能不一致

生产环境建议主从 MySQL 小版本号尽量一致，至少保证大版本相同，比如都是 8.0.x。

主从复制不是一劳永逸的事，最常出问题的地方不在搭建过程，而在后续主库结构变更（如 ALTER table）、从库意外写入、或网络抖动后 IO 线程没自动重连——这些都需要监控脚本或定期人工核对 Seconds_Behind_Master 和线程状态。