MySQL 切换演练

切换演练是 MySQL 高可用运维的重要组成部分，通过定期演练可以验证切换流程的正确性，提高 DBA 团队的应急响应能力，确保在真实故障发生时能够快速、准确地进行切换。本文将详细介绍 MySQL 切换演练的流程和实践，包括计划性切换演练和故障切换演练，兼顾不同 MySQL 版本的差异，帮助 DBA 团队制定和执行有效的切换演练方案。

切换演练概述

1. 切换演练的目的

验证切换流程：验证切换流程的正确性和可行性
提高团队能力：提高 DBA 团队的应急响应能力
发现潜在问题：发现切换过程中可能存在的问题
减少业务影响：减少真实故障发生时的业务中断时间
符合合规要求：满足行业合规要求

2. 切换演练的类型

演练类型	特点	适用场景
计划性切换演练	主库正常运行，按照预定流程进行切换	计划性维护前的验证
故障切换演练	模拟主库故障，测试故障检测和切换能力	故障恢复能力验证
灾难恢复演练	模拟数据中心级故障，测试灾备能力	灾难恢复能力验证

3. 切换演练的关键要素

演练计划：详细的演练步骤和时间表
演练环境：与生产环境相似的演练环境
演练团队：明确的团队分工和职责
监控和记录：详细监控和记录演练过程
回滚计划：完整的回滚方案
演练评估：演练后的评估和改进

切换演练准备

1. 演练环境准备

1.1 环境要求

与生产环境相似的硬件和软件配置
与生产环境相似的复制拓扑
与生产环境相似的应用负载（可选）
独立的网络环境，避免影响生产环境

1.2 环境搭建

bash

# 搭建演练环境的步骤
1. 准备演练服务器
2. 安装 MySQL 数据库
3. 配置主从复制或 MGR
4. 配置监控和告警
5. 部署应用模拟工具（可选）

2. 演练计划制定

2.1 演练目标

明确演练的具体目标和范围
确定演练的成功标准
确定演练的时间和时长

2.2 演练步骤

详细的演练步骤和时间点
每个步骤的责任人和操作内容
预期结果和验证方法

2.3 回滚计划

详细的回滚步骤
回滚的触发条件
回滚后的验证方法

2.4 沟通计划

演练前的通知范围和方式
演练过程中的沟通渠道
演练后的总结和报告

3. 演练团队准备

3.1 团队分工

角色	职责
演练负责人	负责演练的整体协调和指挥
DBA 团队	负责数据库切换操作
应用团队	负责应用切换和验证
监控团队	负责监控演练过程
运维团队	负责服务器和网络支持
业务团队	负责业务验证

3.2 培训和准备

确保所有团队成员了解演练流程
确保所有团队成员掌握必要的技能
准备必要的工具和脚本

计划性切换演练流程

1. 演练前准备

1.1 环境检查

sql

-- 检查主从状态
SHOW SLAVE STATUS\G

-- 检查复制延迟
SHOW GLOBAL STATUS LIKE 'Seconds_Behind_Master';

-- 检查主库状态
SHOW MASTER STATUS;

-- 检查数据库连接
SHOW GLOBAL STATUS LIKE 'Threads_connected';

1.2 应用准备

通知应用团队演练时间
确保应用可以承受短暂的业务中断
准备应用验证脚本

2. 演练执行

2.1 切换前验证

bash

# 记录当前主库状态
mysql -u root -pRoot@123456 -e "SHOW MASTER STATUS\G" > master_status_before.txt

# 记录当前从库状态
mysql -u root -pRoot@123456 -e "SHOW SLAVE STATUS\G" > slave_status_before.txt

# 执行数据一致性检查
pt-table-checksum h=192.168.1.101,u=checksum,p=Checksum@123456 --databases=test

2.2 执行切换

sql

-- 1. 主库锁定表
FLUSH TABLES WITH READ LOCK;

-- 2. 记录主库二进制日志位置
SHOW MASTER STATUS;

-- 3. 从库等待复制完成
SELECT MASTER_POS_WAIT('mysql-bin.000001', 156);

-- 4. 从库停止复制
STOP SLAVE;
RESET SLAVE ALL;

-- 5. 从库解除只读模式
SET GLOBAL read_only = 0;
SET GLOBAL super_read_only = 0;

-- 6. 主库解锁表
UNLOCK TABLES;

-- 7. 主库设置为只读
SET GLOBAL read_only = 1;
SET GLOBAL super_read_only = 1;

