第 16 章 高可用与故障切换面试精讲

📖 本篇简介：MySQL 高可用是生产环境的生命线，面试中常与主从复制、故障切换、脑裂、VIP、MHA、Orchestrator、MGR、InnoDB Cluster 等概念一起考察。本篇基于 MySQL 8.0，系统讲解高可用的核心目标（RTO/RPO）、主从切换流程、脑裂成因与防护、VIP 漂移、MHA 原理、Orchestrator、MGR/InnoDB Cluster、读写分离中间件（ProxySQL/MyCat）、故障演练等高频知识点。学完后你能设计一套"主库宕机 30 秒内自动切换、数据零丢失"的高可用方案，并讲清楚每种方案的取舍。

目录

• 题目 1：MySQL 高可用的核心目标是什么，RTO/RPO 怎么理解
• 题目 2：主从故障切换的完整流程是什么
• 题目 3：什么是脑裂，怎么避免
• 题目 4：VIP 漂移方案的原理与缺点
• 题目 5：MHA 高可用方案的原理与切换流程
• 题目 6：Orchestrator 与 MHA 相比有什么优势
• 题目 7：MGR（MySQL Group Replication）是什么，与传统主从区别
• 题目 8：InnoDB Cluster 由哪几部分组成
• 题目 9：读写分离中间件 ProxySQL/MyCat 的作用
• 题目 10：主库宕机时如何选择新主库
• 题目 11：半同步复制对高可用的意义
• 题目 12：故障切换时数据可能丢多少，怎么降低
• 题目 13：为什么要做故障演练，怎么演练
• 题目 14：双主架构与 MGR 架构怎么选
• 题目 15：VIP 与 ProxySQL 路由切换的区别
• 题目 16：高可用方案中仲裁节点（arbiter）的作用
• 题目 17：主从延迟大时切换有什么风险
• 题目 18：如何做到零宕机升级 MySQL 版本
• 题目 19：高可用监控要监控哪些指标
• 题目 20：常见坑与注意事项
• 速查表：高可用方案速记
• 复习清单
• 练习题

题目 1：MySQL 高可用的核心目标是什么，RTO/RPO 怎么理解

考点

• RTO 恢复时间目标
• RPO 恢复点目标
• 高可用 = 减少 RTO/RPO

参考答案

1. RTO（Recovery Time Objective）：故障发生到服务恢复的时间，理想是秒级，生产一般目标 30 秒~5 分钟。

2. RPO（Recovery Point Objective）：故障时允许丢失的数据量（时间窗），异步复制 RPO=秒级延迟，半同步 RPO≈0，MGR RPO=0。

3. 高可用核心：

• 减少 RTO：自动检测 + 自动切换；
• 减少 RPO：半同步/组复制保证数据不丢。

4. 可用性 SLA：99.99% 全年宕机 < 52 分钟；99.999% < 5 分钟。

| 方案 | RTO | RPO |

|------|-----|-----|

| 手动切换 | 小时级 | 分钟~小时 |

| MHA/VIP | 10~30 秒 | 秒级（异步复制） |

| 半同步 + 自动切换 | 10~30 秒 | ≈0 |

| MGR/InnoDB Cluster | 秒级 | 0 |

追问

• 追问：99.99% 可用性怎么算？应对：一年 365×86400=3153600 秒，宕机时间 < 0.01% = 3153 秒 ≈ 52 分钟。
• 追问：RPO=0 一定能做到吗？应对：同步复制 + 多数派确认可以，但牺牲性能。

题目 2：主从故障切换的完整流程是什么

考点

• 检测故障
• 确认主库真挂
• 选新主
• 应用切新主
• 旧主恢复后当从库

参考答案

1. 故障检测：监控系统（MHA/Orchestrator/Agent）发现主库不可达。

2. 确认主库真挂：防止网络抖动误判，多节点交叉探测（至少 2~3 个节点同时探测）。

3. 选新主：选数据最新的从库（GTID 最齐）。

4. 提升新主：STOP REPLICA → RESET MASTER → 开写权限。

5. 其他从库指向新主：CHANGE REPLICATION SOURCE TO SOURCE_HOST=新主, SOURCE_AUTO_POSITION=1; START REPLICA;。

6. 应用切换：VIP 漂移 / ProxySQL 改路由 / 配置中心改地址。

