主库宕机后从库不能直接升主，必须经验证（slave_io_running和slave_sql_running均为yes、seconds_behind_master=0、exec_master_log_pos最大或gtid最全）、清理（stop slave、reset master、删master.info与relay-log.info）、重配（启用log-bin、关闭read_only/super_read_only、设唯一server-id并重启）、切流（应用及从库指向新主）四步闭环操作，否则易致双主冲突或数据错乱。
主库宕机后，从库不能“直接升主”，必须经过验证、清理、重配、切流四步闭环操作，否则极易引发双主冲突或数据错乱。
先确认哪个从库能接棒
别只看 Seconds_Behind_Master = 0 —— 这只说明 SQL 线程没卡住，不代表 relay log 已全部执行完。真正可用的从库要同时满足：
- Slave_IO_Running 和 Slave_SQL_Running 都是 Yes
- Seconds_Behind_Master 显示为 0
- Exec_Master_Log_Pos 值最大（多个从库时比这个，它代表已回放到主库 binlog 的哪个物理位置）
- 若开启 GTID，优先选 Retrieved_Gtid_Set 最全、且 Executed_Gtid_Set 与之最接近的节点
更稳妥的做法：在候选从库上执行 STOP SLAVE IO_THREAD，再反复 SHOW PROCESSLIST，直到看到 “Has read all relay log” 才算真正追平。
停复制、清状态、固位点
确认无误后，在选定从库上立即执行：
- STOP SLAVE —— 停止所有复制线程
- SHOW MASTER STATUS —— 记下 File 和 Position（后续其他从库重连要用）
- RESET MASTER —— 注意不是 RESET SLAVE ALL！RESET MASTER 会清空当前所有 binlog 并重置为 mysql-bin.000001，新主从此开始记日志；而 RESET SLAVE ALL 只删配置不删文件，位点仍残留，会导致其他从库连错
- 手动删除 master.info 和 relay-log.info —— 防止 MySQL 重启后自动拉起旧复制关系
改配置、开写入、重启生效
仅 SET GLOBAL 修改参数不持久，必须改配置文件并重启：
- 修改 my.cnf 的 [mysqld] 段：
– 设置唯一 server-id（不能和原主库或其他从库重复）
– 取消注释或新增 log_bin = /path/to/mysql-bin（没 binlog 就不是主库）
– 注释掉 read_only = ON 和 super_read_only = ON（否则 INSERT/UPDATE/DELETE 全报错 Error 1290）
– 可加 binlog_format = ROW（务必与原主库一致） - systemctl restart mysqld —— 重启使配置落地
- 重启后验证：SHOW VARIABLES LIKE 'log_bin' 返回 ON，SELECT @@read_only 返回 0
切流量、连从库、收尾闭环
数据库层面升级完成只是第一步，业务连续性取决于这步：
- 将应用连接池、中间件（如 ProxySQL、ShardingSphere）、VIP 或 DNS 解析，全部指向新主库 IP 和端口
- 其他剩余从库执行 CHANGE MASTER TO，目标为主库的 host/port/user/pass，位点参数用新主库 SHOW MASTER STATUS 返回的 File 和 Position（GTID 模式下直接 SET GLOBAL gtid_purged = ... 更安全）
- 启动复制：START SLAVE，再查 SHOW SLAVE STATUS\G 确认 IO/SQL 线程正常、延迟为 0
- 保留原主库为只读备用，待确认数据无误后再决定是否重建为新主的从库
