外观
MySQL 手动切换
手动切换是 MySQL 数据库高可用架构中的重要操作，它包括计划内切换和故障切换两种场景。计划内切换通常用于主库维护、升级或迁移，而故障切换则用于主库突发故障时的应急处理。正确执行手动切换操作对于保障业务连续性和数据安全性至关重要。本文将详细介绍 MySQL 手动切换的实施流程、注意事项和最佳实践，兼顾不同 MySQL 版本的差异。
切换前准备
1. 切换前检查
检查主从复制状态：
sql-- 在从库执行 SHOW SLAVE STATUS\G确认
Slave_IO_Running和Slave_SQL_Running均为Yes，Seconds_Behind_Master为0或较小值。检查从库数据一致性：
bash# 使用 pt-table-checksum 工具检测数据一致性 pt-table-checksum --nocheck-replication-filters --replicate=percona.checksums h=192.168.1.100,u=checksum_user,p=checksum_password检查从库状态：
sql-- 检查从库是否有慢查询 SHOW PROCESSLIST; -- 检查从库资源使用情况 SHOW GLOBAL STATUS LIKE 'Threads_connected'; SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_hit_rate';检查应用连接情况：
- 确认应用使用的数据库连接方式
- 确认应用是否支持切换操作
- 确认应用的切换窗口
2. 切换工具准备
MySQL 命令行工具：
- mysql
- mysqldump
- mysqlbinlog
第三方工具：
- pt-table-checksum：用于检测主从数据一致性
- pt-table-sync：用于修复主从数据不一致
- pt-slave-delay：用于控制从库延迟
- pt-online-schema-change：用于在线 schema 变更
监控工具：
- MySQL Enterprise Monitor
- Percona Monitoring and Management (PMM)
- Zabbix
- Prometheus + Grafana
3. 切换方案制定
确定切换类型：
- 计划内切换：主库维护、升级、迁移
- 故障切换：主库突发故障
确定切换窗口：
- 计划内切换：选择业务低峰期
- 故障切换：立即执行
确定切换步骤：
- 详细的切换步骤和操作命令
- 明确每个步骤的责任人
- 明确每个步骤的执行时间
确定回滚方案：
- 详细的回滚步骤和操作命令
- 明确回滚条件
- 明确回滚的责任人
确定验证方案：
- 切换后的验证步骤
- 验证数据一致性
- 验证应用可用性
计划内切换实施流程
计划内切换是指在主库正常运行的情况下，将主库角色切换到从库的操作。
1. 切换前准备
通知相关团队：
- 通知业务团队切换时间和影响范围
- 通知运维团队做好监控准备
- 通知开发团队做好应用调整准备
备份主库数据：
bash# 全量备份主库数据 mysqldump -u root -p --all-databases --master-data=2 --single-transaction > full_backup.sql停止写入操作：
- 暂停应用写入
- 或在主库设置只读：sql
SET GLOBAL read_only = ON; SET GLOBAL super_read_only = ON;
2. 主从同步确认
确认从库已追上主库：
sql-- 在从库执行 SHOW SLAVE STATUS\G确认
Seconds_Behind_Master为0。记录主库和从库的状态：
sql-- 在主库执行 SHOW MASTER STATUS; -- 在从库执行 SHOW SLAVE STATUS\G记录
Master_Log_File、Read_Master_Log_Pos、Relay_Master_Log_File和Exec_Master_Log_Pos。
3. 停止从库复制
sql
-- 在从库执行
STOP SLAVE;4. 提升从库为主库
取消从库只读状态：
sql-- 在从库执行 SET GLOBAL read_only = OFF; SET GLOBAL super_read_only = OFF;重置从库复制配置：
sql-- 在从库执行（传统复制） RESET SLAVE ALL; -- 在从库执行（GTID复制） RESET SLAVE ALL FOR CHANNEL '';
5. 原主库转为从库（可选）
停止原主库：
bashsystemctl stop mysqld修改原主库配置：
ini# 修改原主库的 server_id（如果需要） server_id = 3 # 启用 relay_log relay_log = mysql-relay-bin启动原主库：
bashsystemctl start mysqld配置原主库作为新主库的从库：
sql-- 传统复制 CHANGE MASTER TO MASTER_HOST = '192.168.1.101', MASTER_USER = 'repl', MASTER_PASSWORD = 'repl_password', MASTER_LOG_FILE = 'mysql-bin.000001', MASTER_LOG_POS = 154; -- GTID复制 CHANGE MASTER TO MASTER_HOST = '192.168.1.101', MASTER_USER = 'repl', MASTER_PASSWORD = 'repl_password', MASTER_AUTO_POSITION = 1; START SLAVE;
6. 更新应用连接配置
更新应用的数据库连接地址：
- 将应用连接从原主库切换到新主库
- 或更新中间件的配置
恢复应用写入：
- 解除应用写入限制
- 或在新主库确认写入正常
7. 切换后验证
验证新主库写入正常：
sqlCREATE DATABASE test_switch; USE test_switch; CREATE TABLE test_table (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255)); INSERT INTO test_table (name) VALUES ('test'); SELECT * FROM test_table;验证原主库作为从库同步正常：
sqlSHOW SLAVE STATUS\G确认
Slave_IO_Running和Slave_SQL_Running均为Yes。验证应用业务正常：
- 检查应用日志
- 验证业务功能正常
- 监控应用性能
故障切换实施流程
故障切换是指在主库发生故障无法正常运行时，将主库角色切换到从库的操作。
1. 故障确认
确认主库故障：
bash# 检查主库进程 ps -ef | grep mysqld # 检查主库端口 telnet 192.168.1.100 3306 # 检查主库网络 ping 192.168.1.100确认故障类型：
- 硬件故障：服务器、存储、网络等
- 软件故障：MySQL 进程崩溃、配置错误等
- 数据故障：数据损坏、丢失等
评估故障影响范围：
- 影响的业务范围
- 影响的用户数量
- 预计恢复时间
2. 选择合适的从库作为新主库
选择标准：
- 复制延迟最小
- 数据完整性最好
- 硬件配置最好
- 地理位置最优
检查从库状态：
sql-- 在候选从库执行 SHOW SLAVE STATUS\G选择
Seconds_Behind_Master最小、Relay_Master_Log_File和Exec_Master_Log_Pos最接近主库的从库。
3. 提升从库为主库
停止从库复制：
sql-- 在候选从库执行 STOP SLAVE;处理复制延迟：
- 如果复制延迟较大，评估是否可以接受数据丢失
- 或等待从库追上主库（如果主库还可以访问）
取消从库只读状态：
sql-- 在候选从库执行 SET GLOBAL read_only = OFF; SET GLOBAL super_read_only = OFF;重置从库复制配置：
sql-- 传统复制 RESET SLAVE ALL; -- GTID复制 RESET SLAVE ALL FOR CHANNEL '';
4. 其他从库指向新主库
停止其他从库的复制：
sql-- 在其他从库执行 STOP SLAVE;配置其他从库指向新主库：
sql-- 传统复制 CHANGE MASTER TO MASTER_HOST = '192.168.1.101', MASTER_USER = 'repl', MASTER_PASSWORD = 'repl_password', MASTER_LOG_FILE = 'mysql-bin.000001', MASTER_LOG_POS = 154; -- GTID复制 CHANGE MASTER TO MASTER_HOST = '192.168.1.101', MASTER_USER = 'repl', MASTER_PASSWORD = 'repl_password', MASTER_AUTO_POSITION = 1; START SLAVE;
5. 更新应用连接配置
更新应用的数据库连接地址：
- 将应用连接从原主库切换到新主库
- 或更新中间件的配置
验证应用连接正常：
- 检查应用日志
- 验证业务功能正常
6. 切换后验证
验证新主库写入正常：
sqlCREATE DATABASE test_failover; USE test_failover; CREATE TABLE test_table (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255)); INSERT INTO test_table (name) VALUES ('test'); SELECT * FROM test_table;验证其他从库同步正常：
sql-- 在其他从库执行 SHOW SLAVE STATUS\G确认
Slave_IO_Running和Slave_SQL_Running均为Yes。验证应用业务正常：
- 检查应用日志
- 验证业务功能正常
- 监控应用性能
评估数据一致性：
- 检查新主库和其他从库的数据一致性
- 处理可能的数据不一致问题
7. 原主库恢复后处理
修复原主库故障：
- 修复硬件故障
- 修复软件故障
- 恢复数据（如果需要）
将原主库作为从库加入集群：
sql-- 在原主库执行 CHANGE MASTER TO MASTER_HOST = '192.168.1.101', MASTER_USER = 'repl', MASTER_PASSWORD = 'repl_password', MASTER_AUTO_POSITION = 1; START SLAVE;
不同版本的切换差异
MySQL 5.6 手动切换特点
- 复制方式：支持传统复制和实验性 GTID 复制
- 并行复制：仅支持基于数据库的并行复制
- 半同步复制：实验性阶段，可靠性一般
- 切换工具：工具支持相对有限
- 切换复杂度：相对较高，需要手动处理较多步骤
MySQL 5.7 手动切换特点
- 复制方式：支持成熟的 GTID 复制
- 并行复制：支持基于组提交的并行复制，减少复制延迟
- 半同步复制：成熟稳定，提高数据一致性
- 切换工具：工具支持完善
- 切换复杂度：相对较低，支持更多自动化操作
- 支持多源复制：适合复杂场景
MySQL 8.0 手动切换特点
- 复制方式：增强的 GTID 复制，提高可靠性
- 并行复制：增强的并行复制，支持 WRITESET 依赖跟踪
- 半同步复制：增强的半同步复制，支持异步连接 failover
- 切换工具：工具支持丰富
- 切换复杂度：较低，支持更多自动化和简化操作
- 支持 replica 延迟监控：便于切换决策
- 重命名了部分复制相关命令：例如
SLAVE改为REPLICA
切换注意事项
1. 数据一致性
确保从库数据与主库一致：
- 切换前检查主从复制延迟
- 切换前验证数据一致性
- 避免在复制延迟较大时进行切换
处理复制中断：
- 切换前修复复制中断问题
- 避免在复制中断时进行切换
处理大事务：
- 避免在主库有大事务运行时进行切换
- 等待大事务完成后再进行切换
2. 应用影响
最小化应用停机时间：
- 计划内切换选择业务低峰期
- 优化切换步骤，减少切换时间
- 考虑使用双写或读写分离等方式减少影响
确保应用支持切换：
- 验证应用是否支持数据库切换
- 确保应用可以处理连接断开和重连
- 测试应用在切换过程中的表现
监控应用状态：
- 切换过程中监控应用日志
- 切换后验证应用功能正常
- 监控应用性能指标
3. 切换操作
严格按照切换方案执行：
- 执行前仔细检查切换步骤
- 执行过程中记录每一步操作
- 执行后验证每一步结果
确保操作权限：
- 使用具有足够权限的用户执行切换操作
- 避免使用 root 用户直接操作
- 确保切换工具具有正确的权限
做好操作回滚准备：
- 制定详细的回滚方案
- 准备好回滚所需的工具和数据
- 明确回滚条件和触发机制
4. 切换后监控
监控新主库状态：
- 监控新主库的连接数、QPS、TPS
- 监控新主库的资源使用情况
- 监控新主库的慢查询和错误日志
监控从库同步状态：
- 监控从库的复制延迟
- 监控从库的复制错误
- 监控从库的数据一致性
监控应用状态：
- 监控应用的响应时间
- 监控应用的错误率
- 监控应用的业务指标
切换最佳实践
1. 制定详细的切换方案
明确切换目标：
- 切换的原因和目的
- 切换的预期结果
- 切换的成功标准
详细的切换步骤：
- 每一步的操作命令和执行顺序
- 每一步的执行责任人
- 每一步的执行时间和超时时间
完善的回滚方案：
- 回滚的触发条件
- 回滚的步骤和操作命令
- 回滚的责任人
全面的验证方案：
- 切换前的验证步骤
- 切换过程中的验证步骤
- 切换后的验证步骤
2. 定期进行切换演练
定期演练：
- 每季度至少进行一次计划内切换演练
- 每半年至少进行一次故障切换演练
- 演练后总结经验教训，优化切换方案
模拟真实场景：
- 模拟不同类型的故障场景
- 模拟不同负载下的切换情况
- 模拟应用在切换过程中的表现
参与人员：
- 数据库运维人员
- 应用开发人员
- 业务人员
- 监控人员
3. 使用工具辅助切换
使用专业工具：
- 使用 pt-table-checksum 检测数据一致性
- 使用 pt-table-sync 修复数据不一致
- 使用 Orchestrator 辅助切换操作
自动化切换脚本：
- 编写自动化切换脚本，减少人为错误
- 脚本中包含错误处理和回滚机制
- 脚本经过充分测试后再使用
4. 文档化切换过程
记录切换过程：
- 记录每一步的操作命令和执行结果
- 记录切换过程中的问题和解决方案
- 记录切换后的验证结果
更新文档：
- 切换后更新架构文档
- 切换后更新监控配置
- 切换后更新应用配置文档
知识共享：
- 切换后组织分享会，分享经验教训
- 更新团队知识库，便于后续参考
- 培训团队成员，提高团队整体能力
常见问题与解决方案
1. 从库数据与主库不一致
症状：切换后发现新主库数据与原主库不一致
解决方案：
- 切换前使用 pt-table-checksum 检测数据一致性
- 切换前使用 pt-table-sync 修复数据不一致
- 切换后再次检测和修复数据一致性
- 考虑使用半同步复制或 MGR 提高数据一致性
2. 切换后应用无法连接新主库
症状：应用无法连接新主库，报连接错误
解决方案：
- 检查新主库的网络和端口
- 检查新主库的用户权限
- 检查新主库的防火墙配置
- 检查应用的连接配置
3. 切换后复制延迟增大
症状：新主库的从库复制延迟增大
解决方案：
- 优化新主库的硬件配置
- 调整新主库的复制参数
- 启用并行复制，增加并行复制线程数
- 减少新主库的写负载
4. 切换后新主库性能下降
症状：新主库的 QPS、TPS 下降，响应时间增大
解决方案：
- 优化新主库的硬件配置
- 调整新主库的参数配置
- 优化新主库的索引和查询
- 考虑增加新主库的从库，分担读负载
5. 切换后原主库无法作为从库加入集群
症状：原主库修复后无法作为从库连接新主库
解决方案：
- 检查原主库的配置
- 检查原主库的 GTID 配置
- 重置原主库的复制配置
- 考虑重新初始化原主库
总结
手动切换是 MySQL 数据库高可用架构中的重要操作，它要求 DBA 具备丰富的经验和严谨的操作流程。正确执行手动切换操作需要做好充分的准备工作，包括切换前检查、工具准备、方案制定等。在切换过程中，需要严格按照切换方案执行，注意数据一致性和应用影响，做好操作记录和监控。切换后需要进行全面的验证和监控，确保系统正常运行。
不同 MySQL 版本的切换操作存在差异，DBA 需要根据实际版本选择合适的切换方式和工具。通过定期进行切换演练、使用专业工具辅助切换、文档化切换过程等最佳实践，可以提高切换操作的成功率和效率，保障业务的连续性和数据的安全性。