性能： 最近对多线程调度程序所做的改进旨在优化其内部数据结构的缓存行为，这些结构的成员放置在给定线程的本地成员不会溢出到可以被另一个线程访问的缓存行中. 在需要时，插入额外的填充字节以隔离其他线程拥有（或共享）的缓存行，从而避免在另一个线程写入不完全由其拥有的缓存行时使整个缓存行无效。此优化将 MT Scheduler 性能提高了几个百分点。

从那以后发现，刚刚描述的优化取决于结构的全局实例 thr_repository从缓存行对齐的基地址开始，以及编译器不重新排列或向调度程序结构添加额外的填充；还发现这些先决条件没有得到保证（甚至没有检查）。因此，此缓存行优化以前仅在g_thr_repository（即全局实例）最终意外对齐缓存行时才有效。此外，在 64 位平台上，编译器在结构中添加了额外的填充字，thr_safe_pool因此尝试将其填充到缓存行对齐大小失败。

当前的修复确保它g_thr_repository 是在高速缓存行对齐的地址上构建的，并且构造函数被修改以验证高速缓存行对齐的地址，这些地址是设计假定的。

内部测试的结果显示，在进行这些更改后，MT Scheduler 的读取性能在某些情况下提高了 10%。（漏洞#18352514）

NDB Cluster API： MySQL NDB Cluster 源代码树中CHAR、 VARCHAR和 VARBINARY列值 的读写 storage/ndb/ndbapi-examples有关这些程序的更多信息，包括源代码清单，请参阅 NDB API 简单数组示例和 使用适配器的 NDB API 简单数组示例。

MySQL NDB ClusterJ： 新属性 PROPERTY_CLUSTER_CONNECT_TIMEOUT_MGM现在可用于设置网络连接超时。（漏洞 #19913569）

NDB 磁盘数据： 在极少数情况下，对大型磁盘数据表的多行进行更新可能会导致节点故障。如果在磁盘数据表上观察到非常大的事务时出现此类问题，您现在可以通过提高 DiskPageBufferEntries 此版本中添加的数据节点配置参数的值来增加分配给磁盘页面缓冲区内存的页面条目数。（漏洞#19958804）

NDB 磁盘数据： 在某些情况下，在DICT主节点接管期间，新主节点可能会在尝试前滚正在进行的模式事务时崩溃。（缺陷 #19875663，缺陷 #74510）

NDB Disk Data： 当作DICT为主节点的节点发生故障时，仲裁器选择另一个节点来接管故障节点。在接管过程中，包括清理在主节点发生故障时仍处于打开状态的任何模式事务，决定未提交模式事务的处置。通常这个事务会被回滚，但是如果它已经完成了提交请求的足够部分，新的 master 就完成了对提交的处理。在交易的命运已经决定之前，没有新的 TRANS_END_REQ可以处理来自客户端的消息。此外，由于不支持多个并发模式事务，因此在启动任何新事务之前必须完成接管清理。

类似的限制适用于在开放模式事务范围内执行的任何模式操作。在接管处理期间和执行任何非本地模式操作时都会使用用于协调所有节点间模式操作的计数器。这意味着在模式事务处于接管阶段时启动模式操作会导致此计数器被并发使用覆盖，从而产生不可预测的结果。

刚刚描述的场景之前在从节点故障中恢复时使用伪随机延迟来处理。现在，我们在新主服务器前滚或后滚之前检查前一个主服务器失败后剩余的任何模式事务，并避免启动新模式事务或使用旧事务执行操作，直到接管处理在放弃的事务之后被清除。（缺陷 #19874809，缺陷 #74503）

NDB 磁盘数据： 当充当DICT主节点的节点发生故障时，仍然可以通过向新主节点发送此请求来请求提交或中止任何打开的模式事务 DICT。在这种情况下，新的主节点接管模式事务并报告提交或中止请求是否成功。在某些情况下，新主节点可能被错误识别——也就是说，请求被发送到错误的节点，该节点响应一个错误，该错误被客户端应用程序解释为一个中止的模式事务，即使在如果联系了正确的节点，交易可能已经成功提交。（错误#74521，错误#19880747）

NDB 复制： 当NDB客户端线程使用诸如 FLUSH BINARY LOGSor SHOW BINLOG EVENTS时，这不仅会刷新该客户端所做的最新更改，还会刷新所有其他客户端所做的所有最新更改，如好吧，即使这不是必需的。此行为导致不必要地等待语句执行，这可能导致超时和其他复制问题。现在，此类语句仅刷新请求线程所做的最新数据库更改。

作为此修复的一部分，最初在 MySQL NDB Cluster 7.4 中实现的状态变量 Ndb_last_commit_epoch_server、 Ndb_last_commit_epoch_session和 Ndb_slave_max_replicated_epoch，现在也可在 MySQL NDB Cluster 7.3 中使用。有关这些变量的描述，请参阅NDB Cluster Status Variables；有关更多信息，请参阅 NDB Cluster 复制冲突解决方案。（漏洞#19793475）

