MySQL 8.0并行GTID开启与配置详解

需要先纠正一个常见的认知误区：MySQL 8.0 中并不存在所谓的“并行 GTID”概念。GTID 的核心职责是为每个事务分配全局唯一的标识符，并自动记录主从同步位置；真正负责加速从库回放的另一套机制叫作“并行复制”。两者可以协同工作，但互不依赖。因此，关键任务是将 GTID 与并行复制合理搭配，使从库既能保持数据一致性，又能实现高效回放。

验证 MySQL 8.0 版本及 GTID 基础支持

GTID 自 MySQL 5.6.5 开始引入，但生产环境强烈建议使用 8.0.22 或更高版本——早期版本对 STOP REPLICA、SOURCE_AUTO_POSITION 等关键语法的支持并不完整，容易遇到兼容问题。

执行以下命令快速确认当前环境：

SELECT VERSION();SHOW VARIABLES LIKE 'gtid_mode';SHOW VARIABLES LIKE 'enforce_gtid_consistency';

必须确保 gtid_mode 为 ON、enforce_gtid_consistency 为 ON，否则后续所有配置都无法生效。如果显示 OFF 或 OFF_PERMISSIVE，说明 GTID 尚未启用——不要试图跳过这一步直接开启并行，这是不可行的。

主从两端统一配置 GTID 关键参数

主库和从库的 my.cnf 文件中 [mysqld] 段，必须同时包含以下参数，缺一不可：

• server_id：每台机器唯一，不能重复（例如主库设为 1，从库设为 2）
• log_bin = mysql-bin：必须开启 binlog，GTID 依赖它来记录事务
• binlog_format = ROW：GTID 严格要求行格式，MIXED 或 STATEMENT 会触发 enforce_gtid_consistency 直接拒绝执行
• gtid_mode = ON：核心开关，必须开启
• enforce_gtid_consistency = ON：禁止不安全的语句，例如 CREATE TABLE ... SELECT、事务内建临时表等操作
• log_sla ve_updates = ON：从库也必须写 binlog，否则级联复制或故障切换时会中断复制链路

修改完成后重启 MySQL。注意：MySQL 8.0 不支持在线动态开启 gtid_mode，必须停机重启才能生效。

启用基于 WRITESET 的并行复制

MySQL 8.0 默认的并行策略为 DATABASE，效率较低；推荐改用 WRITESET，它能够跨不同数据库并行重放事件，前提是主库已开启 binlog_transaction_compression = ON（非强制但建议启用），且事务的写集信息被记录在 binlog 中。

在从库上执行以下命令：

STOP REPLICA;SET PERSIST parallel_applier_type = 'LOGICAL_CLOCK';SET PERSIST parallel_applier_workers = 4;SET PERSIST relay_log_recovery = ON;START REPLICA;

这里有三个关键点需要特别注意：

• parallel_applier_type = 'LOGICAL_CLOCK' 是 8.0 中启用 WRITESET 并行复制的前提（该功能底层由 binlog_transaction_dependency_tracking 控制，但用户无需直接设置它）
• parallel_applier_workers 建议设置为 CPU 核数的 1–2 倍，过高反而会因锁争用降低吞吐量
• relay_log_recovery = ON 必须开启，否则重启后并行线程的状态可能发生混乱
• 特别注意：不要设置 sla ve_parallel_type = LOGICAL_CLOCK —— 这是 MySQL 5.7 的旧参数，8.0 已废弃，使用后会导致 START REPLICA 失败

启动 GTID 复制并验证并行是否生效

从库连接主库时，必须使用 SOURCE_AUTO_POSITION = 1（而非已废弃的 MASTER_AUTO_POSITION = 1）：

CHANGE REPLICATION SOURCE TO  SOURCE_HOST='master_ip',  SOURCE_USER='repl',  SOURCE_PASSWORD='xxx',  SOURCE_AUTO_POSITION = 1;

启动后，建议通过以下方式验证是否真正进入并行模式：

• SHOW REPLICA STATUSG 中 Sla ve_SQL_Running_State 会显示类似 worker 2 is waiting for an event from coordinator 的信息，表明多线程正在工作
• SELECT * FROM performance_schema.replication_applier_status_by_worker; 可查看各个 worker 的 LAST_SEEN_TRANSACTION 是否不同，且 WORKER_ID > 0
• 如果 Seconds_Behind_Master 持续为 0，但 Retrieved_Gtid_Set 不等于 Executed_Gtid_Set，说明并行线程卡在某个事务依赖上（常见于大事务或 DDL 操作）

最容易忽略的一点：即使开启了并行，单个大事务（例如一个 UPDATE 影响百万行）仍然会阻塞所有 worker，因为 writeset 无法拆分。此时只能通过业务层拆分事务，调高 parallel_applier_workers 也解决不了问题。