如何搭建 MySQL 主从复制？

MySQL 主从复制是数据库高可用、读写分离、数据备份的基础能力。

一句话概括：

主库负责写，从库同步数据并负责读。

这篇文章将带你完整走一遍：

• • 主从复制的原理
• • 主库、从库的配置步骤
• • 基于 GTID + ROW 的推荐方案
• • 常见坑位与排查方法

一、主从复制的基本原理

MySQL 主从复制的核心流程是：

主库写 binlog
   ↓
从库 IO 线程拉取 binlog → 写入 relay log
   ↓
从库 SQL 线程重放 relay log

本质：从库重放主库的 binlog

二、准备环境

假设我们有两台服务器：

必须满足的条件

• • MySQL 版本尽量一致（至少大版本一致）
• • 网络互通
• • 时间同步（NTP）
• • 两边字符集、引擎一致（推荐 InnoDB）

三、主库配置（Master）

1️⃣ 修改 my.cnf

[mysqld]
server-id = 1
log_bin = mysql-bin
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON

说明：

• • server-id：集群内必须唯一
• • log_bin：开启 binlog（必须）
• • ROW + GTID：生产推荐组合

重启 MySQL：

systemctl restart mysqld

2️⃣ 创建复制账号

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

👉 不要用 root，这是生产红线。

3️⃣ 确认主库状态

SHOW MASTER STATUS;

如果使用 GTID，这里主要确认：

• • binlog 正常
• • 不需要手动记录 File / Position

四、从库配置（Slave）

1️⃣ 修改 my.cnf

[mysqld]
server-id = 2
relay-log = relay-bin
read_only = ON

gtid_mode = ON
enforce_gtid_consistency = ON

重启 MySQL：

systemctl restart mysqld

2️⃣ 初始化从库数据（非常关键）

主从复制 不是自动全量同步，你必须先让数据一致。

常见方式一：mysqldump（最常用）

在主库执行：

mysqldump -uroot -p \
  --single-transaction \
  --set-gtid-purged=ON \
  --all-databases > full.sql

在从库导入：

mysql -uroot -p < full.sql

👉 这一步 99% 的主从问题都出在这里

3️⃣ 配置主从关系（GTID 模式）

在从库执行：

CHANGE MASTER TO
  MASTER_HOST='192.168.1.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='repl_pass',
  MASTER_AUTO_POSITION=1;

说明：

• • MASTER_AUTO_POSITION=1：启用 GTID 自动定位
• • 不需要指定 binlog 文件和 position

4️⃣ 启动复制

START SLAVE;
-- MySQL 8.0 也可以用
START REPLICA;

五、验证主从是否成功

1️⃣ 查看复制状态（必查）

SHOW SLAVE STATUS\G;

重点看这两行：

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

👉 两个都是 Yes，主从复制才算真正正常。

2️⃣ 验证数据同步

在主库：

CREATE DATABASE test_replica;

在从库：

SHOW DATABASES;

如果能看到 test_replica，说明复制 OK。

六、常见问题 & 排坑指南（非常实用）

❌ 1）Slave_IO_Running = No

原因通常是：

• • 网络不通
• • 账号/密码错误
• • 防火墙阻断 3306

👉 看 Last_IO_Error

❌ 2）Slave_SQL_Running = No

常见原因：

• • 数据不一致
• • 主键冲突
• • 表结构不同

👉 看 Last_SQL_Error

❌ 3）GTID 报错（Executed GTID 不一致）

解决思路：

• • 确保初始化数据时 --set-gtid-purged=ON
• • 不要在从库“偷偷写数据”

❌ 4）主从延迟

GTID 不能解决延迟，只能解决一致性。

延迟常见原因：

• • 大事务
• • 单线程复制
• • IO/CPU 瓶颈

可考虑：

• • 并行复制（slave_parallel_workers）
• • 拆大事务

七、生产环境最佳实践（建议直接照做）

✅ 使用 GTID + ROW
✅ 主库只写，从库只读
✅ 从库开启 read_only
✅ 不要在从库执行 DDL
✅ 定期检查 SHOW SLAVE STATUS
✅ 配合监控（延迟、复制状态）

八、总结

MySQL 主从复制通过主库 binlog、从库 relay log 实现数据同步。
搭建步骤包括：
主库开启 binlog、创建复制账号；
从库初始化数据、配置主库信息并启动复制。
生产环境推荐使用 GTID + ROW，可简化主从切换并保证数据一致性。