如何配置MySQL 8.0的双机主备（Master-Slave）复制环境？-mysql教程-PHP中文网

mysql 8.0主从复制能稳定运行的关键在于三点：两端配置对称性、gtid一致性、认证插件兼容性；任一缺失会导致start slave失败或slave_io_running: no。

如何配置mysql 8.0的双机主备（master-slave）复制环境？

直接说结论：MySQL 8.0 的主从复制（Master-Slave）能稳定跑起来，关键不在“配对”，而在两端配置对称性、GTID一致性、认证插件兼容性这三点踩准了。漏一个，START SLAVE 就卡在 Slave_IO_Running: No 或报错 ERROR 2061。

server-id 和 log-bin 必须显式开启且互斥

主库和从库的 server-id 绝对不能相同，也别用 1 这种默认值——容易和别人撞；log-bin 只需主库开，但从库如果后续要升级为主（比如故障切换），建议提前加上 log-bin 并设 log_slave_updates = ON，否则切过去后无法继续向下游同步。

主库配置片段：server-id = 100 + log-bin = mysql-bin + binlog_format = ROW
从库配置片段：server-id = 101（必须不同），log-bin 可选但推荐加，log_slave_updates = ON 在需要级联或倒切时才生效
改完 /etc/my.cnf 后必须重启 mysqld，仅 FLUSH LOGS 不生效

CREATE USER 要匹配 MySQL 8.0 默认认证插件

MySQL 8.0 默认用 caching_sha2_password，而旧客户端或某些中间件可能不支持。如果从库连不上主库，SHOW SLAVE STATUS 显示 Last_IO_Error: error connecting to master，大概率是这个原因。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

创建复制用户时，显式指定插件：CREATE USER 'repl'@'%' IDENTIFIED WITH caching_sha2_password BY 'your_strong_pwd';
如果下游是老版本客户端（如 Python 3.7 以下 + PyMySQL），可降级为：CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'your_strong_pwd';
执行完记得 GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES;

CHANGE MASTER TO 必须用 GTID 模式且位置一致

MySQL 8.0 默认开启 GTID，CHANGE MASTER TO 如果还按老办法填 MASTER_LOG_FILE 和 MASTER_LOG_POS，会直接忽略，导致同步从头开始或中断。

主库上先查：SHOW MASTER STATUS; 看 Executed_Gtid_Set（空则说明没事务）
从库执行：CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_USER='repl', MASTER_PASSWORD='your_strong_pwd', MASTER_PORT=3306, MASTER_AUTO_POSITION = 1;
MASTER_AUTO_POSITION = 1 是关键——它让从库自动匹配 GTID，不再依赖日志文件名和 position
启动后检查：SHOW SLAVE STATUS\G，确认 Slave_IO_Running: Yes、Slave_SQL_Running: Yes、Seconds_Behind_Master 趋近于 0