本节讨论在NDB集群中使用复制时的已知问题。

源和副本之间失去连接。源集群SQL节点和复制集群SQL节点之间，或者源SQL节点和源集群的数据节点之间，都可能发生连接丢失。在后一种情况下，这不仅可能是由于物理连接丢失(例如，网线断裂)，而且可能是由于数据节点事件缓冲区溢出;如果SQL节点响应太慢，它可能会被集群删除(这在一定程度上可以通过调整MaxBufferedEpochs而且TimeBetweenEpochs配置参数)。如果发生这种情况，将新数据插入源集群而不被记录在源SQL节点的二进制日志中是完全可能的．因此，为了保证高可用性，维护备份复制区域通道、监视主通道以及在必要时故障转移到从复制区域通道以保持复制集群与源同步是极其重要的。新开发银行集群不是为单独执行此类监控而设计的;为此，需要一个外部应用程序。

源SQL节点发出一个”差距”事件，当连接或重新连接到源集群时。(间隙事件是一种”事故事件,”它表示发生的事件会影响数据库的内容，但不能简单地表示为一组更改。例如服务器故障、数据库重新同步、一些软件更新和一些硬件更改。)当副本在复制日志中遇到间隙时，它将停止并发出错误消息。的输出中有此消息显示奴隶状态，并指示SQL线程由于在复制流中注册的事件而停止，并且需要手动干预。看到第21.6.8节“使用NDB集群复制实现故障转移”，以了解在这种情况下该如何做。

圆形的复制。“NDB Cluster Replication”支持循环复制，如下例所示。复制设置涉及编号为1、2和3的三个NDB集群，其中集群1充当集群2的复制源，集群2充当集群3的源，集群3充当集群1的源，这样就完成了一个循环。每个NDB集群有两个SQL节点，其中SQL节点A和B属于集群1,SQL节点C和D属于集群2,SQL节点E和F属于集群3。

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

这种类型的循环复制设置如下图所示:

在此场景中，集群1中的SQL节点A复制到集群2中的SQL节点C;SQL节点C复制到集群3中的SQL节点E;SQL节点E复制到SQL节点a，换句话说，复制线(由图中曲线箭头表示)直接连接所有用作源和副本的SQL节点。

也应该可以设置循环复制，其中不是所有源SQL节点都是副本，如下所示:

在这种情况下，每个集群中的不同SQL节点被用作源和副本。但是，你必须不启动任何SQL节点log_slave_updates系统变量已启用。对于新开发银行集群来说，这种循环复制方案应该是可能的，其中复制线(再次由图中的曲线箭头表示)是不连续的，但应该注意的是，它还没有经过彻底的测试，因此必须仍被视为实验性的。

NDB集群复制和主键。在节点故障的情况下，复制NDB没有主键的表仍然可能出现，因为在这种情况下可能插入重复的行。出于这个原因，强烈建议所有NDB被复制的表具有显式的主键。

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

以这种方式延迟约束目前仅支持NDB．因此，从复制时更新唯一键NDB到不同的存储引擎，例如InnoDB或MyISAM仍然不支持。

在复制而不延迟检查唯一键更新时遇到的问题可以使用NDB表如t，在源上创建并填充(并传输到不支持延迟唯一键更新的副本)，如下所示:

创建表t (p INT主键，c INT，唯一键u (c))引擎NDB;插入t值(1,1),(2,2),(3),(4,4),(5);

以下更新声明t属性确定的顺序处理受影响的行，因此在源上执行命令选项，在整个表上执行:

SET c = c - 1 ORDER BY p;

如果在副本上出现重复的键错误或其他约束违反，则同一语句将失败，因为行更新的顺序是一次针对一个分区执行的，而不是针对整个表。

不支持gtid。使用全局事务id的复制与NDB存储引擎，不支持。启用gtid可能会导致NDB集群复制失败。

