数据库内核月报－ 2016/02 - MariaDB · 版本特性 · MariaDB 的 GTID 介绍 - 《数据库内核月报》

实现方式
GTID的应用

在Master端所有数据库的变更（包括DML和DDL）都会以 Binlog Event 的方式写入Binlog中。Slave会连上Master然后读取 Binlog Event，再重放这些操作到自身的数据中。一个实例可以既是Master同时又是Slave，做成双向复制。也可以一级一级串联，做成级联复制，Binlog Event 中包含的 server_id 可以识别产生 Event 的实例，避免重复执行。

Slave会保存最后一次收到和应用的Binlog的位置，因此Slave重连Master时可以从中断的位置继续开始复制。也可以在暂停Slave后，将其整体拷贝到新的位置，然后作为一个新的Slave继续复制。

全局事务ID（Global transaction ID，GTID）为每个 Event Group （就是一系列 Event 组成的一个原子单元，要么一起提交要么都无法提交）引入了一个标识，因此 GTID 是标识“事务”的最佳方式（尽管 Event 里面还包含一些非事务的DML语句和DDL，它们可以作为一个单独的 Event Group ）。每当一个 Event Group 从Master复制到Slave时，它的 GTID 也通过 GTID Event 被传到Slave。因为每个 GTID 在整个复制拓扑结构中都是一个唯一标志，所以这使得在不同的实例之间识别相同的 Binlog Events 非常简单，然而在有 GTID 之前，想做到这点是很困难的。MariaDB 从 10.0.2 开始提供 GTID 支持，但是 MariaDB 的 GTID 与 MySQL 的 GTID 在实现原理上并不相同，因为 MariaDB 支持像多源复制啊、多主复制等官方暂时还没考虑的复制模型。下面我们来看看 MariaDB 的 GTID 的实现。

使用 GTID 有两个主要的优势：

Slave的状态是 Crash-Safe 的。

Slave的执行状态（最后一个执行的 GTID）被记录在系统表中。如果这张表使用的是事务引擎（例如InnoDB，默认就是），那么修改用户表的数据和修改Slave状态的系统表这两个操作在就可以放在一个事务中完成，这就保证了Slave状态是 Crash-Safe 的，如果Slave崩溃了，那么 Crash Recovery 就可以在重启的时候把用户数据表和Slave状态系统表恢复到一个一致的位点。而在非 GTID 复制的旧版本中，这也是做不到的，Slave状态只是简单的存放在 relay-log.info 文件中（MySQL是可以把 Binlog File 和 Binlog Pos 也存在 slave_relay_log_info 和 slave_master_info 系统表中），而且需要靠不断的 fsync() 调用才能同步到磁盘上，一旦宕机很可能导致Slave状态跟实际不一致（但是也只有事务引擎的DML能保证一致，非事务引擎和DDL本身就不是Crash-Safe的）。

基于这两个优势，通常我们都建议使用GTID复制。并且传统的基于Binlog文件位置的复制方式，和 GTID 的复制方式，在 MariaDB 中是可以相互之间平滑的切换的。

每个GTID，都包含三个数字部分，分别用’-‘号隔开，例如：

0-1-10

第一个数字’0’是Domain ID，这是一个32位的无符号整型。

第二个数字’1’是Server ID，这跟传统的主备复制中 Server ID 的含义是一样的，也是一个32位无符号整型。因此在一个复制拓扑中每个实例的Server ID必须是唯一的。

第三个数字是序列号（Sequence Number）。这是一个64位的无符号整型。每个新产生的 Event Group 记录到Binlog时都会新生成一个单调递增的序列号。

这个规则使得 (server_id, sequence_number) 总是唯一的，因此GTID也是全局唯一的。

使用64位数字可以提供充足序列号支持庞大的 Event Group 数量，在可预见的时间内，应该来说是没有溢出风险的。但是一个可见的风险是，人为地设置一个很高的 gtid_seq_no 值，导致 GTID 的起始序列号就很高，是可能导致序列号逼近64位数值的上限的。

当 Events 从Master复制到Slave时，Events 总是按照从Master读取的顺序记录在Slave的Binlog中。因此，如果同一时刻只有一个Master接收变更操作（不包括复制带来的变更操作），那么 Binlog 中 Events 的顺序在所有参与复制关系的实例上应该都是一样的。

这种一致的 Binlog 顺序，可以被Slave用来追踪当前复制的位置。只要Slave记住最后一个从Master复制过来的 Event Group 的 GTID，重连到Master时（不管是原来的Master还是新的Master），就可以发送这个 GTID 给Master，然后Master就可以开始继续发送这个 GTID 之后的 Event.

