在 MySQL 5.6.9 及更高版本中使用带有全局事务标识符 (GTID) 的 MySQL 复制时，有许多技术可以供应新的副本，该副本随后可用于横向扩展，根据故障转移的需要提升为源。在本节中，我们将讨论此处列出的四种技术：

全局事务标识符被添加到 MySQL 复制中，目的是简化复制数据流的一般管理，特别是故障转移活动。每个标识符唯一标识一组二进制日志事件，这些事件一起构成一个事务。GTID 在将更改应用到数据库中起着关键作用：服务器会自动跳过任何具有服务器识别为它之前处理过的标识符的事务。此行为对于自动复制定位和正确的故障转移至关重要。

标识符和包含给定事务的事件集之间的映射被捕获在二进制日志中。当使用来自另一台现有服务器的数据配置新服务器时，这会带来一些挑战。要在新服务器上重现标识符集，需要将标识符从旧服务器复制到新服务器，并保留标识符与实际事件之间的关系这对于恢复立即可用的副本是必要的在故障转移或切换时成为新源的候选者。

简单复制。  这是在新服务器上复制所有标识符和交易的最简单方法；您只需将新服务器变成具有完整执行历史的源的副本，并在两台服务器上启用全局事务标识符。有关详细信息，请参阅第 17.1.3.2 节，“使用 GTID 设置复制”。

复制开始后，新服务器从源复制整个二进制日志，从而获得有关所有 GTID 的所有信息。

这种方法简单有效，但需要从源读取二进制日志；新副本有时需要相对较长的时间才能赶上源，因此这种方法不适合快速故障转移或从备份恢复。本节介绍如何通过将二进制日志文件复制到新服务器来避免从源获取所有执行历史记录。

将数据和事务复制到副本。  回放整个交易历史可能非常耗时，并且是设置新副本时的主要瓶颈。为了消除这一要求，将数据集的快照、二进制日志和源包含的全局事务信息导入副本。二进制日志被回放，之后可以开始复制，允许副本与任何剩余的事务一起成为当前的。

这种方法有多种变体，不同之处在于二进制日志中的数据转储和事务传输到副本的方式，如下所述：

另见第 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 'source-bin.00000N';

您应该这样做是为了防止此服务器在稍后提升为源时用错误事务淹没复制流。（该FLUSH LOGS语句强制创建一个新的二进制日志文件；PURGE BINARY LOGS清除空事务，但保留它们的标识符。）

此方法创建的服务器本质上是一个快照，但随着它的二进制日志历史与复制流的历史收敛（即，当它赶上一个或多个源）时，它能够及时成为一个源。这个结果在效果上与使用剩余供应方法获得的结果类似，我们将在接下来的几段中讨论。

排除与 gtid_purged 的​​交易。  源的全局 gtid_purged变量包含已从源的二进制日志中清除的所有事务的集合。与前面讨论的方法一样（请参阅 注入空事务），您可以 gtid_executed在拍摄快照的服务器上记录值（代替将二进制日志复制到新服务器）。与以前的方法不同，不需要提交空交易（或发出 PURGE BINARY LOGS）；相反，您可以gtid_purged根据的值直接在副本上设置 gtid_executed在从中获取备份或快照的服务器上。

与使用空事务的方法一样，此方法创建的服务器在功能上是快照，但随着其二进制日志历史与复制源服务器或组的二进制日志历史收敛，及时能够成为源。