

## 一、为什么需要主从复制

单机MySQL在高并发场景下面临诸多挑战：

- **读写压力集中**：所有请求打到一台机器
- **单点故障**：主库宕机，服务完全不可用
- **备份影响性能**：备份时锁表影响业务
- **扩展性差**：无法水平扩展读能力

**主从复制解决的问题：**
- 读写分离，提升读性能
- 数据冗余，提高可用性
- 从库备份，不影响主库
- 水平扩展读能力

## 二、主从复制原理

### 1. 复制流程

```
主库（Master）                    从库（Slave）
    │                                  │
    │  1. 写操作产生Binlog              │
    │                                  │
    │  2. Binlog Dump线程              │
    │  ──────────────────────────────► │
    │                                  │  3. IO线程接收Binlog
    │                                  │     写入Relay Log
    │                                  │
    │                                  │  4. SQL线程读取Relay Log
    │                                  │     重放SQL语句
```

### 2. 三种Binlog格式

| 格式 | 说明 | 优点 | 缺点 |
|------|------|------|------|
| STATEMENT | 记录SQL语句 | 日志量小 | 某些函数不安全（NOW()等） |
| ROW | 记录行变更 | 安全可靠 | 日志量大 |
| MIXED | 混合模式 | 折中方案 | 复杂度高 |

**推荐使用ROW格式：**

```ini
[mysqld]
binlog_format = ROW
binlog_row_image = FULL
```

### 3. GTID复制

GTID（Global Transaction ID）是MySQL 5.6引入的全局事务标识：

```
GTID = server_uuid:transaction_id
示例：3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
```

**GTID的优势：**
- 自动定位复制位置，无需手动指定binlog文件和位置
- 故障切换更简单
- 避免数据重复或丢失

## 三、主从复制搭建

### 1. 主库配置

```ini
# /etc/mysql/my.cnf
[mysqld]
server-id = 1
log-bin = mysql-bin
binlog-format = ROW
gtid-mode = ON
enforce-gtid-consistency = ON
log-slave-updates = ON
sync-binlog = 1
innodb-flush-log-at-trx-commit = 1

# 需要复制的数据库
binlog-do-db = order_db
binlog-do-db = user_db

# 不需要复制的数据库
binlog-ignore-db = mysql
binlog-ignore-db = information_schema
```

**创建复制账号：**

```sql
-- 创建复制用户
CREATE USER 'repl'@'%' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

-- 查看主库状态
SHOW MASTER STATUS;
```

### 2. 从库配置

```ini
# /etc/mysql/my.cnf
[mysqld]
server-id = 2
relay-log = relay-bin
log-bin = mysql-bin
gtid-mode = ON
enforce-gtid-consistency = ON
log-slave-updates = ON
read-only = ON
super-read-only = ON

# 复制过滤
replicate-do-db = order_db
replicate-do-db = user_db
```

**建立复制关系：**

```sql
-- 停止从库
STOP SLAVE;

-- 配置主库信息（GTID模式）
CHANGE MASTER TO
    MASTER_HOST = '192.168.1.100',
    MASTER_USER = 'repl',
    MASTER_PASSWORD = 'repl_password',
    MASTER_PORT = 3306,
    MASTER_AUTO_POSITION = 1;

-- 启动从库
START SLAVE;

-- 查看从库状态
SHOW SLAVE STATUS\G
```

**关键状态字段：**

```
Slave_IO_Running: Yes       -- IO线程正常
Slave_SQL_Running: Yes      -- SQL线程正常
Seconds_Behind_Master: 0    -- 复制延迟（秒）
```

### 3. 数据初始化

**使用mysqldump初始化：**

```bash
# 主库导出数据（加锁保证一致性）
mysqldump -h master \
    --single-transaction \
    --master-data=2 \
    --all-databases \
    -u root -p > master_dump.sql

# 从库导入数据
mysql -h slave -u root -p < master_dump.sql
```

**使用XtraBackup（推荐，不锁表）：**

```bash
# 主库备份
xtrabackup --backup \
    --target-dir=/data/backup \
    --user=root \
    --password=password

# 准备备份
xtrabackup --prepare --target-dir=/data/backup

# 传输到从库
rsync -avz /data/backup/ slave:/data/mysql/

# 从库恢复
xtrabackup --copy-back --target-dir=/data/backup
chown -R mysql:mysql /data/mysql
```

## 四、主从延迟问题

### 1. 延迟原因

```
主库：多线程并发写入
从库：单线程串行重放（MySQL 5.6之前）
```

**MySQL 5.7并行复制：**

```ini
# 从库配置
slave-parallel-type = LOGICAL_CLOCK
slave-parallel-workers = 8
slave-preserve-commit-order = ON
```

### 2. 延迟监控

```sql
-- 查看复制延迟
SHOW SLAVE STATUS\G

-- 关键指标
Seconds_Behind_Master: 0    -- 延迟秒数
Exec_Master_Log_Pos         -- 已执行到的位置
Read_Master_Log_Pos         -- 已读取到的位置
```

**监控脚本：**

