【MySQL】第11节｜MySQL 8.0 主从复制原理分析与实战（一）

一、MySQL主从复制基础

1. 核心概念

定义：

MySQL主从复制是将主库（Source/Master）的数据变更同步到一个或多个从库（Replica/Slave）的机制，默认采用异步复制，支持全库、指定库或表的同步。

角色：
- 主库：负责处理写请求，记录二进制日志（Binlog）。
- 从库：通过读取主库Binlog并回放（Relay Log）实现数据同步，支持读请求分担。

2. 核心优势

高可用性：通过多从库部署提升容灾能力，主库故障时可手动/自动切换至从库。
读写分离：从库承担读请求，缓解主库压力，提升整体吞吐量。
异地灾备：从库部署至异地机房，降低地域级故障风险。

3. 复制类型

异步复制：主库提交事务后立即返回客户端，无需等待从库确认，可能存在延迟和数据丢失风险。
半同步复制：主库等待至少一个从库确认接收Binlog后再提交事务，提升数据可靠性，但增加响应延迟。
延迟复制：从库故意落后主库指定时间，用于数据误操作恢复（如误删表）。

二、异步复制原理与配置

1. 核心流程（基于Binlog位点）

主库生成Binlog：

主库执行写操作时，将变更记录到Binlog文件（如mysql-bin.000001）。

从库拉取Binlog：

从库的I/O线程通过CHANGE MASTER TO指定主库地址、Binlog文件名（如mysql-bin.000001）和起始位置（Position），请求同步数据。

主库推送Binlog：

主库的Dump线程根据从库请求的位点推送Binlog数据。

从库写入中继日志（Relay Log）：

从库接收Binlog并写入本地Relay Log，由SQL线程解析并回放，更新本地数据。

2. 关键配置步骤（示例）

主库配置：

复制代码

# custom.cnf
[mysqld]
server-id=10          # 唯一标识主库
log-bin=mysql-bin     # 启用Binlog
binlog-format=ROW     # 推荐使用ROW格式，记录行级变更

从库配置：

复制代码

[mysqld]
server-id=11          # 唯一标识从库
relay-log=relay-bin   # 中继日志路径
read-only=ON          # 从库设置为只读（避免误写）

主从连接配置（从库执行）：

复制代码

-- MySQL 8.0.23前使用CHANGE MASTER TO
CHANGE MASTER TO 
  MASTER_HOST='主库IP',
  MASTER_PORT=3306,
  MASTER_USER='复制用户',
  MASTER_PASSWORD='密码',
  MASTER_LOG_FILE='mysql-bin.000001',  -- 主库当前Binlog文件
  MASTER_LOG_POS=1234;                 -- 主库当前Binlog位置

-- MySQL 8.0.23+使用CHANGE REPLICATION SOURCE TO
CHANGE REPLICATION SOURCE TO 
  SOURCE_HOST='主库IP',
  SOURCE_PORT=3306,
  SOURCE_USER='复制用户',
  SOURCE_PASSWORD='密码',
  SOURCE_LOG_FILE='mysql-bin.000001',
  SOURCE_LOG_POS=1234;

START REPLICA;  -- 启动从库复制线程

3. 状态验证

复制代码

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

-- 从库查看复制状态（关键字段）
SHOW REPLICA STATUS \G
# 重点关注：
# Replica_IO_Running: Yes       -- I/O线程运行正常
# Replica_SQL_Running: Yes      -- SQL线程运行正常
# Seconds_Behind_Master: 0      -- 复制延迟（0表示无延迟）

三、半同步复制：提升数据可靠性

1. 核心原理

主库在提交事务前，等待至少一个从库确认已接收并写入Relay Log。
若从库超时未响应，主库退化为异步复制；从库恢复后自动切回半同步。

2. 关键配置

主库启用半同步插件：

复制代码

INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
SET GLOBAL rpl_semi_sync_source_enabled=ON;

从库启用半同步插件：

复制代码

INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET GLOBAL rpl_semi_sync_replica_enabled=ON;

核心参数：

rpl_semi_sync_source_wait_for_replica_count：主库等待至少N个从库确认（默认1）。
rpl_semi_sync_source_timeout：等待超时时间（毫秒，默认10000）。

四、基于GTID的复制：自动化位点管理

1. GTID核心优势

全局唯一事务ID ：每个事务在主库生成唯一GTID（格式：server_uuid:transaction_id），避免Binlog位点手动管理。
自动定位同步起点 ：从库通过MASTER_AUTO_POSITION=1自动获取主库最新事务，无需指定Binlog文件名和位置。
一致性保障：确保每个事务在主从库仅执行一次，避免重复或遗漏。

2. 配置要点

主从库启用GTID：

复制代码

[mysqld]
gtid_mode=ON               # 启用GTID模式
enforce_gtid_consistency=ON # 强制GTID一致性（避免非事务语句破坏一致性）

从库配置（自动定位）：

复制代码

CHANGE REPLICATION SOURCE TO 
  SOURCE_HOST='主库IP',
  SOURCE_PORT=3306,
  SOURCE_USER='复制用户',
  SOURCE_PASSWORD='密码',
  SOURCE_AUTO_POSITION=1;  # 关键：启用自动位点管理

START REPLICA;

3. 主从切换实战

模拟主库宕机：停止主库服务。
提升从库为新主库：

-- 在目标从库执行（如replica1）
STOP REPLICA;
RESET MASTER; -- 清除原有复制配置，成为主库
其他从库指向新主库：

CHANGE REPLICATION SOURCE TO
SOURCE_HOST='新主库IP',
SOURCE_AUTO_POSITION=1;
START REPLICA;

五、主从复制痛点与解决方案

1. 传统Binlog位点复制的痛点

手动管理复杂：首次配置或故障恢复时需手动指定Binlog文件名和位置，易出错。
单点故障风险：主库宕机后，从库需人工选择新主库并配置位点，耗时且可能丢失数据。

2. GTID的解决方案

自动化位点管理 ：通过SOURCE_AUTO_POSITION自动同步最新事务，无需人工干预。
快速故障切换：从库基于GTID集合差集自动追赶数据，减少切换时间。

六、总结：复制模式对比

|-----------|--------------------|-------------|----------------|
| 维度 | 异步复制（Binlog位点） | 半同步复制 | GTID复制 |
| 数据可靠性 | 低（可能丢数据） | 中（至少1从库确认） | 高（事务唯一且有序） |
| 配置复杂度 | 高（手动管理位点） | 中（需配置插件和参数） | 低（自动位点管理） |
| 故障恢复 | 慢（人工配置位点） | 中（需手动切换主库） | 快（自动同步差集事务） |
| 适用场景 | 非核心业务、低延迟要求 | 金融类中等可靠性场景 | 高可用集群、频繁主从切换场景 |

建议：生产环境优先使用GTID+半同步复制组合，平衡可靠性与性能；传统Binlog位点复制仅用于 legacy 系统或简单测试场景。