MySQL Replication主从角色切换：Slave升级为Master的操作流程咨询

Got it，我来一步步拆解这个切换流程，确保数据一致性和服务平稳过渡——毕竟线上操作容不得半点马虎：

一、切换前的准备检查（必做！） #

• 先确认Slave的同步状态完全正常，在Slave节点执行：

  SHOW SLAVE STATUS\G
  

  重点核对这几个关键字段：
  • Slave_IO_Running 和 Slave_SQL_Running 必须都是 Yes
  • Seconds_Behind_Master 为 0（或非常接近0，确保数据完全追平旧Master）
  • 记录下 Relay_Master_Log_File 和 Exec_Master_Log_Pos 的值，万一后续需要排查问题能用上
• 暂停所有写入旧Master的业务流量：如果是线上服务，建议先切到只读模式，或者在低峰期操作，避免切换过程中出现数据不一致
• 备份旧Master的最新数据（可选但强烈建议）：用mysqldump做个全量备份，防止切换出问题能快速回滚

  mysqldump -u root -p --all-databases --master-data=2 --single-transaction > master_backup_$(date +%Y%m%d).sql
  

二、正式执行切换操作 #

1. 停止Slave的同步进程 #

在Slave节点执行命令，停止IO和SQL同步线程：

STOP SLAVE;

再执行一次 SHOW SLAVE STATUS\G 确认，Slave_IO_Running 和 Slave_SQL_Running 应该显示为 No，确保同步已经完全停止。

2. 将Slave升级为新Master #

在Slave节点执行以下命令，开启写入权限并重置主节点配置：

# 关闭只读模式（如果之前Slave设置了只读的话）
SET GLOBAL read_only = OFF;
# 重置二进制日志，生成新的日志文件，标记该节点为独立Master
RESET MASTER;

RESET MASTER 会清空旧的二进制日志索引，创建新的二进制日志文件，这一步完成后，这个节点就可以接收业务的写入请求了。

3. 切换业务流量到新Master #

把所有业务系统的数据库连接地址、端口等配置更新为新Master的信息，确保所有写入和读取流量都切换到新节点。可以通过监控工具或者业务日志确认流量已经完全迁移，没有请求再打到旧Master上。

4. 停用旧Master #

确认旧Master已经没有任何业务流量后，停止其MySQL服务：

# 针对systemd系统（如CentOS7+/Ubuntu16.04+）
systemctl stop mysqld
# 针对传统init.d系统
service mysqld stop

如果后续不再使用旧Master，可以考虑卸载服务或者归档服务器资源。

三、切换后的验证工作 #

• 验证新Master的写入能力：插入一条测试数据并查询确认

  INSERT INTO your_test_db.test_table (content) VALUES ('master_switch_test');
  SELECT * FROM your_test_db.test_table WHERE content = 'master_switch_test';
  

• 如果需要搭建新的Slave节点（比如把旧Master重新配置为新Master的Slave），可以在新Master上查看当前二进制日志位置：

  SHOW MASTER STATUS\G
  

  记录下 File 和 Position 的值，然后在新Slave节点配置同步即可。

额外注意事项 #

• 如果是故障切换（旧Master已经宕机无法恢复）：需要先确保Slave已经同步了所有可用的日志，若遇到同步错误，可谨慎使用 SET GLOBAL sql_slave_skip_counter = 1; 跳过错误（前提是确认该错误不影响数据一致性），再停止Slave并升级为Master
• 线上操作务必先在测试环境完整演练一遍，熟悉流程和可能出现的问题
• 如果有多个Slave节点，切换完成后需要将其他Slave重新指向新Master进行同步

内容的提问来源于stack exchange，提问作者Nuwan Vithanage