手动 Failover 是什么
主库宕机且无法快速恢复时的手动切换流程：先确认故障不可恢复，再评估可接受的数据丢失窗口，然后提升数据最新的从库、隔离旧主防止带病复活、最后重建拓扑并切走应用流量。每一步都要留下记录，事后才能说清到底丢了多少事务。
基本信息
| 判定手段 | 多路探测（网络、端口、进程、只读探测）避免误判 |
|---|---|
| 选主依据 | GTID 环境看 gtid_executed 最完整；非 GTID 比位点 |
| 隔离手段 | 断电、禁用网卡、回收账号权限，防止旧主写回 |
| 流量切换 | 应用改配置，或切换 VIP / DNS / 代理后端 |
| 关键动作 | 取消只读、清理复制元数据、重置从库指向 |
典型处置顺序
- 确认主库确实宕机：多路探测并排除网络抖动与中间件问题
- 选择 GTID 最完整的从库，并确认它已回放完中继日志
- 提升该从库：停复制、清复制元数据、取消只读
- fencing 旧主：断电或禁用网卡并回收权限，防止其恢复后继续写入
- 其他从库改挂新主，逐台启动并核对复制状态
- 应用切流并记录丢失事务窗口，随后补齐或对账
提升与改挂
提升与改挂
-- 提升（目标从库执行）
STOP REPLICA;
RESET REPLICA ALL;
SET GLOBAL super_read_only = OFF;
SET GLOBAL read_only = OFF;
SELECT @@GLOBAL.gtid_executed; -- 记录切换时刻的 GTID 集合
-- 其他从库改挂新主
STOP REPLICA;
CHANGE REPLICATION SOURCE TO SOURCE_HOST='10.0.0.11', SOURCE_USER='repl',
SOURCE_PASSWORD='强口令', SOURCE_AUTO_POSITION=1;
START REPLICA;
SHOW REPLICA STATUS\G -- 确认 IO 与 SQL 线程均为 Yes 且无错误步骤与验证点
| 步骤 | 要验证什么 | 常见失误 |
|---|---|---|
| 确认故障 | 多路探测结论一致 | 网络抖动被误判为宕机 |
| 选择新主 | gtid_executed 为超集 | 选了数据落后的从库导致丢更多 |
| 提升新主 | 只读已关闭、复制已停止 | 未清复制元数据，重启后复制错乱 |
| 隔离旧主 | 无法再写入任何数据 | 旧主恢复后造成双写脑裂 |
| 重建拓扑 | 各从库复制线程正常 | 从库指向旧主，数据回退 |
GTID 环境下各从库可能进度不同：切换前比较 gtid_executed，选择超集节点，避免丢更多事务。
没有隔离旧主就切流是最危险的做法：旧主恢复后会继续接受写入，与新主形成双主，数据冲突几乎不可自动修复。