MySQL 高可用方案

面试官问："MySQL 高可用怎么做的？"

小张说："我们用了主从复制。"

面试官追问："主库挂了怎么办？"

小张说："...手动切换？"

面试官继续追问："手动切换要多久？有没有自动切换的方案？"

小张答不上来。

高可用是 MySQL 生产环境的必备能力。主从复制的切换时间可能从几分钟到几十分钟，在业务高峰期这是不可接受的。这道题考的是候选人对 MySQL 高可用架构的理解深度。

一、高可用方案概览 🔴

1.1 常见方案对比

方案	原理	切换时间	数据一致性	复杂度
主从 + 手动切换	人工介入	5~30 分钟	可能丢数据	低
Keepalived + 双主	VIP 漂移	30s~2min	可能丢数据	中
MHA	Master HA	10~30s	可配置	中
MGR	MySQL Group Replication	3~10s	最终一致	高
PXC	Percona XtraDB Cluster	毫秒级	强一致	高

1.2 高可用的衡量指标

指标	说明	目标
RTO（Recovery Time Objective）	恢复时间	< 30 秒
RPO（Recovery Point Objective）	数据丢失量	< 1 分钟数据
可用性	运行时间比例	99.99% = 52 分钟/年

二、Keepalived + 双主架构 🟡

2.1 架构原理

┌──────────────────────────────────────────────────┐
│              VIP: 192.168.1.100                   │
└────────────────────┬─────────────────────────────┘
                     │
              ┌──────┴──────┐
              ↓             ↓
        ┌──────────┐  ┌──────────┐
        │  Master1 │  │  Master2 │
        │ (写+读)  │  │ (读)     │
        └─────┬────┘  └─────┬────┘
              │            │
              └─────互相同步──┘

原理：

两台 MySQL 配置为双主复制（互相同步）
Keepalived 绑定 VIP
Master1 故障时，VIP 漂移到 Master2
应用连接到 VIP，不感知切换

2.2 切换流程

# Master1 故障检测
# 1. Keepalived 心跳检测 Master1 不可达
# 2. 触发 VIP 漂移到 Master2
# 3. Master2 接管 VIP
# 4. 应用自动连接到新 Master

2.3 缺点

切换时间取决于检测频率（通常 3~5 秒检测一次）
切换后原 Master 恢复需要手动处理
可能丢数据：Master1 挂了但数据还没同步到 Master2

三、MHA（Master High Availability）🟡

3.1 MHA 架构

┌────────────────────────────────────────────────────┐
│                      MHA Manager                    │
│              (监控、故障检测、自动切换)              │
└────────────────────┬───────────────────────────────┘
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
    ┌────────┐  ┌────────┐  ┌────────┐
    │Master  │  │ Slave1 │  │ Slave2  │
    │(写)    │  │(读)    │  │(读)    │
    └────────┘  └────────┘  └────────┘

3.2 MHA 切换流程

# Step 1: 检测 Master 故障
# MHA Manager 每秒检测 Master 心跳

# Step 2: 选新 Master（选择最新数据的从库）
# 选择 relay log 应用最快的 Slave

# Step 3: 差异日志补偿
# 把 Master 挂掉前未同步到 Slave 的 binlog 找回来

# Step 4: 切换
# 将 VIP 漂移到新 Master
# 所有 Slave 指向新 Master

# 总耗时：10~30 秒

3.3 MHA 的优势

自动选新 Master：选择数据最新的从库
差异日志补偿：尽量减少数据丢失
半自动切换：可以配置为手动确认后切换
支持 GTID：配合 GTID 复制更可靠

四、MGR（MySQL Group Replication）🟢

4.1 MGR 原理

┌────────────────────────────────────────────────────┐
│                  Group Replication                   │
│              (基于 Paxos 协议的组复制)              │
└────────────────────────────────────────────────────┘
                    │
    ┌───────────────┼───────────────┐
    ↓               ↓               ↓
┌────────┐     ┌────────┐     ┌────────┐
│ Node1  │     │ Node2  │     │ Node3  │
│ Primary│←────┼───────→│←────┼───────→│
└────────┘     └────────┘     └────────┘

核心原理：

基于 Paxos 协议实现分布式一致性
多节点组成复制组
所有写操作在组内广播，经多数节点确认后提交
强一致性：数据不会丢失

4.2 MGR vs MHA

维度	MHA	MGR
数据一致性	可能丢数据	强一致（无数据丢失）
切换时间	10~30 秒	3~10 秒
架构复杂度	中	高
运维难度	中	高（需要 Paxos 知识）
节点数量	2~5 台	3~9 台（推荐 3 或 5）

五、生产选型建议 🟢

5.1 选型原则

场景	推荐方案	原因
成本敏感、业务允许少量数据丢失	Keepalived + 双主	简单、成本低
金融类业务、零数据丢失	MGR 或 PXC	强一致性
中等一致性要求	MHA	平衡成本和数据安全

5.2 不要忽略的问题

-- 1. 切换后的数据修复
-- MHA/MGR 切换后，原 Master 恢复，需要手动或自动重新加入集群

-- 2. 切换时的连接处理
-- 应用要有重连机制，否则切换后连接会断开

-- 3. VIP vs Proxy
-- VIP：简单但有广播问题（ARP）
-- Proxy：复杂但更灵活（支持读写分离）

【面试官心理】高可用是 MySQL 面试中的高级话题。能说清楚 MHA 和 MGR 区别、选型原则的候选人，说明他对 MySQL 生产架构有实战经验。

级别	考察重点	期望回答
P5	基础架构	主从复制、高可用概念
P6	方案理解	MHA 原理、Keepalived 双主
P7	深度选型	MGR vs MHA vs PXC 的权衡

#MySQL 高可用方案

#一、高可用方案概览 🔴

#1.1 常见方案对比

#1.2 高可用的衡量指标

#二、Keepalived + 双主架构 🟡

#2.1 架构原理

#2.2 切换流程

#2.3 缺点

#三、MHA（Master High Availability）🟡

#3.1 MHA 架构

#3.2 MHA 切换流程

#3.3 MHA 的优势

#四、MGR（MySQL Group Replication）🟢

#4.1 MGR 原理

#4.2 MGR vs MHA

#五、生产选型建议 🟢

#5.1 选型原则

#5.2 不要忽略的问题