NDB 复制： 在未用于复制通道的 SQL 节点上， sql_log_bin=0在创建和填充 NDB 表后，表映射事件可能会被写入二进制日志，而没有相应的行事件。当此日志后来被从创建此表的 mysqld 复制的从集群使用时，这会导致问题。

通过添加对维护 any_value全局检查点事件操作的累积位图的支持来修复此问题，该位图表示在给定纪元中为特定表的所有行一致设置的位，并通过添加检查以确定特定表的所有操作（行）是否是全部标记为NOLOGGING，以防止将此表添加到Table_mapbinlog 注入器持有的表中。

作为此修复的一部分，NDB API 添加了一个新 方法，该方法通过检索累积位图来getNextEventOpInEpoch3() 提供有关任何 接收到的信息。（漏洞 #26333981）AnyValueany_value

INFORMATION_SCHEMA.FILES当表包含一个ORDER BY子句时，对该表 的查询 未返回任何结果。（漏洞#26877788）

在重新启动期间DBLQH，从一个或多个重做日志文件加载它管理的每个重做日志部分的重做日志部分元数据。由于每个文件的元数据容量有限，因此必须查阅的文件数量取决于重做日志部分的大小。这些文件按顺序打开、读取和关闭，但一个文件的关闭与下一个文件的打开同时发生。

在文件关闭速度很慢的情况下，每个重做日志部分可能同时打开超过 4 个文件；由于这些文件是使用该 OM_WRITE_BUFFER选项打开的，因此在这种情况下，每个部分分配了 4 个以上的写入缓冲区块。写缓冲池不是无限的；如果所有重做日志部分都处于相似状态，则池已耗尽，导致数据节点关闭。

这个问题通过避免 OM_WRITE_BUFFER在元数据重新加载期间使用来解决，这样每​​个日志文件部分超过 4 个重做日志文件的任何瞬时打开都不会再导致数据节点失败。（错误号 25965370）

在TRUNCATE TABLE一个 NDB表上，它的 AUTO_INCREMENTID 没有在不执行二进制日志记录的 SQL 节点上重置。（漏洞 #14845851）

在某些情况下，从 API 节点并行使用多个对象时，即使请求来自Ndb API 节点，从块引用中提取的块编号与块的编号 DBLQH相同 。SUMA由于这种歧义， DBLQH将来自 API 节点的请求误认为是来自SUMA区块的请求而失败。这是通过在检查块号之前检查节点 ID 来解决的。（缺陷 #88441，缺陷 #27130570）

当重复剔除算法用于评估半连接时，结果有缺失的行。（错误#88117，错误#26984919）

参考资料：另请参阅：Bug #87992、Bug #26926666。

松散扫描中使用的表可以用作推送连接查询中的子项，从而可能导致不正确的结果。（错误#87992，错误#26926666）

当在查询计划中表示物化半连接时，MySQL 优化器插入额外的QEP_TAB和 JOIN_TAB对象来表示对物化子查询结果的访问。连接下推分析器没有为这些正确设置其内部数据结构，而是让它们未初始化。这意味着以后使用任何引用物化半连接的项目对象tableno在访问 64 位位tableno掩码时会访问已初始化的列，可能引用超出其末尾的点，从而导致 SQL 节点意外关闭。（漏洞 #87971，漏洞 #26919289）

当数据节点配置为将线程锁定到 CPU 时，它在启动期间失败并显示Failed to lock tid。

这是上一个问题修复的副作用，它根据可用的 glibc. 仅在响应未被数据节点使用的内部 NDB API 调用（并且只能通过内部 API 调用访问）glibc 时才会遇到要防范的特定问题。Ndb_UnlockCPU()当前修复为数据节点启用 CPU 锁定，并在使用受影响的glibc版本时仅为相关 API 调用禁用它。（漏洞 #87683，漏洞 #26758939）

参考资料：此问题是 Bug #86892、Bug #26378589 的回归。

该NDBFS块的OM_SYNC 标志旨在确保用于给定文件的所有 FSWRITEREQ 信号都是同步的，但被不支持的平台忽略O_SYNC，这意味着该功能在这些平台上无法正常运行。现在同步标志用在那些不支持的平台上O_SYNC。（错误#76975，错误#21049554）