必须确认从库已彻底脱离主从链路且无任何业务或监控依赖：执行stop slave后验证slave_io_running和slave_sql_running均为no、seconds_behind_master为null、gtid集合一致；检查活跃连接、应用配置、监控目标及备份任务；封禁3306端口、回收所有用户权限；清理前快照关键日志与权限结构；停服务后用nc验证不可达，并监控客户端连接池残留。
直接下线老旧从库前，必须确认它已彻底脱离主从链路、不再被任何业务或监控依赖，否则会引发读请求失败、监控告警风暴或主库负载突增。
确认从库已完全停止复制且无残留依赖
别只看 SHOW SLAVE STATUS\G 里 Slave_IO_Running 和 Slave_SQL_Running 是 Yes 就以为安全——很多团队忘了它还在被应用直连或监控轮询。
- 执行
STOP SLAVE;后再查一次SHOW SLAVE STATUS\G，确保Seconds_Behind_Master为NULL，Retrieved_Gtid_Set与Executed_Gtid_Set完全一致 - 用
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_INFO LIKE '%SELECT%';检查是否有活跃连接来自应用服务器或 DBA 终端 - 翻查应用配置中心（如 Nacos / Apollo）、CI/CD 脚本、备份任务（
mysqldump或mydumper命令中是否含该 IP）、Zabbix/Prometheus 的 target 配置，确认无任何地方还指向这台机器
切断所有外部访问入口
下线不是“关服务”就完事，得让别人再也连不上——否则某天开发手抖改错 hosts 或连错终端，后果比不关还糟。
- 防火墙立即封禁 3306 端口：
iptables -I INPUT -p tcp --dport 3306 -s 0.0.0.0/0 -j DROP（先加规则再删服务，防误操作） - MySQL 层 revoke 所有用户权限：
REVOKE ALL PRIVILEGES ON *.* FROM 'app-prod-ro'@'10.20.30.%'; FLUSH PRIVILEGES;；别漏掉'monitor'@'192.168.%'这类运维账号 - 检查
my.cnf中是否启用了skip-networking=OFF（默认是 OFF），确保没意外关闭网络栈；如果用了bind-address = 127.0.0.1，要改成0.0.0.0再封，否则本地 socket 还能连
清理数据目录前先做最小化快照
老从库磁盘里可能存着没归档的 binlog、慢日志、甚至未导出的临时报表数据。直接 rm -rf /data/mysql 是高危动作。
- 用
ls -lt /data/mysql/logs/和find /data/mysql -name "slow.log*" -mtime -30快速扫一遍最近日志，挑关键段 cp 出来 - 运行一次轻量级
mysqldump --no-data --databases mysql > mysql_schema.sql，至少保留下用户和权限结构，万一哪天要复原某个账号有依据 - 确认
datadir下没有软链接指向其他分区（比如/data/mysql/ib_logfile0 -> /ssd/ib_logfile0），避免rm -rf误删共享存储
最后停服务并验证不可达
systemd 服务停掉后，别信 “Active: inactive (dead)” 就算完——得用外部视角验证它真死了。
- 执行
systemctl stop mysqld（不是kill -9，避免pid-file残留导致下次启动报错） - 立刻从另一台跳板机跑：
nc -zv 10.20.30.45 3306，必须返回Connection refused；若通，说明防火墙没生效或 mysqld 没真正退出 - 检查
ps aux | grep mysqld是否还有残留进程；若有，看是不是mysqld_safe（已弃用）在兜底拉起——那就得删掉mysqld_safe相关 service 文件再试
最容易被忽略的是 DNS 缓存和客户端连接池：哪怕服务停了，应用层可能还在复用旧连接，或者 DNS 解析结果还没过期，导致短暂重连失败。所以下线后一小时内，盯着应用错误日志里的 Can't connect to MySQL server 和监控里的连接拒绝率，才算真正收尾。
