MySQL 8.0.23 新特性：assign_gtids_to_anonymous_transactions

在 MySQL 主从复制场景中，GTID（全局事务标识符）是保障数据一致性、简化故障切换的关键技术，但在 8.0.23 版本之前，存在一个棘手的配置限制 —— 若主库未开启 GTID，从库则无法单独启用 GTID，这给需要渐进式升级 GTID 的业务带来了极大不便。而assign_gtids_to_anonymous_transactions特性的出现，恰好打破了这一约束，让 “主库禁用 GTID、从库开启 GTID” 的异构配置成为可能。

一、特性核心：解决什么问题？

在传统配置中，主从复制的 GTID 模式需保持一致：要么两者均开启，要么均关闭。若业务想先在从库启用 GTID 以测试兼容性，主库因风险暂不开启，在 8.0.23 前完全无法实现。

 

而 assign_gtids_to_anonymous_transactions 的核心作用，就是让开启 GTID 模式（gtid_mode=on）的从库，能够接收主库的 “匿名事务”（主库未开 GTID 时生成的事务），并为这些事务自动分配 GTID，从而实现主从 GTID 模式的异构兼容。

 

需要特别注意的约束：从库一旦设置gtid_mode=on，后续无法直接修改，除非移除 assign_gtids_to_anonymous_transactions 的配置。

二、参数详解：三种取值如何用？

assign_gtids_to_anonymous_transactions 支持三种配置值，分别对应不同的 GTID 分配逻辑，语法格式为：

 

CHANGE REPLICATION SOURCE TO assign_gtids_to_anonymous_transactions=off|local|<uuid>;

 

 

其各取值的核心含义如下：

 

• off：默认值，不启用该特性，此时从库若开 GTID，仍无法接收主库的匿名事务。
• local：为匿名事务分配 GTID 时，使用从库本地的server_uuid（可通过select @@server_uuid;查看），生成的 GTID 与从库自身事务的 GTID 格式一致。
• uuid：手动指定一个有效的 UUID（需符合 MySQL UUID 格式，如867e5079-8420-11ed-a0bf-1260d715ed11），事务的 GTID 将基于该 UUID 生成，适用于需统一 GTID 来源标识的场景。

三、实操演示：从 0 到 1 验证特性

下面通过实际步骤，演示如何利用该特性实现 “主库关 GTID、从库开 GTID” 的主从复制：

1. 初始状态检查（主从均未开 GTID）

主库执行查询，确认 GTID 相关参数为关闭状态：

 

mysql> select @@enforce_gtid_consistency,@@gtid_mode;
+----------------------------+-------------+
| @@enforce_gtid_consistency | @@gtid_mode |
+----------------------------+-------------+
| OFF                        | OFF         |
+----------------------------+-------------+
1 row in set (0.00 sec)

 

 

从库执行相同查询，结果与主库一致，均为 OFF，确保初始环境无 GTID 配置。

2. 主库生成匿名事务

在主库的test_gtid数据库中创建表，模拟业务操作，此时主库未开 GTID，事务为 “匿名事务”：

 

mysql> use test_gtid;
mysql> create table gtid_test1 (id int);
Query OK, 1 row affected (0.01 sec)

 

 

查看主库 binlog 事件，可发现事务类型为Anonymous_Gtid（匿名事务），无具体 GTID 标识：

 

mysql> show binlog events in 'binarylogs.000008';
+-------------------+-----+----------------+-----------+-------------+------------------------------------------------------------------+
| Log_name          | Pos | Event_type     | Server_id | End_log_pos | Info                                                             |
+-------------------+-----+----------------+-----------+-------------+------------------------------------------------------------------+
| binarylogs.000008 | 157 | Anonymous_Gtid |         3 |         234 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                             |
| binarylogs.000008 | 234 | Query          |         3 |         365 | use `test_gtid`; create table gtid_test1 (id int) /* xid=196 */  |
+-------------------+-----+----------------+-----------+-------------+------------------------------------------------------------------+

 

3. 从库配置特性并启用 GTID

步骤 1：从库开启 GTID 模式

先将从库的gtid_mode设为 ON（一旦设置无法直接修改）：

 

mysql> set global gtid_mode=ON;
Query OK, 0 rows affected (0.02 sec)

 

步骤 2：配置 assign_gtids_to_anonymous_transactions

选择local模式（使用从库本地 server_uuid），并更新复制源配置：

 

mysql> CHANGE REPLICATION SOURCE TO assign_gtids_to_anonymous_transactions=LOCAL;
Query OK, 0 rows affected, 2 warnings (0.03 sec)

# 启动从库复制进程
mysql> start slave;
Query OK, 0 rows affected, 1 warning (0.01 sec)

 

4. 验证特性效果

查看从库的 binlog 事件，此时主库的匿名事务已被分配 GTID，且 GTID 中的 UUID 与从库server_uuid一致：

 

# 查看从库binlog（以binarylogs.000017为例）
mysql> show binlog events in 'binarylogs.000017';
+-----------------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name                    | Pos | Event_type     | Server_id | End_log_pos | Info                                                               |
+-----------------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| binarylogs.000017           | 197 | Gtid           |         3 |         283 | SET @@SESSION.GTID_NEXT= '867e5079-8420-11ed-a0bf-1260d715ed11:13' |
| binarylogs.000017           | 283 | Query          |         3 |         358 | BEGIN                                                              |
| binarylogs.000017           | 358 | Table_map      |         3 |         419 | table_id: 99 (test_gtid.gtid_test1)                                |
+-----------------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+

# 验证从库server_uuid与GTID中的UUID一致
mysql> select @@server_uuid;
+--------------------------------------+
| @@server_uuid                        |
+--------------------------------------+
| 867e5079-8420-11ed-a0bf-1260d715ed11 |
+--------------------------------------+

 

 

可见，主库的匿名事务在从库中已转化为带 GTID 的事务，实现了异构 GTID 模式下的正常复制。

四、特性价值：为何值得用？

1. 降低 GTID 升级门槛：无需主库停机开启 GTID，可先在从库验证 GTID 兼容性，再逐步推广到主库，减少业务风险。
2. 提升复制灵活性：支持主从 GTID 模式异构，满足部分场景下 “主库保持现状、从库启用新特性” 的需求（如从库需基于 GTID 做数据恢复）。
3. 保障事务可追溯：为匿名事务分配 GTID 后，可通过 GTID 快速定位事务来源，简化主从数据一致性校验和故障排查。