7. 旧主修复：恢复后重新当新主的从库。

追问

• 追问：怎么防止误判？应对：多节点探测 + 等待 5~10 秒再切换，避免网络抖动。
• 追问：切换期间应用报什么错？应对：短暂连接失败，连接池重试即可。

题目 3：什么是脑裂，怎么避免

考点

• 两个主库同时可写
• 数据分叉
• 仲裁/ fencing

参考答案

1. 脑裂（Split-Brain）：网络分区时，旧主未真正下线，新主已提升，两个主同时接受写，数据分叉。

2. 危害：两边数据不一致，合并困难，业务逻辑错乱。

3. 避免手段：

• 仲裁节点：第三节点（arbiter）只有多数派存活才选主；
• Fencing：旧主被切换后强制关只读或隔离网络，不允许它继续写；
• VIP 唯一：同一 VIP 同一时间只能在一个节点；
• MGR Paxos：天然多数派，少数派节点自动只读。

追问

• 追问：两节点架构怎么防脑裂？应对：两节点不行，必须第三仲裁节点（奇数节点 3/5）。
• 追问：脑裂后数据怎么合并？应对：基本无法自动合并，只能从备份恢复，代价大。

题目 4：VIP 漂移方案的原理与缺点

考点

• 虚拟 IP 绑定主库
• 主库挂了 VIP 飘到从库
• 缺点：切换慢、脑裂风险

参考答案

1. 原理：应用连接一个 VIP（如 10.0.0.100），VIP 绑在主库网卡上；主库挂了，keepalived/heartbeat 把 VIP 飘到新主。

2. 优点：应用无感知，配置只一个 IP。

3. 缺点：

• VIP 漂移依赖 VRRP，切换时间 5~30 秒；
• 两节点容易脑裂；
• 跨机房不行（VIP 二层网络限制）；
• 从库读流量无法通过 VIP 分发。

# keepalived 配置示例（主库）
# vrrp_instance VI_1 {
#   state MASTER
#   interface eth0
#   virtual_router_id 51
#   priority 100
#   virtual_ipaddress { 10.0.0.100 }
# }

追问

• 追问：VIP 跨机房能用吗？应对：不能，VIP 是二层广播，跨三层网络不通。
• 追问：VIP 漂移时连接会断吗？应对：会，旧连接断开，应用重连到新主。

题目 5：MHA 高可用方案的原理与切换流程

考点

• Master HA 工具
• Manager 节点
• 自动选最新从库提升
• 0~30 秒切换

参考答案

1. MHA（Master High Availability）：日本 DeNA 开源的 MySQL 高可用工具，由 Manager 节点 + Node 节点组成。

2. 工作原理：

• Manager 定期监控主从；
• 主库挂了，Manager 登录所有从库，对比 relay log，选出数据最新的从库；
• 把其他从库缺失的日志补到新主；
• 提升新主，其他从库指向新主；
• VIP 漂移或调用脚本通知应用。

3. 切换时间：10~30 秒。

4. 优点：自动补差异日志、切换成熟；缺点：MHA 本身需要高可用（Manager 单点），不支持自动读流量分发。

追问

• 追问：MHA 要求主从用 GTID 吗？应对：5.7+ 推荐 GTID；非 GTID 时 MHA 自动差异比对。
• 追问：MHA Manager 挂了怎么办？应对：Manager 本身做主备，或换 Orchestrator。

题目 6：Orchestrator 与 MHA 相比有什么优势

考点

• Go 开发、Web UI
• 自动发现拓扑
• 可恢复性强
• 支持 GUI 操作

参考答案

1. Orchestrator：Go 写的 MySQL 拓扑管理与高可用工具，有 Web UI。

2. 优势：

• 自动发现主从拓扑，可视化展示；
• 支持多种故障检测策略；
• 切换过程可控，支持人工确认；
• 支持逻辑 Master、配置驱动；
• 社区活跃，适合大规模集群。

3. 对比 MHA：MHA 是 Perl 写的老牌工具，Orchestrator 更现代、Web 化、扩展性强。

追问

• 追问：Orchestrator 适合多少实例规模？应对：几百到几千实例的大型集群。
• 追问：Orchestrator 切换需要 VIP 吗？应对：不强制，可配合 ProxySQL/服务发现。

题目 7：MGR（MySQL Group Replication）是什么，与传统主从区别

考点

