一、GTID的基本知识
GTID的概念：
在源（主）服务器上提交的每个事务，将创建和其相关联的唯一标识符的全局事物标识符。
此标识符不但是唯一的，而且在所有的复制从库中都是唯一的。所有事物和所有GTID之间都有一对一的映射关系。
GTID的基本描述：
GTID表示为一对坐标，用冒号（:)分隔，如下所示：
GTID = source_id:transaction_id。
source_id标识源服务器。通常，服务器的server_uuid用于此目的。
transaction_id是一个序列号，由该服务器上的事务提交顺序决定;
例如，要提交的第一个事务具有1作为其transaction_id，并且要在同一源务器上提交的第十个事务被分配了10作为transaction_id。
一个事务在一个GTID中不能有0作为序列号。
例如，原来在server_uuid等于3E11FA47-71CA-11E1-9E33-C80AA9429562服务器上提交的第二十三个事务具有这个GTID：
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
这种格式用于表示语句的输出中的GTID，例如SHOW SLAVE STATUS以及二进制日志
可以使用语句来查看UUID
show variables like '%UUID%';
正如在SHOW MASTER STATUS或SHOW SLAVE STATUS等语句的输出中所写的，源自同一服务器的GTID序列可能会被合并为单个表达式，如下所示：
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
上面显示的示例表示源自MySQL服务器的第一个到第五个事务，其server_uuid是3E11FA47-71CA-11E1-9E33-C80AA9429562。
该格式也用于提供START SLAVE选项SQL_BEFORE_GTIDS和SQL_AFTER_GTIDS所需的参数。
GTID集以几种方式在MySQL服务器中使用。例如，由gtid_executed和gtid_purged系统变量存储的值表示为GTID集合。
另外，函数GTID_SUBSET（）和GTID_SUBTRACT（）需要GTID集作为输入。当从库变量返回GTID集合时，UUID按字母顺序排列，数字区间按照升序排列。
GTID总是保存在主从之间。这意味着可以通过检查二进制日志来确定应用于任何从库的任何事务的来源。 另外，一旦给定GTID的事务在给定的服务器上被提交，任何具有相同GTID的后续事务都被该服务器忽略。因此，在主站上提交的事务不能在从站上应用一次，这有助于保证一致性。
当使用GTID时，从库不需要任何非本地数据，例如主库上文件的名称和该文件中的位置。所有用于与主库同步的必要信息都直接从复制数据流中获取。 GTID替换之前所需的文件偏移对，以确定在主库和从库之间启动，停止或恢复数据流的点。因此，在CHANGE MASTER TO语句中不要包含MASTER_LOG_FILE或MASTER_LOG_POS选项，该语句用于引导从库从给定主库复制;相反，开启gtid之后，只需要启用MASTER_AUTO_POSITION选项。有关使用基于GTID的复制配置和启动主库和从、库所需的确切步骤。GTID的生成和生命周期由以下步骤组成：
1）事务在主服务器上执行并提交。
使用主库的UUID和此库上尚未使用的最小非零事务序列号为该事务分配一个GTID; GTID被写入到master的二进制日志中（直接在日志中的事务本身之前）。
2）二进制日志数据传输到从库并存储在从库的中继日志中，从库读取GTID并将其gtid_next系统变量的值设置为此GTID。这告诉备库，下一个事务必须使用这个GTID记录。需要注意的是，slave在会话上下文中设置gtid_next。
3）从库验证这个GTID是否已经被用来在自己的二进制日志中记录事务。 如果这个GTID没有被使用，那么从设备写入GTID，应用事务并将事务写入其二进制日志。
通过首先读取和检查事务的GTID，在处理事务本身之前，从库不仅保证在从库上没有应用具有此GTID的先前事务，而且还确保没有其他会话已经读取了该GTID但尚未提交相关的交易。换句话说，多个客户端不允许同时应用相同的事务。
4）因为gtid_next不为空，所以从库不会为这个事务生成一个GTID，而是把存储在这个变量中的GTID，也就是从它的二进制日志中事务之前立即从主机获得的GTID写入。

