10bet网址
MySQL NDB集群7.6版本说明
下载这些版本说明
PDF (Ltr)- 0.8 mb
PDF (A4)- 0.8 mb
HTML下载(TGZ)- 169.1 kb
HTML下载(邮政编码)- 225.8 kb


MySQL NDB集群7.6版本说明/ MySQL NDB集群7.6.3 (5.7.18-ndb-7.6.3)(2017-07-03,开发里程碑3)

MySQL NDB集群7.6.3 (5.7.18-ndb-7.6.3)(2017-07-03,开发里程碑3)

MySQL NDB Cluster 7.6.3是NDB 7.6的一个新版本,基于MySQL Server 5.7,包含了该版本7.6的功能NDB存储引擎,以及修复在以前的NDB集群版本中最近发现的错误。

获取NDB集群7.6。NDB Cluster 7.6的源代码和二进制文件可以从10bet博彩公司

有关NDB Cluster 7.6中所做更改的概述,请参见NDB集群7.6有什么新功能

该版本还包含了之前NDB集群版本中所有的bug修复和更改,以及从MySQL 5.7到MySQL 5.7.18主线中添加的所有bug修复和特性更改MySQL 5.7.18的更改(2017-04-10,通用可用性)).

包装的笔记

  • mysqladmin被添加到Docker/Minimal包中,因为InnoDB Cluster需要它。(错误# 25998285)

增加或更改的功能

  • 重要的变化;MySQL NDB ClusterJ:NDB集群不再支持OpenJPA的ClusterJPA插件,并且已经从发行版中删除。(错误# 23563810)

  • NDB复制:添加了——ndb-log-update-minimal通过日志记录的选项mysqld.该选项导致在前一个图像中只写入主键值,而在后一个图像中只写入更改的列。(错误# 24438868)

  • MySQL NDB ClusterJ:新的自动重新连接功能已实现,以方便处理连接问题。通过为新连接属性设置一个正数来启用该特性,com.mysql.clusterj.connection.autoreconnect.timeout,以秒为单位指定超时时间的长度。如果出现连接错误,在应用程序关闭所有会话后,ClusterJ会尝试重新连接应用程序到NDB集群;如果应用程序没有在超时时间内关闭所有会话,ClusterJ将强制关闭所有打开的部分,然后尝试重新连接。看到错误处理和重新连接获取详细信息。

  • 在一些关键情况下,如数据节点故障,产生的日志消息量可能会导致文件系统和其他问题,这使问题更加复杂,因为这些消息是使用同步记录的stdout.为了防止这种情况发生,来自工作线程的日志消息现在使用一个日志缓冲区,这是非阻塞的,因此在这种情况下不太可能对其他进程造成干扰。(错误# 24748843)

  • 添加了——diff-default选择ndb_config.该选项使程序只打印那些值与默认值不同的参数。(Bug #85831, Bug #25844166)

  • 添加了ndb_top在基于unix的平台上编程。该实用程序显示CPU负载和使用信息NDB数据节点,定期更新(默认情况下每秒钟更新一次)。显示为文本或彩色ASCII图形格式;两种格式可以同时显示。也可以禁用图形的颜色输出。

    ndb_top连接到一个NDB集群SQL节点(即MySQL服务器),因此必须能够以MySQL用户的身份连接选择表上的特权ndbinfo数据库。

    ndb_top目前在Windows平台上不可用。

    有关更多信息,请参见ndb_top -查看NDB线程的CPU使用率信息

错误修复

  • 包装:中添加了两个缺失的依赖项恰当的包:

    • 数据节点包需要libclass-methodmaker-perl

    • auto-installer要求python-paramiko

    (Bug #85679, Bug #25799465)

  • NDB磁盘数据:如果在节点故障时磁盘表的表空间已被完全占用,并且在节点不可用时删除和插入表行(或通过缩小或扩大磁盘列值更新表行),则后续重启可能会失败,错误为1601超出区段,表空间已满.为了防止这种情况的发生,我们保留了4%的表空间供节点启动时使用。(错误# 25923125)

  • NDB复制:增加了一个检查来停止NDB检测到配置为多线程从时的复制从(例如,ifslave_parallel_workers设置为非零值)。(错误# 21074209)

  • NDB集群api:的实现方法NdbDictionary:: NdbTableImpl:: getColumn ()在NDB API中通过名称引用列的许多地方都使用了该工具。这种方法使用对列数组的线性搜索来查找正确的列对象,对于有许多列的表,这种方法可能效率很低,并且在客户应用程序中被检测为大量使用CPU。(理想情况下,用户应该执行名称到列的对象映射,然后在方法调用中使用列id或对象,但实际上并不总是这样做。)对于列相对较多的表,恢复了以前用于名称查找的成本较低的哈希索引实现。(线性搜索继续用于列数更少的表,在这些表中性能差异可以忽略不计。)

  • NDB集群api:NDB错误631被重新归类为(临时)节点恢复错误扫描接管错误,重新启动扫描事务.这以前是作为内部(和永久)错误向应用程序公开的,没有提供任何描述。(Bug #86401, Bug #26116231)

  • MySQL NDB ClusterJ:运行ClusterJ的单元测试时,将跳过JTie和NDB JTie测试。(错误# 26088583)

  • MySQL NDB ClusterJ:NDB JTie测试的编译失败。这是由于空引用的处理方式,已通过此修复程序纠正。(错误# 26080804)

  • 备份. log文件包含一个或多个额外片段的日志条目,这是由于过滤相同节点组中其他节点记录的更改时出现的问题。这就导致了较大的. log归档并因此使用了过多的资源;它还可能在恢复时引起问题,因为在应用日志时,来自不同节点的备份可能会相互干扰。(错误# 25891014)

  • 在片段创建期间,内存耗尽导致集群意外关闭。如果同时向大量列添加惟一键,则可能引发此问题。(错误# 25851801)

  • 当对重做日志文件进行最后的写操作时,预期下一个日志文件已经打开进行写操作了,但在磁盘速度慢的情况下并不总是这样,从而导致节点故障。在这种情况下NDB在尝试写入前,等待下一个文件被正确打开。(错误# 25806659)

  • 数据节点线程可以绑定到单个CPU或一组CPU,一组CPU在内部表示为NDB作为一个SparseBitmask.当试图锁定一组CPU时,由于执行锁定的例程使用了mt_thr_config.cpp: do_bind ()方法,该方法查找在整个理论范围内设置的位SparseBitmask(2322, 4294967294)。这是通过使用SparseBitmask: getBitNo (),它只能用于迭代那些实际设置的位。(错误# 25799506)

  • 设置NoOfFragmentLogParts这样,每个本地数据管理器有超过4个重做日志部件,导致资源耗尽和后续多个数据节点故障。由于这是一个无效的配置,因此添加了一个检查来检测每个LDM有超过4个重做日志部分的配置,并以无效为由拒绝它。(错误# 25333414)

  • 在某些情况下,失败了ALTER TABLE……添加独特的关键语句可能导致SQL节点失败。(错误# 24444878)

    这个问题是Bug #23089566的回归。

  • 如果在触发器执行期间外键触发器列与提供给它们的值之间不匹配,但没有指示问题来源的错误消息,则会引发错误240。(错误# 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都将在错误日志和数据节点日志中报告。(错误# 21576576)

  • 由于以前的一个问题,当查询涉及一个时,优化和执行阶段之间的分离不清楚集团时,联接可推的求值器不确定其优化的查询执行计划是否实际上是可推的。因此,这种分组连接总是被认为是不可推的。我们已经确定,在MySQL 5.6中已经完成的工作已经解决了分离问题,所以现在我们删除了这个限制。(Bug #86623, Bug #26239591)

  • 当删除表中的所有行时,紧跟着删除表,就有可能缩小DBACC哈希索引在删除前未准备好。这个收缩是一个每个片段的操作,它不检查表的状态。当桌子掉下来的时候,DBACC释放资源,期间片段大小和页面目录描述不一致;这可能导致读取过时的页面和未定义的行为。

    由于哈希索引的扩展,插入大量行然后删除表也应该有这样的效果。

    为了解决这个问题,当一个片段即将被释放时,我们要确保在这个片段上没有挂起的扩展或收缩操作。(Bug #86449, Bug #26138592)

  • 一些错误消息仍然被引用IndexMemory,尽管该参数已弃用。(Bug #86385, Bug #26107514)

  • 内部函数execute_signals ()mt.cpp从信号中读取三个节指针,即使没有传递给它。这基本上是无害的,尽管没有必要。当读取的信号是作业缓冲区中最后一页上的最后一个信号,而内存中的下一页没有映射或以其他方式访问时,ndbmtd失败,出现错误。为了防止这种情况发生,这个函数现在只读取实际传递给它的节指针。(Bug #86354, Bug #26092639)

  • 在Dbacc中,删除删除表时释放的散列索引页的尝试最多只有一次。这意味着,对于大分区(32页或更多),总有一些页丢失。现在,当使用哈希索引页的表被删除时,所有哈希索引页都被释放。(Bug #86247, Bug #26030894)

  • 上的查询时NDB由于违反外键约束,表失败,错误消息中没有显示有关外键的有用信息,只包含文本未知错误代码.(Bug #86241, Bug #26029485, Bug #16371292)

    参考文献:参见Bug #16275684。

  • ndb_show_tables程序——不合格选项在设置为0时没有正确工作(false);这将禁用该选项,从而导致在输出中打印完全限定的表和索引名。(Bug #86017, Bug #25923164)

  • 当一个NDB表时,首先创建它的索引,然后在创建外键期间,将这些索引加载到NDB字典缓存。当一个创建表语句由于与外键相关的问题而失败,但缓存中已经存在的索引没有失效。这意味着任何后续的创建表任何与失败语句中索引名称相同的索引都会产生不一致的结果。在这种情况下,在失败的创建表立即从缓存中失效。(Bug #85917, Bug #25882950)

  • 在本地检查点期间,记录大小从DBTUP内核块。这个记录大小一直在使用,直到LCP扫描完成,这使得它可以DBTUP对象提交时更新最大记录大小ALTER TABLE将列添加到表中,这可能导致在LCP期间节点故障。现在,获取记录大小时,更新它不会导致这种情况。(Bug #85858, Bug #25860002)

  • 试图执行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)

  • 启用short或packing short的使用TRANSID_AI发送结果的信号DBSPJ回到客户端API。(Bug #85545, Bug #25750355)

    参考文献:参见Bug #85525, Bug #25741170。

  • 的最大BatchByteSize在发送SCANREQ并不总是正确地设置信号,以反映客户端结果缓冲区中可用的有限字节大小。已修改了结果缓冲区大小计算,以便有效批处理字节大小准确反映数据节点可能返回的最大值,以防止结果缓冲区可能溢出。(Bug #85411, Bug #25703113)

  • 当编译NDB内核时海湾合作委员会版本6.0.0或更高版本,现在使用-flifetime-dse = 1.(Bug #85381, Bug #25690926)