-- 8. 主库作为从库连接到新主库
CHANGE MASTER TO
  MASTER_HOST = '192.168.1.102',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'Repl@123456',
  MASTER_AUTO_POSITION = 1;

-- 9. 启动复制
START SLAVE;

2.3 应用切换

更新应用的数据库连接配置
重启应用或刷新连接池
验证应用连接

2.4 切换后验证

sql

-- 验证新主库状态
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Queries';

-- 测试写操作
CREATE DATABASE test_switchover_drill;
CREATE TABLE test_switchover_drill.test_table (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(20));
INSERT INTO test_switchover_drill.test_table (name) VALUES ('drill_test');
SELECT * FROM test_switchover_drill.test_table;

-- 验证从库复制状态
SHOW SLAVE STATUS\G;

3. 演练后处理

3.1 恢复原拓扑（可选）

sql

-- 1. 新主库锁定表
FLUSH TABLES WITH READ LOCK;

-- 2. 原主库等待复制完成
SELECT MASTER_POS_WAIT('mysql-bin.000001', 156);

-- 3. 原主库停止复制
STOP SLAVE;
RESET SLAVE ALL;

-- 4. 原主库解除只读模式
SET GLOBAL read_only = 0;
SET GLOBAL super_read_only = 0;

-- 5. 新主库解锁表
UNLOCK TABLES;

-- 6. 新主库设置为只读
SET GLOBAL read_only = 1;
SET GLOBAL super_read_only = 1;

-- 7. 新主库作为从库连接到原主库
CHANGE MASTER TO
  MASTER_HOST = '192.168.1.101',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'Repl@123456',
  MASTER_AUTO_POSITION = 1;

-- 8. 启动复制
START SLAVE;

3.2 演练总结

记录演练过程中的问题和解决方案
评估演练的成功与否
提出改进建议
编写演练报告

故障切换演练流程

1. 演练前准备

1.1 环境检查

sql

-- 检查主从状态
SHOW SLAVE STATUS\G

-- 检查复制延迟
SHOW GLOBAL STATUS LIKE 'Seconds_Behind_Master';

-- 检查监控状态
-- 确保监控系统正常运行

1.2 故障模拟准备

bash

# 准备故障模拟工具和脚本
# 1. 网络中断模拟脚本
# 2. MySQL 进程终止脚本
# 3. 服务器关机脚本

2. 演练执行

2.1 故障模拟

bash

# 模拟主库网络中断
iptables -A INPUT -s 192.168.1.102 -p tcp --dport 3306 -j DROP

# 或模拟 MySQL 进程终止
pkill -9 mysqld

# 或模拟服务器关机
echo b > /proc/sysrq-trigger

2.2 故障检测

sql

-- 监控系统检测到主库故障
-- 记录故障检测时间

-- 从库检查主库状态
SHOW SLAVE STATUS\G;

-- 检查从库是否自动提升为主库（如果配置了自动切换）
SHOW GLOBAL VARIABLES LIKE 'read_only';

2.3 手动切换（如果自动切换失败）

sql

-- 1. 选择合适的从库
-- 2. 停止从库复制
STOP SLAVE;
RESET SLAVE ALL;

-- 3. 从库解除只读模式
SET GLOBAL read_only = 0;
SET GLOBAL super_read_only = 0;

-- 4. 如果使用 GTID 复制，确保所有事务已提交
SET @@GLOBAL.gtid_purged = (SELECT @@GLOBAL.gtid_executed);

2.4 应用切换和验证

更新应用的数据库连接配置
重启应用或刷新连接池
验证应用连接和业务功能

2.5 其他从库重新指向新主库

sql

-- 其他从库停止复制
STOP SLAVE;

-- 重置从库复制信息
RESET SLAVE ALL;

-- 重新指向新主库
CHANGE MASTER TO
  MASTER_HOST = '192.168.1.102',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'Repl@123456',
  MASTER_AUTO_POSITION = 1;

-- 启动复制
START SLAVE;

-- 验证复制状态
SHOW SLAVE STATUS\G;

3. 演练后处理

3.1 故障恢复

bash

# 恢复主库网络
iptables -D INPUT -s 192.168.1.102 -p tcp --dport 3306 -j DROP

# 或重启 MySQL 进程
systemctl start mysqld

# 或重启服务器
# 服务器自动重启

3.2 原主库重新加入集群

sql

-- 原主库作为从库连接到新主库
CHANGE MASTER TO
  MASTER_HOST = '192.168.1.102',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'Repl@123456',
  MASTER_AUTO_POSITION = 1;

-- 启动复制
START SLAVE;

-- 验证复制状态
SHOW SLAVE STATUS\G;