mysql.gtid_executed表
从MySQL 5.7.5开始，GTID被存储在mysql数据库中名为gtid_executed的表中。
对于每个GTID或其代表的一组GTID，该表中的一行包含源服务器的UUID以及该组的起始和结束事务ID; 对于仅引用单个GTID的行，这两个值是相同的。
当安装或升级MySQL服务器时，会使用CREATE TABLE语句创建mysql.gtid_executed表（如果它尚不存在）
WARNING：与其他MySQL系统表一样，不要试图自己创建或修改这个表。
mysql.gtid_executed表允许在从库上禁用二进制日志记录时使用GTID，并且在二进制日志丢失时保留GTID历史记录。
只有当gtid_mode为ON或ON_PERMISSIVE时，GTID才存储在mysql.gtid_executed表中。GTID的存储点取决于是否启用二进制日志记录：
1）如果禁用二进制日志记录（log_bin为OFF），或者如果log_slave_updates被禁用，则服务器将属于每个事务的GTID与事务一起存储在表中。
另外，表以用户可配置的速率周期性压缩;这种情况只适用于禁用二进制日志记录或从库更新日志记录的复制从库。
它不适用于复制主库，因为在主库上，必须启用二进制日志记录才能进行复制。
2）如果启用了二进制日志记录（log_bin为ON），则无论何时二进制日志被轮换或服务器关闭，服务器都将写入前一个二进制日志的所有事务的GTID写入mysql.gtid_executed表。
这种情况适用于启用二进制日志记录的复制主节点或复制从节点。
在服务器意外停止的情况下，当前二进制日志中的GTID集不会保存在mysql.gtid_executed表中。在这种情况下，这些GTID将在恢复过程中添加到表中，并添加到gtid_executed系统变量中的一组GTID中。
启用二进制日志记录时，mysql.gtid_executed表不会为所有已执行的事务提供完整的GTID记录。该信息由gtid_executed系统变量的全局值提供。
mysql.gtid_executed表由RESET MASTER归零。

mysql.gtid_executed表压缩
随着时间的推移，mysql.gtid_executed表可能会被许多行填充，这些行涉及到来自同一台服务器的单个GTID，并且其事务ID构成一个序列
如果通过用跨越事务标识符的整个间隔的单个行替换每个这样的行集合来周期性地压缩该表格，则可以节省相当大的空间
启用GTID时，服务器会定期在mysql.gtid_executed表上执行这种类型的压缩。您可以通过设置execution_gtids_compression_period系统变量来控制在表压缩之前允许经过的事务数，从而控制压缩率。
这个变量的默认值是1000; 这意味着，默认情况下，表格的压缩在每1000个事务之后执行。将execution_gtid_compression_period设置为0将阻止完全执行压缩; 但是，如果执行此操作，则应该为gtid_executed表可能需要的磁盘空间大量增加做好准备。
对mysql.gtid_executed表的压缩由名为thread/sql/compress_gtid_table的专用前台线程执行。此线程未在SHOW PROCESSLIST的输出中列出，但可以在线程表中查看该行，如下所示：
SELECT * FROM performance_schema.threads WHERE NAME LIKE '%gtid%'\G
thread/sql/compress_gtid_table线程通常会休眠，直到execution_gtids_compression_period事务被执行，然后唤醒以执行前面所述的对mysql.gtid_executed表的压缩。 然后休眠，直到另一个execution_gtids_compression_period事务发生，然后醒来再次执行压缩，无限期地重复这个循环。 禁用二进制日志记录时将此值设置为0意味着线程始终处于睡眠状态，永远不会唤醒。