NDB 复制： 可以使用通配符为异常表（即使用后缀命名的表 $EX）设置冲突解决方案，这是不允许的。现在，当使用通配符表达式定义复制冲突函数时，将检查它们是否存在可能的匹配项，以便在函数覆盖异常表的情况下，不会为该表设置它。（漏洞 #19267720）

NDB Cluster API： 可以删除一个 Ndb_cluster_connection对象，同时仍然存在 Ndb使用对它的引用的实例。现在Ndb_cluster_connection析构函数在完成之前等待所有相关Ndb对象被释放。（漏洞#19999242）

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

NDB Cluster API：在拥有扫描操作关闭NdbScanOperation之前，由 an 分配的用于接收扫描行 的缓冲区 NdbTransaction这可能会导致在同一事务中创建多个扫描的应用程序中过度使用内存，即使这些扫描在其生命周期结束时关闭，除非 等于NdbScanOperation::close()的参数调用。现在，无论此参数的值如何，只要导航结果集的游标用 关闭，就会释放缓冲区 （错误#75128，错误#20166585）releaseOptrueNdbScanOperation::close()

MySQL NDB ClusterJ： 在该 SEVERE级别记录了以下错误；它们现在记录在该 NORMAL级别，因为它们应该是：

（缺陷号 20045455）

MySQL NDB ClusterJ： 该类日志级别为每个查询com.mysql.clusterj.tie发出一条日志消息INFO（缺陷号 20017292）

MySQL NDB ClusterJ： 当应用程序关闭会话工厂而某些会话仍处于活动状态时，ClusterJ 报告了分段冲突。这是因为 MySQL NDB Cluster 允许 Ndb_cluster_connection在某些Ndb实例仍处于活动状态时删除对象，这可能导致 ClusterJ 使用空指针。此修复通过阻止 ClusterJ 在其任何会话仍处于活动状态时关闭会话工厂来阻止这种情况的发生。（漏洞#19846392）

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

全局检查点提交和保存协议可能会因各种原因而延迟，包括磁盘 I/O 速度慢。主 DIH节点监控这两种协议的进度，并且可以强制执行最大延迟时间，在此期间，当延迟达​​到最大值时，通过杀死负责延迟的节点来停止协议。这个 DIH主 GCP 监控机制在每个主节点上执行的任务不超过一次；也就是说，它在检测并处理 GCP 停止后未能继续监测。（缺陷号 20128256）

参考资料：另请参阅：Bug #19858151、Bug #20069617、Bug #20062754。

在MySQL NDB Cluster SQL 节点上 运行mysql_upgradeperformance_schema时，该节点上预期的数据库删除是在连接到集群的所有 SQL 节点上执行的。（缺陷号 20032861）

许多与触发的触发器池相关的问题已得到修复，包括以下问题：

（漏洞#19976428）

使用ndbmtd数据节点并启用mysqld的二进制日志记录时的在线重组 有时可能会导致 内核块TRIX和DBLQH内核块失败，或静默数据损坏。（漏洞#19903481）

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

本地检查点扫描片段看门狗和全局检查点监视器在参与各自协议时都可以在节点太​​慢时排除该节点。这种排除是通过简单地要求故障节点关闭来实现的，如果延迟（无论出于何种原因）可能会延长其他未受影响节点的 GCP 或 LCP 停顿的持续时间。

为了最小化这个时间，两个协议都添加了隔离机制，任何其他活动节点在预定时间后强制断开故障节点。如果可能，这允许故障节点有机会正常关闭（在记录调试和其他信息之后），但限制其他节点必须等待这种情况发生的时间。现在，一旦剩余的活节点处理了任何故障节点的断开连接，它们就可以开始故障处理并重新启动相关协议或协议，即使故障节点需要很长时间才能关闭。（漏洞 #19858151）

参考资料：另请参阅：Bug #20128256、Bug #20069617、Bug #20062754。

TUP_COMMITREQ由于使用未初始化的块变量， 释放磁盘页面时挂起导致看门狗故障。（缺陷 #19815044，缺陷 #74380）

多个线程崩溃导致打印多组跟踪文件并可能导致死锁。（漏洞 #19724313）

当客户端在新主控上重试一个先前失败的模式事务，而前一个主控正在重启时，这个事务在新主控上获得的锁阻止了前一个主控通过启动阶段 3，直到客户端终止，并清理了它持有的资源。（缺陷 #19712569，缺陷 #74154）

