NDB群集复制中的已知问题

本节讨论将复制与NDB Cluster 8.0一起使用时的已知问题。

失去主从连接。复制主SQL节点与复制从SQL节点之间或复制主SQL节点与主群集中的数据节点之间可能会发生连接丢失。在后一种情况下，这不仅可能是由于物理连接丢失（例如，网络电缆断开）引起的，而且还可能是由于数据节点事件缓冲区的溢出引起的。如果SQL节点的响应速度太慢，则群集可能会将其丢弃（通过调整MaxBufferedEpochs和TimeBetweenEpochs配置参数在某种程度上可以控制）。如果发生这种情况，完全有可能将新数据插入到主群集中，而不会记录在复制主数据库的二进制日志中。。因此，为了确保高可用性，维护备份复制通道，监视主通道并在必要时故障转移到辅助复制通道以保持从群集与主群集同步非常重要。NDB Cluster并非旨在自行执行此类监视。为此，需要外部应用程序。

在连接或重新连接到主群集时，复制主服务器会发出“间隙”事件。（间隔事件是“事件事件”的一种，它表示发生的事件会影响数据库的内容，但不能轻易地表示为一组更改。事件的示例包括服务器崩溃，数据库重新同步，（一些）软件更新和（某些）硬件更改。）当从属服务器在复制日志中遇到间隔时，它将停止并显示一条错误消息。该消息在以下输出中可用SHOW SLAVE STATUS，并指示SQL线程由于复制流中注册的事件而停止，并且需要手动干预。有关在这种情况下的处理方法的更多信息，请参见“使用NDB群集复制实现故障转移”。

重要
因为NDB群集不是单独设计来监视复制状态或提供故障转移，所以如果从属服务器或群集要求高可用性，则必须设置多个复制行，在主复制行上监视主mysqld，以及准备在必要时故障转移到辅助线路。必须手动完成此操作，或者可能通过第三方应用程序完成。有关实现这种类型的设置的信息，请参见“使用两个复制通道进行NDB集群复制”和“使用NDB集群复制实现故障转移”。
但是，如果要从独立的MySQL服务器复制到NDB群集，通常一个通道就足够了。

循环复制。 NDB群集复制支持循环复制，如下例所示。复制设置涉及三个NDB群集，编号分别为1、2和3，其中群集1充当群集2的复制主机，群集2充当群集3的主机，群集3充当群集1的主机。完成圈子。每个NDB群集都有两个SQL节点，其中SQL节点A和B属于群集1，SQL节点C和D属于群集2，SQL节点E和F属于群集3。

只要满足以下条件，就支持使用这些群集的循环复制：

所有主服务器和从服务器上的SQL节点都相同。
在log_slave_updates启用系统变量的情况下启动所有充当复制主服务器和从服务器的SQL节点。

下图显示了这种类型的循环复制设置：

NDB群集循环复制，所有主服务器为从服务器

在这种情况下，群集1中的SQL节点A复制到群集2中的SQL节点C。SQL节点C复制到群集3中的SQL节点E；SQL节点E复制到SQL节点A。换句话说，复制线（由图中的弯曲箭头指示）直接连接用作复制主服务器和从服务器的所有SQL节点。

还可以设置并非所有主SQL节点也都是从节点的循环复制，如下所示：

NDB群集循环复制，其中并非所有主服务器都是从服务器

在这种情况下，每个群集中的不同SQL节点将用作复制主服务器和从属服务器。但是，不得在log_slave_updates启用了系统变量的情况下启动任何SQL节点。这种类型的NDB群集循环复制方案应该是可行的，其中复制线（再次由图中的弯曲箭头指示）是不连续的，但应注意，它尚未经过全面测试，因此必须仍被认为是实验性的。

注意
的NDB存储引擎使用幂等执行模式，这抑制重复键和以其他方式分解NDB簇的圆形复制其他错误。这等效于将全局slave_exec_mode系统变量设置为IDEMPOTENT，尽管在NDB Cluster复制中这不是必需的，因为NDB Cluster会自动设置此变量，而忽略任何显式设置的尝试。

NDB群集复制和主键。在节点发生故障的NDB情况下，由于在这种情况下可能会插入重复的行，因此在没有主键的表的复制中仍然会发生错误。因此，强烈建议所有NDB要复制的表都具有主键。

NDB群集复制和唯一键。在旧版本的NDB Cluster中，更新NDB表的唯一键列的值的操作在复制时可能导致重复键错误。NDB通过将唯一键检查推迟到所有表行更新执行之后，解决了表之间复制的问题。

