关于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语句，配置主从复制。
后续有时间的话，将会进行相关实验：
- 利用GTID模式快速改变主从复制关系
- 在线实现GTID模式和传统复制模式的互相切换
- 搭建master上具有大量数据，并且缺失部分binlog时的主从GTID搭建过程。 敬请期待！