主从切换核心风险在于数据一致性、服务连续性与状态同步不可见；须校验位点/gtid完全一致、元数据及路由实时更新、自增id配置统一、复制拓扑重建成功，切前验证、切中可控、切后闭环。
识别主从切换过程中的潜在风险，关键在于监控指标是否真实反映数据同步状态、角色转换是否可控、以及周边系统是否同步响应。不能只看表面数值，要穿透到执行层和依赖链。
同步状态不能只盯 Seconds_Behind_Master = 0
这个值归零不代表真正一致——它只表示中继日志已执行完，但不包含网络缓冲、事务提交顺序、DDL阻塞等隐性延迟。
- 必须比对 Exec_Master_Log_Pos 和主库当前 SHOW MASTER STATUS 的 Position 是否完全相等（位点模式）
- GTID 模式下，检查 Retrieved_Gtid_Set 与 Executed_Gtid_Set 是否完全一致，差值为 0 才算真正追平
- 避免依赖监控平台的“平均延迟”曲线，应实时查询从库状态，尤其在大事务或 DDL 后手动验证
角色切换时必须验证元数据与连接路由
旧主降级、新主上位后，如果应用或中间件仍往错误节点发请求，轻则报错，重则双写导致数据冲突。
- 提前梳理所有硬编码主库地址的位置：应用配置、定时脚本、ETL 工具、备份任务、ProxySQL/MyCat 路由规则
- 切换后立即在旧主执行 SET GLOBAL read_only = ON，并确认 super_read_only = ON，防止误写
- 使用 VIP 或 DNS 切换时，需确认客户端本地 DNS 缓存 TTL 已过期，建议搭配健康检查 + 强制刷新机制
自增 ID 与复制参数容易被忽略但后果严重
切换后若新主继续分配 ID，可能和旧主残留记录或恢复实例产生主键重复，插入直接失败。
- 检查 auto_increment_increment 和 auto_increment_offset 是否在所有节点统一配置；双节点建议设为 2/1 和 2/2
- 切换后查看新主 SELECT @@auto_increment_offset, @@auto_increment_increment，确认未被重置或错配
- 对核心业务表，切换后快速执行 SELECT MAX(id) 对比历史增长趋势，排查跳变或回退异常
切换后必须校验复制拓扑是否重建成功
其他从库若未及时指向新主，或 CHANGE MASTER TO 参数出错，会导致复制永久中断，形成“孤岛从库”。
- 在每个从库执行 SHOW SLAVE STATUS\G，确认 Master_Host 指向新主 IP，且 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes
- GTID 模式下，务必用 RESET SLAVE ALL 清理旧状态，再通过 MASTER_AUTO_POSITION=1 重新建立复制，避免位点混用
- 监控 Slave_SQL_Running_State，警惕卡在 “Waiting for table metadata lock” 或 “Executing event” 等异常状态
