使用GTID进行故障转移和横向扩展
当使用带有全局事务标识符(GTID)的MySQL复制来配置新的从服务器时,可以使用多种技术进行扩展,然后将其升级为故障转移所需的主服务器。本节介绍以下技术:
- 简单复制
- 将数据和事务复制到从站
- 注入空交易
- 排除具有gtid_purged的交易
- 恢复GTID模式从属
全局事务标识符已添加到MySQL复制中,目的是简化复制数据流的常规管理,尤其是简化故障转移活动。每个标识符唯一标识一组二进制日志事件,这些事件共同构成一个事务。GTID在将更改应用于数据库中起着关键作用:服务器自动跳过任何具有标识符的事务,该标识符被服务器识别为之前已处理过的事务。此行为对于自动复制定位和正确的故障转移至关重要。
标识符和包含给定事务的事件集之间的映射在二进制日志中捕获。在向新服务器供应来自其他现有服务器的数据时,这会带来一些挑战。为了再现在新服务器上设置的标识符,必须将标识符从旧服务器复制到新服务器,并保留标识符和实际事件之间的关系。这对于还原一个从属服务器是必要的,该从属服务器可以立即用作候选服务器,以在故障转移或切换时成为新的主服务器。
简单复制。在新服务器上重现所有标识符和事务的最简单方法是使新服务器成为具有完整执行历史记录的主服务器的从属服务器,并在两个服务器上启用全局事务标识符。有关更多信息,请参见“使用GTID设置复制”。
复制开始后,新服务器将从主服务器复制整个二进制日志,从而获得有关所有GTID的所有信息。
这种方法简单有效,但是需要从属服务器从主控服务器读取二进制日志。新的从服务器要赶上主服务器有时会花费比较长的时间,因此此方法不适用于快速故障转移或从备份还原。本节说明如何通过将二进制日志文件复制到新服务器来避免从主服务器获取所有执行历史记录。
将数据和事务复制到从属服务器。当源服务器以前处理大量事务时,执行整个事务历史记录可能很耗时,这可能是设置新的复制从属服务器时的主要瓶颈。为了消除此要求,可以将源服务器包含的数据集快照,二进制日志和全局事务信息导入新的从属服务器。源服务器可以是主服务器,也可以是从服务器,但是在复制数据之前,必须确保源服务器已处理所有必需的事务。
此方法有多种变体,区别在于将二进制日志中的数据转储和事务传输到从属的方式,如下所示:
- 数据集
- 在源服务器上使用mysqldump创建转储文件。设置mysqldump选项
--master-data
(默认值为1)以包括CHANGE MASTER TO
带有二进制日志信息的语句。将--set-gtid-purged
选项设置为AUTO
(默认值)或ON
,以在转储中包含有关已执行事务的信息。然后使用mysql客户端将转储文件导入目标服务器上。 - 或者,使用原始数据文件创建源服务器的数据快照,然后按照“选择数据快照的方法”中的说明将这些文件复制到目标服务器。如果使用
InnoDB
表,则可以使用MySQL Enterprise Backup组件中的mysqlbackup命令生成一致的快照。此命令记录与要在从站上使用的快照相对应的日志名称和偏移量。MySQL Enterprise Backup是商业产品,包含在MySQL Enterprise订阅中。看到有关详细信息,请参见“ MySQL企业备份概述”。 - 或者,停止源服务器和目标服务器,将源数据目录的内容复制到新从属服务器的数据目录,然后重新启动从属服务器。如果使用此方法,则必须为从属服务器配置基于GTID的复制,即使用
gtid_mode=ON
。有关此方法的说明和重要信息,请参见“将从站添加到复制环境”。
- 在源服务器上使用mysqldump创建转储文件。设置mysqldump选项
- 交易记录
如果源服务器在其二进制日志中具有完整的事务历史记录(即GTID集
@@GLOBAL.gtid_purged
为空),则可以使用这些方法。- 使用和选项,使用mysqlbinlog将二进制日志从源服务器导入到新的从属服务器。
--read-from-remote-server
--read-from-remote-master
或者,将源服务器的二进制日志文件复制到从属服务器。您可以使用带有和选项的mysqlbinlog从从站进行复制。可以使用mysqlbinlog(不带选项)将这些文件读入从站,以将二进制日志文件导出为SQL文件,然后将这些文件传递给mysql客户端进行处理。确保使用单个mysql进程而不是多个连接来处理所有二进制日志文件。例如:
--read-from-remote-server
--raw
>
file
--raw
shell>
mysqlbinlog copied-binlog.000001 copied-binlog.000002 | mysql -u root -p有关更多信息,请参见“mysqlbinlog 处理二进制日志文件的实用程序”。
- 使用和选项,使用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 BINARYLOGS TO 'master-bin.00000N';
您应执行此操作,以防止此服务器在以后提升为主服务器的情况下,用错误的事务泛洪复制流。(该FLUSH LOGS
语句强制创建新的二进制日志文件;PURGE BINARY LOGS
清除空的事务,但保留其标识符。)
此方法创建的服务器本质上是快照,但是由于其二进制日志历史记录与复制流的二进制日志历史记录收敛(也就是说,随着它赶上一个或多个主服务器),因此能够及时成为主服务器。该结果实际上与使用剩余配置方法获得的结果相似,我们将在接下来的几段中讨论该结果。
排除具有gtid_purged的交易。主服务器的全局gtid_purged
变量包含已从主服务器的二进制日志中清除的所有事务的集合。与前面讨论的方法一样(请参阅注入空事务),您可以gtid_executed
在获取快照的服务器上记录其值(代替将二进制日志复制到新服务器上)。与以前的方法不同,无需提交空事务(或发出PURGE BINARY LOGS
)。取而代之的是,您可以gtid_purged
根据gtid_executed
从中获取备份或快照的服务器上的值直接在从属服务器上进行设置。
与使用空事务的方法一样,此方法创建的服务器在功能上是快照,但由于其二进制日志历史记录与复制主数据库或组的二进制日志历史记录收敛,因此能够及时成为主服务器。
恢复GTID模式从属。在基于GTID的复制设置中还原遇到错误的从属服务器时,注入空事务可能无法解决问题,因为事件没有GTID。
使用mysqlbinlog查找下一个事务,它可能是事件之后下一个日志文件中的第一个事务。将所有内容复制到该COMMIT
交易的,并确保包含SET @@SESSION.gtid_next
。即使您没有使用基于行的复制,您仍然可以在命令行客户端中运行二进制日志行事件。
停止从属服务器并运行您复制的事务。该mysqlbinlog可以输出设置的分隔符/*!*/;
,所以将其设置回:
mysql>DELIMITER ;
自动从正确的位置重新启动复制:
mysql>SET GTID_NEXT=automatic; mysql>RESET SLAVE ; mysql>START SLAVE ;