在MySQL主从复制架构中,当主库(Master)宕机后,需要将从库(Slave)提升为新主库(Promote to Master),并确保其他从库重新指向新主库。以下是详细操作步骤:
1. 确认主库状态
首先确认原主库确实无法恢复(如硬件故障或长时间不可用):
# 尝试连接原主库
mysql -h [原主库IP] -u root -p
2. 选择并提升从库为新主库
2.1 确保从库数据一致
在目标从库上执行:
STOP SLAVE;
SHOW SLAVE STATUS \G
检查 Seconds_Behind_Master
是否为 0
(表示数据已同步完成),且无报错。
2.2 重置从库角色
RESET SLAVE ALL; -- 清除所有复制信息(MySQL 5.7+/8.0)
RESET MASTER; -- 如果该从库曾作为其他实例的主库,清理二进制日志
2.3 启用写操作
SET GLOBAL read_only = OFF; -- 关闭只读模式
3. 配置其他从库指向新主库
在其他从库上执行:
STOP SLAVE;
CHANGE MASTER TO
MASTER_HOST = '[新主库IP]',
MASTER_USER = 'repl_user',
MASTER_PASSWORD = 'password',
MASTER_AUTO_POSITION = 1; -- GTID复制方式推荐
START SLAVE;
4. (可选)原主库恢复后的处理
若原主库恢复后需降级为从库:
RESET MASTER;
CHANGE MASTER TO
MASTER_HOST = '[新主库IP]',
MASTER_USER = 'repl_user',
MASTER_PASSWORD = 'password';
START SLAVE;
5. 验证复制状态
在所有从库上检查:
SHOW SLAVE STATUS \G
确认 Slave_IO_Running
和 Slave_SQL_Running
均为 Yes
。
关键注意事项
GTID vs Binlog Position
- GTID模式(推荐):使用
MASTER_AUTO_POSITION=1
,避免手动定位日志位置。 - Binlog模式:需记录故障前的主库
File
和Position
。
- GTID模式(推荐):使用
应用层配置
- 更新应用连接字符串至新主库IP。
- DNS或代理层(如HAProxy)需及时切换流量。
高可用工具
- 考虑使用Orchestrator、MHA或Keepalived自动化故障转移。
数据一致性校验
- 使用
pt-table-checksum
+pt-table-sync
(Percona Toolkit)修复差异。
- 使用
通过以上步骤可完成人工切换。对于生产环境,建议提前演练并配置监控工具(如Prometheus + Grafana)实时检测复制延迟。
内容由零声教学AI助手提供,问题来源于学员提问