如何在MySQL 8.0中启用并配置并行的全局事务标识符GTID？

MySQL 8.0中“并行的GTID”不存在，GTID仅提供事务唯一标识与自动位点管理；真正提升从库回放速度需配置GTID（gtid_mode=ON、enforce_gtid_consistency=ON）与并行复制组合（slave_parallel_type=LOGICAL_CLOCK、slave_parallel_workers=4–16、slave_preserve_commit_order=ON），并确保主库启用WRITESET依赖追踪及ROW格式。

MySQL 8.0 中没有“并行的 GTID”这个概念——GTID 本身是事务级唯一标识，不提供并行能力；所谓“并行复制”是另一个独立机制（slave_parallel_workers），它可与 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_slave_updates = ON：从库也要写 binlog，否则级联复制或故障切换时无法继续

改完重启 MySQL。注意：MySQL 8.0 不支持在线动态开启 gtid_mode，必须重启生效。

启用并行复制（基于 WRITESET）

MySQL 8.0 默认并行策略是 DATABASE，效率低；推荐用 WRITESET，它能跨库并行，前提是主库已开启 binlog_transaction_compression = ON（非必需但推荐）且事务写集（writeset）信息被记录。

在从库上执行：

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 必须开启，否则重启后并行线程可能状态错乱
• 不要设 slave_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 中 Slave_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。