如果主Cluster复制进程失败,可以切换到-secondary复制通道。以下过程描述了实现这一步骤所需的步骤。
-
获取最新的全局检查点(GCP)的时间,即从副本集群的
ndb_apply_status
表中确定最新的时期,可以使用以下查询:mysqlR'> SELECT @latest:=MAX(epoch) -> FROM mysql.ndb_apply_status;
在环形复制拓扑结构中,使用
ndb_log_apply_status=1
,NDB Cluster 时期将被写入副本的二进制日志中。这意味着ndb_apply_status
表包含了该主机上的副本信息,以及该主机上作为副本服务器的其他主机信息。在这种情况下,您需要确定该副本的最新时期,排除该副本二进制日志中来自其他副本的时期,这些时期未在
IGNORE_SERVER_IDS
选项中列出。您可以从CHANGE REPLICATION SOURCE TO
语句的输出中检索该列表,作为Replicate_Ignore_Server_Ids
。mysqlR'> SELECT @latest:=MAX(epoch) -> FROM mysql.ndb_apply_status -> WHERE server_id NOT IN (ignore_server_ids);
在某些情况下,使用包含要包括的服务器ID列表可能更简单或更高效(或两者),并在查询的
WHERE
条件中使用server_id IN
。server_id_list
-
使用步骤1中获取的信息,从源集群的
ndb_binlog_index
表中获取相应的记录。您可以使用以下查询从源集群的
ndb_binlog_index
表中获取所需的记录:mysqlS'> SELECT -> @file:=SUBSTRING_INDEX(next_file, '/', -1), -> @pos:=next_position -> FROM mysql.ndb_binlog_index -> WHERE epoch = @latest;
这些记录是自主复制通道失败以来在源集群上保存的记录。我们在这里使用了用户变量
@latest
,它的值是在步骤1中获取的。当然,一个 mysqld 实例不能直接访问另一个服务器实例上的用户变量。这些值必须手动或通过应用程序“插入”到第二个查询中。Important您必须确保副本 mysqld 使用
--replica-skip-errors=ddl_exist_errors
选项启动,然后执行START REPLICA
。否则,复制可能会因重复的DDL错误而停止。 -
现在,您可以通过在副本服务器上运行以下查询来同步次要通道:
mysqlR'> CHANGE REPLICATION SOURCE TO -> SOURCE_LOG_FILE='@file', -> SOURCE_LOG_POS=@pos;
我们再次使用了用户变量(在这里是
@file
和@pos
),以表示步骤2和步骤3中获取的值;在实践中,这些值必须手动或通过应用程序插入。Note@file
是一个字符串值,例如'/var/log/mysql/replication-source-bin.00001'
,因此在SQL或应用程序代码中必须加引号。但是,@pos
代表的值不能加引号。虽然MySQL通常尝试将字符串转换为数字,但这是一种例外情况。 -
现在,您可以在辅助副本上发出适当的命令来启动辅助通道的复制mysqld:
mysqlR'> START REPLICA;
一旦辅助复制通道激活,您可以调查主通道的故障并进行修复。需要采取的确切操作取决于主通道故障的原因。
只有在主复制通道故障时,才启动辅助复制通道。同时运行多个复制通道可能会导致副本上创建重复记录。
如果故障仅限于单个服务器,那么理论上可以从 S
复制到 R'
,或者从 S'
复制到 R
。