数据库的动态切换（Failover）实际上分为**"底层数据与拓扑切换"** 和**"上层流量入口动态绑定"**两条并行线。以下是补充了流量绑定机制的完整全景总结：
一、 核心架构与前置配置
- 高可用管理组件（大脑）：部署如 MHA、Orchestrator 或 MGR，负责监控、选主与调度。
- 分布式 Node 节点（手脚）：在每台 MySQL 服务器上部署 Node 组件，赋予组件直接读取本地底层文件（Binlog/Relay Log）的权限，用于极端宕机下的数据抢救。
- 复制与同步机制（底线） ：配置主从复制，强烈建议开启增强同步（Semi-sync），确保"未确认的数据不算成功"。
- 流量接入层（门面与绑定）：配置统一的流量入口，对外暴露一个固定的逻辑地址（域名或 VIP），应用端只连接该入口。
- 钩子脚本（Hook） ：在高可用组件中配置切换后执行的脚本（如
PostMasterFailoverProcesses），用于自动触发 DNS API 更新或 VIP 漂移。
二、 动态切换的完整执行流程
当主库发生故障时，高可用组件会自动接管，执行以下标准化接力赛：
1. 故障检测与集群冻结
组件通过心跳机制发现主库宕机，立即停止所有从库的 IO/SQL 线程，锁定集群，防止在切换期间产生新的数据写入导致数据错乱。
2. 扫描比对与选主
通过 SQL 指令（如 SHOW SLAVE STATUS）扫描所有存活的从库，对比 GTID 或 Binlog 位点，选出复制延迟最小、数据最新的节点作为新主库候选。
3. 底层文件抢救与对齐（尽力而为）
- 如果原主库 SSH 仍可达，Manager 会触发原主库上的 Node 节点，直接读取本地磁盘上的 Binlog 物理文件，拉取并应用到新主库上，实现零数据丢失（RPO=0）。
- 随后计算其他从库与新主库的数据差异，将落后的从库补齐，确保存活节点数据完全一致。
4. 角色提升与拓扑重构
向新主库发送提权指令，开放写权限；同时向其他存活的从库发送指令，让它们重新指向新主库，恢复复制链路。
5. 流量入口的动态绑定与切换（核心补充）
底层拓扑重构完成后，高可用组件会调用预设的钩子脚本，通过以下两种方式之一完成流量入口的动态绑定：
-
方式 A：域名动态绑定（DNS API 联动）
对外暴露一个统一的域名（如
db-master.company.com），在 DNS 服务器上设置极短的 TTL（如 10~30 秒）。主库宕机后，高可用组件调用 DNS 服务商的 API（如阿里云 DNS API），将db-master.company.com的 A 记录动态修改为新主库的真实 IP。应用端在极短的 TTL 过期后重新解析，自动获取新 IP 并重连。 -
方式 B：VIP 动态绑定（虚拟 IP 漂移）
对外暴露一个虚拟 IP（VIP），该 IP 初始绑定在主库的网卡上。主库宕机后，高可用组件（如 MHA 或 Keepalived）会自动执行脚本，将 VIP 从旧主库的网卡上"摘除"，并"绑定（漂移）"到新主库的网卡上。应用端始终连接该 VIP，无需修改任何配置，也无需等待 DNS 缓存刷新，流量即可无缝切入新主库。
三、 核心底层执行指令
在"角色提升与拓扑重构"阶段，高可用组件会在底层自动向数据库发送以下核心 SQL 指令：
1. 针对"新主库"的提权指令：
STOP SLAVE;：彻底停止当前的复制线程。RESET SLAVE ALL;：清除该节点作为从库的旧配置和旧日志，使其成为一张白纸。SET GLOBAL read_only = OFF;：解除只读限制，正式开放写入权限。
2. 针对"其他从库"的拓扑重构指令：
CHANGE MASTER TO MASTER_HOST='新主库IP', MASTER_USER='...', MASTER_PASSWORD='...';：修改复制目标，让从库指向新的主库。START SLAVE;：重新启动复制线程，继续从新主库拉取并应用数据。
3. 针对"旧主库"（若修复后恢复上线）的降级指令：
CHANGE MASTER TO MASTER_HOST='新主库IP', ...;START SLAVE;
总结来说：
数据库的动态切换是一场高可用组件在底层通过精准的 SQL 指令与分布式节点协同，完成的**"集群拓扑在线重构"** ；同时，配合 DNS 动态解析 或 VIP 漂移 机制，完成了**"流量入口的动态绑定"**。这两条线紧密咬合，最终在应用层实现了完全无感知的故障自愈。