• Paxos 多数派
• 多主写或单主模式
• 强一致
• 性能开销

参考答案

1. MGR：MySQL 官方组复制，基于 Paxos 协议，事务要多数派节点确认才能提交。

2. 两种模式：

• 单主模式：只有一个主可写，其他从只读，自动选主；
• 多主模式：所有节点可写，冲突检测后回滚。

3. 与传统主从区别：

• 传统主从异步，可能丢数据；
• MGR 强一致，RPO=0；
• MGR 自动故障检测与选主，无需外部工具；
• MGR 性能比异步主从低（多轮网络通信）。

-- MGR 单主模式典型配置（my.cnf）
# transaction_write_set_extraction=XXHASH64
# loose-group_replication_group_name="aaaaaaaa-...."
# loose-group_replication_start_on_boot=off
# loose-group_replication_local_address="10.0.0.1:33061"
# loose-group_replication_group_seeds="10.0.0.1:33061,10.0.0.2:33061,10.0.0.3:33061"

追问

• 追问：MGR 至少几个节点？应对：3 个起步（奇数），容忍 1 个节点宕机；5 节点容忍 2 个。
• 追问：MGR 多主写冲突怎么办？应对：Paxos 检测到冲突，后提交的事务回滚，业务要重试。

题目 8：InnoDB Cluster 由哪几部分组成

考点

• MGR + MySQL Router + MySQL Shell
• 官方完整高可用方案
• 自动路由

参考答案

1. InnoDB Cluster：MySQL 官方一体化高可用方案，三组件：

• MGR：底层组复制，强一致；
• MySQL Router：路由层，自动把读写请求发到主/从；
• MySQL Shell：管理工具，配置与监控。

2. 优点：官方支持、自动故障转移、自动路由、无需第三方工具。

3. 缺点：架构较重，性能比异步主从低，适合中大型对一致性要求高的业务。

追问

• 追问：InnoDB Cluster 与 Orchestrator 怎么选？应对：官方强一致选 InnoDB Cluster；灵活、大规模异构选 Orchestrator。
• 追问：MySQL Router 挂了怎么办？应对：Router 本身无状态，部署多实例 + VIP/LB。

题目 9：读写分离中间件 ProxySQL/MyCat 的作用

考点

• 路由读写
• 连接池
• 故障自动摘除
• SQL 审计

参考答案

| 中间件 | 特点 |

|--------|------|

| ProxySQL | 开源、高性能、协议层代理、支持规则路由、MySQL 生态常用 |

| MyCat | 国产、支持分库分表、JVM 开发、社区版功能有限 |

| Vitess | Google 开源、超大规模、云原生、K8s 友好 |

1. 作用：

• 写请求路由主库，读请求路由从库；
• 主库故障自动摘除，读请求切到健康从库；
• 连接池复用，减少 MySQL 连接数；
• SQL 审计、慢查询记录、查询改写。

2. 注意：中间件本身要高可用（多实例 + VIP/LB）。

追问

• 追问：读写分离有什么业务坑？应对：主从延迟导致读到旧数据，业务要容忍或强制走主库。
• 追问：ProxySQL 性能好吗？应对：单实例 1 万+ QPS，比应用层读写分离更集中。

题目 10：主库宕机时如何选择新主库

考点

• 数据最新优先
• GTID 最齐
• 硬件健康
• 一致性

参考答案

1. 第一原则：数据最新，即从库 Executed_Gtid_Set 与主库最接近，避免丢数据。

2. MHA/Orchestrator 自动做：对比各从库 relay log 与 GTID，自动选最新。

3. 其他考虑：

• 从库硬件健康（CPU/磁盘正常）；
• 从库复制无延迟；
• 从库不是过滤复制（数据全）；
• 避免选延迟大的从库做新主。

4. 如果所有从库都延迟很大：宁可等几秒追数据再切，或接受 RPO=延迟。

追问

• 追问：从库数据都不全怎么办？应对：半同步复制下至少有一个从库有完整数据；异步复制下可能丢，业务层补偿。
• 追问：手动选主要看什么？应对：SHOW REPLICA STATUS 的 Seconds_Behind_Source 与 Executed_Gtid_Set。

题目 11：半同步复制对高可用的意义

考点

• 减少 RPO
• 切换不丢数据
• 与自动切换配合

参考答案