普通复制模式切换为gtid模式，在5.6环境只能冷操作，5.7环境可在线操作
二.1、在主从复制中使用GTID（5.6环境冷操作）
最简单的GTID复制拓扑的启动过程中的关键步骤（由一个主库和一个从库组成）如下所示：
1）如果复制已经在运行，则通过将它们设置为只读来同步这两个服务器。
2）停止两台服务器。
3）重新启动两台服务器并启用GTID并配置正确的选项。
4）指示从服务器使用主服务器作为复制数据源并使用自动定位。完成这一步所需的SQL语句在本节后面的例子中描述。
5）采取新的备份。包含没有GTID的交易的二进制日志不能在启用了GTID的服务器上使用，因此在此点之前进行的备份不能用于新配置。
6）启动从服务器，然后在两台服务器上再次禁用只读模式，以便他们可以接受更新。
具体过程：
1，主库设置为read_only，使从库追上主库
2，主从都关闭MySQL服务
3，主从都在my.cnf文件中配置gtid的启动参数
gtid_mode=ON
enforce-gtid-consistency=true
4，从库使用skip-slave-start启动MySQL服务
从库使用MASTER_AUTO_POSITION = 1。配置主从
CHANGE MASTER TO
MASTER_HOST = 'host',
MASTER_PORT = port,
MASTER_USER = 'user',
MASTER_PASSWORD = 'password',
MASTER_AUTO_POSITION = 1;
MASTER_LOG_FILE选项和MASTER_LOG_POS选项都不能与MASTER_AUTO_POSITION设置为1一起使用
5，采取gtid之后，需要做一个新的备份，因为开启gtid之前做的备份不可用了
例如，您可以在执行备份的服务器上执行FLUSH LOGS。 然后，明确地进行备份，或者等待您可能已经设置的任何定期备份例程的下一次迭代。
6，从库开启主从
主库关闭
Using GTIDs for Failover and Scaleout
将全局事务标识符（GTID）用于MySQL复制时，有许多技术用于配置新的从站，然后可用于扩展，并根据故障转移的需要提升为主站。本节介绍以下技术：
简单的复制
将数据和事务复制到从站
注入空的交易
排除与gtid_purged的交易
恢复GTID模式从站
全局事务标识符被添加到MySQL复制中，以便简化对复制数据流和特别是故障转移活动的一般管理。 每个标识符唯一标识一组构成一个事务的二进制日志事件。 GTID在对数据库进行更改时扮演着重要的角色：服务器会自动跳过任何具有服务器识别为之前处理过的标识符的事务。 此行为对于自动复制定位和正确的故障转移至关重要。
在二进制日志中捕获标识符和包含给定事务的事件集合之间的映射。 使用来自其他现有服务器的数据供应新服务器时，这带来了一些挑战。 为了再现在新服务器上设置的标识符，需要将标识符从旧服务器复制到新服务器，并保持标识符与实际事件之间的关系。 这对于恢复作为候选者立即可用的从站成为故障切换或切换的新主站是必要的。
简单的复制。在新服务器上重现所有标识符和事务的最简单方法是将新服务器变为具有全部执行历史记录的主服务器的从服务器，并在两台服务器上启用全局事务标识符。
一旦复制启动，新的服务器将从主服务器复制整个二进制日志，从而获得有关所有GTID的所有信息。
该方法简单有效，但要求从机从主机读取二进制日志; 有时需要较长的时间才能使新的从机跟上主机，所以这种方法不适用于快速故障切换或备份恢复。 本节介绍如何通过将二进制日志文件复制到新服务器来避免从主服务器获取所有执行历史记录。
将数据和事务复制到从站。 当源服务器先前已经处理了大量的事务时，执行整个事务历史可能是耗时的，而这可能是设置新复制从服务器时的主要瓶颈。 为了消除这种需求，可以将源服务器包含的数据集，二进制日志和全局事务信息的快照导入到新的从服务器。 源服务器可以是主服务器，也可以是从服务器，您必须确保源在复制数据之前处理了所有必需的事务。