使用NDB存储引擎时，数据库或表名的最大可能长度为 63 个字符，但并不总是严格执行此限制。这意味着使用具有 64 个字符的名称（例如CREATE DATABASE, DROP DATABASE或 ）的语句ALTER TABLE RENAME可能会导致执行该语句的 SQL 节点失败。现在，此类语句会失败并显示相应的错误消息。（漏洞 #19550973）

当一个新的数据节点启动时，API 节点被允许在数据节点准备好之前尝试向数据节点注册自己以执行事务。这迫使 API 节点在重试之前等待额外的心跳间隔。

为了解决这个问题， 在此期间可能发出 的一些HA_ERR_NO_CONNECTION错误（错误 4009）已更改为集群暂时不可用错误（错误 4035），这应该允许 API 节点比以前更快地使用新数据节点。作为此修复的一部分，一些错误分类的错误已移至正确的类别中，一些不再使用的错误已被删除。（缺陷 #19524096，缺陷 #73758）

当执行涉及一个或多个索引的非常大的下推连接时，每个索引都在多个列上定义，在某些情况下，内核中的DBSPJ块（请参阅 DBSPJ 块） NDB可能会生成 SCAN_FRAGREQ过大的信号。由于内核对此类信号大小 (32K) 的硬限制，这会导致数据节点在无法正确处理时发生故障。此修复程序通过分解SCAN_FRAGREQ对于此类信号来说太大的数据，并将其 SCAN_FRAGREQ作为分块或分段信号发送来绕过该限制。（漏洞 #19390895）

当对包含唯一索引的表使用时， ndb_index_stat有时会失败。（漏洞 #18715165）

针对包含 CHAR(0) 列的表的查询失败， 错误 1296 (HY000)：从 NDBCLUSTER 得到错误 4547 'RecordSpecification 具有重叠偏移量'。（漏洞 #14798022）

在NDB内核中， TransporterFacade对象可能会在发送缓冲区中包含的数据时重置缓冲区，这可能会导致竞争条件。（错误#75041，错误#20112981）

mysql_upgrade未能 ndbinfo按预期删除并重新创建数据库及其表。（错误#74863，错误#20031425）

由于缺少内存屏障，MySQL NDB Cluster 程序（如ndbmtd）无法在 POWER平台上编译。（错误#74782，错误#20007248）

在某些情况下，当针对具有AFTER DELETE触发器 的表运行时DELETE，没有匹配行的语句仍然会导致触发器执行。（错误#74751，错误#19992856）

存储引擎设计的一个基本要求NDB 是传输器注册表不会尝试同时从同一组传输器接收数据 ( TransporterRegistry::performReceive()) 和更新连接状态 ( TransporterRegistry::update_connections())，因为更新执行缓冲区的最终清理和重新初始化接收数据时使用。在读取或写入这些缓冲区时更改这些缓冲区的内容可能会导致读取或写入“垃圾”或不一致的信号。

在之前为改进传输器外观的实现所做的工作过程中，无意中删除 了旨在防止在同一传输器上同时使用 performReceive()和 )方法的互斥锁。update_connections()此修复程序为并发使用添加了看门狗检查。此外， 现在在轮询传输器时将update_connections()和 performReceive()调用一起序列化。（错误#74011，错误#19661543）

ndb_restore在还原包含主键内置转换和 TEXT列暂存转换的表时失败。

在暂存期间，将BLOB创建一个表，其中包含目标类型的主键列。但是，在将主键值加载到暂存 blob 表之前，未提供转换函数来转换主键值，这导致暂存 BLOB表中的主键值损坏。将数据从暂存表移动到目标表时，BLOB 读取失败，因为它无法在 BLOB表中找到主键。

现在检查所有BLOB表，查看其主表的主键是否有转换。这个检查是在所有的主表都处理完之后进行的，这样主表的转换函数和参数就已经设置好了。用于主表中主键的任何转换函数和参数现在都在表中复制BLOB。（错误#73966，错误#19642978）

发送到数据节点的损坏消息有时未被发现，导致将错误信号传递到中止数据节点的块。这种故障与断开节点相结合可能反过来导致整个集群关闭。

为了防止这种情况发生，现在在解包通过 TCP 接收到的信号时会进行额外的检查，包括检查字节顺序、压缩标志（不得使用）以及接收缓冲区中下一条消息的长度（如果有的话） ).

每当两个连续的解包消息未能通过刚才描述的检查时，就假定当前消息已损坏。在这种情况下，传输器被标记为具有错误数据，并且在重新连接传输器之前不会再对消息进行解包。此外，一个条目被写入集群日志，其中包含错误以及损坏消息的十六进制转储。（错误#73843，错误#19582925）

ndb_restore --print-data截断 TEXT和 BLOB列值到 240 字节而不是 256 字节。（漏洞 #65467，漏洞 #14571512）

发送失败后，传输器发送缓冲区未正确更新。（错误#45043，错误#20113145）