ndb_restore没有正确恢复超过 341 列的表。这是因为用于保存从 .ctl文件中读取的表元数据的缓冲区大小不足，因此在这种情况下只能从中读取部分表描述符。此问题已通过增加ndb_restore用于文件读取的缓冲区大小来解决。（缺陷号 25182956）

参考资料：另请参阅：Bug #25302901。

ndbinfo.memory_per_fragment 使用大量数据节点运行时 对表的查询 可能会对编号最大的节点产生意外结果。（缺陷号 25176404）

该函数用于生成唯一的表 ID 和表版本，以识别分布在多个 SQL 节点之间的模式操作，依赖于永远不会在两个不同的 mysqld 实例上生成相同数字rand()的假设。rand()后来确定情况并非如此，实际上很可能在所有 SQL 节点上产生相同的随机数。

此修复删除了rand()用于生成唯一表 ID 或版本的用法，而是将序列与协调器的节点 ID 结合使用。这保证了序列计数器回绕之前的唯一性，这对于此目的应该足够了。

当同时或几乎同时重新启动多个 mysqld进程时，或者在多个 SQL 节点上发出相同的or语句时， 可以在日志中观察到这种重复的影响（例如NDB create db: waiting max 119 sec for distribution ）。（漏洞 #24926009）CREATE DATABASEDROP DATABASE

ndb_show_tables实用程序不显示哈希映射或完全复制的触发器的类型信息。（漏洞 #24383742）

触发即时触发器时，长消息缓冲区耗尽可能会导致行 ID 泄漏；这可能会在以后导致持久的RowId already allocated错误（NDB错误 899）。（漏洞 #23723110）

参考资料：另请参阅：Bug #19506859、Bug #13927679。

当更新外键关系中的父NDB表时，更新会按预期级联到子表，但更改不会级联到该子表的子表（即原始父表的孙表）。这可以使用由以下CREATE TABLE语句生成的表来说明：

CREATE TABLE parent(
  id INT PRIMARY KEY AUTO_INCREMENT,
  col1 INT UNIQUE,
  col2 INT
) ENGINE NDB;

CREATE TABLE child(
  ref1 INT UNIQUE,
  FOREIGN KEY fk1(ref1)
    REFERENCES parent(col1) ON UPDATE CASCADE
) ENGINE NDB;

CREATE TABLE grandchild(
  ref2 INT,
  FOREIGN KEY fk2(ref2)
    REFERENCES child(ref1) ON UPDATE CASCADE
) ENGINE NDB;

表child是表的孩子 parent；tablegrandchild 是 table 的子项child，是 的孙项parent。在这种情况下，对列col1的更改parent 级联到ref1表中 child，但它并不总是依次传播到ref2表中 grandchild。（缺陷 #83743，缺陷 #25063506）

当 StopOnError设置为 0 运行的数据节点经历意外关闭时，自动重启执行与前一个相同类型的启动。在数据节点之前已使用该 --initial选项启动的情况下，这意味着执行了初始启动，这在多个数据节点故障的情况下可能会导致数据丢失。每当数据节点关闭导致生成核心转储时，也会发生此问题。现在执行检查以捕获所有此类情况，并改为执行正常重启。

此外，如果发生故障的数据节点在关闭之前无法向天使进程发送启动阶段信息，则关闭始终被视为启动失败，也会导致初始重启。通过添加检查以仅在从客户端接收到有效启动阶段时才执行启动失败处理来解决此问题。（缺陷 #83510，缺陷 #24945638）