Mysql的gtid详解

原文：MySQL GTID详解_woailyoo0000的博客-CSDN博客_mysql的gtid

MySQL在5.6版本推出了GTID复制，相比传统的复制，GTID复制对于运维更加友好，这个事物是谁产生，产生多少事物，非常直接的标识出来。

今天将讨论一下 关于从库show slave status 中的Retrieved_Gtid_Set 和 Executed_Gtid_Set.

Retrieved_Gtid_Set : 从库已经接收到主库的事务编号

Executed_Gtid_Set : 从库自身已经执行的事务编号

下面将解释这两列的含义：

首先看看master和slave的server-uuid

Master:

 show variables like '%uuid%';       
+---------------+--------------------------------------+
| Variable_name | Value                                |
+---------------+--------------------------------------+
| server_uuid   | 2a09ee6e-645d-11e7-a96c-000c2953a1cb |
+---------------+--------------------------------------+
1 row in set (0.00 sec)

Slave

>[root@localhost][(none)]> show variables like '%uuid%';
+---------------+--------------------------------------+
| Variable_name | Value                                |
+---------------+--------------------------------------+
| server_uuid   | 8ce853fc-6f8a-11e7-8940-000c29e3f5ab |
+---------------+--------------------------------------+
1 row in set (0.01 sec)

其中主库的server-id是10,从库的server-id是20.

搭建好主从以后，如果没有数据写入，那么show slave status是下面这样的:

Replicate_Ignore_Server_Ids: 
            ** Master_Server_Id: 10
                  Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb**
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: **Slave has read all relay log; waiting for more updates**
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
 **Retrieved_Gtid_Set: 
            Executed_Gtid_Set:** 
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 

如果在主库创建表，并且写入2条数据，是下面这样的:

 **create table t2 ( id int);**
Query OK, 0 rows affected (0.07 sec)

[root@localhost][db1]> **insert into t2 select 1;**
Query OK, 1 row affected (0.07 sec)
Records: 1  Duplicates: 0  Warnings: 0

[root@localhost][db1]> **insert into t2 select 2;**
Query OK, 1 row affected (0.02 sec)
Records: 1  Duplicates: 0  Warnings: 0

这里auto_commit=1,可以看到创建表加插入2条数据，一共执行了3个事务.

从库：show slave status\G

Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 10
                  Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           **Retrieved_Gtid_Set**: **2a09ee6e-645d-11e7-a96c-000c2953a1cb**:**1-3**
            **Executed_Gtid_Set**: **2a09ee6e-645d-11e7-a96c-000c2953a1cb**:**1-3**
                Auto_Position: 1

主库：show master status

+------------------+----------+--------------+------------------+------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000001 |      912 |              |                  | **2a09ee6e-645d-11e7-a96c-000c2953a1cb**:**1-3** |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)

其中主库的 Executed_Gtid_Set为：2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3

看到从库的Retrieved_Gtid_Set为: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3

Executed_Gtid_Set为： 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3

也就是说主库产生了3个事务，从库接收到了主库的3个事务，且都已全部执行。

其中 **2a09ee6e-645d-11e7-a96c-000c2953a1cb **是主库的server-uuid. 可以从从库解析binlog看出:

# at 154
#170823  0:38:38 **server id 10**  end_log_pos 219 CRC32 0x6268641f         GTID    last_committed=0        **sequence_number=1**
SET @@SESSION.GTID_NEXT= '**2a09ee6e-645d-11e7-a96c-000c2953a1cb**:**1**'/*!*/;
# at 219
#170823  0:38:38 server id 10  end_log_pos 316 CRC32 0x6c837618         Query   thread_id=103   exec_time=0     error_code=0
use `db1`/*!*/;
SET TIMESTAMP=1503419918/*!*/;
SET @@session.pseudo_thread_id=103/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
**create table t2 ( id int)**
/*!*/;

可以看见server-id为10，gtid-next为2a09ee6e-645d-11e7-a96c-000c2953a1cb:1，执行了建表，剩下的

2a09ee6e-645d-11e7-a96c-000c2953a1cb:2 与 ****2a09ee6e-645d-11e7-a96c-000c2953a1cb:3 执行的查询我没有写出来。

这里也体现了文章开始提到的：这个事物由谁产生，产生多少事物，非常直接的标识了出来。

那么对于文章开头那个诡异的gtid是怎么出来的呢？先说说已经执行的事务：

Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1

