真正可用的从库必须同时满足：Slave_IO_Running和Slave_SQL_Running均为Yes、Seconds_Behind_Master=0、Exec_Master_Log_Pos最大（或多从库中该值最高）；GTID模式下优先选Retrieved_Gtid_Set最全且Executed_Gtid_Set与之最接近的节点，最稳妥是STOP SLAVE IO_THREAD后确认“Has read all relay log”。
确认哪个从库能真正接棒
别只看 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” 才算真正追平。
停复制、清状态、固位点
确认无误后，在选定从库上立即执行以下操作，顺序不能错：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
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 修改参数不持久，必须改配置文件并重启：
- 修改
/etc/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时，不能硬写MASTER_LOG_FILE='mysql-bin.000001'和MASTER_LOG_POS=154——新主刚RESET MASTER后，第一个事件位置未必是 154（尤其启用了binlog_checksum或gtid_mode=ON） - 原主库恢复后，不能直接配个 IP 就重连；若未启用 GTID，必须用
MASTER_POS_WAIT在新主库上等待一个确定位置，再把该位置传给原主库
最容易被忽略的是：GTID 模式下严禁执行 RESET MASTER，否则会清空 gtid_executed，导致后续从库无法自动定位；而 read_only 和 super_read_only 若只在内存里关掉，不注释配置文件，下次重启立刻回归只读状态。