然而，如果用户同时在多个实例上做了更新，那么一般来说各个实例上的Binlog顺序是不可能一样的。当使用多源复制、或者实例之间构成环状拓扑结构时，这种情况是可能出现的；或者人为手动对一个Slave做了更新操作，也可能发生这种情况。如果 Binlog 顺序在新老Master之间不一样，那么仅仅使用一个独立的GTID（不包含 Domain ID）并不足以记录当前的状态。

而 Domain ID 的任务, 就是为了解决这种情况。

通常，Binlog 并非是一个单一有序的数据流（Strem），相反，它是由许多不同的数据流组成的，每个数据流都由一个自己的 Domain ID 来识别。对每个数据流，GTID 总是以相同的 Binlog 顺序存储在每个实例中。但是，不同的数据流可以以不同的方式在不同的实例中交错。

Slave通过记录每个复制数据流（Replication Stream）中最后一次应用的 GTID 位置来跟踪复制的位点。当连上一个新的Master时，Slave可以为每个 Domain ID 从不同的 Binlog 位点开始复制。

后面有一节我们专门阐述了如何设置 Domain ID，以及如何在多源复制、多主复制的场景下利用 Domain ID.

从 MariaDB 10.0.2 开始，GTID 是默认自动打开的。每个 Event Group 写到 Binlog 时会先收到一个GTID_EVENT，用MariaDB的 mysqlbinlog 工具或者 SHOW BINLOG EVENTS 命令可以看到这个Event。

Slave自动记录了最后一次应用的 Event Group 的 GTID，可以通过 gtid_slave_pos 变量来查看：

当Slave连接到Master时，可以选择是否使用 GTID 方式，或者使用原来的文件位置的方式来判断起始的复制点位。如果使用 GTID 方式复制，那么在 CHANGE MASTER 的时候使用 master_use_gtid 选项来设置：

CHANGE MASTER TO master_use_gtid = { slave_pos | current_pos | no }

CHANGE MASTER TO master_use_gtid=slave_pos 将把Slave配置为使用 GTID 方式。当Slave连接到Master时，Master将从最后一个GTID开始给Slave复制 Binlog，可以通过 @@gtid_slave_pos 这个变量来查看目前最后一个GTID是什么。由于GTID在所有参与复制的实例之间都是相同的，因此Slave可以被指向不同的Master，Master可以自动决定正确的复制起始位置。

但是，假设我们设置了两个实例A和B，并且让A是Master，B是他的Slave。运行一段时间后，我们关闭A，然后让B成为新的Master，然后一段时间后我们再把A加回来作为B的Slave。

由于A从来没有成为Slave，它没记录任何之前复制的GTID，所以@@gtid_slave_pos是空的。如果要让A自动被加为Slave，可以使用 master_use_gtid=current_pos 这个方法。这样做在连接的时候，Slave会把@@gtid_current_pos存的GTID发给Master，而不是 @@gtid_slave_pos，这样就把A做Master时产生的最后一个GTID发送给了B，然后从这个位置开始复制。

使用master_use_gtid=current_pos可能是最简单的方式，因为这样不需要考虑之前这个实例是作为Master还是Slave。但是，必须注意的是，如果这样做的话，就不要在Slave上做任何非复制带来的修改操作，否则就乱了。如果出现了这种情况，复制可能无法继续，因为这些事务在Master运行时并没有在Master上出现过，当切换Master和Slave身份时，就出现了未知的GTID。为了避免这种情况，可以在Slave上设置 @@sql_log_bin=0。

如果这不是Slave期望的运行方式，Slave上就是可能有一些数据变更，那么就应该使用master_use_gtid=slave_pos方式。这样Slave总是使用最后一次复制的GTID发送给Master来获取之后的Event Group。这可以避免上面的方式在一些不可控因素修改了Slave本地的数据却没有在Binlog之中有所记录的问题。

当GTID严格模式开启时（@@GLOBAL.gtid_strict_mode=1），通常最好是用current_pos。在严格模式下，不允许有额外的事务。

如果Slave没有开启Binlog，那么current_pos和是一回事。

即使当Slave被配置为旧的复制方式时（CHANGE MASTER TO master_log_file=..., master_log_pos=... ），MariaDB依然会跟踪当前的GTID位置并保存在 @@GLOBAL.gtid_slave_pos。这意味着一个用非GTID模式复制的Slave可以很容易地修改为GTID方式：

CHANGE MASTER TO master_use_gtid = slave_pos

Slave会保存 master_use_gtid=slave_pos|master_pos的信息以为后来进行连接，直到复制方式被修改为指定 master_log_file/pos=... 或者 master_use_gtid=no。当前的复制方式可以通过SHOW SLAVE STATUS的Using_Gtid列来判断:

