PDF(美国Ltr)- 0.9 mb
PDF (A4)- 0.9 mb
MySQL NDB Cluster 7.4.1是NDB Cluster的一个新的开发里程碑版本，基于MySQL Server 5.6，预览了正在为版本7.4开发的新特性NDB存储引擎。
获取MySQL NDB Cluster 7.4。MySQL NDB Cluster 7.4的源代码和二进制文件可以从10bet博彩公司 ．
有关MySQL NDB Cluster 7.4中所做更改的概述，请参阅NDB集群7.4有什么新内容．
该版本还包含了之前NDB集群版本中所做的所有bug修复和更改，以及从MySQL 5.6到MySQL 5.6.20主线中添加的所有bug修复和特性更改MySQL 5.6.20的更改(2014-07-31，通用可用性)）.
NDB复制:对MySQL NDB集群复制冲突检测和解决的异常表进行了大量更改和改进。现在为元列使用保留的列名命名空间，这允许记录不属于表主键的主表列的任意子集。异常表中所有元列的名称现在都应该加上前缀
NDB美元．不再需要记录完整的主键。主表列与异常表列的匹配现在仅根据名称和类型执行。此外，您现在可以在异常表中记录不属于主表主键的列的值。
现在可以在冲突异常表中使用预定义的可选列，以获取关于冲突的类型、原因和发起事务的信息。
现在支持读取跟踪——即检测一个集群中给定行的读取与另一个集群中同一行的更新或删除之间的冲突。这需要通过设置获得排他读锁
ndb_log_exclusive_reads在从集群上等于1。冲突读操作读取的所有行都记录在异常表中。有关更多信息和示例，请参见阅读冲突检测和解决．继续支持现有的异常表。有关其他信息，请参见冲突解决例外表．
性能:在节点启动和重启方面进行了许多性能和其他方面的改进。以下列表简要描述了每一项更改:
在使用启动时分配的内存之前，必须接触它，导致操作系统分配实际所需的物理内存。触摸所分配的每一页内存的过程现在是多线程的，触摸时间是单线程(由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复制:当使用冲突检测和解决与循环或”active - active”MySQL NDB集群复制设置，现在可以显式和动态地设置主集群和备用集群的角色
ndb_slave_conflict_role此版本中引入的服务器系统变量。这个变量可以取任意一个值主要的，二次，通过,或零(默认)。（通过启用一个直通状态，在该状态下，忽略任何冲突解决函数的影响。)当需要从充当主服务器的MySQL NDB集群进行故障转移时，这将非常有用。当这个变量的值被更改时，从SQL线程必须停止。另外，不可能在两者之间直接改变它
通过其中任何一个主要的或二次．有关更多信息，请参见
ndb_slave_conflict_role以及NDB集群复制冲突解决．
性能:的几个内部方法
NDB接收线程已经优化制作mysqld可以更有效地处理SQL应用程序NDB存储引擎。特别是，该工作提高了性能NdbReceiver: execTRANSID_AI ()方法，该方法通常用于作为扫描操作的一部分从数据节点接收记录。(因为接收线程有时必须每秒处理数百万条接收记录，所以这个方法不能执行不必要的工作，也不能占用不完全需要的资源，这一点很关键。)相关的内部功能receive_ndb_packed_record ()和handleReceivedSignal ()方法也得到了改进，提高了效率。
关于各个片段的内存使用情况的信息现在可以从
memory_per_fragment中添加的视图ndbinfo信息数据库。该信息包括具有固定和可变元素大小、行、固定元素空闲槽、可变元素空闲字节和散列索引内存使用情况的页面。有关信息，请参见ndbinfo memory_per_fragment表．
NDB集群接口:当NDB API客户端应用程序接收到一个带有无效块或信号号的信号时，
NDB只提供了一个非常简短的错误信息，没有准确地传达问题的本质。在这种情况下，当检测到错误信号或消息时，将提供适当的打印输出。此外，现在检查消息长度，以确保它与嵌入信号的大小匹配。(错误# 18426180)在某些情况下，一个线程在读取另一个线程时重置传输器接收缓冲区。当接收数据的线程和另一个启动传输程序断开连接(断开连接将清除该缓冲区)的线程之间发生竞争条件时，就会发生这种情况。现在已经实现了并发逻辑来防止这种竞争的发生。(Bug #19552283, Bug #73790)
当一个新的数据节点启动时，允许API节点在数据节点准备好之前尝试将自己注册到数据节点以执行事务。这迫使API节点在再次尝试之前等待一个额外的心跳间隔。
为了解决这个问题，有一些HA_ERR_NO_CONNECTION在此期间可能发出的错误(错误4009)已更改为集群暂时不可用错误4035)，这应该允许API节点比以前更快地使用新的数据节点。作为修复的一部分，一些被错误分类的错误被移到正确的类别中，一些不再使用的错误被删除。(Bug #19524096, Bug #73758)
执行
修改表…重组分区将集群中的数据节点数量从4个增加到16个后，导致数据节点崩溃。这个问题被证明是由之前的修复程序所导致的回归，该修复程序使用已经在使用的转储代码(7019)添加了一个新的转储处理程序，这导致该命令执行两个具有不同语义的不同处理程序。新联络员被分配了一个新的转储代码(7024)。(错误# 18550318)这个问题是Bug #14220269的回归。
当某些查询在节点故障之前生成的信号有超过18个数据字时，这些信号不会被正确写入跟踪文件中。(错误# 18419554)
使用时多个节点故障ndbmtd在中等流量的情况下，不能很好地处理多个TC线程，这在某些情况下可能导致集群意外关闭。(错误# 18069334)
对于多线程数据节点，有些线程确实经常通信，其结果是非常旧的信号可能保留在信号缓冲区的顶部。在执行线程跟踪时，信号转储器根据在信号缓冲区中找到的信息计算最新的信号ID，这意味着这些旧信号可能被错误地计算为最新的信号。现在，信号ID计数器被保留为线程状态的一部分，在为跟踪文件转储信号时使用的正是这个值。(Bug #73842, Bug #19582807)