老主库安全下线需四层交叉验证：数据写入（read lock+processlist+状态变量+命令计数）、复制关系（show slave status为空、performance_schema无配置、错误日志无重连）、应用连接（threads/sleep数归零、tcpdump无新连接、dns/连接池更新）、回切能力（gtid集合比对、binlog完整保留、禁用reset master）。

主备切换完成后，老主库是否真正“安全下线”，不能只看它有没有被设为 read_only，而要从数据写入、复制关系、应用连接、系统行为四个层面交叉验证。漏掉任一环，都可能引发双写、覆盖、回切失败等严重问题。

确认老主库已彻底停止写入

仅执行 SET GLOBAL read_only = ON 不够可靠——SUPER 权限用户、触发器、存储过程仍可绕过。必须叠加验证：

• 执行 FLUSH TABLES WITH READ LOCK;（低峰期慎用），再立刻查 SHOW PROCESSLIST，确认无活跃的 Query 状态 DML 连接
• 检查 SELECT @@read_only, @@super_read_only; 均返回 1（后者在 5.7+ 中更严格）
• 观察 SHOW GLOBAL STATUS LIKE 'Com_insert%'; 和 Com_update 在锁释放后是否持续为 0，确认无后台 JOB 或定时任务偷偷写入

验证复制链路已完全断开

老主库若仍被其他节点当作主源，或自身残留复制配置，可能意外重连、拉取旧 binlog、甚至覆盖新主数据：

• 在老主库上执行 SHOW SLAVE STATUS\G，确认输出为空（不是 NULL，而是无结果集），表示未启用从角色
• 检查 SELECT * FROM performance_schema.replication_connection_configuration;，应无任何记录
• 查看错误日志，确认无 Failed to connect to master 或 Relay log write failure 类报错——说明没在尝试当从库运行

检查应用层是否真正脱离老主库

数据库端停写只是第一步，应用是否还在连？这是最常被忽略的“假下线”原因：

• 在老主库上执行 SELECT * FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_COMMAND = 'Sleep';，连接数应快速归零或仅剩监控探针
• 抓包验证：在老主库所在服务器执行 tcpdump -i any port 3306 | grep -i "established"，确认无新建 TCP 连接
• 排查 DNS 缓存（dig +short db.example.com）、连接池最大空闲时间、负载均衡健康检查缓存周期，确保流量已稳定落在新主

确认老主库可随时安全回切（兜底能力）

真正安全的下线，是“能随时无缝切回来”。这要求老主库状态干净、位点明确、不破坏 GTID 集合：

• 执行 SELECT @@gtid_executed; 记录当前 GTID 集合，与新主的 SELECT @@gtid_purged; 对比，确认老主未 purged 掉新主需要的事务
• 检查 SHOW BINARY LOGS;，确认 binlog 文件完整保留，且最新文件末尾有有效事务（非空文件）
• 不做 RESET MASTER；如已执行，需提前备份 mysql-bin.index 和所有 binlog 文件