SHOW SLAVE STATUS\G
...
Using_Gtid: Slave_pos

Slave内部用mysql.gtid_slave_pos表来存储GTID位置（所以重启后@@GLOBAL.gtid_slave_pos的值会重新被填充）。升级MariaDB的版本到10.0之后，必须使用mysql_upgrade来保证这些表和列被创建了。

为了保证Crash-Safe，这张表必须使用事务引擎，例如InnoDB。当MariaDB第一次安装或者升级到10.0.2+时，这张表会用默认的存储引擎创建 - 默认就是InnoDB。当然如果把默认引擎改成MyISAM的话，这张表就会被创建成MyISAM。如果需要修改引擎，可以直接用ALTER TABLE的方式：

mysql.gtid_slave_pos 表不应该被Slave线程之外的方式修改。尤其是不要尝试直接修改表的数据来改变Slave的GTID位置，如果要修改应该用这种方式：

SET GLOBAL gtid_slave_pos = '0-1-1'

设置一个新的使用GTID的Slave跟设置一个非GTID方式复制的Slave差别很大，基本步骤是:

配置一个新的实例并且载入初始数据。
从相应的Master Binlog位置开始Slave的复制。

从一个空实例开始

出于测试的目的，最简单的方式就是新建一个新的空实例，然后从Master复制所有的Binlog（在实际生产环境中这几乎是不可能的，因为最早的Binlog文件应该早就被清除了）。

正常方式安装的Slave实例，默认情况下GTID位点都是空的，因此可以从Master的第一个Binlog文件开始复制。但是如果Slave之前被用作其他目的，那么初始位置需要手动设置为空：

SET GLOBAL gtid_slave_pos = "";

下一步就是用CHANGE MASTER来指向Master，指定master_host什么的。只是不再用master_log_file和master_log_pos，而是用master_use_gtid=current_pos（或者slave_pos）:

START SLAVE;

从备份集设置

一般来说创建Slave的方式都是通过备份集来恢复出一个新的实例，然后找到Master上复制的起始点创建复制关系。

因而找到正确的复制起始位置是非常重要的，否则Slave可能因为数据与Master不一致而导致复制中断。

一旦获取了备份时正确的Binlog位点（文件名和偏移量），那么就可以用BINLOG_GTID_POS()函数来计算GTID:

从MariaDB 10.0.13版本开始，mysqldump会自动完成这个工作，并且把GTID的写在导出文件中，只要设置 –master-data 或 –dump-slave 的同时设置 –gtid 即可。

这样的话新的SLAVE就可以通过设置 @@gtid_slave_pos 的值来设定复制的起始位置，用 CHANGE MASTER 把这个值传给主库，然后开始复制：

SET GLOBAL gtid_slave_pos = "0-1-2";
CHANGE MASTER TO master_host="127.0.0.1", master_port=3310, master_user="root", master_use_gtid=slave_pos;
START SLAVE;

用Master备份搭建一个Slave时这种方式尤其有用。不过一定要记得确保Master和Slave的server_id要设置成不一样的。

如果备份是从现有的Slave实例创建的，那么GTID的位置已经存在mysql.gtid_slave_pos表中了，并且跟其他事务引擎表都是在一个一致状态。这种情况下，就没必要去找GTID的位置然后设置变量之类的，因为已经从mysql.gtid_slave_pos载入了正确的值。然而从Master做备份就没这个福利了，因为正确的GTID位点信息在Binlog中，而不是在mysql.gtid_slave_pos。

将非GTID复制的SLAVE切换为GTID方式

如果已经有一个SLAVE运行在Binlog文件名和偏移量的复制模式下，那么可以直接修改为GTID模式。对于升级来说这是很有用的方式。

当一个SLAVE通过Binlog位点的方式跟Master连接，并且Master支持GTID，那么SLAVE会自动把GTID位置的信息也获取过来，并且在复制过程中会不断更新。因此，当一个SLAVE已经连上了一个支持GTID的Master，那么并不需要额外的动作就可以把复制切换为使用GTID：

STOP SLAVE;
CHANGE MASTER TO master_host="127.0.0.1", master_port=3310, master_user="root", master_use_gtid=current_pos;
START SLAVE;

（后面更新的版本可能会增加一种方式，如果第一次连接的时候使用的是原来的Binlog文件位点的方式，那么只要主库是支持GTID的，后面再连接的时候就自动切换为GTID方式）

一旦复制运行在GTID模式下（master_use_gtid=current_pos|slave_pos），Slave就可以很容易地用CHANGE MASTER更换到新的Master：

STOP SLAVE;
CHANGE MASTER TO master_host='127.0.0.1', master_port=3312;
START SLAVE;