3.3 演练总结

记录故障检测时间和切换时间
分析故障切换过程中的问题
评估故障切换的效果
提出改进建议
编写演练报告

不同 MySQL 版本的切换演练差异

MySQL 5.6

复制延迟可能较高，影响切换演练的效果
GTID 支持有限，切换流程复杂
自动切换方案选择有限
监控和管理工具相对简单

MySQL 5.7

增强了 GTID 复制的可靠性，切换流程简化
支持基于逻辑时钟的并行复制，减少复制延迟
支持更多自动切换方案
增强了监控和管理工具

MySQL 8.0

引入了 MGR，原生支持自动故障切换
增强了 GTID 复制的性能
支持基于 WRITESET 的并行复制，进一步减少复制延迟
与 MGR 集成良好，支持自动故障切换
增强了监控和管理工具

切换演练最佳实践

1. 演练计划

制定详细的演练计划和回滚计划
选择合适的演练时间，避免业务高峰期
提前通知相关团队和业务方
明确演练的目标和范围

2. 演练环境

使用与生产环境相似的演练环境
定期更新演练环境，确保与生产环境一致
隔离演练环境，避免影响生产环境

3. 演练执行

严格按照演练计划执行
详细记录演练过程和时间点
实时监控演练过程，及时处理异常
执行完整的回滚测试

4. 演练评估

演练后进行全面评估
分析演练过程中的问题和改进点
编写详细的演练报告
跟踪改进措施的落实

5. 自动化辅助

使用自动化工具辅助演练
编写自动化脚本，减少人为错误
利用监控工具记录演练过程
实现演练结果的自动分析

切换演练工具

1. pt-switchover

1.1 工具介绍

pt-switchover 是 Percona Toolkit 中的一个工具，用于自动化 MySQL 主从切换，支持计划性切换和故障切换。

1.2 使用示例

bash

# 计划性切换演练
pt-switchover --master-host=192.168.1.101 --master-port=3306 --master-user=root --master-password=Root@123456 \
--slave-host=192.168.1.102 --slave-port=3306 --slave-user=root --slave-password=Root@123456 \
--force --verbose --dry-run

# 实际执行切换
pt-switchover --master-host=192.168.1.101 --master-port=3306 --master-user=root --master-password=Root@123456 \
--slave-host=192.168.1.102 --slave-port=3306 --slave-user=root --slave-password=Root@123456 \
--force --verbose

2. Orchestrator

2.1 工具介绍

Orchestrator 是一个开源的 MySQL 复制拓扑管理工具，支持自动故障切换、复制拓扑管理和可视化监控。

2.2 使用示例

bash

# 使用 Orchestrator 进行手动切换
curl -X POST -u admin:Admin@123456 "http://orchestrator:3000/api/switchover?master=192.168.1.101:3306&slave=192.168.1.102:3306"

# 使用 Orchestrator 进行故障切换
curl -X POST -u admin:Admin@123456 "http://orchestrator:3000/api/recover?instance=192.168.1.101:3306"

3. MGR 自动切换

3.1 工具介绍

MGR 是 MySQL 8.0 引入的原生高可用方案，支持自动故障切换。

3.2 演练示例

sql

-- 查看 MGR 状态
SELECT * FROM performance_schema.replication_group_members;

-- 模拟主库故障
pkill -9 mysqld

-- 查看 MGR 自动切换结果
SELECT * FROM performance_schema.replication_group_members;

切换演练常见问题与解决方案

1. 演练环境与生产环境不一致

症状：演练环境与生产环境的配置或拓扑不一致，导致演练结果不可靠

解决方案：

定期更新演练环境，确保与生产环境一致
使用配置管理工具同步配置
建立演练环境的自动构建机制

2. 演练过程中出现意外问题

症状：演练过程中出现预期之外的问题，影响演练进度

解决方案：

制定详细的回滚计划
提前准备应急方案
演练团队保持沟通，及时处理问题

3. 切换时间超过预期

症状：切换时间超过预期，影响业务可用性

解决方案：

优化切换流程，减少切换步骤
提高团队的操作熟练度
考虑使用自动化工具

4. 应用切换失败

症状：数据库切换成功，但应用无法连接或功能异常

解决方案：

提前测试应用的切换兼容性
优化应用的连接管理
实现应用的自动重连机制

总结

切换演练是 MySQL 高可用运维的重要组成部分，通过定期演练可以验证切换流程的正确性，提高 DBA 团队的应急响应能力。计划性切换演练和故障切换演练是两种主要的演练类型，需要根据实际需求选择合适的演练方式。不同 MySQL 版本的切换演练流程略有差异，需要根据实际版本进行调整。

