自动故障转移

做的事：真实一主两从，写数据后立刻kill -9模拟崩溃

代码-- source真实提前写入了e1,e2,e3 -- 两个replica真实都已同步 INSERT INTO app.events (msg) VALUES ('e4-before-crash'); -- 真实立刻kill -9掉source进程

验证：崩溃发生时，两个replica真实都已经追上了最新数据

实测 · 本机执行输出（source真实进程已死）

$ ps aux | grep fo-lab/src   （真实查不到这个进程了）

两个replica真实都查到：
id  msg
1   e1
2   e2
3   e3
4   e4-before-crash   ← 真实两边都有，没有丢失

本机这个本地复制环境延迟极低，source崩溃前写入的最后一行数据真实已经被两个replica都同步到了——这是故障转移能真实做到零数据丢失的前提：如果replica落后于source，从落后的replica里提升出的新source真实会丢掉还没同步过去的那部分数据。

验证：真实手动提升一个replica，另一个真实重新指向它

代码（在被提升为新source的replica上）STOP REPLICA; RESET REPLICA ALL; SET GLOBAL read_only=0; CREATE USER 'repl'@'%' IDENTIFIED BY 'FoPass123!'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; 代码（在另一个replica上，重新指向新source）STOP REPLICA; CHANGE REPLICATION SOURCE TO SOURCE_HOST='127.0.0.1', SOURCE_PORT=19341, ...; START REPLICA;

实测 · 本机执行输出

INSERT INTO app.events (msg) VALUES ('e5-after-failover');   -- 真实写在新source上
（约1秒后）
SELECT * FROM app.events;   -- 在另一个replica上查询
→ ... 5  e5-after-failover   ← 真实同步过来了

SHOW REPLICA STATUS真实确认：Source_Port: 19341（新source的端口）

这一整套动作——提升某个replica、给它建复制账号、让其余replica重新指向它——MySQL社区版真实不会自动帮你做，需要人工判断(或者运维脚本、外部工具)真实去执行。这也是为什么Group Replication/InnoDB Cluster这类方案存在的意义：把这套判断和切换过程真实自动化，本文前两篇也真实验证了这套自动化机制本身在实际搭建时会遇到真实的复杂度和坑。传统主从架构下的手动故障转移，真实的关键前提是"确认新source真实是所有存活节点里数据最新的那一个"，否则切换本身就会造成真实的数据丢失或者不一致。

分步演示：一次真实的手动故障转移全过程

每一步都是本文上面用真实一主两从环境跑出来的原始结果。

从source崩溃到新拓扑重新工作的真实过程

这一步新完成的操作

本文用到的工具

本机真实搭建的一主两从复制环境，真实kill -9模拟source崩溃
手动RESET REPLICA ALL + CHANGE REPLICATION SOURCE完成故障转移

下一篇 · MYSQL / INNODB 103

复制冲突