PDF (Ltr)- 0.9 mb
PDF (A4)- 0.9 mb
性能:在节点启动和重启方面进行了许多性能和其他方面的改进。以下列表简要描述了每一项更改:
在使用启动时分配的内存之前，必须接触它，导致操作系统分配实际所需的物理内存。触摸所分配的每一页内存的过程现在是多线程的，触摸时间是单线程(由16个线程执行)的3倍。
当执行节点或系统重启时，有必要恢复片段的本地检查点。这个过程之前使用延迟信号在一个点被发现是关键的性能;这些信号现在已经被正常的(未延迟的)信号所取代，这将大大缩短备份MySQL NDB集群或从备份中恢复它所需的时间。
以前，在任何给定时间最多可以有2个LDM实例使用本地检查点活动。现在，最多可以使用16个ldm来执行此任务，这提高了可用CPU功率的利用率，并可以将lcp的速度提高10倍，从而大大提高重新启动时间。
更好地报告磁盘写操作，并增加对这些操作的控制，也占了这项工作的很大一部分。新
ndbinfo表disk_write_speed_base，disk_write_speed_aggregate,disk_write_speed_aggregate_node为正在使用的每个LDM线程提供关于磁盘写速度的信息。的DiskCheckpointSpeed而且DiskCheckpointSpeedInRestart配置参数已弃用，并将在未来的MySQL NDB集群版本中删除。该版本添加了数据节点配置参数MinDiskWriteSpeed，MaxDiskWriteSpeed，MaxDiskWriteSpeedOtherNodeRestart,MaxDiskWriteSpeedOwnRestart当当前节点、另一个节点或没有节点重新启动时，控制lcp和备份的写速度。有关更多信息，请参阅
ndbinfo表和MySQL NDB集群配置参数前面命名。MySQL NDB集群启动阶段的报告得到了改进，打印输出更加频繁。资料来源和文件中也提供了关于开始阶段及其执行情况的新的和更好的资料。10bet官方网站看到NDB集群启动阶段总结．
性能:的几个内部方法
NDB接收线程已经优化制作mysqld可以更有效地处理SQL应用程序NDB存储引擎。特别是，该工作提高了性能NdbReceiver: execTRANSID_AI ()方法，该方法通常用于作为扫描操作的一部分从数据节点接收记录。(因为接收线程有时必须每秒处理数百万条接收记录，所以这个方法不能执行不必要的工作，也不能占用不完全需要的资源，这一点很关键。)相关的内部功能receive_ndb_packed_record ()而且handleReceivedSignal ()方法也得到了改进，提高了效率。
关于各个片段的内存使用情况的信息现在可以从
memory_per_fragment中添加的视图ndbinfo信息数据库。该信息包括具有固定和可变元素大小、行、固定元素空闲槽、可变元素空闲字节和散列索引内存使用情况的页面。信息,请参阅ndbinfo memory_per_fragment表．
NDB集群api:当NDB API客户端应用程序接收到一个带有无效块或信号号的信号时，
NDB只提供了一个非常简短的错误信息，没有准确地传达问题的本质。在这种情况下，当检测到错误信号或消息时，将提供适当的打印输出。此外，现在检查消息长度，以确保它与嵌入信号的大小匹配。(错误# 18426180)在某些情况下，一个线程在读取另一个线程时重置传输器接收缓冲区。当接收数据的线程和另一个启动传输程序断开连接(断开连接将清除该缓冲区)的线程之间发生竞争条件时，就会发生这种情况。现在已经实现了并发逻辑来防止这种竞争的发生。(Bug #19552283, Bug #73790)
当一个新的数据节点启动时，允许API节点在数据节点准备好之前尝试将自己注册到数据节点以执行事务。这迫使API节点在再次尝试之前等待一个额外的心跳间隔。
为了解决这个问题，有一些HA_ERR_NO_CONNECTION在此期间可能发出的错误(错误4009)已更改为集群暂时不可用错误4035)，这应该允许API节点比以前更快地使用新的数据节点。作为修复的一部分，一些被错误分类的错误被移到正确的类别中，一些不再使用的错误被删除。(Bug #19524096, Bug #73758)
执行
ALTER TABLE……重组分区将集群中的数据节点数量从4个增加到16个后，导致数据节点崩溃。这个问题被证明是由之前的修复程序所导致的回归，该修复程序使用已经在使用的转储代码(7019)添加了一个新的转储处理程序，这导致该命令执行两个具有不同语义的不同处理程序。新联络员被分配了一个新的转储代码(7024)。(错误# 18550318)这个问题是Bug #14220269的回归。
当某些查询在节点故障之前生成的信号有超过18个数据字时，这些信号不会被正确写入跟踪文件中。(错误# 18419554)
使用时多个节点故障ndbmtd在中等流量的情况下，不能很好地处理多个TC线程，这在某些情况下可能导致集群意外关闭。(错误# 18069334)
对于多线程数据节点，有些线程确实经常通信，其结果是非常旧的信号可能保留在信号缓冲区的顶部。在执行线程跟踪时，信号转储器根据在信号缓冲区中找到的信息计算最新的信号ID，这意味着这些旧信号可能被错误地计算为最新的信号。现在，信号ID计数器被保留为线程状态的一部分，在为跟踪文件转储信号时使用的正是这个值。(Bug #73842, Bug #19582807)