MySQL 一主多从高可用架构搭建

什么是主从架构

MySQL 主从复制（Master-Slave Replication）是最基础的高可用架构方案。一主多从架构包含一个主库（Master）负责写操作，多个从库（Slave）负责读操作，通过异步或半同步复制机制保持数据同步。

架构原理

主库将数据变更记录到二进制日志（binlog）中，从库通过 I/O 线程拉取主库的 binlog 并写入自己的中继日志（relay log），再由 SQL 线程重放中继日志中的数据变更，从而实现数据同步。

客户端写入 → Master（写） → binlog → Slave1（读）→ relay log → SQL 线程
                                    → Slave2（读）→ relay log → SQL 线程
                                    → Slave3（读）→ relay log → SQL 线程

搭建步骤

1. 主库配置

在 my.cnf 中开启 binlog 并设置 server-id：

[mysqld]
server-id = 1
log-bin = mysql-bin
binlog-format = ROW
expire_logs_days = 7
max_binlog_size = 1G
binlog-do-db = your_database  # 可选，限制复制的数据库

创建复制用户：

CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

查看主库状态，记录 File 和 Position：

SHOW MASTER STATUS;

2. 从库配置

[mysqld]
server-id = 2  # 每个从库不同
relay-log = mysql-relay-bin
read_only = 1  # 从库设置为只读

启动复制：

CHANGE MASTER TO
  MASTER_HOST='master_host',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=123;

START SLAVE;
SHOW SLAVE STATUS\G

关键状态检查：Slave_IO_Running: Yes，Slave_SQL_Running: Yes，Seconds_Behind_Master: 0

高可用实现方案

方案一：Keepalived + VIP 漂移

主库挂掉时，VIP 漂移到提升为新的主库的从库上。需要配合半同步复制减少数据丢失。

方案二：MHA（Master High Availability）

MHA 可以自动检测主库故障，选择数据最完整的从库提升为新主，并将其他从库指向新主。切换时间通常在 10-30 秒内。

部署架构：

Manager 节点 → 监控 Master
              Master → Slave1（候选）
                     → Slave2
                     → Slave3

故障切换流程：
1. 尝试从宕机主库保存 binlog
2. 选择数据最新的从库作为新主
3. 补齐新主的 relay log
4. 将其他从库指向新主
5. 通知 VIP 漂移或更新 DNS

方案三：Orchestrator

比 MHA 更现代化的拓扑管理工具，支持自动故障检测和切换，提供 Web UI 和 API。

读写分离实现

架构搭建好后，需要通过读写分离来利用从库的读能力：

• 应用层实现：在代码中区分读写数据源
• 中间件实现：使用 ProxySQL、MyCat、ShardingSphere 等代理层自动路由

读写分离注意事项：
– 主从延迟导致读不到刚写入的数据（”刚写入就查询不到”的问题）
– 解决方案：关键读走主库、设置延迟阈值、使用半同步复制

复制模式选择

面试要点

• 一主多从的典型用途：读写分离 + 故障切换
• 核心问题：主从延迟的成因和对策
• 高可用方案对比：MHA vs Orchestrator
• 半同步复制 vs 异步复制的取舍
• GTID 复制相比基于 Position 复制的优势