在进行切换演练时，需要注意以下几点：

制定详细的演练计划和回滚计划
使用与生产环境相似的演练环境
严格按照演练计划执行
详细记录演练过程和时间点
演练后进行全面评估和总结
跟踪改进措施的落实

通过合理的切换演练，可以确保在真实故障发生时，DBA 团队能够快速、准确地进行切换，减少业务中断时间，提高系统的可用性。

MySQL 切换演练 ​

切换演练概述 ​

1. 切换演练的目的 ​

2. 切换演练的类型 ​

3. 切换演练的关键要素 ​

切换演练准备 ​

1. 演练环境准备 ​

1.1 环境要求 ​

1.2 环境搭建 ​

2. 演练计划制定 ​

2.1 演练目标 ​

2.2 演练步骤 ​

2.3 回滚计划 ​

2.4 沟通计划 ​

3. 演练团队准备 ​

3.1 团队分工 ​

3.2 培训和准备 ​

计划性切换演练流程 ​

1. 演练前准备 ​

1.1 环境检查 ​

1.2 应用准备 ​

2. 演练执行 ​

2.1 切换前验证 ​

2.2 执行切换 ​

2.3 应用切换 ​

2.4 切换后验证 ​

3. 演练后处理 ​

3.1 恢复原拓扑（可选） ​

3.2 演练总结 ​

故障切换演练流程 ​

1. 演练前准备 ​

1.1 环境检查 ​

1.2 故障模拟准备 ​

2. 演练执行 ​

2.1 故障模拟 ​

2.2 故障检测 ​

2.3 手动切换（如果自动切换失败） ​

2.4 应用切换和验证 ​

2.5 其他从库重新指向新主库 ​

3. 演练后处理 ​

3.1 故障恢复 ​

3.2 原主库重新加入集群 ​

3.3 演练总结 ​

不同 MySQL 版本的切换演练差异 ​

MySQL 5.6 ​

MySQL 5.7 ​

MySQL 8.0 ​

切换演练最佳实践 ​

1. 演练计划 ​

2. 演练环境 ​

3. 演练执行 ​

4. 演练评估 ​

5. 自动化辅助 ​

切换演练工具 ​

1. pt-switchover ​

1.1 工具介绍 ​

1.2 使用示例 ​

2. Orchestrator ​

2.1 工具介绍 ​

2.2 使用示例 ​

3. MGR 自动切换 ​

3.1 工具介绍 ​

3.2 演练示例 ​

切换演练常见问题与解决方案 ​

1. 演练环境与生产环境不一致 ​

2. 演练过程中出现意外问题 ​

3. 切换时间超过预期 ​

4. 应用切换失败 ​

总结 ​

MySQL 切换演练

切换演练概述

1. 切换演练的目的

2. 切换演练的类型

3. 切换演练的关键要素

切换演练准备

1. 演练环境准备

1.1 环境要求

1.2 环境搭建

2. 演练计划制定

2.1 演练目标

2.2 演练步骤

2.3 回滚计划

2.4 沟通计划

3. 演练团队准备

3.1 团队分工

3.2 培训和准备

计划性切换演练流程

1. 演练前准备

1.1 环境检查

1.2 应用准备

2. 演练执行

2.1 切换前验证

2.2 执行切换

2.3 应用切换

2.4 切换后验证

3. 演练后处理

3.1 恢复原拓扑（可选）

3.2 演练总结

故障切换演练流程

1. 演练前准备

1.1 环境检查

1.2 故障模拟准备

2. 演练执行

2.1 故障模拟

2.2 故障检测

2.3 手动切换（如果自动切换失败）

2.4 应用切换和验证

2.5 其他从库重新指向新主库

3. 演练后处理

3.1 故障恢复

3.2 原主库重新加入集群

3.3 演练总结

不同 MySQL 版本的切换演练差异

MySQL 5.6

MySQL 5.7

MySQL 8.0

切换演练最佳实践

1. 演练计划

2. 演练环境

3. 演练执行

4. 演练评估

5. 自动化辅助

切换演练工具

1. pt-switchover

1.1 工具介绍

1.2 使用示例

2. Orchestrator

2.1 工具介绍

2.2 使用示例

3. MGR 自动切换

3.1 工具介绍

3.2 演练示例

切换演练常见问题与解决方案

1. 演练环境与生产环境不一致

2. 演练过程中出现意外问题

3. 切换时间超过预期

4. 应用切换失败

总结