MySQL NDB集群7.4.16是基于MySQL Server 5.6的新版本MySQL NDB群集7.4,包括7.4版本中的功能NDB.
存储引擎,以及修复最近发现的bug在以前的NDB集群版本。
获取MySQL NDB Cluster 7.4。MySQL NDB Cluster 7.4的源代码和二进制文件可以从10bet博彩公司 。
关于MySQL NDB Cluster 7.4中更改的概述,请参见NDB Cluster 7.4有什么新功能。
这个版本还包含了之前NDB Cluster版本中所有的bug修复和更改,以及在主线MySQL 5.6到MySQL 5.6.37中添加的所有bug修复和特性更改MySQL 5.6.37更新(2017-07-17,General Availability))。
重要的变化;MySQL NDB ClusterJ:NDB Cluster不再支持OpenJPA的ClusterJPA插件,并且已经从发行版中移除。(错误# 23563810)
NDB复制:添加了
——ndb-log-update-minimal
通过登录的选项mysqld。这个选项导致在前面的图像中只写入主键值,而在后面的图像中只更改列。(错误# 24438868)添加了
--diff-default.
选择ndb_config。此选项使程序仅打印具有与其默认值不同的值的值。(bug#85831,bug#25844166)添加了
——查询所有
选项ndb_config。此选项的作用与——查询
选择除了——查询所有
(简式:-一种
)一次转储所有属性的配置信息。(bug#60095,bug#11766869)
NDB复制:添加一个检查来停止
NDB.
当配置为多线程从属时(例如,如果slave_parallel_workers
设置为非零值)。(错误# 21074209)NDB集群api:的实现方法
ndbdictionary :: ndbtableimpl :: getColumn()
从NDB API中的许多地方使用,其中列由名称引用,已经更有效。此方法使用列数阵列的线性搜索找到正确的列对象,这对于具有许多列的表来说,这可能效率低下,并且被检测为客户应用中的CPU大量使用。(理想情况下,用户应该执行name-to-colument对象映射,然后在方法调用中使用列ID或对象,但实际上并不总是完成。)以前用于名称查找的较低次数哈希索引实现,是恢复有相对多列的表格。(线性搜索继续用于具有较少列的表格,性能差异是忽略的。)(bug#24829435)MySQL NDB ClusterJ:当运行Clusterj的单元测试时,跳过JTIE和NDB JTIE测试。(bug#26088583)
MySQL NDB ClusterJ:NDB JTie测试的编译失败。这是由于null引用的处理方式,该修复程序已经纠正了这一点。(错误# 26080804)
备份
. log
文件包含一个或多个额外片段的日志条目,这是由于过滤出同一节点组中其他节点记录的更改的问题。这导致了更大的. log
文件并因此使用比必要更多的资源;它也可能在还原时造成问题,因为来自不同节点的备份可能在应用日志时会彼此干扰。(bug#25891014)当对重做日志文件进行最后一次写操作时,预计下一个日志文件已经被打开进行写操作,但在慢盘上并不总是这样,这会导致节点故障。在这种情况下
NDB.
在尝试写入之前,等待下一个文件被正确打开。(错误# 25806659)数据节点线程可以绑定到单个CPU或一组CPU,一组CPU在内部由
NDB.
作为一个SparseBitmask
。当试图锁定一组CPU时,由于执行锁的例程使用mt_thr_config.cpp: do_bind ()
方法,它寻找设置在整个理论范围内的位SparseBitmask
(2322, 4294967294)。这是通过使用来固定的SparseBitmask: getBitNo ()
,它可以用来迭代那些位实际上设置,而不是。(错误# 25799506)批量更新是通过读取记录并在一组记录上执行事务来执行的,该事务在读取记录时启动。当事务初始化失败时,事务执行器函数随后没有意识到已经发生了这一点,从而导致SQL节点失败。通过在尝试初始化事务时提供适当的错误处理,可以修复此问题。(错误# 25476474)
参考:参见Bug #20092754。
环境
NoOfFragmentLogParts
这样,每个本地数据管理器有超过4个重做日志部件,这将导致资源耗尽和随后的多个数据节点故障。因为这是一个无效的配置,所以添加了一个检查来检测每个LDM包含超过4个重做日志部分的配置,并将其视为无效拒绝。(错误# 25333414)执行网上文件
ALTER TABLE ...重新组织分区
声明一个NDB.
主键长度大于80字节的表会导致重新启动数据节点,导致重组失败。(错误# 25152165)当外键触发列之间存在不匹配时出现错误240,并且在触发器执行期间提供给它们的值,但没有错误消息指示问题的源。(bug#23141739)
参考文献:另见:Bug#23068914,Bug#85857。
如果LDM块的数量均匀地被TC / SPJ块的数量均匀地默认,则SPJ请求并未在可用的SPJ实例上同样分布。现在,循环分发用于更有效地在所有可用的SPJ实例上分发SPJ请求。
作为这项工作的一部分,已经从类中删除了许多未使用的成员变量
DBTC.
。(错误# 22627519)ALTER TABLE . .MAX_ROWS = 0
现在只能通过使用复制来执行ALTER TABLE
陈述。重置max_rows.
不能再使用执行到0算法=原地
或者在线的
关键字。(错误# 21960004)在系统重新启动期间,当由于未错过发送心跳而失败时,所有其他节点都仅报告另一个节点在没有任何其他信息的情况下失败。现在在这种情况下,错误地区错过了心跳的事实以及错误日志和数据节点日志中未能发送心跳的节点的ID。(bug#21576576)
超过10个数据节点的NDB集群的计划关闭并不总是正常执行。(错误# 20607730)
由于以前的问题,当查询涉及一个
通过...分组
,即加入可推评估器不确定其优化的查询执行计划是否实际上可推动。因此,这种分组的连接总是被认为不可动力。已经确定,在MySQL 5.6中已经完成的工作已经解决了分离问题,因此我们现在删除此限制。(bug#86623,bug#26239591)当从表中删除所有行时,紧跟着
删除表
,有可能是缩小了DBACC
哈希索引在下降之前没有准备好。这种收缩是一个每个片段的操作,它不检查表的状态。当一个表被删除时,DBACC
释放资源时,片段大小和页目录的描述不一致;这可能导致读取过时的页面和未定义的行为。插入很多行,然后丢弃表格也应该由于散列索引的扩展而产生这样的效果。
为了解决这个问题,我们要确保,当一个片段即将被释放时,在这个片段上没有等待的扩展或收缩操作。(Bug #86449, Bug #26138592)
内部函数
Execute_signals()
在mt.cpp
从信号中读取三个section指针,即使没有传递给它。这虽然是不必要的,但基本上是无害的。当读取的信号是作业缓冲区中最后一页上的最后一页,而内存中的下一页没有被映射或以其他方式可访问时,ndbmtd失败,出现错误。为了防止这种情况发生,这个函数现在只读取实际传递给它的节指针。(Bug #86354, Bug #26092639)的ndb_show_tables程序
——不合格
选项设置为0时不能正确工作(false);这应该禁用该选项,从而导致在输出中打印完全限定的表名和索引名。(Bug #86017, Bug #25923164)当AN.
NDB.
创建了具有外键约束的表,首先创建其索引,然后在外键创建期间,这些索引将加载到NDB.
字典缓存。当一个创建表
语句失败,由于与外键相关的问题,已经在缓存中的索引没有失效。这意味着任何后续创建表
如果索引的名称与失败语句中的索引名称相同,则会产生不一致的结果。现在,在这种情况下,在失败中命名的任何索引创建表
立即从缓存中失效。(Bug #85917, Bug #25882950)试图执行
ALTER TABLE……添加外键
当要添加的键具有同一表上现有外键的名称时,会出现错误的错误消息。(Bug #85857, Bug #23068914)节点内部调度程序(在
mt.cpp
)收集有关自身进度和正在执行的任何未完成工作的统计数据。此类统计数据之一是未完成发送字节数send_buffer: m_node_total_send_buffer_size
。该信息稍后可能被发送线程调度程序使用,后者将其作为一个指标来调优自己的发送性能与延迟。为了减少内部发送缓冲区上的锁争用,它们被分成两个
thr_send_buffer.
部分,m_buffer
和m_sending
,每个都由自己的互斥锁保护,它们的组合大小用m_node_total_send_buffer_size.
。对代码的调查显示,没有一致性,互斥锁用于更新
m_node_total_send_buffer_size.
,结果是这个值没有并发保护。为了避免这种情况,m_node_total_send_buffer_size.
替换为两个值,m_buffered_size.
和m_sending_size
,它分别跟踪两个缓冲区的大小。这些计数器在分别保护每个缓冲区的两个不同互斥的保护下进行更新,现在将它们加在一起以获得总大小。建立了并发控制之后,局部计数的更新现在应该是正确的,这样它们的合并值就不会随着时间的推移而累积错误。(Bug #85687, Bug #25800933)
掉下来
trans_ai.
类不处理使用长信号格式的信号DBTC.
内核块。(Bug #85606, Bug #25777337)参考文献:另见:bug#85519,bug#27540805。
为了防止扫描返回更多的行,字节,或两者都比客户端的保留缓冲区,
DBTUP.
内存块的大小TRANSID_AI
中已发送给客户端TUPKEYCONF
发送给请求者的信号DBLQH
块。DBLQH
知道可用于结果集的最大批处理大小,并在超过此大小时终止扫描批处理。的
dbspj.
块的FLUSH_AI
属性允许DBTUP.
制作两者TRANSID_AI
来自同一行的结果,一个用于客户机,一个用于dbspj.
,这是在连接的表上查找键所必需的。这两个的大小都被添加到由DBTUP.
阻塞,导致控制DBLQH
块认为它已经消耗了比实际情况更多的可用最大批大小,导致扫描批处理的过早终止,这可能会对SPJ扫描的性能产生负面影响。为了纠正这种情况,现在只报告API请求的实际读长度部分。(Bug #85408, Bug #25702850)在编译NDB内核时海湾合作委员会版本6.0.0或更高版本,现在使用
-flifetime-dse = 1
。(Bug #85381, Bug #25690926)