使用NDB群集复制实现故障转移
如果主群集复制过程失败,则可以切换到辅助复制通道。以下过程描述了完成此操作所需的步骤。
获取最近的全局检查点(GCP)的时间。也就是说,您需要根据
ndb_apply_status
从集群上的表确定最近的纪元,可以使用以下查询找到该纪元:mysqlS'>
SELECT @latest:=MAX(epoch) ->FROM mysql.ndb_apply_status;在循环复制拓扑中,在每个主机上都有一个主服务器和一个从属服务器运行时,在使用时
ndb_log_apply_status=1
,会将NDB群集纪元写入从属二进制日志中。这意味着该ndb_apply_status
表包含该主机上的从机以及充当此主机上运行的主机的从机的任何其他主机的信息。在这种情况下,您需要确定此从属服务器上的最新纪元,以排除该从属服务器二进制日志中任何其他从属服务器中未在用于设置该从属服务器
IGNORE_SERVER_IDS
的CHANGE MASTER TO
语句选项中列出的任何纪元。排除此类时间段的原因是,mysql.ndb_apply_status
表中其服务器IDIGNORE_SERVER_IDS
与用于准备该从属主机的CHANGE MASTER TO语句一起使用的列表中的行匹配的表中的行,除具有从属主机的那些服务器外,还被视为来自本地服务器。自己的服务器ID。您可以Replicate_Ignore_Server_Ids
从以下列表的输出中检索此列表SHOW SLAVE STATUS
。我们假定您已获得此列表,并ignore_server_ids
在此处显示的查询中替换了该列表,该查询与先前版本的查询一样,将最大时期选择为一个名为的变量@latest
:mysqlS'>
SELECT @latest:=MAX(epoch) ->FROM mysql.ndb_apply_status ->WHERE server_id NOTIN (ignore_server_ids);在某些情况下,使用要包含的服务器ID列表并在先前查询的条件下可能更简单或更有效(或两者兼有)。
server_id IN server_id_list
WHERE
使用从步骤1中显示的查询获得的信息,从
ndb_binlog_index
主集群上的表中获取相应的记录。您可以使用以下查询从主
ndb_binlog_index
表中获取所需的记录:mysqlM'>
SELECT -> @file:=SUBSTRING_INDEX(next_file, '/', -1), -> @pos:=next_position ->FROM mysql.ndb_binlog_index ->WHERE epoch >= @latest ->ORDER BY epochASC LIMIT 1;这些是自主复制通道故障以来保存在主数据库上的记录。我们在
@latest
这里采用了一个用户变量来表示在步骤1中获得的值。当然,一个mysqld实例不可能直接访问在另一个服务器实例上设置的用户变量。这些值必须手动或在应用程序代码中“插入”到第二个查询中。重要
在执行之前,必须确保启动了从属mysqld。否则,复制可能会因重复的DDL错误而停止。
--slave-skip-errors=ddl_exist_errors
START SLAVE
现在可以通过在辅助从服务器上运行以下查询来同步辅助通道:
mysqlS'>
CHANGE MASTER TO ->MASTER_LOG_FILE ='@file', ->MASTER_LOG_POS =@pos;再次,我们已经采用用户变量(在这种情况下
@file
和@pos
)来表示在步骤2中得到,并在步骤3中应用的值;实际上,必须手动插入这些值,或者使用可以访问所涉及的两个服务器的应用程序代码插入这些值。注意
@file
是一个字符串值,例如'/var/log/mysql/replication-master-bin.00001'
,因此在SQL或应用程序代码中使用时必须用引号引起来。然而,该值表示通过@pos
绝不能被引用。尽管MySQL通常会尝试将字符串转换为数字,但是这种情况是一个例外。现在,您可以通过在辅助从属mysqld上发出适当的命令来在辅助通道上启动复制:
mysqlS'>
START SLAVE ;
辅助复制通道处于活动状态后,您可以调查主复制失败并影响修复。为此所需的确切操作将取决于主通道失败的原因。
警告仅当主复制通道发生故障时,才可以启动辅助复制通道。同时运行多个复制通道可能导致在复制从站上创建不必要的重复记录。
如果故障仅限于单个服务器,则(理论上)应该可以从复制M
到S'
或从复制M'
到S
;但是,这尚未经过测试。