10bet网址
MySQL NDB群集7.6发行说明
下载这些发布说明
PDF (Ltr)- 0.8MB.
PDF (A4)- 0.8MB.
HTML下载(TGZ)- 169.1 kb
HTML下载(邮政编码)- 225.8 kb


MySQL NDB群集7.6发行说明/发布系列变更日志:MySQL NDB Cluster 7.6MySQL NDB集群7.6.2 (5.7.18-ndb-7.6.2)(2017-04-26,开发里程碑2)

MySQL NDB Cluster 7.6.2 (5.7.18-ndb-7.6.2)(2017-04-26,开发里程碑2)

添加或更改的功能

  • 不相容的变化;NDB磁盘数据:由于磁盘文件格式的变化,有必要执行——初始从该版本升级或降级时,重启每个数据节点。

  • 重要的变化:作为简化NDB群集配置的持续精力的一部分,现在可以动态分配索引的内存datamemory.;的IndexMemory配置参数现在已弃用,并且在将来的NDB版本中删除。任何已设置的内存IndexMemoryconfig.ini文件现在自动添加到datamemory.。另外,默认值为datamemory.已增加到98M,默认的IndexMemory已减为0。

    除了简化配置NDB,这些更改的另一个好处是,通过增加LDM线程数量来进行扩展,不再会因为为IndexMemory。以前,有时情况会增加LDM线程的数量可能导致索引记忆耗尽,而大量datamemory.仍然可用。

    因为DBACC.内核块(负责散列索引存储)现在彼此共享内存,也与DBLQH(充当本地数据管理器的内核块),它们可以利用向上伸缩不增加这一事实datamemory.大量使用,充分利用索引的空闲内存。(有关这些内核块的更多信息,请参见DBACC块,DBLQH块)。换句话说,索引内存不再是仅在集群启动时分配给每个DBACC实例一次的静态数量,而是现在可以在条件需要时分配和释放该资源。

    这里列出了作为这项工作的一部分所做的相关更改:

    • 的几个实例datamemory.与表数据存储无关的使用现在使用事务内存代替。

      因此,某些系统可能需要增加sharedglobalmemory.。此外,使用大型事务执行初始批量数据负载的系统可能需要将大型事务分解为较小的事务。

    • 现在生成数据节点MemoryUsage事件(见NDB群集日志事件),并在资源使用达到99%(以及像以前一样达到80%、90%或100%)时在集群日志中写入适当的消息。

    • 报告MEMORYUSAGE和其他曝光内存消耗的命令现在使用页面大小为32K而不是8K来显示索引存储器消耗。

    • IndexMemory不再是显示的值之一ndbinfo.memoryusage表的memory_type柱子。

    • ndbinfo.resources表现在显示DISK_OPERATIONS资源transaction_memory.

      预订的资源已被移除。

    • IndexMemory不再显示在ndb_config输出。

  • 性能:源中的许多调试语句和打印输出DBTCDBLQH内核块以及相关代码中的内核块被移到调试代码中,或者完全删除。在许多常见的用例中,预计这将使本地数据管理和事务协调器线程的性能提高至多10%。

  • NDB集群api;ndbinfo信息数据库:添加两个表到ndbinfo信息数据库。的然后表提供了被配置为给定NDB集群一部分的节点的信息,例如节点ID和进程类型。的流程表显示了当前连接到集群的节点的信息;该信息包括进程名、系统进程ID和服务地址。对于每个数据节点和SQL节点,它还显示了节点天使进程的进程ID。

    作为实现流程表,一个新的set_service_uri()方法已经添加到NDB API中。

    有关更多信息,请参见表ndbinfo config_nodes,ndbinfo进程表,以及Ndb_cluster_connection: set_service_uri ()

  • NDB集群api:NDB集群的系统名现在可以在mysql.客户端作为值Ndb_system_name状态变量,也可以通过NDB API应用程序使用Ndb_cluster_connection: get_system_name ()方法。系统名称可以使用名称参数在(系统)集群配置文件的一部分。

  • 添加了——查询所有选项ndb_config。此选项的作用与- 询问选项除了——查询所有(简式:——一个)一次转储所有属性的配置信息。(Bug #60095, Bug #11766869)

  • 以前,当一个LDM线程遇到I/O延迟时,比如在磁盘过载情况下,它向本地检查点写入的速度会更慢——也就是说,它在I/O延迟模式下写入。但是,其他LDM线程不一定遵守或符合这种状态。当遇到这样的减速时,为了确保所有LDM线程都降低LCP的写速度,NDB现在全局跟踪I/O延迟模式,以便一旦至少有一个线程在I/O延迟模式下进行写操作,就报告I/O延迟状态,因此当延迟条件持续存在时,所有LDM线程都被迫在延迟模式下进行写操作。其他LDM实例写速度的降低应该会增加总体容量,从而在这种情况下能够比以前更快地克服磁盘过载的情况。

  • 添加了ndb_import.工具,以便于加载csv格式的数据,例如由选择到输出文件,变成一个NDB表格ndb_import.它的功能很像mysqlimport或者是加载数据SQL语句,并支持许多类似选项,用于格式化数据文件。连接到一个NDB管理服务器(ndb_mgmd.) 是必须的;必须有另外用的(api)集群中的插槽config.ini为此目的文件。此外,目标数据库和表(使用该表(使用)NDBCSV文件的名称(不含任何文件扩展名)必须与目标表的名称保持一致。创建目标数据库和表需要一个正在运行的SQL节点,但不需要ndb_import.函数。

    有关更多信息,请参见ndb_import -导入CSV数据到NDB

错误修复

  • 分区:的输出解释分区显示不正确的值分区在显式分区上运行时NDB具有大量分区的表。

    这是由于这样一个事实,当处理解释声明中,mysqld.计算散列值的分区ID(hash_value%number_of_partitions),只有当表被分区时才正确哈希,由于其他分区类型使用将映射散列值的不同方法映射到分区ID。此修复程序替换所执行的分区ID计算mysqld.与内部NDB函数,根据表的分区类型正确计算分区ID。(错误# 21068548)

    参考:参见Bug #25501895, Bug #14672885。

  • 微软的Windows操作系统:在接收Windows上收集有关CPU的信息时,自动安装程序仅计算物理核心,与其他平台不同,它收集有关物理和虚拟核心的信息。现在在Windows上获得的CPU信息与其他平台上提供的CPU信息相同。(bug#85209,bug#25636423)

  • NDB磁盘数据:在某些情况下,将NDB磁盘数据表的内存中的动态列设置为没有正确处理。(bug#79253,bug#22195588)

  • ndb_report_thresh_binlog_epoch_slip事件缓冲区状态消息是否已启用report_reason =低/ ENOUGH_FREE_EVENTBUFFER当事件缓冲区使用率高然后降低到较低级别时,将在日志中打印。此计算基于已分配的事件缓冲区内存总数,而不是所设置的限制ndb_eventbuffer_max_alloc.;即使事件缓冲区有无限内存(ndb_eventbuffer_max_alloc.= 0,默认值),这可能会让用户感到困惑。

    这是固定如下:

    • 的计算ndb_eventbuffer_free_percent.现在是基于ndb_eventbuffer_max_alloc.,而不是实际分配的数量。

    • ndb_eventbuffer_free_percent.设置和ndb_eventbuffer_max_alloc.使用等于0,事件缓冲区状态消息report_reason =低/ ENOUGH_FREE_EVENTBUFFER都不再印刷了。

    • ndb_report_thresh_binlog_epoch_slip是否设置,显示事件缓冲区状态消息Report_Reason = Buffered_epochs_over_threshold.每10秒(而不是每秒)写入,无论何时大于阈值,都会写入。

    (错误# 25726723)

  • 通过读取记录并在记录集上执行事务来执行批量更新,这在读取它们时启动。当事务初始化失败时,事务执行程序函数随后未知发生此操作,导致SQL节点故障。通过在尝试初始化事务时提供适当的错误处理来修复此问题。(bug#25476474)

    参考:另请参阅:Bug#20092754。

  • CPU使用数据节点的主线程DBDIH.在某些情况下,当数据库有大量的片段副本时,作为本地检查点末端的主块可能接近100%。通过减少LCP期间片段队列检查的频率和范围来解决这个问题。(错误# 25443080)

  • 执行网上文件ALTER TABLE……重组分区对A.的声明NDB主键长度大于80字节的表会导致重新启动数据节点,导致重组失败。(错误# 25152165)

  • 群集部分重启期间的多个数据节点故障可能导致API节点失败。这是由于一个线程的内部对象ID映射的扩展,从而将其位置更改为内存,而另一个线程仍在访问旧位置,导致后一个线程中的分段错误。

    内部map ()的映射()出现此问题的函数现在被设置为线程安全的。(错误# 25092498)

    参考资料:参见Bug #25306089。

  • 超过10个数据节点的NDB集群的计划关闭并不总是正常执行。(错误# 20607730)

  • 下降了TRANS_AI使用长信号格式的信号未被处理DBTC内核块。(bug#85606,bug#25777337)

    参考:参见Bug #85519, Bug #27540805。

  • 通过消除不需要的方式推动推动加入处理Flush_ai.属性传递空行给DBSPJ当一行应该只传递给SPJ API时,内核块;这减少了集合AttrInfo必须执行的投影以产生结果。这也可以使用包装TRANSID_AI在传递SPJ API结果时发出信号,这样效率更高。(Bug #85525, Bug #25741170)

    参考:参见Bug #85545, Bug #25750355。

  • 使用长信号格式(在NDB 6.4中引入)接收TRANSID_AI的支持备份,DBTC,DBLQH,SUMA,DBSPJ,DBUTILNDB内核块,但是DBTUP块只在发送时产生长信号DPSPJDBUTIL,然后发送一系列短信号。现在DBTUP只要接收块支持这种优化,就对此类消息使用长信号。(Bug #85519, Bug #25740805)

  • 为防止扫描返回多于客户端预留缓冲区的行、字节或两者都返回,则DBTUP内核块报告的大小TRANSID_AI中已发送给客户端TUPKEYCONF信号发送给请求DBLQH块。DBLQH知道可用于结果集的最大批处理大小,并在超过此大小时终止扫描批处理。

    DBSPJFlush_ai.属性允许DBTUP生产两个TRANSID_AI来自同一行的结果,一个用于客户机,一个用于DBSPJ,这是在连接的表上查找键所必需的。这两个的大小都被添加到由DBTUP块,导致控制DBLQH块相信它已经消耗了更多的最大批量大小,而不是实际情况,导致扫描批次过早终止,这可能对SPJ扫描的性能产生负面影响。为纠正此问题,在此情况下,才会报告API请求的实际读取长度部分。(bug#85408,bug#25702850)

  • 在SPARC平台上使用Oracle Developer Studio 12.5构建的Solaris 11的数据节点二进制文件由于总线错误而失败。(Bug #85390, Bug #25695818)

  • 在扫描请求的初始阶段DBTC内核块发送一系列DIGETNODESREQ信号到了DBDIH.块,以获取要扫描的每个片段的字典信息。如果DBDIH.返回DIGETNODESREF,该信号的错误代码没有读取,错误218走出来的LongMessageBuffer.结果总是被退回来。在这种情况下,来自DIGETNODESREF信号实际上是用的。(Bug #85225, Bug #25642405)

  • 如果用户试图调用ndb_setup.py当自动安装程序仍在运行时(例如,在关闭启动它的终端后,然后打开一个新的终端并在新的终端中调用它),程序会出现错误而失败Web服务器已经运行,这是预期的行为。在这种情况下,mcc.pid在重新启动自动安装程序之前必须首先删除文件(也是预期的行为)。现在,当程序因此原因而失败时,位置mcc.pid包含在错误消息中,以简化此任务。(Bug #85169, Bug #25611093)

  • 在同一节点组中的一个或多个数据节点发生故障后,计划关闭数据节点的操作并不总是正确执行。(Bug #85168, Bug #25610703)

  • 在来自不同SQL节点的同一个数据库对象上的模式操作之间存在竞争条件的可能性;当其中一个SQL节点延迟释放受影响的模式对象上的元数据锁时,就可能发生这种情况,因为这样一来,模式分布协调器就会认为锁释放是因为错误的模式更改。这可能导致在部分或所有SQL节点上错误地应用模式更改,或出现重复超时等待马克斯# # #证券交易委员会分配……由于分发协议的故障,节点日志中的消息。(bug#85010,bug#25557263)

    参考:参见Bug #24926009。

  • 在NDB表中添加或删除外键时ALTER TABLE语句,父表的元数据未更新,这使得可以在父级执行无效的更改操作。

    在升级到这个版本之前,您可以通过运行来解决这个问题显示创建表在父节点上添加或删除外键后立即执行;此语句将导致重新加载表的元数据。(Bug #82989, Bug #24666177)

  • 交易NDB当查询缓存也被启用时,具有级联外键的表返回的结果不一致,这是因为mysqld.没有意识到子表更新。这就意味着结果要等一会儿选择从子表中从查询缓存中获取数据,此时查询缓存中包含过时的数据。

    在这种情况下,通过将父表的所有子表添加到一个要检查的内部列表来解决这个问题NDB更新父级更新时,以至于mysqld.现在正确地通知任何应该从查询缓存中无效的更新的子表。(Bug #81776, Bug #23553507)