这里的2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33好理解，就是已经执行主库的1-33的事务，那么8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1呢?其实也简单，有两种情况：

NO.1 从库有数据写入（即从库插入数据）

**insert into t2 select 1;**
Query OK, 1 row affected (0.03 sec)
Records: 1  Duplicates: 0  Warnings: 0</pre>

show slave status\G;

Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 10
                  Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           **Retrieved_Gtid_Set**: **2a09ee6e-645d-11e7-a96c-000c2953a1cb**:**1-3**
            **Executed_Gtid_Set**: **2a09ee6e-645d-11e7-a96c-000c2953a1cb**:**1-3**,
**8ce853fc-6f8a-11e7-8940-000c29e3f5ab**:**1**
                Auto_Position: 1
         Replicate_Rewrite_DB:

可以看到已经执行的事务有来自主库的2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,也有从库自己写入的数据：8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1。我们可以解析binlog看看

mysqlbinlog -vv mysql-bin.000001 --include-gtids='8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1'

# at 896
#170823  0:59:19 **server id 20 ** end_log_pos 961 CRC32 0x0492528a         GTID    last_committed=3        **sequence_number=4**
SET @@SESSION.GTID_NEXT= '**8ce853fc-6f8a-11e7-8940-000c29e3f5ab**:**1**'/*!*/;
# at 961
#170823  0:59:19 server id 20  end_log_pos 1032 CRC32 0xbf545cca        Query   thread_id=25    exec_time=0     error_code=0
SET TIMESTAMP=1503421159/*!*/;
SET @@session.pseudo_thread_id=25/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 1032
#170823  0:59:19 server id 20  end_log_pos 1079 CRC32 0x2f2de3ec        Rows_query
# insert into t2 select 1
# at 1079
#170823  0:59:19 server id 20  end_log_pos 1123 CRC32 0x18fe1c5c        Table_map: `db1`.`t2` mapped to number 109
# at 1123
#170823  0:59:19 server id 20  end_log_pos 1163 CRC32 0x163a708e        Write_rows: table id 109 flags: STMT_END_F

BINLOG '
52KcWR0UAAAALwAAADcEAACAABdpbnNlcnQgaW50byB0MiBzZWxlY3QgMezjLS8=
52KcWRMUAAAALAAAAGMEAAAAAG0AAAAAAAEAA2RiMQACdDIAAQMAAVwc/hg=
52KcWR4UAAAAKAAAAIsEAAAAAG0AAAAAAAEAAgAB//4BAAAAjnA6Fg==
'/*!*/;
### **INSERT INTO `db1`.`t2`**
### **SET**
###  ** @1=1 /* INT meta=0 nullable=1 is_null=0 */**
# at 1163
#170823  0:59:19 server id 20  end_log_pos 1194 CRC32 0xe3347ac1        Xid = 68
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;

从binlog中可以清楚看到是从库进行了写入。

NO.2 主从切换(这里使用的是MHA切换主从)

>             Master_Server_Id: 20
                  Master_UUID: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           **Retrieved_Gtid_Set**: **8ce853fc-6f8a-11e7-8940-000c29e3f5ab**:**1**
            **Executed_Gtid_Set**: **2a09ee6e-645d-11e7-a96c-000c2953a1cb**:**1-3**,
**8ce853fc-6f8a-11e7-8940-000c29e3f5ab**:**1**
                Auto_Position: 1

可以看到主从切换以后主库的server-id是20。这里的意思是接收到主库8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1,并已经执行了这个事物，这个事物其实就是之前从库写入的那条数据。对于2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3就是之前主库执行的3个事务，如果此时在主库再插入一条数据，那么变化如下：

** Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-2**
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-2

下面说说GTID不连续问题，类似 ****2a09ee6e-645d-11e7-a96c-000c2953a1cb:37-45 ****，这个是由于binlog被清理后导致的，我们可以测试一下，然后查看gtid_purge变量。

binlog不可能永远驻留在服务上，需要定期进行清理(通过expire_logs_days可以控制定期清理间隔)，否则迟早它会把磁盘用尽。gtid_purged用于记录已经被清除了的binlog事务集合，它是gtid_executed的子集。只有gtid_executed为空时才能手动设置该变量，此时会同时更新gtid_executed为和gtid_purged相同的值。gtid_executed为空意味着要么之前没有启动过基于GTID的复制，要么执行过RESET MASTER。执行RESET MASTER时同样也会把gtid_purged置空，即始终保持gtid_purged是gtid_executed的子集。

