MySQL基于GTID的主从同步（一）

MySQL基于GTID的主从同步（一）

原文来自MySQL的官方文档 MySQL :: MySQL 5.6 Reference Manual :: 17.1.3 Replication with Global Transaction Identifiers

global transaction identifiers (GTIDs)，意味全局事务标识符。在MySQL主从同步中，如果使用GTID的方式来进行同步，任何在各主库中提交的事务能被识别和追踪，而且能被发送到各个从库中去。同时使用GTID模式进行复制，不需要在增加从库或更换主库时区记录binlog日志文件和文件中的偏移位置，极大简化了建主从同步的操作。GTID同步完全基于事务，因此主从的数据一致性是能得到保证的。但使用GTID会带来一些MySQL使用上的限制。具体内容看后续的介绍。

GTID的概念

GTID是主库为每个事务分配的一个全局标识符，这个标识不仅仅在源主库上是唯一的，同时在同步配置中设置的所有数据库中都是唯一的。事务和GTID是一对一的关系。

GTID的组成：

GTID = source_id:transaction_id

source_id

代表源库，用的是源库的

server_uuid

。

transaction_id

是个序列号，取决于事务提交的顺序。

在

SHOW SLAVE STATUS

语句的输出里，相同源库的GTID会被缩写成下面简单的格式：

3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5

代表uuid为3E11FA47-71CA-11E1-9E33-C80AA9429562这个数据库上的第1个到第5个事务。

GTID集合

GTID的集合像下面那样表示：

gtid_set:
uuid_set [, uuid_set] ...
| ''

uuid_set:
uuid:interval[:interval]...

uuid:
hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh

h:
[0-9|A-F]

interval:
n[-n]

(n >= 1)

MySQL中

gtid_executed

和

gtid_purged

变量会使用GTID set的格式来表示。

GTID会始终在主从上保留，这就意味着能通过查binlog来确定在任意从库上运行的任意事务的源。另外一个GTID在指定的某个数据库中提交了，随后所有有相同的GTID的事务都会被这个数据库忽略。因此在主库上提交的事务不会在从库上重复执行，保证了数据的一致性。

若使用GTID进行同步，从库不需要任何的外部信息，如主库的binlog名称和position，所有需要的信息都会在同步过程中获得。只需要在

CHANGE MASTER TO

中指定

MASTER_AUTO_POSITION

为1即可。

GTID的生成和生命周期包括下面几步：

1. 事务在主库上提交和执行；

* GTID由主库UUID和当前最小的未使用的事务序列号组成；

* GTID会被写入主库binlog；

2. Binlog传到从库并存储在从库的relay log中（详见 MySQL :: MySQL 5.6 Reference Manual :: 17.2 Replication Implementation）。从库读取GTID，同时将system variable

gtid_next

置为GTID的值。这将告诉从库下一个要执行的事务必须符合这个GTID。设置

gtid_next

是会话级别的;

3. 从库检查确认该GTID没有用于记录别的事务，如果没有，从库就执行事务并把GTID写入自己的binlog。在执行前进行检查，不仅保证先前没有该GTID的事务被执行，也能确保没有别的会话读取了该GTID但未提交事务的情况。也就是说，不允许多个客户端同时执行相同的事务。

4. 因为

gtid_next

不会为空，从库不会去尝试自己生成GTID而不是去读取

gtid_next

的值。GTID从主库上获得，并写在binlog中对应的事务之前。