19.1.3.5 使用 GTID 进行故障转移和横向扩展
使用 MySQL Replication with Global Transaction Identifiers (GTIDs) 可以实现故障转移和横向扩展的多种技术。下面描述了以下技术:
Global transaction identifiers 在 MySQL Replication 中添加的目的是简化复制数据流和故障转移活动。每个标识符唯一地标识一组二进制日志事件,这些事件组成一个事务。GTIDs 在应用更改时扮演着关键角色:服务器自动跳过已经处理过的标识符,这是自动复制定位和正确故障转移的关键行为。
标识符与事件的映射在二进制日志中捕捉。这个问题在为新服务器复制数据时出现。为了在新服务器上复制标识符,需要将标识符从旧服务器复制到新服务器,并保留标识符与事件之间的关系。这是为了恢复副本,使其可以立即作为故障转移或切换候选。
简单复制 将新服务器变为源服务器的副本,并在两个服务器上启用 Global Transaction Identifiers。详见第19.1.3.4节,“使用 GTIDs 设置复制”,了解更多信息。
一旦复制开始,新服务器将从源服务器复制整个二进制日志,从而获得所有关于所有 GTIDs 的信息。
这个方法简单有效,但需要副本从源服务器读取二进制日志;在某些情况下,这可能需要较长时间,使新副本赶上源服务器,这个方法不适用于快速故障转移或恢复备份。
将数据和事务复制到副本。 执行整个事务历史记录可能会在源服务器已经处理了大量事务的情况下花费很长时间,这可能会在设置新副本时成为主要瓶颈。为了消除这个要求,可以将源服务器的数据集快照、二进制日志和全局事务信息导入到新副本中。快照可以在源服务器或其副本上拍摄,但是必须确保服务器已经处理了所有需要的事务。
有多种方法的变体,区别在于将数据dump和事务从二进制日志转移到副本的方式,以下是其中的一些:
- Data Set
-
-
使用mysqldump在源服务器上创建dump文件。将mysqldump选项
--source-data
设置为1,以包括CHANGE REPLICATION SOURCE TO
语句和二进制日志信息。将--set-gtid-purged
选项设置为AUTO
(默认)或ON
,以包括执行的事务信息在dump文件中。然后使用mysql客户端将dump文件导入到目标服务器上。 -
或者,创建源服务器的数据快照,然后将这些文件复制到目标服务器,按照第19.1.2.5节,“选择数据快照方法”中的说明进行操作。如果您使用
InnoDB
表,可以使用mysqlbackup命令从 MySQL Enterprise Backup 组件中生产一致快照。这命令记录快照对应的日志名称和偏移量,以便在副本上使用。MySQL Enterprise Backup 是一个商业产品,作为 MySQL Enterprise 订阅的一部分。见第32.1节,“MySQL Enterprise Backup Overview”获取详细信息。 -
或者,停止源服务器和目标服务器,复制源服务器的数据目录到新副本的数据目录,然后重新启动副本。如果您使用这个方法,副本必须配置为GTID-基于的复制,即
gtid_mode=ON
。对于这个方法的说明和重要信息,见第19.1.2.8节,“添加副本到复制环境”。
-
- Transaction History
-
如果源服务器具有完整的事务历史记录在其二进制日志中(即
@@GLOBAL.gtid_purged
的GTID集为空),您可以使用这些方法。-
使用mysqlbinlog将源服务器的二进制日志文件复制到新副本中,使用
--read-from-remote-server
和--read-from-remote-source
选项。 -
或者,您可以将源服务器的二进制日志文件复制到副本中。您可以使用mysqlbinlog与
--read-from-remote-server
和--raw
选项将文件复制到副本中,然后使用mysqlbinlog将文件导出到SQL文件,然后将这些文件传递给mysql客户端进行处理。确保所有二进制日志文件使用单个mysql进程处理,而不是多个连接。例如:$> mysqlbinlog copied-binlog.000001 copied-binlog.000002 | mysql -u root -p
-
这个方法的优点是,新的服务器可以在几乎实时可用状态下提供;只有在快照或备份文件被重新播放时提交的事务需要从现有源服务器获取。这意味着副本的可用性不是实时的,但只需要短暂的时间来赶上这些少量的剩余事务。
将二进制日志文件复制到目标服务器之前通常比从源服务器实时读取事务执行历史记录更快。然而,在某些情况下,可能无法将这些文件移动到目标服务器,因为文件大小或其他考虑因素。该部分讨论的最后两个方法用于为新副本提供信息的其他方法使用其他方式将事务信息传输到新副本。
注入空事务. 源服务器的全局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
变量包含了源服务器的二进制日志中已被purge的事务。与之前讨论的方法类似(见注入空事务),可以记录来自快照服务器的gtid_executed
值,而不是复制二进制日志到新服务器。与之前的方法不同,不需要提交空事务(或使用PURGE BINARY LOGS
语句);相反,可以在复制服务器上设置gtid_purged
,基于来自快照服务器的gtid_executed
值。
与使用空事务的方法类似,这方法创建了一个基本上是快照的服务器,但随着时间的推移,它可以变成源服务器,因为它的二进制日志历史与源服务器和其他复制服务器的历史相一致。
恢复 GTID 模式复制服务器. 在 GTID 基于复制设置中遇到错误的复制服务器时,注入空事务可能不能解决问题,因为事件没有 GTID。
使用mysqlbinlog找到下一个事务,该事务可能是下一个日志文件中的第一个事务,复制该事务到COMMIT
,确保包括SET @@SESSION.gtid_next
。即使您不使用行级别复制,也可以在命令行客户端中运行二进制日志行事件。
停止复制服务器,运行您复制的交易。mysqlbinlog输出将delimiter设置为/*!*/;
,因此将其设置回默认值,如下所示:
mysql> DELIMITER ;
自动从正确位置重新启动复制:
mysql> SET gtid_next=AUTOMATIC;
mysql> RESET REPLICA;
mysql> START REPLICA;