二.2 在主从复制中使用GTID（5.7环境在线操作）
1.在每台服务器上执行:
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;
2.在每台服务器上执行:
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
3.在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
4.在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
5.在每台服务器上,等到状态变量ONGOING_ANONYMOUS_TRANSACTION_COUNT为零，可以使用下面的语句查询:
SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
在复制从属设备上，理论上可能的是，它显示为零，然后再次为非零。这不是问题，只要一次显示零即可。
6. 等到第5步生成的所有事务复制到所有服务器，您可以在不停止更新的情况下执行此操作：唯一重要的是所有匿名事务都被复制。
7.如果您使用二进制日志来进行复制以外的任何其他操作（例如，即时备份和还原），请等到您不需要具有没有GTID的事务的旧的二进制日志。
例如，在步骤6完成之后，您可以在执行备份的服务器上执行FLUSH LOGS。 然后，明确地进行备份，或者等待您设置的任何定期备份例程的下一次迭代。
理想情况下，等待服务器清除第6步完成时存在的所有二进制日志。 还等待在步骤6之前进行的任何备份过期。
Important--没回头路了
这是第二重要的一点。 理解包含匿名事务的二进制日志，而不使用GTIDs在下一步之后不能使用是非常重要的。 完成此步骤之后，您必须确保没有GTID的事务不存在于拓扑中的任何位置。
8.在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = ON;
9.在每台服务器上, 在my.cnf参数文件中添加gtid-mode=ON
gtid_mode=ON
#log_slave_updates=1
enforce-gtid-consistency=1
10.change master-从库
STOP SLAVE [FOR CHANNEL 'channel'];
CHANGE MASTER TO MASTER_AUTO_POSITION = 1 [FOR CHANNEL 'channel'];
START SLAVE [FOR CHANNEL 'channel'];

二.3 在主从复制中关闭GTID（MySQL 5.7.6或更高版本 环境在线操作）
1.在每个从站上执行以下操作，如果使用多源复制，请为每个通道执行此操作，并包含FOR CHANNEL通道子句
语法：
STOP SLAVE [FOR CHANNEL 'channel'];
CHANGE MASTER TO MASTER_AUTO_POSITION = 0, MASTER_LOG_FILE = file, MASTER_LOG_POS = position [FOR CHANNEL 'channel'];
START SLAVE [FOR CHANNEL 'channel'];
使用MASTER_LOG_FILE和MASTER_LOG_POS开启主从
CHANGE MASTER TO
MASTER_AUTO_POSITION = 0,
MASTER_LOG_FILE = 'mysql-bin.000008',
MASTER_LOG_POS = 677786318;
2.在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
3.在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
4.在每个服务器上，等待变量@@ GLOBAL.GTID_OWNED等于空字符串。 这可以使用以下方法检查：
SELECT @@GLOBAL.GTID_OWNED;
在复制从机上，理论上可能这是空的，然后又是非空的。 这不是一个问题，只要它是空的就足够了。
5.等待任何二进制日志中当前存在的所有事务复制到所有从站。 有关检查所有匿名事务已复制到所有服务器的方法。
6.如果您将二进制日志用于除复制以外的其他任何操作，例如执行时间点备份或还原：请等到您不需要具有GTID事务的旧的二进制日志。
例如，在步骤5完成之后，您可以在要备份的服务器上执行FLUSH LOGS。然后，明确地进行备份，或者等待您设置的任何定期备份例程的下一次迭代。
理想情况下，等待服务器清除第5步完成时存在的所有二进制日志。等待第5步之前的备份过期。
重要
这是这个程序中的一个重点。理解包含GTID事务的日志在下一步之后不能使用是很重要的。在继续之前，您必须确定GTID事务不存在于拓扑中的任何地方。
7.在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = OFF;
8.在每台服务器上, 在my.cnf参数文件中注释掉gtid-mode相关的参数
#gtid_mode=ON
#log_slave_updates=1
#enforce-gtid-consistency=1