MySQL 主从复制配置教程：MySQL 8.0 GTID 主从同步搭建详解与常见问题排查

MySQL 主从复制是企业级数据库部署中最常见的高可用方案之一。通过将主库的数据实时同步到从库，不仅可以实现读写分离，还能够提升数据库性能，并为数据备份、故障恢复提供可靠保障。

随着 MySQL 8.0 的广泛应用，官方更加推荐使用 GTID（Global Transaction Identifier，全局事务标识）复制方式，相比传统基于 Binlog Position 的复制更加稳定，切换主从也更加方便。本文将介绍 MySQL 主从复制的工作原理，并以 MySQL 8.0 为例，讲解 GTID 主从复制的完整配置流程。

什么是 MySQL 主从复制

MySQL 主从复制是指主服务器（Source）负责处理数据写入，并将所有数据变更记录到 Binary Log（二进制日志）中。从服务器（Replica）持续读取主服务器的 Binlog，并重放日志，从而保持与主库数据一致。

整个复制过程主要包括三个阶段：

首先，主服务器记录所有事务到 Binlog。

随后，从服务器上的 IO Thread 连接主服务器，持续获取 Binlog 内容，并写入 Relay Log（中继日志）。

最后，SQL Thread 或 Replica SQL Thread 读取 Relay Log，并执行其中的 SQL，使从库数据保持同步。

GTID 复制为每个事务分配唯一的事务 ID，因此无需记录 Binlog 文件和 Position，在主从切换、故障恢复和扩容时更加简单可靠。MySQL 官方也推荐在 MySQL 8.0 环境优先使用 GTID 复制。

配置前准备

假设有两台服务器：

• 主服务器（Source）：192.168.1.10
• 从服务器（Replica）：192.168.1.20

两台服务器建议安装相同版本的 MySQL 8.0，并确保：

• 网络互通
• 时间同步
• server-id 不重复
• 已开启 Binary Log
• 防火墙允许 3306 端口访问

第一步：配置主服务器

修改 MySQL 配置文件 my.cnf（Windows 为 my.ini）。

建议启用如下配置：

• server-id=1
• log_bin=mysql-bin
• binlog_format=ROW
• gtid_mode=ON
• enforce_gtid_consistency=ON
• log_replica_updates=ON（部分版本仍兼容 log_slave_updates）

其中，ROW 模式能够获得更高的数据一致性，也是官方推荐的 Binlog 格式。GTID 模式开启后，每个事务都会拥有唯一标识，后续复制无需记录 Binlog 文件位置。

修改完成后重启 MySQL 服务。

随后创建复制账号：

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

对于较新的 MySQL 版本，虽然权限名称仍保留 REPLICATION SLAVE，但复制命令已经逐步改为 Source / Replica 的新命名方式。

第二步：初始化从服务器

在主服务器导出数据库：

mysqldump --all-databases --single-transaction > backup.sql

将备份恢复到从服务器：

mysql < backup.sql

随后修改从服务器配置：

• server-id=2
• relay_log=relay-bin
• gtid_mode=ON
• enforce_gtid_consistency=ON
• log_replica_updates=ON

完成后重启 MySQL 服务。

第三步：建立主从复制

在从服务器执行复制配置。

MySQL 8.0 推荐使用新的复制命令：

CHANGE REPLICATION SOURCE TO
SOURCE_HOST='192.168.1.10',
SOURCE_USER='repl',
SOURCE_PASSWORD='YourPassword',
SOURCE_AUTO_POSITION=1;

然后启动复制：

START REPLICA;

如果仍是较早版本 MySQL，则可能仍使用 CHANGE MASTER TO 和 START SLAVE 命令，但新版本已经逐步采用 Source / Replica 新命名。

第四步：验证复制状态

执行：

SHOW REPLICA STATUS\G

重点查看以下几个字段：

• Replica_IO_Running：Yes
• Replica_SQL_Running：Yes
• Seconds_Behind_Source：接近 0

如果三个状态均正常，则说明主从复制已经成功建立。

随后可以在主库创建测试表、插入数据，确认从库能够自动同步。

常见问题排查

1. Replica_IO_Running 为 No

通常是网络、防火墙、账号权限或密码错误导致。

建议检查：

• 主库是否开放 3306
• 用户权限是否正确
• bind-address 是否允许远程访问

2. Replica_SQL_Running 为 No

通常表示 SQL 执行失败。

可以查看：

SHOW REPLICA STATUS\G

根据 Last_SQL_Error 获取具体错误原因，例如：

• 主键冲突
• 表不存在
• 字段不一致
• 数据结构不同

3. 主从延迟较大

常见原因包括：

• 大事务提交
• 从库硬件性能不足
• SQL 执行速度慢
• 网络延迟

可以优化事务大小、增加索引、升级磁盘性能，必要时开启并行复制以提升同步效率。

4. 主从数据不一致

建议：

• 使用 mysqldump 或物理备份重新初始化从库
• 避免人工修改从库数据
• 定期校验数据一致性

GTID 模式能够有效降低因为 Binlog Position 错误导致的数据同步异常，因此更适合作为生产环境部署方案。

MySQL 主从复制最佳实践

在生产环境中，建议优先采用 GTID + ROW Binlog 模式，同时开启 Binary Log、合理设置 Binlog 保留时间，并定期监控复制延迟。对于读压力较大的业务，可以部署多个 Replica 提供读服务，再结合高可用组件实现自动故障切换。

此外，应保持主从 MySQL 版本一致，避免跨大版本复制带来的兼容性问题，并定期进行备份和恢复演练，确保数据库能够快速恢复。

总结

MySQL 主从复制是构建高性能、高可用数据库架构的重要基础。相比传统复制方式，GTID 复制配置更加简单，维护成本更低，也更适合现代生产环境。只要正确配置 Binary Log、GTID、复制账号以及 Source 和 Replica 参数，就可以快速完成 MySQL 8.0 主从同步部署，为读写分离、备份恢复以及数据库扩展提供稳定可靠的基础。