不支持多线程副本。NDB集群不支持多线程副本，并设置相关的系统变量如slave_parallel_workers，slave_checkpoint_group,slave_checkpoint_group(或同等mysqld启动选项)没有影响。

这是因为副本可能无法将一个数据库中发生的事务与另一个数据库中发生的事务分开，如果它们是在同一纪元内写入的。此外，每笔交易都由NDB存储引擎至少涉及两个数据库——目标数据库和mysql系统数据库-由于更新的需求mysql.ndb_apply_status表(参见第21.6.4节，“NDB集群复制模式和表”)．这反过来又打破了事务特定于给定数据库的多线程需求。

用——initial重新启动。方法重新启动集群——初始选项使GCI和历元数的序列重新开始0．(这通常适用于NDB集群，不限于涉及集群的复制场景。)在这种情况下，涉及复制的MySQL服务器应该重新启动。在此之后，您应该使用重置的主人而且重置的奴隶语句清除无效ndb_binlog_index而且ndb_apply_status表,分别。

从NDB复制到其他存储引擎。可以复制一个NDB将源上的表转换为副本上使用不同存储引擎的表，同时考虑下面列出的限制:

接下来的几段将提供关于刚才描述的每个问题的附加信息。

复制NDB到其他存储引擎时，不支持多个源。用于从NDB对于不同的存储引擎，两个数据库之间的关系必须是一对一的。这意味着NDB集群与其他存储引擎之间不支持双向复制或循环复制。

另外，当在两者之间进行复制时，不能配置多个复制区域通道NDB还有一个不同的存储引擎。(NDB集群数据库可以同时复制到多个NDB集群数据库。)如果源使用NDB表，仍然可以让多个MySQL服务器维护所有更改的二进制日志，但对于副本更改源(故障转移)，新的源-副本关系必须显式地定义在副本上。

将NDB表复制到不执行二进制日志记录的存储引擎。如果您试图从NDB集群复制到使用不处理其自身二进制日志的存储引擎的副本，则复制过程会因错误而终止二进制日志不可能…语句不能原子地编写，因为涉及到多个引擎，并且至少有一个引擎是自记录的(错误1595)．解决这个问题的方法有以下几种:

从NDB复制到非事务性存储引擎。当从NDB到非事务性存储引擎，例如MyISAM，在复制时可能会遇到不必要的重复键错误插入……关于重复密钥更新语句。你可以通过使用——ndb-log-update-as-write = 0，它强制将更新记录为写入，而不是更新。

复制和二进制日志过滤规则，NDB集群间复制。如果您正在使用任何选项——replicate-do - *，——replicate-ignore - *，——binlog-do-db,或——binlog-ignore-db要过滤正在复制的数据库或表，必须注意不要阻塞复制或二进制日志记录mysql.ndb_apply_status，这是NDB集群间复制正常运行所必需的。特别是，你必须牢记以下几点:

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

如果要将NDB集群复制到使用其他存储引擎的副本NDB，如本节其他部分所述，前面给出的考虑因素可能不适用。

NDB集群复制和IPv6。虽然NDB API和MGM API(以及数据节点和管理节点)在NDB 7.5和7.6中不支持IPv6，但MySQL服务器(包括在NDB集群中充当SQL节点的服务器)可以使用IPv6与其他MySQL服务器联系。这意味着您可以在NDB集群之间使用IPv6进行复制，以连接源SQL节点和复制SQL节点，如下图中虚线箭头所示:

所有连接发起在NDB集群(上图中用实线箭头表示)必须使用IPv4。换句话说，所有NDB集群数据节点、管理服务器和管理客户端必须通过IPv4相互访问。此外，SQL节点必须使用IPv4与集群通信。

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

属性提升和降级。NDB集群复制包括支持属性提升和降级。的实现可以区分有损类型转换和非有损类型转换，并且可以通过设置slave_type_conversions全局服务器系统变量。

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

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