目前只有支援以这种方式延缓约束NDB。因此，仍然不支持从中复制NDB到其他存储引擎（例如MyISAM或）时唯一密钥的更新InnoDB。

可以使用NDB表（例如）说明在不进行延迟检查唯一密钥更新的情况下进行复制时遇到的问题，该表t在主服务器上创建并填充（并复制到不支持延迟唯一密钥更新的从服务器），如下所示：

CREATE TABLE t (
    p INT PRIMARY KEY,
    c INT,
    UNIQUE KEY u (c)
)   ENGINE NDB;

INSERT INTO t
    VALUES (1,1), (2,2), (3,3), (4,4), (5,5);

以下UPDATE语句在t主数据库上成功执行，因为受影响的行是按ORDER BY选项确定的顺序处理的，并在整个表上执行：

UPDATE t SET c = c - 1 ORDER BY p;

但是，同一条语句失败，在从属服务器上出现重复的键错误或其他违反约束的情况，因为行更新的顺序一次是针对一个分区进行的，而不是针对整个表。

注意
每个NDB表在创建时都按键隐式分区。有关更多信息，请参见“按键分区”。

不支持GTID。使用全局事务ID的复制与NDB存储引擎不兼容，因此不受支持。启用GTID可能会导致NDB群集复制失败。

不支持多线程从站。 NDB簇不支持多线程的奴隶，并设置相关的系统变量，例如slave_parallel_workers，slave_checkpoint_group和slave_checkpoint_group（或等值的mysqld启动选项）没有任何影响。

这是因为如果从属服务器在同一时期内写入事务，则它们可能无法将一个数据库中发生的事务与另一数据库中发生的事务分开。此外，由于需要更新表（请参见“ NDB群集复制架构和表”），NDB存储引擎处理的每个事务都至少涉及两个数据库（目标数据库和mysql系统数据库）。反过来，这打破了多线程对事务特定于给定数据库的要求。mysql.ndb_apply_status

用--initial重新启动。使用--initial选项重新启动集群会导致GCI和纪元编号的序列从重新开始0。（对于NDB Cluster，通常是这样，不限于涉及Cluster的复制方案。）在这种情况下，应重新启动涉及复制的MySQL服务器。之后，您应该使用RESET MASTER和RESET SLAVE语句分别清除无效表ndb_binlog_index和ndb_apply_status表。

从NDB复制到其他存储引擎。NDB考虑到此处列出的限制，可以使用从属服务器上的其他存储引擎将主服务器上的表复制到表。

不支持多主机和循环复制（主机和从机上的表都必须使用NDB存储引擎才能正常工作）。
使用不对从属表执行二进制日志记录的存储引擎需要进行特殊处理。
对于从表使用非事务性存储引擎也需要特殊处理。
主mysqld必须以--ndb-log-update-as-write=0或开头--ndb-log-update-as-write=OFF。

接下来的几段提供了有关上述每个问题的其他信息。

将NDB复制到其他存储引擎时，不支持多个主服务器。为了从NDB另一个存储引擎复制，两个数据库之间的关系必须是简单的主从关系。这意味着NDB Cluster和其他存储引擎之间不支持循环或主-主复制。

此外，在NDB不同存储引擎之间进行复制时，不能配置多个复制通道。（但是，一个NDB Cluster数据库可以同时复制到多个从属NDB Cluster数据库。）如果主数据库使用NDB表，则仍然可能有多个MySQL Server维护所有更改的二进制日志。但是，要使从站更改主站（故障转移），必须在从站上显式定义新的主从关系。

将NDB复制到不执行二进制日志记录的从属存储引擎。如果尝试从NDB群集复制到使用不处理其自身二进制日志的存储引擎的从属服务器，则复制过程将中止，并显示错误“无法进行二进制日志记录...”由于多个引擎无法自动编写该语句且至少有一个引擎在自我记录（错误 1595）。可以通过以下方式之一解决此问题：

关闭从属服务器上的二进制日志记录。可以通过设置完成sql_log_bin = 0。
更改用于mysql.ndb_apply_status表的存储引擎。使该表使用不处理自己的二进制日志记录的引擎也可以消除冲突。这可以通过ALTER TABLE mysql.ndb_apply_status ENGINE=MyISAM在从站上发布一条语句来完成。当NDB在从属服务器上使用非存储引擎时，这样做是安全的，因为您不必担心保持多个从属SQL节点同步。
过滤对从属服务器上mysql.ndb_apply_status表的更改。这可以通过使用来启动从属SQL节点来完成--replicate-ignore-table=mysql.ndb_apply_status。如果需要复制忽略其他表，则可能希望使用适当的--replicate-wild-ignore-table选项。