1. 意义：异步复制下主库宕机，已提交但未发送从库的事务丢失，RPO=秒级。

2. 半同步：主库提交后等至少一个从库 ACK 才返回客户端，切换时从库有完整数据，RPO≈0。

3. 与自动切换配合：MHA/Orchestrator + 半同步 = 自动切换 + 不丢数据。

4. 代价：写延迟略增（同机房 5%~10%）。

追问

• 追问：半同步一定不丢吗？应对：从库 ACK 后宕机，relay log 在磁盘，可恢复；极端掉电仍可能丢，要 MGR。
• 追问：半同步超时降级怎么办？应对：降级后要告警，恢复后自动升回半同步。

题目 12：故障切换时数据可能丢多少，怎么降低

考点

• 异步复制 RPO
• 半同步 RPO≈0
• MGR RPO=0
• 业务补偿

参考答案

1. 异步复制：主库宕机瞬间，binlog 未发送到从库的事务丢失，RPO=主从延迟（秒~分钟）。

2. 半同步：主库等从库 ACK 才返回，已返回客户端的事务不丢，RPO≈0。

3. MGR：多数派确认才提交，RPO=0。

4. 业务补偿：

• 关键业务（支付、下单）用半同步/MGR；
• 非关键业务（日志、埋点）容忍少量丢失；
• 切换后对账补数据。

追问

• 追问：半同步 RPO 真的是 0 吗？应对：从库收到 binlog 写 relay log 但还没重放时从库宕机，relay log 在磁盘，恢复后重放，不丢。
• 追问：MGR 性能影响多大？应对：比异步低 20%~40%，网络 RTT 敏感。

题目 13：为什么要做故障演练，怎么演练

考点

• 纸上谈兵没用
• 真实环境演练
• 发现脚本/监控问题

参考答案

1. 为什么演练：

• 切换脚本可能坏了没人知道；
• 监控告警链路可能断；
• 应用重连逻辑可能有 bug；
• 真实故障时手忙脚乱。

2. 怎么演练：

• 预发环境：定期 kill 主库，观察自动切换；
• 生产环境：业务低峰期做"计划内切换"（switchover），验证流程；
• 混沌工程：随机注入故障（网络延迟、磁盘满、进程 kill）。

3. 频率：每月至少一次预发演练，每季度一次生产计划内切换。

追问

• 追问：演练会影响业务吗？应对：计划内切换在低峰，秒级闪断，连接池重试。
• 追问：演练发现问题怎么办？应对：记录到 runbook，修完再练，直到熟练。

题目 14：双主架构与 MGR 架构怎么选

考点

• 双主异步、性能高但脑裂风险
• MGR 强一致但性能低
• 按业务一致性要求选

参考答案

| 维度 | 双主 + VIP | MGR |

|------|-----------|-----|

| 一致性 | 异步，可能丢 | 强一致，不丢 |

| 性能 | 高 | 较低（多轮 Paxos） |

| 脑裂风险 | 有，需仲裁 | Paxos 天然防脑裂 |

| 架构复杂度 | 中 | 高 |

| 适用 | 一般业务 | 金融/支付核心 |

1. 选双主：业务能容忍少量数据丢失、追求性能、有成熟运维。

2. 选 MGR：核心交易、不能丢数据、能接受性能损失。

3. 折中：核心库 MGR，非核心库双主 + 半同步。

追问

• 追问：MGR 多主写适合互联网业务吗？应对：冲突概率高，一般用单主模式，多主写谨慎。
• 追问：MGR 节点跨机房？应对：Paxos 对网络延迟敏感，跨城 RTT > 5ms 性能骤降。

题目 15：VIP 与 ProxySQL 路由切换的区别

考点

• VIP 二层漂移
• ProxySQL 协议层路由
• 各自适用场景

参考答案

1. VIP：应用连一个 IP，切换是 IP 漂移，应用无感知但连接会断；二层网络限制，不能跨机房。

2. ProxySQL：应用连 ProxySQL，ProxySQL 内部维护主从列表，切换只改路由规则，连接池可复用，应用连接不断。

3. 对比：

• VIP：简单、二层、连接断；
• ProxySQL：复杂、跨机房、连接复用、支持读流量分发。

追问

• 追问：用了 ProxySQL 还要 VIP 吗？应对：ProxySQL 本身要高可用，多实例 + VIP/LB 调度 ProxySQL。
• 追问：ProxySQL 切换多快？应对：毫秒级（路由规则切换），比 VIP 快。

