性能:最近对多线程调度程序的改进旨在优化其内部数据结构的缓存行为，这些结构的成员放置在给定线程的本地成员不会溢出到可由另一个线程访问的缓存线上。在需要的地方，会插入额外的填充字节来隔离其他线程拥有(或共享)的缓存线，从而避免当另一个线程写入不完全属于自己的缓存线时整个缓存线失效。这个优化使MT调度器的性能提高了几个百分点。

后来发现，刚才描述的优化依赖于struct的全局实例thr_repository从缓存行对齐的基址开始，以及编译器不重新排列或添加额外的填充到调度器结构;还发现这些先决条件没有得到保证(甚至没有得到检查)。因此，这种缓存线优化以前只在以下情况下有效g_thr_repository(即全局实例)最终被缓存线对齐只是偶然的。此外，在64位平台上，编译器在struct中添加了额外的填充词thr_safe_pool这样，尝试将其填充到缓存线对齐大小失败。

目前的修复方案确保了这一点g_thr_repository在缓存线对齐地址上构造，构造函数被修改以验证设计中假定的缓存线对齐地址。

内部测试的结果显示，在某些情况下，MT Scheduler的读取性能在这些更改之后提高了10%。(错误# 18352514)

NDB集群api:两个新的示例程序，演示的读写字符，VARCHAR,VARBINARY列值已添加到存储/ ndb / ndbapi-examples在MySQL NDB集群源树中。有关这些程序的更多信息，包括源代码清单，请参见NDB API简单数组示例,使用适配器的NDB API简单数组示例．

MySQL NDB ClusterJ:一个新的属性，PROPERTY_CLUSTER_CONNECT_TIMEOUT_MGM，现在可以用来设置网络连接超时。(错误# 19913569)

NDB磁盘数据:在少数情况下，对大型Disk Data表的多行进行更新可能会导致节点故障。属性的值来增加分配给磁盘页缓冲内存的页条目的数量，如果在Disk Data表上的非常大的事务中观察到此类问题DiskPageBufferEntries新增数据节点配置参数。(错误# 19958804)

NDB磁盘数据:在某些情况下，在DICT主服务器接管时，新主服务器可能在尝试前滚正在进行的模式事务时崩溃。(Bug #19875663, Bug #74510)

NDB磁盘数据:当一个节点充当DICT主节点失败，仲裁器选择另一个节点来接替失败的节点。在接管过程中(包括清理主服务器失败时仍然打开的任何模式事务)，将决定对未提交的模式事务的处置。通常情况下，这个事务会回滚，但是如果它完成了提交请求的足够部分，新的主服务器就会完成提交处理。在交易的命运决定之前，没有新的消息TRANS_END_REQ可以处理来自客户端的消息。此外，由于不支持多个并发模式事务，因此必须在启动任何新事务之前完成接管清理。

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

前面描述的场景是在从节点故障恢复时使用伪随机延迟处理的。现在，我们检查在新主节点前滚或后滚前一个主节点失败后剩余的任何模式事务之前，避免启动新的模式事务或使用旧事务执行操作，直到接管处理在放弃事务后清理完毕。(Bug #19874809, Bug #74503)

NDB磁盘数据:当一个节点充当DICTMaster失败时，仍然可以通过将此请求发送给new来请求提交或终止任何打开的模式事务DICT的主人。在这种情况下，新的主服务器接管模式事务，并报告提交或中止请求是否成功。在某些情况下，可能会错误地识别新主服务器——也就是说，请求被发送到错误的节点，该节点响应一个错误，客户机应用程序将该错误解释为一个已终止的模式事务，即使在与正确的节点联系时，事务也可以成功提交的情况下。(Bug #74521, Bug #19880747)

NDB复制:当一个NDB客户端线程使用如下语句请求刷新二进制日志刷新二进制日志或显示binlog事件，这不仅会导致该客户端最近所做的更改被刷新，而且所有其他客户端最近所做的所有更改也会被刷新，尽管这并不需要。这种行为会导致不必要的语句执行等待，这可能会导致复制超时和其他问题。现在，这样的语句只刷新请求线程最近所做的数据库更改。

作为修复的一部分，状态变量Ndb_last_commit_epoch_server，Ndb_last_commit_epoch_session,Ndb_slave_max_replicated_epoch，最初在MySQL NDB集群7.4中实现，现在也可以在MySQL NDB集群7.3中使用。有关这些变量的描述，请参见NDB集群状态变量；有关详细信息，请参见NDB集群复制冲突解决．(错误# 19793475)

NDB复制:可以使用通配符为异常表(即使用后缀命名的表)设置冲突解决美元的前女友)，这是不应该被允许的。现在，当使用通配符表达式定义复制冲突函数时，将检查这些通配符表达式是否存在可能的匹配，以便在函数覆盖异常表的情况下，不为这个表设置它。(错误# 19267720)

NDB集群api:可以删除Ndb_cluster_connection的实例仍然存在时Ndb使用它的引用。现在,Ndb_cluster_connection析构函数等待所有相关的Ndb在完成之前释放的对象。(错误# 19999242)

参考资料:参见Bug #19846392。

NDB集群api:对象分配的缓冲区NdbScanOperation用于接收扫描的行，直到NdbTransaction日志含义关闭所属扫描操作。这可能导致在同一个事务中创建多个扫描的应用程序中过度使用内存，即使这些扫描在其生命周期结束时关闭，除非NdbScanOperation: close ()调用了releaseOp参数等于真正的．现在，只要导航结果集的光标被关闭，缓冲区就会被释放NdbScanOperation: close ()，不管这个参数的值。(Bug #75128, Bug #20166585)

MySQL NDB ClusterJ:日志记录了以下错误严重的水平;它们现在被记录在正常的水平，就像他们应该的那样:

(错误# 20045455)

MySQL NDB ClusterJ:的com.mysql.clusterj.tie类发出的日志消息信息这是不必要的，并且会影响使用ClusterJ的应用程序的性能。(错误# 20017292)

MySQL NDB ClusterJ:当应用程序关闭会话工厂而一些会话仍处于活动状态时，ClusterJ报告了分段违规。这是因为MySQL NDB集群允许一个Ndb_cluster_connection对象将被删除Ndb实例仍然是活动的，这可能导致ClusterJ使用空指针。这个修复通过阻止ClusterJ在会话仍然活跃时关闭会话工厂来阻止这种情况的发生。(错误# 19846392)

参考:参见Bug #19999242。

全局检查点提交和保存协议可能因各种原因而延迟，包括磁盘I/O慢。的DIH主节点监视这两个协议的进程，并可以强制执行最大延迟时间，在此期间，当延迟达到最大值时，通过杀死负责延迟的节点来停止协议。这DIH主GCP监控机制没有在每个主节点执行一次以上的任务;也就是说，在检测到并处理GCP停止后，无法继续监视。(错误# 20128256)

参考资料:参见Bug #19858151, Bug #20069617, Bug #20062754。

运行时mysql_upgrade在一个MySQL NDB集群SQL节点上，预期的performance_schema而是在连接到集群的所有SQL节点上执行。(错误# 20032861)

与触发触发器池相关的一些问题已被修复，包括以下问题:

(错误# 19976428)

使用时在线重组ndbmtd数据节点和二进制日志记录由mysqld方法中有时会导致失败特利克斯而且DBLQH内核块，或在静默数据损坏。(错误# 19903481)

参考:参见Bug #19912988。

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

为了尽量减少这个时间，两个协议中都添加了隔离机制，任何其他活动节点都可以在预定时间后强制断开故障节点。这允许故障节点有机会在可能的情况下优雅地关闭(在记录调试和其他信息之后)，但限制了其他节点等待这种情况发生的时间。现在，一旦剩余的活动节点处理了任何故障节点的断开连接，它们就可以开始故障处理并重新启动相关协议或协议，即使故障节点需要很长时间才能关闭。(错误# 19858151)

参考资料:参见Bug #20128256, Bug #20069617, Bug #20062754。

在释放磁盘页时挂起看门狗失败TUP_COMMITREQ，由于使用了一个未初始化的块变量。(Bug #19815044, Bug #74380)

多个线程崩溃导致打印多组跟踪文件，并可能导致死锁。(错误# 19724313)

当客户端对一个新的主服务器重试一个模式事务时，该事务在前一个主服务器重新启动时失败了，该事务在新主服务器上获得的锁将阻止前一个主服务器继续进行到启动阶段3之后，直到客户端被终止，并且它所持有的资源被清理。(Bug #19712569, Bug #74154)

当使用NDB在存储引擎中，数据库或表名的最大可能长度是63个字符，但这个限制并不总是严格执行。这意味着使用64个字符的语句创建数据库，删除数据库,或重命名表可能会导致执行它的SQL节点失败。现在这样的语句失败了，并出现了相应的错误消息。(错误# 19550973)

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

为了解决这个问题，我们采取了一些措施HA_ERR_NO_CONNECTION在此期间可能发出的错误(错误4009)已更改为集群暂时不可用错误(错误4035)，这应该允许API节点使用新的数据节点比以前更快。作为修复的一部分，一些错误的分类已经被移动到正确的类别，一些不再使用的错误已经被删除。(Bug #19524096, Bug #73758)

当执行非常大的下推连接时，涉及到每个索引定义在几列上的一个或多个索引，在某些情况下可以使用DBSPJ块(见DBSPJ块)在NDB要生成的内核SCAN_FRAGREQ信号太大了。由于内核对此类信号的大小有硬性限制(32K)，这将导致数据节点在不能正确处理时出现故障。这个修复程序通过中断绕过了这个限制SCAN_FRAGREQ对于一个这样的信号来说太大的数据，并且发送SCAN_FRAGREQ作为一个分块或碎片信号。(错误# 19390895)

ndb_index_stat当对包含唯一索引的表使用时，有时会失败。(错误# 18715165)

对包含CHAR(0)列的表的查询失败从NDBCLUSTER中得到错误4547 'RecordSpecification有重叠偏移量'．(错误# 14798022)

在NDB对于内核，它是可能的TransporterFacade对象在发送缓冲区中包含的数据时重置缓冲区，这可能导致竞争条件。(Bug #75041, Bug #20112981)

mysql_upgrade删除并重新创建文件失败ndbinfo数据库及其表。(Bug #74863, Bug #20031425)

由于缺乏内存障碍，MySQL NDB集群程序如ndbmtd没有编译权力平台。(Bug #74782, Bug #20007248)

在某些情况下，当运行到具有后删除触发,删除语句没有匹配任何行，仍然导致触发器执行。(Bug #74751, Bug #19992856)

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

在之前改进传输程序外观实现的过程中，使用了互斥锁来防止并发使用performReceive ()而且update_connections ())方法被无意中删除了。此修复增加了一个看门狗检查并发使用。此外,update_connections ()而且performReceive ()调用现在在轮询传输程序时一起序列化。(Bug #74011, Bug #19661543)

ndb_restore项上的分段转换和主键上的内置转换，在恢复该表时失败文本列。

在分段期间，团表使用目标类型的主键列创建。但是，在将主键值加载到登台blob表之前，没有提供转换函数来转换主键值，这导致登台中的主键值损坏团表格在将数据从staging表移动到目标表时，团对象中找不到主键，因此读取失败团表格

现在所有团检查表以查看其主表的主键是否有转换。该检查是在所有主表都被处理之后进行的，因此已经为主表设置了转换函数和参数。中用于主键的任何转换函数和参数现在都在团表格(Bug #73966, Bug #19642978)

发送到数据节点的损坏消息有时未被检测到，导致将坏信号传递到中止数据节点的块。这种失败再加上断开连接的节点，可能会导致整个集群关闭。

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

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

ndb_restore——打印数据的截断文本而且团列值改为240字节而不是256字节。(Bug #65467, Bug #14571512)

传送器发送缓冲区在发送失败后没有正确更新。(Bug #45043, Bug #20113145)