应用连接配置必须同步更新，否则写请求仍发往旧主库导致报错或数据丢失；需验证新主库read_only=0、show master status正常，并通过中间件/dns/直连等方式切换流量，同时预留旧主只读兜底。
主从切换完成后，应用连接配置必须同步更新，否则写请求仍会发往已下线的旧主库，导致报错或数据丢失。这不是可选步骤，而是切换闭环中最关键的一环。
确认新主库可写且服务就绪
在修改应用配置前，先验证新主库状态：
- 登录新主库执行
SELECT @@read_only;，结果应为0（非只读） - 检查
SHOW MASTER STATUS\G，确认File和Position有正常输出，说明 binlog 已启用 - 用复制账号测试连通性：
mysql -h新主IP -urepl -prepl_password -e "SELECT 1"
应用层连接变更方式选择
不同架构下更新方式差异较大，优先级从高到低如下：
-
数据库中间件（推荐）：如 ProxySQL、MaxScale 或 MyCat。只需修改其后端节点配置并重载，应用完全无感。例如 ProxySQL 中执行
UPDATE mysql_servers SET hostgroup_id=10 WHERE hostname='旧主IP';，再LOAD MYSQL SERVERS TO RUNTIME; -
DNS 切换：将业务使用的域名（如
db-master.company.com）解析指向新主库 IP。需控制 TTL ≤ 60 秒，并提前预热 DNS 缓存 -
直连 IP/域名替换：适用于配置集中管理的场景（如 Spring Boot 的
application.yml）。需批量更新所有实例，配合滚动发布，避免全量重启 - 连接池热重载：部分高级连接池（如 HikariCP 配合 Apollo/Nacos）支持运行时刷新 JDBC URL。需确认框架和驱动版本支持该能力
连接切换中的关键细节
容易被忽略但直接影响成败的点：
- 确保应用使用的是写专用连接池，读写分离中间件或代码中明确区分
writeDataSource和readDataSource，避免误将写流量导向从库 - 检查连接字符串是否硬编码了旧主库 IP 或主机名，尤其是脚本、定时任务、ETL 工具、监控探针等边缘组件
- 若应用启用了连接缓存（如 MySQL Connector/J 的
cacheServerConfiguration=true），需重启或清除缓存，否则可能复用旧连接参数 - 切换后立即验证：执行一条带
FOR UPDATE的简单写语句，确认事务能成功提交并返回影响行数
回滚与兜底策略
切换不是单向操作，必须预留快速回退路径：
- 保留旧主库至少 30 分钟（不关闭服务），仅设为
read_only=1，便于异常时秒级切回 - 所有配置变更需版本化（Git 管控），回滚即还原配置+重载
- 监控项必须包含「写入成功率」「主库连接数」「慢查询突增」，任一异常触发告警并人工介入
