PDF (Ltr)- 0.8MB.
PDF（A4）- 0.8MB.
HTML下载（TGZ）- 166.6KB.
HTML下载(邮政编码)- 222.9KB.
性能:此版本介绍了扫描表现的许多显着改善;这些列在此处：
行校验和帮助检测硬件问题，但以牺牲性能为代价。
NDB.现在提供了通过设置新的禁用这些的可能性ndb_row_checksum.服务器系统变量为0;这样做意味着行校验和不会用于新的或修改过的表。对于所有类型的查询，这可能会对性能产生重大影响(某些情况下为5%到10%)。默认情况下，这个变量被设置为1，以提供与前面行为的兼容性。当队列不繁忙时，由扫描组成的查询可以在LDM线程中执行较长时间。
以前，在检查推动的条件之前读取了列;现在在读取任何列之前检查推送的条件。
当使用范围扫描作为连接执行的一部分时，推入连接的性能应该会有显著的提高。
包装：预期的NDB标题文件在于
开发RPM包代替libndbclient-devel.。（bug＃84580，bug＃26448330）NDB磁盘数据：在恢复本地检查点时，可以插入数据库中已经存在的行;这是预期的行为，处理方法是先删除现有行，然后插入该行的新副本。在一些涉及磁盘数据的情况下，
NDB.无法删除现有行。（bug＃91627，bug＃28341843）NDB客户端程序:删除了内存泄漏
ndbimportutil :: rangelist.在Asan建立中透露。（bug＃91479，bug＃28264144）当将已删除的行从活动节点复制到刚开始的节点时，其中的一行或多行可能具有等于零的全局检查点索引。如果发生这种情况时，由于撤消日志已满而启动了一个完整的本地检查点，则
lcp_skip.位设置为GCI = 0的行，导致数据节点意外关闭。(错误# 28372628)ndbmtd.有时在退出由于日志线程关闭时出现挂起。（bug＃28027150）
当。。。的时候
SUMA.内核块收到一个sub_stop_req.信号，它执行信号然后回复SUB_STOP_CONF。（在此响应后继回API后，API将打开以发送更多sub_stop_req.发信号。）发送后SUB_STOP_CONF如果没有存在订阅者，Suma会降低订阅，这涉及发送多个订阅者DROP_TRIG_IMPL_REQ消息到DBTUP.。LocalProxy可以并行地处理最多21个请求;不仅仅是在短时间排队中排队。当执行一个DROP_TRIG_IMPL_REQ如果延迟，则可能会导致队列过载，从而导致数据节点使用短时间队列中的错误。通过延迟执行来解决这个问题
sub_stop_req.如果信号DBTUP.已经处理DROP_TRIG_IMPL_REQ信号满负荷，而不是排队DROP_TRIG_IMPL_REQ信号。（bug＃26574003）拥有大量的延迟触发器有时会导致作业缓冲区耗尽。这可能是因为单个触发器可以执行许多操作——例如，外键父触发器可以对多个匹配的子表行执行操作——以及基表上的行操作可以执行多个触发器。在这种情况下，行操作是批量执行的。当多个触发器被延迟执行时——这意味着所有的延迟触发器都在预提交时执行——大量触发器操作的并发执行可能导致数据节点作业缓冲区或发送缓冲区耗尽，从而导致节点失败。
通过限制并发触发操作的数量以及每次交易未完成的触发触发请求的数量来修复此问题。
对于立即触发，并发触发操作的限制可能会增加等待执行的触发器的数量，耗尽触发记录池并导致错误并发触发的触发器太多(增加MaxNoOfFiredTriggers。这可以通过增加来避免
MaxNoOfFiredTriggers，减少用户事务批量大小，或两者。（bug＃22529864）参考:参见:Bug #18229003, Bug #27310330。
ndbout.和ndberr.退出后变得无效mgmd_run（），并在下次调用之前重定向到它们mgmd_run（）在一个过程中导致分割错误ndb_mgmd.服务重新启动。此修复确保ndbout.和ndberr.始终保持有效。（bug＃17732772，bug＃28536919）使用错误921报告正在耗尽撤销日志缓冲区内存事务内存不足…(增加SharedGlobalMemory)。
这个问题通过引入一个新的错误代码923来解决undo缓冲存储器（增加undo_buffer_size）。（bug＃92125，bug＃28537319）
当移动一个
operationRec.从串行到并行队列，dbacc :: startnext（）无法更新OperationRec :: op_acc_lock_mode.需要反映累计的标志op_lock_mode.在并行队列中的所有先前操作中的所有操作。ACC锁定队列中的这种不一致导致扫描锁定收购机制失败，因为它错误地结束了锁定不遵守。当中止作为这种不一致的并行锁定队列成员的操作时，同样的故障导致断言。（bug＃92100，bug＃28530928）数据节点在启动过程中由于到达
SCAN_FRAGREQ恢复阶段的信号。这个信号来自于一个在节点之前开始的扫描，该扫描应该由于故障节点的参与而终止。(Bug #92059, Bug #28518448)DBTUP.发送错误检测到元组腐败当读取操作尝试读取插入在同一事务中的元组的值时。（bug＃92009，bug＃28500861）参考文献：另见：Bug＃28893633。
在执行自引导外键上执行更新时，可能会发生错误约束违规错误。（bug＃91965，bug＃28486390）
参考文献：另见：bug＃90644，bug＃27930382。
一个
NDB.通过尝试查找已经发布的触发器的定义，可以删除内部触发定义。仍然要执行触发器的挂起实例。这导致不可预测的，因此可能导致数据节点故障的不安全行为。问题的根本原因介绍了与确定是否已发布给定触发器的代码中的无效假设;通过确保行为来解决问题NDB.当确定触发器定义已被发布时，它是一致的，并且满足预期。(Bug #91894, Bug #28451957)在某些情况下，包含大量并发插入的工作负载导致使用调试构建时的数据节点故障。（bug＃91764，bug＃28387450，bug＃29055038）
在初始节点期间重新启动磁盘数据表和存在的磁盘数据表
TwopassinitialNoderEstartArtCopy.启用，DBTUP.使用不安全扫描磁盘顺序。在这种情况下，这种扫描将不再采用。（bug＃91724，bug＃28378227）检查旧的LCP文件可以测试表版本，但这并不总是可靠的。现在，不再依赖表版本，检查将任何具有
maxGCI小于它creategci.。（bug＃91637，bug＃28346565）在某些情况下，在同一记录中反复触发级联更新触发器，最终消耗所有可用的并发操作，导致错误233事务协调器中的操作外记录(增加MaxNoOfConcurrentOperations)。如果
MaxNoofConCurrentopoperations.设置为足够高的值以避免这种情况，则数据节点消耗大量CPU，很可能最终导致超时。(Bug #91472, Bug #28262259)插入一行到
NDB.具有自引用外键(除主键外)的表失败ER_NO_REFERENCED_ROW_2。这是由于这一事实NDB.在更新唯一索引之前检查了外键约束，以便约束检查无法使用索引来定位该行。现在，在这种情况下，NDB.等待所有唯一索引值更新后，再检查插入行的外键约束。(Bug #90644, Bug #27930382)参考:参见:Bug #91965, Bug #28486390。
以斜杠开头的连接字符串（
/)字符现在被拒绝ndb_mgmd.。我们感谢Daniëlvan eeden为此修复提供了贡献。（bug＃90582，bug＃27912892）