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

一、MySQL主从复制基础

1. 核心概念

• 定义：

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

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

2. 核心优势

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

3. 复制类型

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

二、异步复制原理与配置

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

1. 主库生成Binlog：

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

1. 从库拉取Binlog：

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

1. 主库推送Binlog：

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

1. 从库写入中继日志（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. 主从切换实战

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

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

1. 其他从库指向新主库：

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 系统或简单测试场景。