错误注入测试环境需通过可控、可逆、可观测方式主动触发故障，重点验证show replica status变化、vip漂移、应用连接恢复是否在预期窗口内完成，而非随机kill或网络断开等不可控操作。
直接上结论：错误注入测试环境不是靠“模拟错误”来验证高可用，而是用可控、可逆、可观测的方式主动触发故障点，重点验证 SHOW REPLICA STATUS 状态变化、VIP漂移、应用连接恢复这三件事是否在预期窗口内完成。其他花式注入（比如 kill -9 mysqld、dd 损坏 ibdata1）只会让问题不可复现、日志混乱、掩盖真实切换逻辑。
为什么不能用随机 kill 或网络断开做高可用测试
真实高可用链路里，MHA 或 InnoDB Cluster 的决策依赖明确信号：比如 mysqladmin ping 超时、TCP 连接拒绝、SELECT 1 返回非 0、或 Group Replication 的 group_replication_group_name 不一致。随意 kill 进程会跳过这些检测路径，导致：
- MHA manager 日志里看不到
Dead master found，而是报SSH connection failed—— 它根本没走到复制层判断逻辑 - 从库的
Seconds_Behind_Master可能卡在非零值，但Slave_IO_Running仍显示Yes，因为 TCP 连接还没被 kernel 清理，状态滞后 - VIP 脚本没被触发，因为 MHA 没进入
failover流程，只是 manager 自己挂了
推荐的三类可控错误注入方式
每种都对应一个关键验证点，且能在 10 秒内完成、30 秒内回滚：
-
主库 MySQL 进程软终止：执行
mysqladmin -uroot -p123456 shutdown（不是kill -9）。MHA 会在 3 秒内探测到连接拒绝，触发 failover；InnoDB Cluster 会在 10 秒内将该节点标记为UNREACHABLE -
主库网卡临时禁用：在主库机器上运行
ip link set eth0 down && sleep 15 && ip link set eth0 up。这会触发 TCP RST，让从库和 manager 快速感知连接中断，但不丢失 binlog 位置 -
主库强制只读+拒绝写入：在主库执行
SET GLOBAL super_read_only = ON; SET GLOBAL read_only = ON;，再立刻停掉应用写流量。这不是故障，但能验证 VIP 是否仍绑定、路由是否自动切走写请求（适用于 ProxySQL/MySQL Router 场景）
必须同步验证的三个状态输出
注入后不看日志、不查脚本，只盯这三个终端命令的输出，5 秒内就能判断是否成功：
- 在 manager 节点跑：
masterha_check_status --conf=/etc/mha/app1.cnf，应返回app1 (pid:12345) is running(0:PING_OK), master:192.168.23.100→ 切换后变成master:192.168.23.105 - 在新主库执行：
SHOW VARIABLES LIKE 'read_only';必须返回OFF；在旧主库执行同样命令，应为ON（MHA 默认设置） - 在任意客户端连新主库执行：
SELECT @@hostname, @@server_id, @@gtid_executed LIMIT 1;，确认 server_id 已更新、GTID 链连续（无 gap）
最容易被忽略的是：错误注入后，别急着看 MHA 日志，先确认从库有没有自动重连新主——很多失败案例是因为 CHANGE REPLICATION SOURCE TO 里写的还是旧主地址，而 MHA 并没真正修改从库的 source_host 配置，只是靠脚本临时改了 master_ip_failover。真要压测，得把 masterha_master_switch 的 --interactive=0 和 --skip_change_master 组合用对。
