在MySQL 5.6.9及更高版本中将MySQL复制与全局事务标识符（GTID）一起使用时，有多种技术可用于配置新的从服务器，然后将该服务器用于扩展，并根据需要升级为从服务器以进行故障转移。在本节中，我们讨论此处列出的四种技术：
简单复制
将数据和事务复制到从站
注入空交易
排除具有gtid_purged的交易
全局事务标识符已添加到MySQL复制中，目的是简化复制数据流的常规管理，尤其是简化故障转移活动。每个标识符唯一标识一组二进制日志事件，这些事件共同构成一个事务。GTID在将更改应用于数据库中起着关键作用：服务器自动跳过任何具有标识符的事务，该标识符被服务器识别为之前已处理过的事务。此行为对于自动复制定位和正确的故障转移至关重要。
标识符和包含给定事务的事件集之间的映射在二进制日志中捕获。在向新服务器供应来自其他现有服务器的数据时，这会带来一些挑战。要再现在新服务器上设置的标识符，必须将标识符从旧服务器复制到新服务器，并保留标识符和实际事件之间的关系。这对于还原立即可用的从属服务器是必要的。成为故障转移或切换新主控者的候选人。
简单复制。 这是在新服务器上再现所有标识符和事务的最简单方法。您只需将新服务器变成具有完整执行历史记录的主服务器的从服务器，然后在两台服务器上启用全局事务标识符。有关更多信息，请参见第17.1.3.2节“使用GTID设置复制”。
复制开始后，新服务器将从主服务器复制整个二进制日志，从而获得有关所有GTID的所有信息。
这种方法简单有效，但是需要从属服务器从主控服务器读取二进制日志。新的从服务器要赶上主服务器有时会花费比较长的时间，因此此方法不适用于快速故障转移或从备份还原。本节说明如何通过将二进制日志文件复制到新服务器来避免从主服务器获取所有执行历史记录。
将数据和事务复制到从属服务器。 回放整个事务历史记录可能很耗时，并且在设置新的复制从属设备时是一个主要瓶颈。为了消除此要求，将主机包含的数据集快照，二进制日志和全局事务信息导入到从属。二进制日志将被播放，然后可以开始复制，从而使从属设备在剩余的事务中成为最新的。
此方法有多种变体，区别在于将二进制日志中的数据转储和事务传输到从属的方式，如下所示：
数据集 交易记录
使用mysql客户端导入使用mysqldump创建的转储文件。使用该 --master-data 选项可以包含二进制日志记录信息，并且 --set-gtid-purged （在MySQL 5.6.9和更高版本中可用）包括 AUTO（默认值）或 ON，以包括有关已执行事务的信息。gtid_mode=ON在从站上导入转储时，您应该有 。（错误＃14832472）
停止从站，将主站数据目录的内容复制到从站的数据目录，然后重新启动从站。
如果gtid_mode不是 ON，请在启用GTID模式的情况下重新启动服务器。
使用带有 和 选项的mysqlbinlog导入二进制日志 。 --read-from-remote-server–read-from-remote-master
将主站的二进制日志文件复制到从站。您可以使用mysqlbinlog 从从站进行复制 。可以通过以下两种方式将它们读入从站： --read-from-remote-server --raw
更新从站的 binlog.index文件，使其指向复制的日志文件。然后CHANGE MASTER TO 在mysql客户端中执行一条 语句以指向第一个日志文件，并 START SLAVE读取它们。
使用mysqlbinlog > file （不带 --raw 选项）将二进制日志文件导出到可以由mysql客户端处理的SQL文件 。
另请参见第4.6.8.3节“使用mysqlbinlog备份二进制日志文件”。
这种方法的优点是几乎可以立即使用新服务器。仅需要重播快照或转储文件时提交的那些事务，就需要从现有的主数据库中获取这些事务。这意味着从站的可用性不是即时的，但是从站只需要相对较短的时间即可赶上剩余的少量事务。
预先将二进制日志复制到目标服务器通常比实时从主服务器读取整个事务执行历史记录要快。但是，由于大小或其他考虑因素，在需要时将这些文件移动到目标可能并不总是可行的。本节中讨论的用于配置新从服务器的其余两种方法使用其他方式将有关事务的信息传输到新从服务器。
注入空交易。 主机的全局gtid_executed变量包含在主机上 执行的所有事务的集合。您可以gtid_executed在创建快照的服务器上记下其内容，而不是在创建快照以配置新服务器时复制二进制日志 。在将新服务器添加到复制链之前，只需针对主服务器中包含的每个事务标识符在新服务器上提交一个空事务gtid_executed，如下所示：
SET GTID_NEXT=‘aaa-bbb-ccc-ddd:N’;
BEGIN;
COMMIT;
SET GTID_NEXT=‘AUTOMATIC’;
使用空事务以这种方式恢复了所有事务标识符后，必须刷新并清除从站的二进制日志，如下所示，其中 N是当前二进制日志文件名的非零后缀：
FLUSH LOGS;
PURGE BINARY LOGS TO ‘master-bin.00000N’;
您应执行此操作，以防止此服务器在以后提升为主服务器的情况下，用错误的事务泛洪复制流。（该FLUSH LOGS语句强制创建新的二进制日志文件；PURGE BINARY LOGS清除空的事务，但保留其标识符。）
此方法创建的服务器本质上是快照，但是由于其二进制日志历史记录与复制流的二进制日志历史记录收敛（也就是说，随着它赶上一个或多个主服务器），因此能够及时成为主服务器。该结果实际上与使用剩余配置方法获得的结果相似，我们将在接下来的几段中讨论该结果。
排除具有gtid_purged的交易。 主服务器的全局 gtid_purged变量包含已从主服务器的二进制日志中清除的所有事务的集合。与前面讨论的方法一样（请参阅 注入空事务），您可以gtid_executed在获取快照的服务器上记录其值 （代替将二进制日志复制到新服务器上）。与以前的方法不同，无需提交空事务（或发出 PURGE BINARY LOGS）。相反，您可以gtid_purged根据的值直接在从站上进行设置 gtid_executed 在从中获取备份或快照的服务器上。
注意
在MySQL 5.6.9之前， gtid_purged不可设置。（bug＃14797808）
与使用空事务的方法一样，此方法创建的服务器在功能上是快照，但由于其二进制日志历史记录与复制主数据库或组的二进制日志历史记录收敛，因此能够及时成为主服务器。