题目 16：高可用方案中仲裁节点（arbiter）的作用

考点

• 防止脑裂
• 多数派投票
• 不存数据

参考答案

1. 仲裁节点：不存数据、只参与投票的轻量节点，用于 2 节点架构凑奇数。

2. 作用：网络分区时，多数派（含 arbiter）存活的一侧才能选主，少数派自动只读，防脑裂。

3. 常见实现：

• MGR 天然 3 节点；
• 双主 + 第三方节点（或 VIP 管理节点）投票；
• ZooKeeper/etcd 作为仲裁。

追问

• 追问：arbiter 挂了怎么办？应对：只要多数派仍存活，不影响；3 节点挂 1 个仍可用。
• 追问：2 节点为什么不行？应对：网络分区两边都 1 票平票，无法选主。

题目 17：主从延迟大时切换有什么风险

考点

• 丢数据多
• 选新主困难
• 业务读到旧数据

参考答案

1. 丢数据：延迟大说明从库落后主库很多事务，切换后这些事务全丢。

2. 选主困难：多个从库延迟不同，选哪个都丢数据。

3. 业务风险：切换后业务写到新主，旧主恢复后数据分叉。

4. 应对：

• 切换前等从库追平（或延迟可控）；
• 半同步/MGR 从根本解决；
• 大促前保证从库无延迟。

追问

• 追问：紧急切换但从库延迟大怎么办？应对：业务接受少量丢失，先恢复服务，事后对账补偿。
• 追问：怎么避免切换时延迟大？应对：监控延迟，延迟大不触发自动切换，告警人工介入。

题目 18：如何做到零宕机升级 MySQL 版本

考点

• 滚动升级
• 先升从库再切主
• 版本兼容

参考答案

1. 滚动升级步骤：

• 先升级所有从库到新版本；
• 观察从库运行正常；
• 切换主从（旧主降为从库，新主升主）；
• 升级旧主；
• 整个过程业务只闪断一次切换。

2. 版本兼容：从库版本 ≥ 主库版本才能正常复制；升级前查 release notes 不兼容项。

3. 大版本升级（5.7→8.0）：先在预发验证 SQL/ORM 兼容，再滚动。

追问

• 追问：8.0 升级有什么坑？应对：sql_mode 默认严格、密码插件 caching_sha2、GROUP BY 不再隐式排序。
• 追问：回滚怎么办？应对：升级前备份，回滚用备份恢复，比前滚慢。

题目 19：高可用监控要监控哪些指标

考点

• 主从状态
• 延迟
• 连接数
• 复制错误
• 硬件

参考答案

| 指标 | 说明 | 告警阈值 |

|------|------|----------|

| 主从 IO/SQL 线程 | 是否 Yes | 任一 No 立刻告警 |

| Seconds_Behind_Source | 主从延迟 | >10s 告警 |

| 连接数 | Threads_connected | >80% max_connections |

| QPS/TPS | 负载 | 突增突降告警 |

| 慢查询数 | 慢日志 | 突增告警 |

| 磁盘使用率 | 数据盘/binlog 盘 | >80% 告警 |

| 主库存活 | 定期探测 | 3 次失败触发切换 |

| 半同步状态 | rpl_semi_sync_status | OFF 告警 |

-- 本示例基于 MySQL 8.0，高可用常用巡检命令
SHOW REPLICA STATUS\G                          -- 查看复制状态与延迟
SHOW VARIABLES LIKE 'rpl_semi_sync%';          -- 查看半同步配置
SHOW STATUS LIKE 'Rpl_semi_sync_status';       -- 半同步运行状态
SHOW STATUS LIKE 'Threads_connected';          -- 当前连接数

追问

• 追问：监控系统本身挂了怎么办？应对：监控多副本、跨机房部署；MGR/Orchestrator 自带健康检查。
• 追问：告警风暴怎么处理？应对：分级告警、聚合、值班人员轮值。

题目 20：常见坑与注意事项

考点

• 高可用高频坑
• 脑裂/误切换/数据丢失
• 运维操作

参考答案

1. 坑 1：只部署 2 节点，网络分区脑裂。

2. 坑 2：异步复制 + 自动切换，主库宕机丢数据。

3. 坑 3：故障检测太敏感，网络抖动误切换。