Slave已经记录了最后执行的旧Master的GTID，而且由于GTID在整个复制拓扑中都是全局唯一的，因此Slave只需要根据GTID在新Master的Binlog里找到合适的位置，继续复制就行了。

Binlog是一组有序的Events数据流（或者多个数据流，每个复制域（Replication Domain）都是一个数据流，参照接下来那一节），数据流内的Event在每个Slave上总是按照同一顺序被应用。MariaDB 的 GTID 凭借这个顺序，使得它足以记住每个数据流中的这个点。由于Event顺序在每个实例上是相同的，切换到另一个实例的Binlog中相同的GTID点将会得到一样的结果。

比较通俗易懂的讲，就是MariaDB的GTID复制是全异步的，并且是非常灵活的。甚至Binlog顺序的一致性被破坏了，切换Master后，GTID依然可以尝试从当前GTID位点继续复制。

Binlog顺序在不同的实例之间产生不一致，最常见的情况是用户或者DBA直接更新了Slave实例（并且把日志写到Binlog了）。这会导致Slave上的有些Event，在Master和其他Slave上都没有。虽然可以通过设置sql_log_bin=0来避免这些变更写到Binlog。

这通常是避免实例之间Binlog不一样的最好的办法。话虽然这么说，但MariaDB的复制就是为最大的灵活性而设计的，而且有时这种不一致是有合理需求的。这种情况下，只需要理解GTID位点在每个Binlog数据流（每个Replication Domain就有数据流）中是一个单独的点。

当一个复制拓扑中两个Master在同一时间都是活跃的时候，也可能出现不一致。比如使用环形多主复制的时候。但是只要保证旧Master上的变更在完全复制到所有Slave之前不允许切换到新的Master。通常情况下，要切换Master，首先原Master上的写应该先停止，然后等待所有变更复制到了新的Master，然后写开始发送到新的Master。有意使用多个Master写的情况也是支持的，下一节会描述这种情况。

GTID严格模式将用于强制保证所有实例之间的Binlog相同。当这个选项开启，如果遇到任何不一致情况都会导致复制停止并且报错。

MariaDB的GTID支持同时有多个活跃的Master。通常这种情况发生在多源复制或者环形多主情况下。

在这样的设置下，每个活跃的Master都必须用友自己独特的Replication Domain ID，gtid_domain_id。然后Binlog实际上就会由多个独立的数据流组成，每个活跃的Master都有一个。在每个Replication Domain中，每个实例的Binlog顺序总是一样的。但是两个不同的数据流在不同的实例的Binlog里可能是交错的。

这样的话，一个GTID位点不单单是一个单独的GTID了，它将是每个Domain ID下最后一个执行的Event Group的GTID，实际上这表示了每个Binlog数据流达到的位置。当Slave连上Master的时候，它可以在不同的Binlog位置上继续复制一个数据流。由于一个数据流内的数据顺序在不同实例上是一样的，这使得Slave可以在任何一个新的Master上找到正确的位点继续复制。

Domain ID是由DBA按照应用的需要分配的，@@GLOBAL.gtid_domain_id的默认值是0。对于大部分的复制场景这都是个合适的值，只要复制拓扑中同时只有一个活跃的Master。MariaDB永远不会自己写一个新的domain_id到Binlog中。

当使用多源复制的时候，一个Slave同时会连上多个Master，每个Master都应该配置一个不同的Domain ID。

同样的，在环形多主复制拓扑结构中，所有的环上所有的Master都会被应用并发写入（可以通过一些机制来避免冲突，例如区分ID段），每个实例也需要配置不同的Domain ID。（在环形多主情况下，如果应用程序保证同一时刻只会更新一个Master，那么一个Domain ID就够了）

正常情况下，一个Slave实例不应该直接接受任何更新（这导致了跟Master的Binlog不一致）。因此在Slave上被设为什么值并不重要，尽管它可能是有意义的，例如把它设置为跟Master一样（如果不使用多主），来使其更容易把Slave改成新的Master。当然，如果Slave自身是一个活跃的Master，例如在环形多主拓扑中，那么Domain ID还是应该设置的，因为这时候实例的角色是一个活跃的Master。

没有正确的配置Domain ID本身并不是一个错误（比如根本没配）。例如，一个5.5版本的环形多主复制环境，升级到10.0。这个环可以继续像之前一样继续工作下去，即使所有的实例上Domain ID还是默认值0。甚至有可能还是使用GTID在实例之间复制。然而，当切换Slave的Master时必须小心翼翼，如果Binlog顺序在新旧Master不一样，那么用一个单独的GTID位置（没有Domain ID）从新的Master继续复制，数据就可能出错。