>[root@localhost][db1]> **show master logs;**
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |      3530 |
+------------------+-----------+
1 row in set (0.00 sec)

[root@localhost][db1]> **flush logs;**
Query OK, 0 rows affected (0.05 sec)

[root@localhost][db1]> **show master logs;**
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |      3577 |
| mysql-bin.000002 |       234 |
+------------------+-----------+
2 rows in set (0.00 sec)

[root@localhost][db1]> **PURGE BINARY LOGS TO 'mysql-bin.000002';**
Query OK, 0 rows affected (0.01 sec)

[root@localhost][db1]> **show master logs;**
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000002 |       234 |
+------------------+-----------+
1 row in set (0.00 sec)

然后只要从库有重新启动，才会读取。MySQL服务器启动时，通过读binlog文件，初始化gtid_executed和gtid_purged,使它们的值能和上次MySQL运行时一致。

gtid_executed 本机被执行并写入日志的gtid
gtid_purged 该变量中记录的是本机上已经执行过，但是已经被purge binary logs to命令清理的gtid_set

没启动前：

Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9
Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9</pre>

重启并插入数据：

>            Master_Server_Id: 20
                  Master_UUID: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           **Retrieved_Gtid_Set**: **8ce853fc-6f8a-11e7-8940-000c29e3f5ab**:**10**
            **Executed_Gtid_Set**: **2a09ee6e-645d-11e7-a96c-000c2953a1cb**:**1-3**,
**8ce853fc-6f8a-11e7-8940-000c29e3f5ab**:**1-10**
                Auto_Position: 1

**show variables like 'gtid_purged';** 
+---------------+------------------------------------------------------------------------------------+
| Variable_name | Value                                                                              |
+---------------+------------------------------------------------------------------------------------+
| gtid_purged   | **2a09ee6e-645d-11e7-a96c-000c2953a1cb**:**1-3**,
**8ce853fc-6f8a-11e7-8940-000c29e3f5ab**:**1-9** |
+---------------+------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

可以看到 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3 与 ****8ce853fc-6f8a-11e7-8940-000c29e3f5ab:**1-9 **都在mysql-bin.000001里，已经被清除了。

下面的两个实验，将会告诉我们如果主日志被清除，但从还没获得这些日志，该怎么处理：

实验一：如果slave所需要事务对应的GTID在master上已经被purge了

根据show global variables like '%gtid%'的命令结果我们可以看到，和GTID相关的变量中有一个gtid_purged。从字面意思以及 官方文档可以知道该变量中记录的是本机上已经执行过，但是已经被purge binary logs to命令清理的gtid_set。
本节中我们就要试验下，如果master上把某些slave还没有fetch到的gtid event purge后会有什么样的结果。

以下指令在master上执行

master [localhost] {msandbox} (test) > show global variables like '%gtid%';+---------------------------------+----------------------------------------+| Variable_name                   | Value                                  |+---------------------------------+----------------------------------------+| binlog_gtid_simple_recovery     | OFF                                    || enforce_gtid_consistency        | ON                                     || gtid_executed                   | 24024e52-bd95-11e4-9c6d-926853670d0b:1 || gtid_mode                       | ON                                     || gtid_owned                      |                                        || gtid_purged                     |                                        || simplified_binlog_gtid_recovery | OFF                                    |+---------------------------------+----------------------------------------+7 rows in set (0.01 sec) master [localhost] {msandbox} (test) > flush logs;create table gtid_test2 (ID int) engine=innodb;Query OK, 0 rows affected (0.04 sec) Query OK, 0 rows affected (0.02 sec) master [localhost] {msandbox} (test) > flush logs;create table gtid_test3 (ID int) engine=innodb;Query OK, 0 rows affected (0.04 sec) Query OK, 0 rows affected (0.04 sec) master [localhost] {msandbox} (test) > show master status;+------------------+----------+--------------+------------------+------------------------------------------+| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |+------------------+----------+--------------+------------------+------------------------------------------+| mysql-bin.000005 |      359 |              |                  | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |+------------------+----------+--------------+------------------+------------------------------------------+1 row in set (0.00 sec) master [localhost] {msandbox} (test) > purge binary logs to 'mysql-bin.000004';Query OK, 0 rows affected (0.03 sec) master [localhost] {msandbox} (test) > show global variables like '%gtid%';+---------------------------------+------------------------------------------+| Variable_name                   | Value                                    |+---------------------------------+------------------------------------------+| binlog_gtid_simple_recovery     | OFF                                      || enforce_gtid_consistency        | ON                                       || gtid_executed                   | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 || gtid_mode                       | ON                                       || gtid_owned                      |                                          || gtid_purged                     | 24024e52-bd95-11e4-9c6d-926853670d0b:1   || simplified_binlog_gtid_recovery | OFF                                      |+---------------------------------+------------------------------------------+7 rows in set (0.00 sec)

