必须确认三件事：Seconds_Behind_Master为数值0（非NULL或抖动）、Slave_IO_Running和Slave_SQL_Running均为Yes、无阻塞长事务；STOP SLAVE后须执行RESET SLAVE ALL清空所有元数据；关闭read_only与super_read_only需同步修改配置文件并验证生效。
主库彻底不可达时，从库提升前必须确认的三件事
不能只看 Seconds_Behind_Master = 0 就动手。很多切换失败，根源都在这一步跳过验证。
-
Seconds_Behind_Master必须是 数值 0，不是NULL（主库失联后常见），也不是反复在 0/1 之间抖动 -
Slave_IO_Running和Slave_SQL_Running都必须为Yes，缺一不可；任一为No表示复制链路已中断或卡住 - 执行
SHOW PROCESSLIST，确认没有State为Updating、Copying to tmp table或长时间Sending data的事务——这些长事务会阻塞STOP SLAVE，甚至导致后续RESET SLAVE ALL失败
STOP SLAVE 后必须立刻执行 RESET SLAVE ALL，而不是 RESET SLAVE
RESET SLAVE 只清空内存里的复制信息，relay_log 文件、master.info、relay-log.info 这些磁盘残留还在。下次重启 MySQL 或误执行 START SLAVE，它会按旧配置自动重连原主库，极可能写入冲突数据。
- 务必用
RESET SLAVE ALL（MySQL 5.6+ 支持），它会删掉所有复制元数据文件 + 清空内存状态 - 执行后检查
SHOW SLAVE STATUS\G，确认输出里Master_Host、Master_User、Relay_Log_File全部为空，Slave_IO_Running和Slave_SQL_Running都为No - 如果 MySQL 版本低于 5.6，只能手动删除
master.info、relay-log.info和所有host-relay-bin.*文件，再重启 mysqld
关闭只读不是 SET GLOBAL read_only = OFF 就完事
只改运行时变量，不碰配置文件，等于没关。MySQL 重启后 read_only = ON 会自动生效，新主库瞬间变“假主库”，应用写入直接报错。
- 先执行
SET GLOBAL read_only = OFF和SET GLOBAL super_read_only = OFF（8.0+ 必须同时关） - 然后编辑
/etc/my.cnf，注释或删掉read_only = ON和super_read_only = ON行 - 检查
SHOW VARIABLES LIKE 'read_only'和SHOW VARIABLES LIKE 'super_read_only'，确认两者都返回OFF
非 GTID 模式下必须执行 RESET MASTER，GTID 模式下严禁执行
这是最容易踩的坑：该执行时不执行，不该执行时手抖敲了回车。
- 非 GTID 模式：必须执行
RESET MASTER，否则新主库的binlog起始位置还是继承自原主库，其他从库CHANGE MASTER TO时会因位点错乱而同步失败 - GTID 模式：绝对禁止
RESET MASTER！它会清空gtid_executed，导致所有从库无法通过MASTER_AUTO_POSITION = 1自动定位，后续同步直接卡死 - 不确定是否启用 GTID？执行
SELECT @@gtid_mode;，返回ON才算启用
整个过程最脆弱的环节不是命令本身，而是“以为做完就结束了”。比如忘记检查 log_bin 是否开启，新主库没 binlog，其他从库连上来就是个哑巴；或者没确认原主库是否彻底宕机，它突然复活又开始写入，就会形成双写分裂。每一步操作后，都得用对应命令反向验证结果，而不是依赖记忆或脚本输出。