重要
你应该不是的禁用复制或二进制日志mysql.ndb_apply_status或更改复制从一个NDB簇到另一个时使用此表的存储引擎。有关详细信息，请参见在NDB群集之间进行复制的复制和二进制日志过滤规则。

从NDB复制到非事务存储引擎。从复制NDB到非事务存储引擎（例如）时MyISAM，在复制INSERT ... ON DUPLICATE KEY UPDATE语句时可能会遇到不必要的重复键错误。您可以通过使用禁止显示这些信息--ndb-log-update-as-write=0，这将强制将更新记录为写入（而不是更新）。

在NDB群集之间进行复制的复制和二进制日志过滤规则。如果你正在使用任何选项--replicate-do-*，--replicate-ignore-*，--binlog-do-db，或--binlog-ignore-db进行过滤数据库或表被复制，必须小心不能带到块复制或二进制日志的mysql.ndb_apply_status，这是需要NDB集群之间的复制正常工作。特别是，您必须牢记以下几点：

使用（并没有其他或期权）意味着只有在数据库表中被复制。在这种情况下，你也应该使用，或以保证填充的奴隶。--replicate-do-db=db_name--replicate-do-*--replicate-ignore-*db_name--replicate-do-db=mysql--binlog-do-db=mysql--replicate-do-table=mysql.ndb_apply_statusmysql.ndb_apply_status
使用（且无其他选项）意味着仅将数据库中的表更改写入二进制日志。在这种情况下，你也应该使用，或以保证填充的奴隶。--binlog-do-db=db_name--binlog-do-dbdb_name--replicate-do-db=mysql--binlog-do-db=mysql--replicate-do-table=mysql.ndb_apply_statusmysql.ndb_apply_status
使用--replicate-ignore-db=mysql表示不mysql复制数据库中的表。在这种情况下，您还应该使用--replicate-do-table=mysql.ndb_apply_status来确保将mysql.ndb_apply_status其复制。
使用--binlog-ignore-db=mysql表示没有将mysql数据库中表的任何更改写入二进制日志。在这种情况下，您还应该使用--replicate-do-table=mysql.ndb_apply_status来确保将mysql.ndb_apply_status其复制。

您还应该记住，每个复制规则都需要满足以下条件：

它本身--replicate-do-*或--replicate-ignore-*选项，并且不能在单个复制筛选选项中表示多个规则。有关这些规则的信息，请参见“复制和二进制日志记录选项和变量”。
它本身--binlog-do-db或--binlog-ignore-db选项，并且不能在单个二进制日志过滤选项中表示多个规则。有关这些规则的信息，请参见“MySQL服务器二进制日志”。

如果要将NDB群集复制到使用除之外的存储引擎的从属服务器NDB，则如本节中其他部分所述，前面提到的注意事项可能不适用。

NDB群集复制和IPv6。当前，NDB API和MGM API不支持IPv6。但是，MySQL服务器（包括那些在NDB群集中充当SQL节点的服务器）可以使用IPv6与其他MySQL服务器联系。这意味着您可以使用IPv6在NDB群集之间进行复制，以连接主SQL节点和从SQL节点，如下图中的虚线箭头所示：

使用IPv6连接的SQL节点之间的复制

但是，在 NDB群集内发起的所有连接（在上图中用实线箭头表示）必须使用IPv4。换句话说，所有NDB Cluster数据节点，管理服务器和管理客户端都必须使用IPv4相互访问。此外，SQL节点必须使用IPv4与群集进行通信。

由于NDB和MGM API当前不支持IPv6，因此使用这些API编写的任何应用程序还必须使用IPv4进行所有连接。

属性提升和降级。 NDB群集复制包括对属性提升和降级的支持。后者的实现区分有损类型转换和非有损类型转换，可以通过设置slave_type_conversions全局服务器系统变量来控制它们在从属设备上的使用。

有关NDB群集中属性提升和降级的更多信息，请参见基于行的复制：属性提升和降级。

NDB与InnoDB或不同MyISAM，不会将对虚拟列的更改写入二进制日志；但是，这对NDB群集复制或NDB其他存储引擎之间的复制没有不利影响。记录对存储的生成列的更改。