4. 坑 4：切换脚本没演练，真故障时跑不通。

5. 坑 5：VIP 方案跨机房部署，VIP 不通。

6. 坑 6：从库延迟大时切换，丢一堆数据。

7. 坑 7：MHA Manager 单点，Manager 挂了无法切换。

8. 坑 8：ProxySQL 没高可用，ProxySQL 成新单点。

9. 坑 9：从库误开 super_read_only=OFF，切换后数据分叉。

10. 坑 10：升级 MySQL 没做兼容测试，业务 SQL 报错。

追问

• 追问：怎么知道高可用方案真的能切换？应对：定期演练，演练记录留档。
• 追问：切换后旧主自动变从库吗？应对：MHA/Orchestrator 可自动处理；手工切换要记得把旧主重新指向新主。

速查表：高可用方案速记

| 方案 | RTO | RPO | 脑裂风险 | 适用 |

|------|-----|-----|----------|------|

| 手动切换 | 小时级 | 分钟~小时 | 低 | 小业务 |

| VIP + keepalived | 5~30s | 秒级（异步） | 高（2 节点） | 同机房小集群 |

| MHA + VIP | 10~30s | 秒级 | 中 | 传统主从 |

| Orchestrator | 秒~十秒 | 秒级 | 中 | 大规模集群 |

| 半同步 + 自动切换 | 10~30s | ≈0 | 中 | 核心业务 |

| MGR/InnoDB Cluster | 秒级 | 0 | Paxos 防 | 金融核心 |

复习清单

| 题目 | 核心结论 | 易错点 |

|------|----------|--------|

| 1 | RTO 恢复时间、RPO 数据丢失 | 99.99% 全年 52 分钟 |

| 2 | 检测→选主→提升→切应用 | 误判主库真挂 |

| 3 | 脑裂 = 双主同时写 | 2 节点必脑裂 |

| 4 | VIP 二层漂移、连接断 | 跨机房 VIP 不通 |

| 5 | MHA 自动选最新从库 | Manager 单点 |

| 6 | Orchestrator Web 化、大规模 | 比 MHA 重 |

| 7 | MGR Paxos 多数派、RPO=0 | 性能比异步低 |

| 8 | MGR + Router + Shell | Router 要高可用 |

| 9 | ProxySQL 读写路由 | 中间件本身单点 |

| 10 | 选 GTID 最新从库 | 延迟大的从库不选 |

| 11 | 半同步降 RPO | 超时降级要告警 |

| 12 | 异步 RPO=延迟 | 半同步极端掉电仍可能丢 |

| 13 | 定期演练切换流程 | 不演练真故障翻车 |

| 14 | 双主性能高、MGR 强一致 | 按业务一致性选 |

| 15 | VIP 二层、ProxySQL 协议层 | ProxySQL 连接复用 |

| 16 | 仲裁节点凑奇数票 | 2 节点无法选主 |

| 17 | 延迟大切换丢数据 | 紧急切换后对账 |

| 18 | 滚动升级先从后主 | 从库版本要 ≥ 主库 |

| 19 | 监控复制/延迟/连接/磁盘 | 监控自身高可用 |

| 20 | 脑裂/误切/丢数据三大坑 | 不演练切换脚本 |

练习题

1. 题目：2 节点主从 + VIP 方案有什么脑裂风险？怎么改进？

• 参考答案：网络分区时两边都认为自己该当主，VIP 可能两边都绑；要加第三仲裁节点，或改用 MGR 3 节点。

2. 题目：MGR 与异步主从的核心区别是什么？

• 参考答案：MGR 基于 Paxos，事务要多数派确认才提交，RPO=0，自动选主；异步主从主库写 binlog 即返回，可能丢数据。

3. 题目：故障切换时为什么要选 GTID 最新的从库？

• 参考答案：GTID 最新说明数据最全，切换后丢失事务最少，降低 RPO。

4. 题目：为什么要做故障演练？

• 参考答案：切换脚本、监控告警、应用重连等链路只有真实演练才能发现问题；不演练真故障时手忙脚乱。

5. 题目：ProxySQL 相比 VIP 方案的优势？

• 参考答案：协议层路由，切换毫秒级、连接池复用、支持读流量分发；不依赖二层网络，可跨机房。

下一篇预告：第 17 章 分库分表面试精讲