```bash
#!/bin/bash
# check_slave_lag.sh

SLAVE_HOST="192.168.1.101"
THRESHOLD=60  # 延迟超过60秒告警

LAG=$(mysql -h${SLAVE_HOST} -e "SHOW SLAVE STATUS\G" | grep "Seconds_Behind_Master" | awk '{print $2}')

if [ "${LAG}" = "NULL" ]; then
    echo "CRITICAL: 从库复制已停止"
    exit 2
fi

if [ ${LAG} -gt ${THRESHOLD} ]; then
    echo "WARNING: 从库延迟 ${LAG} 秒，超过阈值 ${THRESHOLD} 秒"
    exit 1
fi

echo "OK: 从库延迟 ${LAG} 秒"
exit 0
```

### 3. 延迟解决方案

**方案1：并行复制**

```ini
slave-parallel-type = LOGICAL_CLOCK
slave-parallel-workers = 16
```

**方案2：半同步复制**

```sql
-- 主库安装插件
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_master_timeout = 1000;

-- 从库安装插件
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
```

**方案3：读写分离时处理延迟**

```java
@Service
public class OrderService {
    
    @Autowired
    private DataSource masterDataSource;
    
    @Autowired
    private DataSource slaveDataSource;
    
    public Order createOrder(OrderRequest request) {
        // 写操作走主库
        Order order = masterOrderMapper.insert(request);
        
        // 写完后短时间内的读也走主库（避免读到旧数据）
        ThreadLocalContext.setUseMaster(true);
        
        return order;
    }
    
    public Order getOrder(Long orderId) {
        // 检查是否需要走主库
        if (ThreadLocalContext.isUseMaster()) {
            return masterOrderMapper.selectById(orderId);
        }
        
        // 普通读走从库
        return slaveOrderMapper.selectById(orderId);
    }
}
```

## 五、主从切换

### 1. 手动切换

```bash
# 1. 停止主库写入
mysql -h master -e "FLUSH TABLES WITH READ LOCK;"

# 2. 等待从库追上主库
mysql -h slave -e "SHOW SLAVE STATUS\G" | grep "Seconds_Behind_Master"

# 3. 从库提升为主库
mysql -h slave -e "STOP SLAVE; RESET SLAVE ALL;"
mysql -h slave -e "SET GLOBAL read_only = OFF;"

# 4. 其他从库指向新主库
mysql -h slave2 -e "CHANGE MASTER TO MASTER_HOST='slave1'..."
```

### 2. 自动切换（MHA）

```yaml
# mha.conf
[server default]
manager_workdir=/var/log/mha
manager_log=/var/log/mha/manager.log
master_binlog_dir=/var/lib/mysql
user=mha
password=mha_password
ssh_user=root
repl_user=repl
repl_password=repl_password
ping_interval=3

[server1]
hostname=192.168.1.100
port=3306

[server2]
hostname=192.168.1.101
port=3306
candidate_master=1

[server3]
hostname=192.168.1.102
port=3306
```

```bash
# 启动MHA Manager
masterha_manager --conf=/etc/mha/mha.conf &

# 检查状态
masterha_check_status --conf=/etc/mha/mha.conf
```

## 六、常见问题

### Q1：主从数据不一致怎么办？

```bash
# 使用pt-table-checksum检查一致性
pt-table-checksum --host=master \
    --user=root \
    --password=password \
    --databases=order_db

# 使用pt-table-sync修复不一致
pt-table-sync --execute \
    --host=master \
    --user=root \
    --password=password \
    --databases=order_db \
    h=slave
```

### Q2：从库复制报错怎么处理？

```sql
-- 查看错误信息
SHOW SLAVE STATUS\G

-- 跳过错误（谨慎使用）
STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

-- 或者使用GTID跳过
STOP SLAVE;
SET GTID_NEXT = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:N';
BEGIN; COMMIT;
SET GTID_NEXT = 'AUTOMATIC';
START SLAVE;
```

## 七、总结

MySQL主从复制是高可用架构的基础：

- **复制原理**：Binlog → Relay Log → 重放SQL
- **GTID复制**：更简单可靠的复制方式
- **延迟优化**：并行复制 + 半同步复制
- **自动切换**：MHA等工具实现自动故障转移

**最佳实践：**
1. 使用GTID模式，简化运维
2. 开启并行复制，减少延迟
3. 监控复制延迟，及时告警
4. 定期演练主从切换

**思考题**：你们的MySQL是什么复制架构？有没有遇到过主从延迟的问题？

---

*个人观点，仅供参考*

GTID（Global Transaction ID）是MySQL 5.6引入的全局事务标识：

【架构实战】MySQL主从复制架构深度解析

单机MySQL在高并发场景下面临诸多挑战：

读写压力集中：所有请求打到一台机器

单点故障：主库宕机，服务完全不可用

备份影响性能：备份时锁表影响业务

扩展性差：无法水平扩展读能力

研发部经理

数据库

架构设计

后端

MySQL主从复制解决高并发场景下的单机瓶颈，实现读写分离、数据冗余和水平扩展。通过Binlog日志传输实现主从数据同步，推荐使用ROW格式和GTID模式确保数据一致性。搭建时需配置主从库参数，监控复制延迟并优化并行复制性能。主从切换可通过手动或MHA工具实现，定期检查数据一致性是保障业务稳定的关键。

数据冗余

MySQL

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【架构实战】MySQL主从复制架构深度解析-腾讯云开发者社区-腾讯云

【架构实战】MySQL主从复制架构深度解析

【架构实战】MySQL主从复制架构深度解析

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