10bet网址
MySQL集群NDB 7.3发行说明
下载这些版本说明
PDF (Ltr)- 0.9 mb
PDF (A4)- 0.9 mb


MySQL集群NDB 7.3发行说明/发行版系列的更新日志:MySQL集群NDB 7.3/ MySQL集群NDB 7.3.5变化(5.6.17-ndb-7.3.5)(2014-04-07,一般可用性)

MySQL集群NDB 7.3.5变化(5.6.17-ndb-7.3.5)(2014-04-07,一般可用性)

功能添加或改变

  • 的处理LongMessageBuffer短缺和统计数据已得到改进如下:

    • 的默认值LongMessageBuffer已经从4 MB增加到64 MB。

    • 这个资源耗尽时,一个合适的信息性消息现在打印的数据节点日志描述问题的可能原因,并提出可能的解决方案。

    • LongMessageBuffer现在使用信息中显示ndbinfo.memoryusage表。看到这个表为例的描述和附加信息。

错误修复

  • 重要的变化:服务器系统变量ndb_index_cache_entriesndb_index_stat_freq在先前已经弃用MySQL集群NDB发行版系列,现在已经被移除。(错误# 11746486,错误# 26673)

  • Solaris:一个问题发现当编译MySQL NDB集群软件Solaris平台在使用时可能会导致问题ThreadConfig在这样的系统上。(错误# 18181656)

  • NDB集群api:当一个NDB API客户机应用程序收到一个信号与无效块或信号的数字,NDB只提供了一个非常简短的错误消息,并没有准确地传达的本质问题。现在在这种情况下,不提供相应的打印输出,当检测到一个糟糕的信号或消息。此外,现在消息长度检查,确保它匹配嵌入式信号的大小。(错误# 18426180)

  • NDB集群api:重构是在MySQL集群NDB 7.3.4无意中引入了一个依赖Ndb.hpp文件中不包括分布,导致NDB API编译应用程序失败。依赖被移除。(错误# 18293112,错误# 71803)

    引用:这个问题的回归:错误# 17647637。

  • NDB集群api:NDB API应用程序发送一个扫描查询一个数据节点;扫描处理的事务协调员(TC)。TC转发一LQHKEYREQ请求到适当的LDM,中止事务如果没有收到LQHKEYCONF响应指定的期限内。事务成功中止后,TC发送一个TCROLLBACKREPNDBAPI客户机,NDB API客户端处理这个消息通过清理Ndb与事务相关联的对象。

    客户端接收到的数据请求的形式TRANSID_AI信号,缓冲发送数据的节点,并可能被交付后延迟。收到这样一个信号,NDB检查事务状态和ID:如果这些正如预期的那样,它处理信号使用Ndb对象与该事务有关。

    当前的错误发生在所有满足以下条件:

    • 事务协调器中止事务由于延误和发送TCROLLBACPREP信号到客户端,同时TRANSID_AI一直在LDM缓冲交付交付给相同的客户端。

    • NDB API客户端认为收到的事务完成TCROLLBACKREP信号,并立即关闭交易。

    • 客户有一个单独的接收器线程同时运行的线程从事关闭交易。

    • 末的到来TRANSID_AI上面的关闭用户线程的事务,这样TRANSID_AI处理通过正常检查closeTransaction ()重置事务状态和无效的接收器。

    当这些条件都满足时,接收器线程开始继续工作TRANSID_AI使用无效信号接收器。由于接收机已经失效,导致一个节点故障。

    现在,Ndb对象清理完成TCROLLBACKREP包括无效的事务ID,因此,对于一个给定的事务,任何收到信号后TCROLLBACKREP到达时没有通过事务ID检查和默默删除。此修复也实现了TC_COMMITREF,TCROLLBACKREF,TCKEY_FAILCONF,TCKEY_FAILREF信号。

    另请参阅操作和信号关于NDB传递附加信息。(错误# 18196562)

  • NDB集群api:这个例子ndbapi-examples / ndbapi_blob_ndbrecord / main.cpp包括内部头文件(ndb_global.h)没有找到MySQL集群NDB二进制发行版。现在使用的例子stdlib.hstring.h而不是这个文件。(错误# 18096866,错误# 71409)

  • NDB集群api:字典:dropTable ()尝试(作为一个正常的一部分,其内部操作)删除索引使用的外键约束,减少失败。现在在这种情况下,调用dropTable ()导致所有要删除外键的表,这个表是否作为一个父表,子表,或两者兼而有之。

    这个问题并不影响使用SQL语句删除索引。(错误# 18069680)

    引用:参见:错误# 17591531。

  • NDB集群api:ndb_restore可能有时报告错误701系统忙于其他模式操作不必要的时候恢复并行。(错误# 17916243)

  • 当一个ALTER TABLE语句改变表模式而导致改变表的分区,新表定义不复制哈希映射从旧的定义,但是当前默认使用散列映射。然而,表数据不是根据新的hashmap重组,使一些行无法使用一个主键查找,如果两个散列映射不相容的定义。

    为了防止这种情况发生,任何ALTER TABLE现在需要一个hashmap变化触发重组的表。此外,在这种情况下,当复制表定义hashmap现在也复制。(错误# 18436558)

  • 当某些查询生成的信号超过18个数据字前一个节点失败,这样的信号没有写正确的跟踪文件。(错误# 18419554)

  • 检查超时处理的信号TIME_SIGNAL。以前,这个信号是生成的QMGRNDB在主线程内核块,送到QMRG,DBLQH,DBTC块(见NDB内核模块),需要检查(分别)心跳,磁盘写操作和事务超时。在ndbmtd(而不是ndbd),这些都块不同的线程中执行。例如,这意味着如果QMGR积极工作和其他线程是睡觉,以前睡觉线程收到大量的吗TIME_SIGNAL消息同时再次醒来的时候,快速有效的时间移动的效果DBLQH以及在DBTC。在DBLQH,这没有明显的不利影响,但事实并非如此DBTC;后者块不能即使时间仍在推进工作事务,导致许多操作出现超时的情况,因为事务协调员(TC)线程是相对缓慢的回答请求。

    此外,当TC线程睡了超过1500毫秒,由于检测数据节点崩溃,超时处理循环还没有停止。为了纠正这个问题,的生成TIME_SIGNAL已经进入了本地线程而不是QMGR;这提供了更好的控制速度TIME_SIGNAL信息可以到达。(错误# 18417623)

  • ServerPortTcpBind_INADDR_ANY配置参数并不包括在输出的ndb_mgmd——print-full-config。(错误# 18366909)

  • 删除一个NDB表,无论是集群日志的输出报告MemoryUsage命令显示IndexMemory所使用的那张桌子已经被释放,尽管内存实际上被收回。这个问题是在MySQL NDB引入集群7.3.2。(错误# 18296810)

  • ndb_show_tables有时失败的错误消息无法连接到管理服务器并立即终止,没有提供失败的根本原因。提供更多有用的信息在这种情况下,这个项目现在也打印最新的错误Ndb_cluster_connection用于实例化连接对象。(错误# 18276327)

  • -DWITH_NDBMTD = 0没有正常工作,导致构建失败等平台的胳膊,覆盆子π不定义编译所需内存屏障功能ndbmtd。(错误# 18267919)

    引用:参见:错误# 16620938。

  • 阻塞线程管理的多线程调度程序通过将通信信号在一个队列或工作所有块线程之间设置缓冲区。这个队列有一个固定的最大大小,填满时,工作线程必须等待消费者流失队列。在高加载系统中,多个线程可能最终导致循环等待锁满了缓冲区,这样他们阻止对方执行任何有用的工作。这种状况最终导致了数据节点被宣布死亡,被看门狗定时器。

    解决这个问题,我们发现一个循环等待锁的情况下即将开始,并导致缓冲,否则在储备成为信号处理的队列是高度可用加载。(错误# 18229003)

  • ndb_mgm客户端开始备份命令(见命令在NDB集群管理客户端)可以体验偶尔随机失败当平之前收到一个预期BackupCompleted事件。现在建立的连接通过这个命令不是检查,直到它被正确设置。(错误# 18165088)

  • 当创建一个表的外键引用另一个表中的索引,有时即使出现可以创建外键列的索引的顺序不匹配,因为内部并不总是返回一个适当的错误。此修复改善错误内部使用在大多数情况下工作;然而,它仍然是可能的这种情况发生时,父指数是一个独特的指数。(错误# 18094360)

  • 更新父表的外键扫描资源过度使用,所以需要设置非常高MaxNoOfLocalScansMaxNoOfConcurrentScans。(错误# 18082045)

  • 删除一个不存在的外键NDB例如,表(使用ALTER TABLE似乎成功了。现在在这种情况下,语句失败相关的错误消息,如预期。(错误# 17232212)

  • 数据节点运行ndbmtd可能停滞在执行一个在线升级的MySQL NDB集群包含许多表从一个版本之前NDB 7.2.5 7.2.5或更高版本。(错误# 16693068)