MySQL主从复制架构搭建实战：GTID模式配置与读写分离实现

MySQL主从复制是数据库高可用架构的基础。主库执行写操作，将变更记录到binlog，从库拉取binlog并回放，实现数据同步。基于GTID（Global Transaction Identifier）的复制模式相比传统基于binlog位置（Position）的复制，解决了断点续传定位困难和手动指定位置的运维风险。本文从主库配置、从库搭建、读写分离三个环节，给出完整可操作的配置流程。

GTID模式主库配置

GTID为每个事务分配全局唯一标识，格式为server_uuid:transaction_id。从库自动从主库最后同步的GTID位置继续复制，无需手动指定binlog文件和位置。

主库my.cnf配置：

[mysqld]
# 基础配置
server_id = 1
log_bin = /var/log/mysql/binlog/mysql-bin
binlog_format = ROW
binlog_row_image = FULL
expire_logs_days = 7
max_binlog_size = 256M

# GTID配置
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = ON

# 半同步复制（提升数据安全）
plugin_load = "rpl_semi_sync_master=semisync_master.so"
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_master_timeout = 3000  # 超时3秒降级为异步

gtid_mode=ON和enforce_gtid_consistency=ON必须同时启用。enforce_gtid_consistency阻止不安全的事务（如CREATE TABLE ... SELECT）执行，保证GTID连续性。log_slave_updates使从库也记录binlog，支持级联复制。

创建复制账号并导出初始数据：

-- 创建复制账号
CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'Repl@2026Secure';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'192.168.1.%';
FLUSH PRIVILEGES;

-- 锁定主库并记录GTID位置
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS\G
-- 记录输出的Executed_Gtid_Set值

# 使用mysqldump导出初始数据（另开终端执行，避免锁释放）
mysqldump -u root -p --all-databases --triggers --routines --events   --single-transaction --master-data=2 --set-gtid-purged=ON   > /tmp/full_backup.sql

--master-data=2在dump文件中记录binlog位置为注释，--set-gtid-purged=ON在文件头部写入SET @@GLOBAL.GTID_PURGED语句，导入从库时自动设置GTID起点。

从库配置与复制启动

从库my.cnf配置：

[mysqld]
server_id = 2
log_bin = /var/log/mysql/binlog/mysql-bin
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = ON
read_only = ON
super_read_only = ON

# 半同步从库
plugin_load = "rpl_semi_sync_slave=semisync_slave.so"
rpl_semi_sync_slave_enabled = 1

# 并行复制（基于组提交）
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
slave_preserve_commit_order = ON

read_only=ON阻止非SUPER权限用户写入，super_read_only=ON连SUPER用户也只读，防止误操作在从库写入数据导致主从不一致。

导入初始数据并启动复制：

-- 导入主库数据
SOURCE /tmp/full_backup.sql;

-- 配置GTID复制（无需指定binlog位置）
CHANGE MASTER TO
  MASTER_HOST = '192.168.1.100',
  MASTER_PORT = 3306,
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'Repl@2026Secure',
  MASTER_AUTO_POSITION = 1;

START SLAVE;
SHOW SLAVE STATUS\G

MASTER_AUTO_POSITION = 1是GTID复制的核心配置，从库自动使用GTID协议与主库协商复制起点。

检查复制状态关键字段：

SHOW SLAVE STATUS\G
-- 重点关注：
-- Slave_IO_Running: Yes
-- Slave_SQL_Running: Yes
-- Seconds_Behind_Master: 0
-- Retrieved_Gtid_Set / Executed_Gtid_Set: GTID范围
-- Last_IO_Error / Last_SQL_Error: 错误信息

读写分离实现与ProxySQL配置

应用层实现读写分离通常通过中间件。ProxySQL是MySQL高性能代理，自动路由读写请求：

-- ProxySQL Admin配置
-- 添加主从节点
INSERT INTO mysql_servers(hostgroup_id, hostname, port, max_connections)
VALUES (1, '192.168.1.100', 3306, 200);  -- 写组(主库)

INSERT INTO mysql_servers(hostgroup_id, hostname, port, max_connections)
VALUES (2, '192.168.1.101', 3306, 200);  -- 读组(从库)

-- 配置读写分离规则
INSERT INTO mysql_query_rules(rule_id, active, match_digest, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT.*FOR UPDATE', 1, 1);  -- SELECT FOR UPDATE走主库

INSERT INTO mysql_query_rules(rule_id, active, match_digest, destination_hostgroup, apply)
VALUES (2, 1, '^SELECT', 2, 1);  -- 普通SELECT走从库

INSERT INTO mysql_query_rules(rule_id, active, match_digest, destination_hostgroup, apply)
VALUES (3, 1, '^(INSERT|UPDATE|DELETE|CREATE|ALTER|DROP)', 1, 1);  -- 写操作走主库

-- 加载配置
LOAD MYSQL SERVERS TO RUNTIME;
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
SAVE MYSQL QUERY RULES TO DISK;

ProxySQL通过正则匹配SQL语句类型，自动将写请求路由到主库(hostgroup 1)，读请求路由到从库(hostgroup 2)。SELECT ... FOR UPDATE单独匹配到主库，避免从库读到未提交数据。

从库延迟监控与排障

从库延迟监控：

-- 主库执行，查看从库延迟
SHOW SLAVE STATUS\G
-- Seconds_Behind_Master字段

-- 使用pt-heartbeat更精确监控（基于时间戳对比）
pt-heartbeat --daemonize --database monitoring --table heartbeat   --master-server-id 1 --interval 1

Seconds_Behind_Master基于binlog事件时间戳，在主从时钟不同步时不准确。pt-heartbeat在主库定时写入当前时间戳，从库读取该时间戳与本地时间对比，消除时钟依赖。

常见复制中断原因及修复：

• 1032错误（记录不存在）：从库缺少主库正在更新的记录，跳过该事务：SET GTID_NEXT='uuid:seq'; BEGIN; COMMIT; SET GTID_NEXT=AUTOMATIC; START SLAVE;
• 1062错误（主键冲突）：从库已存在重复数据，检查数据一致性后跳过
• 1236错误（GTID gap）：从库GTID有空洞，需注入缺失的空事务或重新导出数据

MySQL GTID主从复制配合ProxySQL读写分离，构成数据库高可用架构的基础。后续可在此基础上引入MHA或Orchestrator实现主库故障自动切换，构建完整的数据库高可用方案。GTID模式相比传统Position模式大幅简化了复制管理，是新建主从环境的首选方案。