在slave2上重新做一次主从，以下命令在slave2上执行

slave2 [localhost] {msandbox} ((none)) > change master to master_host='127.0.0.1',master_port =21288,master_user='rsandbox',master_password='rsandbox',master_auto_position=1;Query OK, 0 rows affected, 2 warnings (0.04 sec) slave2 [localhost] {msandbox} ((none)) > start slave;Query OK, 0 rows affected (0.01 sec)slave2 [localhost] {msandbox} ((none)) > show slave status\G*************************** 1. row ***************************                          ......             Slave_IO_Running: No            Slave_SQL_Running: Yes                          ......                   Last_Errno: 0                   Last_Error:                 Skip_Counter: 0          Exec_Master_Log_Pos: 0              Relay_Log_Space: 151                          ......                Last_IO_Errno: 1236                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'               Last_SQL_Errno: 0               Last_SQL_Error:                          ......                Auto_Position: 11 row in set (0.00 sec)

实验二：忽略purged的部分，强行同步

那么实际生产应用当中，偶尔会遇到这样的情况：某个slave从备份恢复后（或者load data infile）后，DBA可以人为保证该slave数据和master一致；或者即使不一致，这些差异也不会导致今后的主从异常（例如：所有master上只有insert没有update）。这样的前提下，我们又想使slave通过replication从master进行数据复制。此时我们就需要跳过master已经被purge的部分，那么实际该如何操作呢？
我们还是以实验一的情况为例：

先确认master上已经purge的部分。从下面的命令结果可以知道master上已经缺失24024e52-bd95-11e4-9c6d-926853670d0b:1这一条事务的相关日志

master [localhost] {msandbox} (test) > show global variables like '%gtid%';+---------------------------------+------------------------------------------+| Variable_name                   | Value                                    |+---------------------------------+------------------------------------------+| binlog_gtid_simple_recovery     | OFF                                      || enforce_gtid_consistency        | ON                                       || gtid_executed                   | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 || gtid_mode                       | ON                                       || gtid_owned                      |                                          || gtid_purged                     | 24024e52-bd95-11e4-9c6d-926853670d0b:1   || simplified_binlog_gtid_recovery | OFF                                      |+---------------------------------+------------------------------------------+7 rows in set (0.00 sec)

在slave上通过set global gtid_purged='xxxx'的方式，跳过已经purge的部分

slave2 [localhost] {msandbox} ((none)) > stop slave;Query OK, 0 rows affected (0.04 sec) slave2 [localhost] {msandbox} ((none)) > set global gtid_purged = '24024e52-bd95-11e4-9c6d-926853670d0b:1';Query OK, 0 rows affected (0.05 sec) slave2 [localhost] {msandbox} ((none)) > start slave;Query OK, 0 rows affected (0.01 sec) slave2 [localhost] {msandbox} ((none)) > show slave status\G                *************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                          ......              Master_Log_File: mysql-bin.000005          Read_Master_Log_Pos: 359               Relay_Log_File: mysql_sandbox21290-relay-bin.000004                Relay_Log_Pos: 569        Relay_Master_Log_File: mysql-bin.000005             Slave_IO_Running: Yes            Slave_SQL_Running: Yes                          ......          Exec_Master_Log_Pos: 359              Relay_Log_Space: 873                          ......             Master_Server_Id: 1                  Master_UUID: 24024e52-bd95-11e4-9c6d-926853670d0b             Master_Info_File: /data/mysql/rsandbox_mysql-5_6_23/node2/data/master.info                    SQL_Delay: 0          SQL_Remaining_Delay: NULL      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it                          ......           Retrieved_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:2-3            Executed_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:1-3                Auto_Position: 11 row in set (0.00 sec)

可以看到此时slave已经可以正常同步，并补齐了24024e52-bd95-11e4-9c6d-926853670d0b:2-3范围的binlog日志。