旧从库安全下线需满足三前提：不承担读流量、不参与高可用决策、新从库已完全追平并验证同步；操作前须完成复制状态、GTID子集、新从库稳定性三步验证，再依序执行STOP SLAVE、RESET SLAVE ALL、SET GLOBAL read_only=ON、停服务。
旧从库可以安全下线，前提是它不承担读流量、不参与高可用决策（如MHA或Orchestrator）、且新从库已完全追平并验证同步状态。直接停服务或删配置会引发复制中断、监控告警甚至应用报错。
确认旧从库是否仍在被使用
别只看 SHOW SLAVE STATUS\G，得查真实依赖：
- 检查应用连接池配置，确认没有直连该从库的
jdbc:mysql://old_slave_ip:3306/连接串 - 运行
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_HOST LIKE '%old_slave_ip%';，看是否有活跃会话 - 查代理层（如 ProxySQL、MaxScale）路由规则，确认该节点未在
mysql_servers表中启用（status = 'ONLINE'） - 检查监控系统（如 Zabbix、Prometheus）是否还在采集该实例的
Seconds_Behind_Master，避免误删后触发虚假告警
执行前必须完成的三步验证
跳过任一验证，下线后可能出现数据断层或复制链路断裂：
- 在旧从库上执行
SHOW SLAVE STATUS\G，确认Slave_IO_Running和Slave_SQL_Running均为Yes，且Seconds_Behind_Master = 0 - 比对 GTID：在旧从库和主库分别执行
SELECT @@global.gtid_executed;，用GTID_SUBSET(gtid_set1, gtid_set2)验证旧从库已执行全部主库 GTID（返回1才安全） - 确认新从库已上线并稳定同步至少 5 分钟：新从库的
Seconds_Behind_Master持续为0，且Retrieved_Gtid_Set与主库一致
下线操作本身只需四条命令
顺序不能错，否则可能残留复制线程或 relay log 文件：
- 在旧从库上执行
STOP SLAVE;—— 先停线程，避免边删边同步 - 执行
RESET SLAVE ALL;—— 清除master.info、relay-log.info及所有 relay log 文件（MySQL 5.7+ 推荐用ALL，否则relay_log目录可能残留） - 执行
SET GLOBAL read_only = ON;—— 防止误写，也向监控表明“已只读待下线” - 停 MySQL 服务：
systemctl stop mysqld或kill -15 $(pgrep mysqld)—— 不要用kill -9，避免 InnoDB crash recovery 异常
替换后必须清理的残留项
下线只是第一步，真正容易出问题的是后续“清理惯性”：
- 删掉旧从库 IP 在 DNS 或 hosts 中的解析记录，否则部分脚本仍可能尝试连接
- 从备份策略中移除该实例：检查
mysqldump定时任务、XtraBackup 配置文件、以及云平台 RDS 的自动备份开关 - 如果用了 MHA，需更新
app1.cnf中的candidate_master和no_master配置，否则下次故障转移可能选错目标 - 旧从库磁盘不要立刻格式化，保留至少 7 天——万一发现新从库有隐性同步延迟（如大事务未刷盘），还能快速回切
最常被忽略的是 GTID 集合残留：即使执行了 RESET SLAVE ALL，若之前开启过 log_slave_updates，旧从库的 gtid_executed 里可能混入其他集群的 GTID。下线前务必用 SELECT GTID_SUBTRACT(@@global.gtid_executed, '主库的gtid集合'); 检查是否有额外 GTID，有则说明它曾作为中间节点转发过日志，不能简单当普通从库处理。
