添加了
——diff-default
选择ndb_config.此选项使程序只打印那些值与默认值不同的参数。(Bug #85831, Bug #25844166)添加了
——查询所有
选项ndb_config.该选项与——查询
除了——查询所有
(简式:——一个
)一次性转储所有属性的配置信息。(Bug #60095, Bug #11766869)
NDB集群api:实现方法
NdbDictionary:: NdbTableImpl:: getColumn ()
,在NDB API中很多地方都使用,其中列是通过名称引用的,已经变得更加高效。这种方法使用对列数组进行线性搜索来找到正确的列对象,对于有许多列的表来说,这种方法效率很低,并且在客户应用程序中被检测到大量使用CPU。(理想情况下,用户应该执行名称到列的对象映射,然后在方法调用中使用列id或对象,但实际上并不总是这样做。)对于具有相对较多列的表,恢复了以前用于名称查找的成本较低的散列索引实现。(线性搜索继续用于列较少的表,其中性能的差异可以忽略不计。)备份
. log
文件包含一个或多个额外片段的日志条目,这是由于过滤掉同一节点组中其他节点记录的更改时出现的问题。这导致了更大的. log
文件,从而使用更多的资源比必要的;它还可能在恢复时引起问题,因为在应用日志时,来自不同节点的备份可能会相互干扰。(错误# 25891014)当对重做日志文件进行最后一次写入时,预计下一个日志文件已经被打开进行写入,但对于慢磁盘并不总是这样,从而导致节点故障。在这种情况下
NDB
等待下一个文件被正确打开,然后再尝试写入。(错误# 25806659)数据节点线程可以绑定到单个CPU或一组CPU,一组CPU在内部由
NDB
作为一个SparseBitmask
.当尝试锁定一组CPU时,由于执行锁定的例程使用mt_thr_config.cpp: do_bind ()
方法,该方法查找在整个理论范围内设置的位SparseBitmask
(232-2,或4294967294)。这是通过使用SparseBitmask: getBitNo ()
,它可以用来迭代那些实际设置的位。(错误# 25799506)批量更新是通过读取记录并在记录集上执行事务来执行的,该事务在读取记录时启动。当事务初始化失败时,事务执行器函数随后不知道发生了这种情况,从而导致SQL节点失败。通过在尝试初始化事务时提供适当的错误处理,可以修复此问题。(错误# 25476474)
参考:参见Bug #20092754。
设置
NoOfFragmentLogParts
这样,每个本地数据管理器有超过4个重做日志部件,导致资源耗尽,随后多个数据节点故障。由于这是一个无效的配置,因此添加了一个检查来检测每个LDM有超过4个重做日志部分的配置,并将其视为无效而拒绝它。(错误# 25333414)在线执行
修改表…重组分区
声明NDB
如果表的主键长度大于80字节,则会导致数据节点重新启动,从而导致重组失败。(错误# 25152165)如果在触发器执行期间外键触发器列与提供给它们的值不匹配,但没有指示问题来源的错误消息,则会引发错误240。(错误# 23141739)
参考:参见Bug #23068914, Bug #85857。
如果LDM块的数量不能被TC/SPJ块的数量平均整除,那么SPJ请求就不能均匀地分布在可用的SPJ实例上。现在,使用循环分布更有效地将SPJ请求分布到所有可用的SPJ实例中。
作为这项工作的一部分,已经从类中删除了许多未使用的成员变量
Dbtc
.(错误# 22627519)修改表..MAX_ROWS = 0
现在只能通过复制来执行吗ALTER TABLE
声明。重置MAX_ROWS
不能再使用算法=原地
或者是在线
关键字。(错误# 21960004)在系统重新启动期间,当一个节点由于没有发送心跳而失败时,所有其他节点只报告另一个节点失败,而没有任何其他信息。现在,在这种情况下,错误日志和数据节点日志中都会报告心跳丢失和发送心跳失败的节点的ID。(错误# 21576576)
有超过10个数据节点的NDB集群的计划关闭并不总是能正常执行。(错误# 20607730)
由于以前的问题与优化和执行阶段之间的分离不清楚时,查询涉及一个
集团
时,连接可推计算器不能确定其优化的查询执行计划实际上是否可推。因此,这样的分组连接总是被认为是不可推的。我们已经确定,在MySQL 5.6中已经解决了分离问题,所以我们现在删除了这个限制。(Bug #86623, Bug #26239591)当删除表中的所有行时
删除表
,这是有可能的萎缩DBACC
哈希索引在删除之前没有准备好。收缩是一个分段操作,不检查表的状态。当桌子掉下来的时候,DBACC
释放资源时,分片大小和页面目录描述不一致;这可能导致读取陈旧的页面和未定义的行为。由于散列索引的扩展,插入大量行然后删除表也应该有这样的效果。
为了解决这个问题,我们要确保,当一个片段即将被释放时,这个片段上没有待定的扩展或收缩操作。(Bug #86449, Bug #26138592)
内函数
execute_signals ()
在mt.cpp
从信号中读取三个节指针,即使没有传递给它。虽然没有必要,但基本上是无害的。当读取的信号是作业缓冲区最后一页上的最后一个信号时,内存中的下一页没有映射或以其他方式可访问,ndbmtd失败,出现错误。为了防止这种情况发生,这个函数现在只读取实际传递给它的节指针。(Bug #86354, Bug #26092639)的ndb_show_tables程序
——不合格
选项在设置为0时不能正常工作(false);这将禁用该选项,从而导致在输出中打印完全限定的表名和索引名。(Bug #86017, Bug #25923164)当一个
NDB
表,首先创建其索引,然后,在创建外键期间,将这些索引加载到NDB
字典缓存。当一个创建表
语句由于与外键相关的问题而失败,缓存中已经存在的索引没有失效。这意味着任何后续的创建表
与失败语句中的索引名称相同的任何索引都会产生不一致的结果。在这种情况下,在failed中命名的任何索引创建表
立即从缓存中失效。(Bug #85917, Bug #25882950)尝试执行
修改表…添加外键
当要添加的键具有同表上现有外键的名称时,出现错误的错误消息。(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)