mysql> show master status;
+-------------------+----------+--------------+------------------+----------------------------------------------------------------------------------------------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+----------------------------------------------------------------------------------------------------------------------------------+
| master-bin.000093 | 3439 | | | 009d1a13-4f30-11ef-90ca-000c291f1937:1-151,
4e61fadf-d4e8-11ef-b3de-000c291f1937:1-11,
8be0d2d1-cf34-11ef-a62a-000c291f1937:1-12 |
+-------------------+----------+--------------+------------------+----------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> select @@server_uuid;
+--------------------------------------+
| @@server_uuid |
+--------------------------------------+
| 4e61fadf-d4e8-11ef-b3de-000c291f1937 |
+--------------------------------------+
1 row in set (0.00 sec)
如果你的 MySQL 服务器参与了多源复制，即从多个源服务器接收事务并应用，那么这些来自不同源服务器的 GTID 会累积在 Executed_Gtid_Set 中。每个 GTID 代表来自不同源的事务集，在多源复制的场景下，不同的源服务器会有不同的 UUID 标识，所以你会看到不同 UUID 下的 GTID 范围。
即使在单源复制或没有复制的情况下，如果服务器之前经历过不同的事务源或进行过切换，之前的 GTID 记录可能会保留下来。例如，你可能曾经配置过该服务器作为其他服务器的从服务器接收事务，或者进行过基于 GTID 的主从切换，这些操作都会留下相应的 GTID 信息。
评论
有用 3- 如果涉及利用主从切换做迁移的场景时，从库提主之前，没有 reset master，从库会在涉及变更时，生成一个新的从库的UUID。之前从主从同步，从主库同步过来的GTID也会保留下来，就有了两个GTID。多次切换迁移以后，会有多个GTID。
- 要避免这个情况的话，可以在从库提主时，从库reset salve后，也执行以下 reset master，就能保证后续从库只有一个GTID。
评论 有用 0
