如何在生产环境中安全更换MySQL主从复制的Master节点？-mysql教程-PHP中文网

必须确认从库已完全追平：Slave_IO_Running=No、Slave_SQL_Running=Yes、SHOW PROCESSLIST显示“Has read all relay log”，再核对Relay_Master_Log_File与Exec_Master_Log_Pos；之后STOP SLAVE、RESET SLAVE ALL、关闭read_only，最后用SHOW MASTER STATUS配置其他从库。

如何在生产环境中安全更换mysql主从复制的master节点？

能换，但必须先确认从库已完全应用完所有中继日志，否则必然丢数据；关键不是“停不停”，而是“有没有真正追平”。

怎么判断从库是否真的追平了原主库？

很多人只看 Seconds_Behind_Master = 0 就动手，这是最常见误操作起点。这个值在主库宕机后会变成 NULL 或停滞不更新，完全不可信。

真正可靠的判断依据是这三点同时满足：

Slave_IO_Running: No（说明已连不上原主库，IO线程停了）
Slave_SQL_Running: Yes（SQL线程还在跑）
执行 SHOW PROCESSLIST，看到 SQL 线程的 State 是 Has read all relay log; waiting for more updates

再查 Relay_Master_Log_File 和 Exec_Master_Log_Pos，这两个值代表它最后执行到原主库哪条 binlog，后续切换时其他节点要用。

STOP SLAVE 和 RESET SLAVE ALL 的区别与风险

STOP SLAVE 只暂停复制线程，master.info 和 relay-log.info 文件都还留着；而 RESET SLAVE ALL 会彻底删掉这两个文件，清空所有复制元数据。

所以：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

计划内切换且原主库确定不再回归 → 用 RESET SLAVE ALL
只是临时断开、后续可能切回 → 用 STOP SLAVE + 手动记录 SHOW SLAVE STATUS\G 输出，避免信息丢失

特别注意：如果复制参数写死在 my.cnf 里（比如 master-host=），RESET SLAVE ALL 后重启 MySQL 仍会读配置自动重连，导致意外恢复旧关系 —— 这就是为什么官方强烈建议不要把复制配置放配置文件里。

CHANGE MASTER TO 指向新主库时最关键的三个参数

其他参数可以省略，但这三个必须显式指定，否则容易连错位置或跳过事务：

MASTER_LOG_FILE = 'mysql-bin.000012'：必须填新主库上 SHOW MASTER STATUS 返回的 File 值，不是从旧状态里抄的
MASTER_LOG_POS = 154：对应上面 File 的起始偏移，通常为 154（MySQL 8.0+ 默认），但不能假设，得实查
MASTER_AUTO_POSITION = 0：如果没开 GTID，必须显式关掉，否则 CHANGE MASTER TO 会忽略 MASTER_LOG_FILE 和 MASTER_LOG_POS，直接报错

示例命令：

CHANGE MASTER TO 
  MASTER_HOST='192.168.1.20', 
  MASTER_USER='repl', 
  MASTER_PASSWORD='repl_pass', 
  MASTER_LOG_FILE='mysql-bin.000003', 
  MASTER_LOG_POS=154, 
  MASTER_AUTO_POSITION=0;

切换后最容易被跳过的验证动作

很多故障出现在“以为切成功了”之后，尤其是以下三项常被跳过：

在新主库执行一条带时间戳的测试写入：INSERT INTO test_switch VALUES (NOW());
立即在新从库查这条记录是否出现、时间是否一致
检查新从库的 SHOW SLAVE STATUS\G 中 Seconds_Behind_Master 是否保持为 0，且 Retrieved_Gtid_Set 和 Executed_Gtid_Set 相等（若启用 GTID）

特别注意：应用连接字符串里的 host 和端口是否已指向新主库，DNS 缓存 或连接池可能仍连着老地址 —— 这类问题不会报错，只会静默写错库。