验证MySQL主从切换后数据一致性的测试用例设计

主从切换是MySQL高可用架构的核心环节，数据一致性的验证需覆盖正常场景、边界场景和异常场景，结合“全量校验+增量追踪+业务校验”三层验证逻辑，确保切换后数据无丢失、无篡改、无冗余。

一、测试前置条件与环境准备

准备项	具体要求
主从架构状态	主从复制正常（IO线程、SQL线程运行正常），无延迟（Seconds_Behind_Master=0）
测试数据基数	包含多种数据类型（int/varchar/datetime/blob等）、索引（主键/唯一索引/普通索引）、约束（外键/非空/默认值）
工具准备	校验工具（mysqldump、pt-table-checksum）、binlog解析工具（mysqlbinlog）、监控工具（Prometheus+Grafana）
切换触发方式	覆盖手动切换（stop slave; reset master;）和自动切换（如MHA、Orchestrator触发）

二、核心测试用例设计（按场景分类）

场景1：正常切换（无业务写入时切换）

测试目标：验证无数据写入时，切换后从库（新主库）与原主库数据完全一致。

测试步骤	验证点	预期结果
1. 切换前：在主库执行全量数据校验（如pt-table-checksum），记录校验值	确认切换前主从数据已一致	主从所有表校验值相同，无差异记录
2. 停止主库所有写入业务（flush tables with read lock;）	确保切换过程无新数据写入	主库处于只读状态，业务写入阻塞
3. 触发主从切换（如将从库提升为主库，原主库降为从库）	切换流程无报错，新主库可正常提供服务	切换成功，新主库read_only=OFF，原主库read_only=ON
4. 切换后：在新主库执行全量校验，与切换前主库校验值对比	全量数据无新增差异	新主库所有表校验值与切换前主库完全一致
5. 验证特殊对象一致性（视图、存储过程、触发器、事件）	结构定义与内容无丢失	新主库information_schema中记录的对象与原主库完全一致

场景2：有增量写入时切换（模拟业务正常运行）

测试目标：验证切换过程中存在持续写入时，增量数据是否完整同步至新主库。

测试步骤	验证点	预期结果
1. 切换前：启动自动化脚本，向主库持续写入增量数据（含DML/DDL）	模拟真实业务写入（如每秒100条INSERT/UPDATE/DELETE，穿插CREATE TABLE、ALTER TABLE）	主库数据持续更新，binlog正常生成
2. 记录切换触发时刻的主库binlog位置（show master status;）	标记增量数据的“时间锚点”	获得binlog文件名（如mysql-bin.000005）和位置（如12345）
3. 触发主从切换（切换过程中不停止写入脚本）	验证切换期间增量数据的同步完整性	切换过程中写入的所有数据均被从库（新主库）接收并应用
4. 切换后：对比“锚点前全量数据+锚点后增量数据”在新主库的完整性	全量数据无丢失，增量数据无重复/遗漏	新主库数据量=切换前主库数据量+切换期间增量数据量
5. 校验特殊场景增量数据	含大事务（10万行INSERT）、并发更新（同一行被多次UPDATE）、自增ID插入	大事务完整执行，并发更新结果与主库一致，自增ID无跳跃或重复

场景3：异常场景下的切换（网络中断/主库宕机）

测试目标：验证极端情况下切换的一致性，如主库宕机前存在未同步的binlog。

测试步骤	验证点	预期结果
1. 主库执行大事务（如批量更新10万行数据），执行期间强制断开主从网络连接	模拟主从复制中断，主库存在未同步的binlog	从库Seconds_Behind_Master逐渐增大，主库binlog缓存存在未发送数据
2. 强制kill主库进程（模拟主库宕机），触发自动切换	验证切换机制对未同步数据的处理	切换工具（如MHA）会识别未同步binlog，选择“最接近主库”的从库提升为主库
3. 切换后：对比新主库与原主库（重启后）的数据	未同步的binlog是否导致数据差异	若原主库可重启，未同步的binlog可通过mysqlbinlog手动补充；若不可重启，新主库数据应与切换前从库一致（无脏数据）
4. 验证“脑裂”防护（如使用MGR的quorum机制）	防止双主写入导致的数据冲突	切换后原主库被隔离（read_only=ON），仅新主库可写入

三、核心验证方法与工具

1. 全量数据校验

   • pt-table-checksum：通过在主库执行checksum计算，自动对比从库相同表的校验值，支持分表、忽略指定表，适合大规模数据校验。
   • 脚本对比：分别从主库和新主库导出全量数据（mysqldump --single-transaction），通过diff工具对比文件差异（注意忽略注释、自增ID顺序等无关差异）。

2. 增量数据追踪

   • 记录切换前后的binlog位置：切换后新主库的Exec_Master_Log_Pos应不小于原主库切换时的Position。
   • 业务日志关联：将应用层写入日志与新主库数据对比，确保每一条写入记录都能在新主库查询到。

3. 业务场景专项验证

   • 核心业务流程校验：如用户注册→下单→支付全流程，切换后查询订单状态、金额等关键字段是否与切换前一致。
   • 约束与索引验证：检查主键唯一性（无重复ID）、外键关联（子表无孤立项）、索引有效性（查询计划与原主库一致）。

四、测试结果判定标准

1. 通过标准：

   • 全量数据校验无差异（行数、字段值、索引结构完全一致）；
   • 增量数据100%同步（切换期间的写入在新主库均可见，无重复写入）；
   • 业务功能不受影响（核心查询、写入、更新操作结果与切换前一致）。

2. 失败场景处理：

   • 若发现数据不一致，通过binlog回溯定位差异点（使用mysqlbinlog解析主从binlog，对比执行命令差异）；
   • 记录差异数据的类型（如大字段、自增ID）和操作类型（如REPLACE、INSERT ... ON DUPLICATE KEY UPDATE），针对性优化测试用例。

总结：数据一致性测试的核心原则

设计测试用例时需紧扣“全量覆盖+增量追踪+异常容错”：

• 全量覆盖确保基础数据无遗漏，增量追踪验证切换过程的实时性，异常容错模拟极端场景下的可靠性；
• 结合工具自动化（如Jenkins集成pt-table-checksum）和业务场景化验证，既能提高测试效率，又能贴近实际生产环境。

通过多维度验证，可有效规避主从切换后的数据不一致风险，保障高可用架构的稳定性。