10bet网址
MySQL 8.0参考手册
相关的文档10bet官方网站 下载本手册
PDF(美国Ltr)- 41.4 mb
PDF (A4)- 41.5 mb
HTML下载(TGZ)- 9.3 mb
HTML下载(Zip)- 9.3 mb
手册(TGZ)- 262.1 kb
手册(Zip)- 372.1 kb
信息(Gzip)- 4.0 mb
信息(邮政编码)- 4.0 mb
本手册节选

17.1.3.5使用gtid进行Failover和Scaleout

在使用MySQL带有全局事务标识符的复制(gtid)来提供一个新的副本时,有许多技术可以用于扩展,并在必要时提升到源代码进行故障转移。本节介绍以下技术:

全局事务标识符被添加到MySQL Replication中,目的是简化复制数据流的一般管理,特别是故障转移活动。每个标识符唯一标识组成事务的一组二进制日志事件。gtid在向数据库应用更改时起着关键作用:服务器自动跳过任何具有标识符的事务,服务器将其识别为它以前处理过的标识符。此行为对于自动复制定位和正确的故障转移非常关键。

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

简单的复制。在新服务器上重新生成所有标识符和事务的最简单方法是使新服务器成为具有整个执行历史的源的副本,并在两个服务器上启用全局事务标识符。看到第17.1.3.4节“使用gtid设置复制”,以查询更多资料。

一旦复制启动,新服务器将从源复制整个二进制日志,从而获得关于所有gtid的所有信息。

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

将数据和事务复制到副本。如果源服务器之前处理了大量事务,那么执行整个事务历史记录可能会很耗时,这可能是设置新副本时的一个主要瓶颈。为了消除这个需求,可以将数据集的快照、二进制日志和源服务器包含的全局事务信息导入到新的副本中。创建快照的服务器可以是源服务器,也可以是它的一个副本,但是在复制数据之前,必须确保服务器已经处理了所有必需的事务。

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

数据集
  1. 使用创建转储文件, mysqldump在源服务器上。设置, mysqldump选项——主数据(默认值为1)来包含一个将复制源更改为|将master更改为语句,其中包含二进制日志信息。设置——set-gtid-purged选项汽车(默认值)或,以便在转储中包含有关已执行事务的信息。然后使用mysql在目标服务器上导入转储文件。

  2. 或者,使用原始数据文件创建源服务器的数据快照,然后按照中的说明将这些文件复制到目标服务器第17.1.2.5节“选择数据快照的方法”.如果你使用InnoDB表,您可以使用mysqlbackup命令从MySQL Enterprise Backup组件生成一致的快照。此命令记录要用于副本的快照对应的日志名称和偏移量。MySQL企业备份是一个商业产品,包含在MySQL企业订阅中。看到第30.2节,“MySQL企业备份概述”详细信息。

  3. 或者,同时停止源服务器和目标服务器,将源数据目录的内容复制到新副本的数据目录中,然后重新启动副本。如果使用此方法,则必须将副本配置为基于gtid的复制,换句话说就是gtid_mode =对.有关此方法的说明和重要信息,请参见第17.1.2.8节“向复制环境中添加副本”

交易历史记录

如果源服务器的二进制日志(即GTID集合)中有完整的事务历史@@GLOBAL.gtid_purged为空),您可以使用这些方法。

  1. 将二进制日志从源服务器导入到新副本mysqlbinlog,与——read-from-remote-server——read-from-remote-source,——read-from-remote-master选项。

  2. 或者,将源服务器的二进制日志文件复制到副本。您可以使用mysqlbinlog——read-from-remote-server——生选项。可以使用mysqlbinlog>文件(没有——生选项)将二进制日志文件导出到SQL文件,然后将这些文件传递到mysql客户端进行处理。确保所有二进制日志文件都使用单一的mysql进程,而不是多个连接。例如:

    Shell > mysqlbinlog copy -binlog。000001 copied-binlog。000002 | mysql -u root -p

    有关更多信息,请参见第4.6.9.3节“使用mysqlbinlog备份二进制日志文件”

这种方法的优点是新服务器几乎立即可用;只有那些在快照或转储文件被重放时提交的事务仍然需要从现有源获取。这意味着副本的可用性不是即时的,而是副本应该只需要相对较短的时间就可以赶上这些剩余的事务。

提前将二进制日志复制到目标服务器通常比实时从源读取整个事务执行历史要快。然而,由于大小或其他考虑,在需要时将这些文件移动到目标可能并不总是可行的。本节中讨论的其余两种提供新副本的方法使用其他方法将有关事务的信息传输到新副本。

注入空事务。消息来源是全球性的gtid_executed变量包含源上执行的所有事务的集合。的内容,而不是在创建快照以提供新服务器时复制二进制日志gtid_executed在从中获取快照的服务器上。在将新服务器添加到复制链之前,只需在新服务器上为源中包含的每个事务标识符提交一个空事务gtid_executed,像这样:

设置GTID_NEXT = ' aaa-bbb-ccc-ddd: N ';开始;提交;设置GTID_NEXT = '自动';

使用空事务以这种方式恢复所有事务标识符之后,必须刷新和清除副本的二进制日志,如下所示,其中N当前二进制日志文件名的非零后缀:

刷新日志;清除二进制日志到'source-bin.00000N”;

您应该这样做,以防止该服务器在以后将复制流提升到源时使用错误事务泛滥复制流。(刷新日志语句强制创建一个新的二进制日志文件;清除二进制日志清除空事务,但保留它们的标识符。)

该方法创建的服务器本质上是一个快照,但随着它的二进制日志历史与复制流的历史收敛(也就是说,当它赶上源时),它最终能够成为一个源。这个结果实际上与使用剩下的准备方法得到的结果相似,我们将在接下来的几段中讨论这个方法。

排除gtid_purged的事务。消息来源是全球性的gtid_purged变量包含从源的二进制日志中清除的所有事务的集合。与前面讨论的方法一样(参见注入空事务),您可以记录的值gtid_executed在从中获取快照的服务器上(代替将二进制日志复制到新服务器)。与前面的方法不同,不需要提交空事务(或发出事务)清除二进制日志);相反,您可以设置gtid_purged直接在副本上,基于的值gtid_executed在从中获取备份或快照的服务器上。

与使用空事务的方法一样,该方法创建的服务器在功能上是一个快照,但随着它的二进制日志历史与源和其他副本的历史收敛,它最终能够成为一个源。

恢复GTID模式副本。当在基于GTID的复制设置中恢复遇到错误的副本时,注入空事务可能无法解决问题,因为事件没有GTID。

使用mysqlbinlog查找下一个事务,它可能是事件之后的下一个日志文件中的第一个事务。复制所有内容到提交对于该事务,确保包含设置@@SESSION.gtid_next.即使不使用基于行的复制,也可以在命令行客户机中运行二进制日志行事件。

停止副本并运行所复制的事务。的mysqlbinlog输出将分隔符设置为/ * ! * /;,所以把它放回去:

mysql> DELIMITER;

自动从正确位置重新启动复制:

SET GTID_NEXT=automatic;mysql> RESET SLAVE;mysql>启动SLAVE;或者从MySQL 8.0.22: MySQL > SET GTID_NEXT=automatic;mysql>:mysql>启动副本;