重要的变化:弃用数据节点的选择——connect-delay被移除。这个选项是同义词——connect-retry-delay在所有情况下,这是不尊敬;这个问题已经被修复,现在可以正确地工作。此外,短形式- r这个选项已经被弃用,你应该期望它在将来的版本中被删除。(错误# 31565810)

引用:参见:错误# 33362935。

NDB集群api:它不再是可能的使用DIVERIFYREQ异步信号。(错误# 33161562)

的时机等待扫描日志输出在线重组期间没有被正确的执行。作为此修复的一部分,我们改变时间来生成一个消息每10秒而不是无限扩展,以提供定期更新。(错误# 35523977)

添加缺失的值检查ndbd和ndbmtd。(错误# 33661024)

在线表重组的碎片的数量增加一个表,以及它们之间移动行。这是完成以下步骤:

由于计算错误,它是可能的重组挂在步骤6;扫描引用计数不递减,因此从来没有达到零。(错误# 33523991)

同样的推动加入NDB表返回不正确的结果的时候batched_key_access优化器开关启用。

出现这个问题如下:当批键访问(BKA)算法用于连接两个表,一组批处理键首先是收集从一个表;构造一个多波段的阅读(MRR)操作与另一个。一组MRR指定范围(范围),使用批处理关键构造每个绑定。

当结果返回行需要确定哪些范围返回的每一行的来源。这是用来识别外部表行执行BKA加入。MRR操作时的问题是一个根连接操作,SPJ无法检索这个标识符(RANGE_NO)。我们解决这个问题通过实现失踪SPJ等返回一个API功能RANGE_NO从一个连接查询。(错误# 33416308)

MySQL优化器使用两种不同的方法,处理程序::read_cost ()和Cost_model: page_read_cost ()为不同的访问方法,估计成本,但成本值返回的这些并不总是具有可比性;在某些情况下,这导致了错误的索引被选中,再影响查询的执行时间。为了解决这个问题,NDB,我们覆盖优化器的page_read_cost ()与一个特定的方法NDBCLUSTER。也是在这个问题上工作时发现的NDB处理程序并没有实现read_time ()所使用的方法,read_cost ();现在这个方法的实现ha_ndbcluster,从而优化器现在可以正确地考虑的成本差异NDB当使用一个唯一键而不是有序指数(范围扫描)。(错误# 33317872)

在某些情况下,一个事件的类别没有正确地检测到。(错误# 33304814)

DBDICT并不总是正确执行表名检查。(错误# 33161548)

添加了一个失踪的ID和其他值检查的数量ndbd和ndbmtd。(错误# 33161486,错误# 33162047)

SET_LOGLEVELORD信号并不总是正确处理。(错误# 33161246)

转储11001并不总是正确地处理所有的参数。(错误# 33157513)

文件名并不总是正确地验证。(错误# 33157475)

添加了一个失踪的ID和其他值检查的数量ndbd和ndbmtd。(# 32893708,# 32983700,Bug错误# 32957478,错误# 32983256,错误# 32983339,错误# 32983489,错误# 32983517,错误# 33157527,错误# 33157531,错误# 33161271,错误# 33161298,错误# 33161314,错误# 33161331,错误# 33161372,错误# 33161462,错误# 33161511,错误# 33161519,错误# 33161537,错误# 33161570,错误# 33162059,错误# 33162065,错误# 33162074,错误# 33162082,错误# 33162092,错误# 33162098,错误# 33304819)

管理服务器并不总是正确处理事件错误的大小。(错误# 32957547)

在某些情况下,问题的重做日志恢复备份导致数据节点的计划外停机。为了解决这个问题,重做日志文件时不能用于写道,我们现在包括正确的等待代码和日志的一部分CONTINUEB信号在发送之前。(错误# 32733659)

引用:参见:错误# 31585833。

查询所使用的MySQL NDB集群中的企业监视器来监视内存使用成为明显的数量更少的性能NDB表增加。我们解决这个问题如下:

这些改进后,查询ndbinfo表应该明显更快。(错误# 28658625)

NDB不关闭任何悬而未决的交易模式时返回一个错误从内部系统表创建和删除功能。