关于GTID的一些知识点补充

关于GTID的一些知识点补充 01

GTID知识点补充

3月5号的文章中，对GTID做过一些基础的说明，这里就不在赘述了，今天这篇文章主要是对GTID部分的知识点的一个补充。

1.GTID一般由两部分组成，结构如下：

GTID=source_id:sequence_id

其中，source_id一般使用server_UUID来替代，它一般存在于配置文件中，或者auto.cnf文件中(不懂的话，可以查查auto.cnf里面的内容)。

2.我们可以通过show master status\G来查看当前数据库的gtid情况：

mysql(none) ::>>show master status\G
*************************** 1. row ***************************
             File: mysqlbin.000106
         Position: 
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: eb99e9de-c2cb-11e8-81e4-005056b7dfa4:-6373065
 row in set (0.00 sec)

上述第7行代码中就是我们想要的当前已经执行过的gtid。需要注意的是Executed_Gtid_Set值得是已经执行过的GTID集合，eb99e9de-c2cb-11e8-81e4-005056b7dfa4是source_id,后面的1-6373065是指一共提交了6373065个事务。

3.GTID始终保持在主从实例中，可以通过检查二进制日志来确定事务的来源，此外，一旦在给定的实例中提交了事务，具有相同GTID的事务便会被该服务器忽略。而且在主实例上提交的事务在从实例上仅仅只能应用一次。

4.GTID生命周期

GTID的声明周期主要分为以下几个步骤：

4.1 master产生GTID，并保存到binlog中

4.2 发送binlog到从库中，并且存储在从库的relay log中，slave读取GTID并设置其gtid_next的值为该GTID的值，从而告知slave用这个值开启下一个事务

4.3 slave执行GTID，slave会首先验证是否已经应用过了这个GTID的号，如果没有，则写入GTID，并将事务写入从库自己的二进制日志。

4.4 slave不生成GTID，由于gtid_next在第二步中已经写入了值，所以不为空，下次执行的过程中始终会从gtid_next里面读取GTID的值并写入二进制日志。

5.GTID的维护

mysql库中的表gtid_executed可以用来查看当前使用的gtid集合，如下：

mysql ::>>select * from mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid                          | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| eb99e9de-c2cb-11e8-81e4-005056b7dfa4 |               |       |
+--------------------------------------+----------------+--------------+
 row in set (0.00 sec)

需要注意的是，当gtid_mode=on或者on_permissive的时候，GTID才会保存在这个表中。当我们没有启用二进制日志时，每个事务都会记录到这个表里，如果我们启用了binlog，则不仅会记录事务到这个表中，而且会将事务写入到二进制日志。

还有一点需要注意，这个表是经过压缩的表，这个表本来是一行一行的，类似下面这样：

mysql ::>>select * from mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid                          | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| eb99e9de-c2cb-11e8-81e4-005056b7dfa4 |               |             |
+--------------------------------------+----------------+--------------+
。。。。。。
。。。。。。
| eb99e9de-c2cb-11e8-81e4-005056b7dfa4 |         |       |
+--------------------------------------+----------------+--------------+
 row in set (0.00 sec)

，后台的一个线程对这个表进行了压缩，才变成上面的样子。压缩的进程名称可以通过下面的方法获得：

mysql ::>>select * from performance_schema.threads where name like '%gtid%'\G
*************************** 1. row ***************************
          THREAD_ID: 
               NAME: thread/sql/compress_gtid_table
               TYPE: FOREGROUND
     PROCESSLIST_ID: 
   PROCESSLIST_USER: NULL
   PROCESSLIST_HOST: NULL
     PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Daemon
   PROCESSLIST_TIME: 
  PROCESSLIST_STATE: Suspending
   PROCESSLIST_INFO: NULL
   PARENT_THREAD_ID: 
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: NULL
       THREAD_OS_ID: 
 row in set (0.00 sec)

我们可以设置mysql中的参数executed_gtids_compression_period来控制压缩表之前允许的事务数量，从而控制压缩率。

02

搭建主从过程中的注意事项

这个问题，之前讲过，但是之前只说了3个必要的参数，这里多说几个参数：

server_id

它是设置mysql实例的server_id，主从的值不能一样。

gtid_mode=on

这个参数控制是否开启GTID模式

enforce_gtid_consitency=on

使用GTID模式时，需要开启这个参数，从而保证数据一致

log-bin

这个特是开启binlog的参数

log-slave-updates=1

这个参数决定slave从master接收到更新之后，并执行完成，是否将执行到的binlog记录到slave的binlog中。建议是开启的

binlog_format=ROW

建议使用这个格式的binlog，因为这个模式的binlog最为细致，还有其他两种情况，感兴趣可以了解。

skip-slave-start=1

当slave数据库启动的时候，slave不会自动开启复制。这个参数给我们实验验证某些功能提供了便捷。

这里说明一下，关于GTID搭建主从的过程，不在赘述，之前3月5日的文章里面已经写过了，这里主要讲一讲参数，有兴趣可以用这些参数自己搭建一套来看看。下面说一说搭建主从的时候，我们需要考虑的一些问题：

1.如果master是新搭建的而且上面没有什么数据，那么我们可以通过change master 语句进行搭建。

2.master运行不久，所有的binlog保留完整，也就是说我们没有手工删除binlog文件，也没有使用purge binary logs to语句来删除binlog，针对这种情况，可以使用类似上面的方法来搭建主从。

3.如果master已经具有大量数据，针对这种情况，可能不能使用上面的第二种方法，因为最原始的binlog可能已经被删除了，无法从头开始获取所有的GTID信息，需要从master上获取数据以及该数据的GTID范围，然后通过在slave上设置选项gtid_purged的方式来跳过这些gtid，然后通过change master的方式搭建主从。

具体的搭建步骤为：

3.1 利用备份的方式获取master的数据以及GTID的范围，包含了gtid_purged(如果我们使用innobackupex备份将会将该信息保留在xtrabackup_binlog_info文件中)

3.2 利用备份的数据，先启动一个从库

3.3 启动从库，并且设置gtid_purged的值，跳过这段范围

3.4 启动change master语句，配置主从复制。

后续有时间的话，将会进行相关实验：

1. 利用GTID模式快速改变主从复制关系
2. 在线实现GTID模式和传统复制模式的互相切换
3. 搭建master上具有大量数据，并且缺失部分binlog时的主从GTID搭建过程。 敬请期待！