Documentation Home
MySQL NDB Cluster 7.4 发行说明
MySQL NDB Cluster 7.4 发行说明  / 发布系列变更日志：MySQL NDB Cluster 7.4  /  MySQL NDB Cluster 7.4.7 (5.6.25-ndb-7.4.7) 的变化（2015-07-13，全面上市）

MySQL NDB Cluster 7.4.7 (5.6.25-ndb-7.4.7) 的变化（2015-07-13，全面上市）

添加或更改的功能

  • 不推荐使用的 MySQL NDB Cluster 节点配置参数现在由ndb_config 指示。对于当前弃用的每个参数，XML 输出中的相应 标记现在包含属性。（漏洞 #21127135）--configinfo --xml<param/>deprecated="true"

  • 此处列出的一些改进是关于处理由于在本地检查点 (LCP) 期间执行大量插入而导致过载时可能出现的问题：

    • 由于查找日志末尾的问题，尝试执行撤消日志时，在重新启动处理期间有时会发生故障。当写入第二个 undo 文件时，第一个 undo 文件的末尾仍有未写入的页面，导致以相反的顺序执行 undo 日志，从而执行旧的甚至不存在的日志记录时，就会发生这种情况。

      这是通过确保撤消日志的执行从日志的正确结尾开始来解决的，如果更早开始，则忽略任何未写入或错误的页面。

    • COPY_FRAGREQ由于操作记录用完， 在 LCP 期间或执行 时可能会失败 。我们通过确保 LCP 和 COPY_FRAG使用为操作记录保留的资源来解决此问题，就像扫描记录一样。此外，不再需要但可能导致失败的 ACC 操作旧代码已被删除。

    • 当在加载表时执行 LCP 时，可能会在 LCP 扫描期间遇到活锁，因为在 LCP 启动后插入到新页面中的每条记录都LCP_SKIP设置了其标志。这些记录按 LCP 扫描的预期被丢弃，但是当插入发生的速度快于 LCP 扫描可以丢弃记录时，扫描似乎挂起。作为此问题的一部分，扫描未能向 LCP 看门狗报告任何进展，该看门狗在活锁 70 秒后终止了进程。使用单个 LDM 在较长时间段（120 秒或更长时间）内每秒执行大约 250000 次插入时会观察到此问题。

      修复的这一部分进行了一些更改，在此处列出：

      • 我们现在确保在 LCP 启动后创建的页面不包含在 LCP 扫描中；我们还确保插入这些页面的记录都没有 LCP_SKIP设置标志。

      • 扫描协议的处理发生了变化，无论负载如何，LCP 都会取得一定的进展；我们现在向 LCP 看门狗报告进度，以避免在 LCP 正在取得进展但未写入任何记录的情况下发生故障。

      • 我们现在采取措施确保 LCP 扫描比插入更快地进行，方法是确保扫描优先于此扫描活动，因此 LCP 实际上（最终）已完成。

      • 此外，通过预取元组，扫描效率更高；这有助于避免在 CPU 中获取内存时出现停顿。

    • 用于防止数据损坏的行校验和现在包括元组标头位。

    （错误#76373、错误#20727343、错误#76741、错误#69994、错误#20903880、错误#76742、错误#20904721、错误#76883、错误#20980229）

修正错误

  • 不相容的变化；NDB Cluster API：pollEvents2()只要时间参数使用负值， 该（缺陷号 20762291）

  • 重要变更；NDB Cluster API： 该 Ndb::getHighestQueuedEpoch() 方法返回事件队列中的最大纪元，而不是调用 pollEvents2(). （缺陷号 20700220）

  • 重要变更；NDB Cluster APIs： Ndb::pollEvents()现在与MySQL NDB Cluster 7.4.3 中引入的 、 和 event 类型TE_EMPTY兼容 TE_INCONSISTENT。 TE_OUT_OF_MEMORY有关此更改的详细信息，请参阅 MySQL NDB Cluster API 开发人员指南中对此方法的描述。（缺陷号 20646496）

  • 重要变更；NDB Cluster API： 将方法添加 Ndb::isExpectingHigherQueuedEpochs() 到 NDB API 以检测何时检测到额外的、更新的事件纪元 pollEvents2()。

    的行为 Ndb::pollEvents()也已修改，现在 当检测到集群故障时它返回NDB_FAILURE_GCI（等于 ）。~(Uint64) 0（漏洞 #18753887）

  • NDB Cluster API： 添加了 根据列的类型（文本/blob 或其他）Column::getSizeInBytesForRecord() 返回列所需的大小 NdbRecord（缺陷号 21067283）

  • NDB Cluster API： 为 表事件类型 NdbEventOperation::isErrorEpoch() 错误返回（请参阅Event::TableEvent）。这导致后续调用 失败。（缺陷号 20729091）falseTE_INCONSISTENTgetEventType()

  • NDB Cluster API：多个线程 创建和销毁 Ndb_cluster_connection对象可能会使用相同的应用程序锁，这在某些情况下会导致全局字典缓存失败。为了缓解这个问题，已经序列化了几个内部 NDB API 对象的创建和销毁。（缺陷号 20636124）

  • NDB Cluster API：NDB API 中的许多超时未正确处理。（缺陷号 20617891）

  • NDB Cluster APIs： 当一个Ndb在集群失败之前创建的对象被重用时，这个对象的事件队列仍然可以包含来自失败之前的数据节点事件。这些事件可以引用 “旧”时期（从失败发生之前开始），这反过来又可能违反该 nextEvent()方法所做的时期数总是增加的假设。此问题已通过在此类情况下明确清除事件队列得到解决。（漏洞#18411034）

    参考资料：另请参阅：Bug #20888668。

  • 通过运行ndb_restore --restore-meta（或 -m）恢复数据库元数据（但不是任何数据）后，SQL 节点在尝试 SELECT从元数据恢复到的数据库中的表时挂起。在这种情况下，查询表的尝试现在会按预期失败，因为在 使用 ( )执行 ndb_restore之前，表实际上并不存在。（缺陷号 21184102）--restore-data-r

    参考资料：另请参阅：错误 #16890703。

  • 当大量线程快速连续地打开和关闭 NDB API 中的块时， close_clnt()同步块关闭的内部函数等待的时间不够长，无法收到表明需要处理的潜在附加信号的自信号。这导致 ndb_mgmd过度使用 CPU ，并阻止其他线程打开或关闭其他块。此问题已通过更改函数轮询调用以等待特定条件被唤醒（即，当信号实际上已被执行时）得到解决。（漏洞 #21141495）

  • 以前，可以调用多个发送线程来处理对同一节点的发送；然后这些线程竞争同一个发送锁。虽然发送锁阻塞了额外的发送线程，但工作线程可以传递给其他节点。

    此问题已通过确保在已将活动发送线程分配给同一节点时不激活新发送线程来解决。此外，已经分配有活动发送线程的节点不再对其他已经活动的发送线程可见；也就是说，当一个发送线程当前分配给它时，这样的节点不再被添加到节点列表中。（缺陷 #20954804，缺陷 #76821）

  • 重做日志过载（API 节点配置参数）时挂起的操作排队DefaultOperationRedoProblemAction 可能会导致数据节点用完重做日志空间时超时（P_TAIL_PROBLEM错误）。现在，当重做日志已满时，节点会中止请求而不是将它们排队。（缺陷号 20782580）

    参考资料：另请参阅：Bug #20481140。

  • NDB事件缓冲区可与 对象一起使用Ndb以订阅表级行更改事件流。用户订阅现有事件；这会导致数据节点开始向对象发送事件数据信号 ( SUB_TABLE_DATA) 和纪元完成信号 ( SUB_GCP_COMPLETE) Ndb。 SUB_GCP_COMPLETE_REP在用于启动订阅的内部方法调用完成之前，信号可以到达并发接收器线程中执行。

    信号的执行SUB_GCP_COMPLETE_REP取决于SUMA桶（子数据流）的总数，但这可能尚未设置，导致当前问题，当用于跟踪 SUB_GCP_COMPLETE_REP信号的计数器 ( TOTAL_BUCKETS_INIT) 被发现设置为错误值时。现在TOTAL_BUCKETS_INIT进行测试以确保它在使用前已正确设置。（缺陷 #20575424，缺陷 #76255）

    参考资料：另请参阅：Bug #20561446、Bug #21616263。

  • NDBndb_index_stat_option当被查询的索引被标记为内部错误时，统计查询可能会被设置的错误延迟延迟 （默认 60 秒）。当对具有多个索引的表执行时，同样的潜在问题也可能导致 ANALYZE TABLE挂起，NDB其中一个或多个但不是所有索引发生内部错误。

    现在在这种情况下，将立即返回任何现有统计信息，而无需等待发现任何其他统计信息。（错误#20553313、错误#20707694、错误#76325）

  • 多线程调度程序直接从每个工作线程或从专用发送线程发送到远程节点，具体取决于集群的配置。此发送可能会传输所有、部分或不传输来自发送缓冲区的可用数据。虽然仍有未决的发送数据，但工作线程或发送线程继续尝试循环发送。现在会跟踪最近一次尝试执行发送时发送的数据的实际大小，并用于检测发送或工作线程是否缺少发送进度。当没有取得任何进展，并且没有其他未完成的工作时，调度程序会暂停 1 毫秒以释放 CPU 以供其他线程使用。（缺陷号 18390321）

    参考资料：另请参阅：Bug #20929176、Bug #20954804。

  • 在某些情况下，由于缺少表片段文件 ，尝试恢复以前备份的表失败并出现“未找到文件”错误。这是由于 NDB 内核块在尝试获取表描述时 BACKUP收到繁忙错误的结果，由于来自外部客户端的其他流量，并且没有重试该操作。

    此问题的修复为此类请求创建了两个单独的队列——一个用于内部客户端，如 BACKUP块或 ndb_restore，另一个用于外部客户端，如 API 节点——并优先考虑内部队列。

    请注意，使用 NDB API 的外部客户端应用程序（包括针对 SQL 节点运行的 MySQL 应用程序）总是希望通过稍后重试事务来处理 Busy错误；此预期不会因此问题的修复而改变。（漏洞 #17878183）

    参考资料：另请参阅：错误 #17916243。

  • 在启动时，API 节点（包括作为 SQL 节点运行的mysqld 进程）等待连接尚未加入集群的数据节点。现在他们只等待实际上已经加入集群的数据节点。

    在新数据节点加入现有集群的情况下，API 节点仍会尝试在 HeartbeatIntervalDbApi 几毫秒内连接到新数据节点。（漏洞 #17312761）

  • 在某些情况下，DBDICT区块无法处理GET_TABINFOREQ第一个信号后的重复信号，从而导致可能的节点故障和重启。这可以在为 设置足够高的值 MaxNoOfExecutionThreads 和足够低的值 后观察到LcpScanProgressTimeout。（错误#77433，错误#21297221）

  • 通过内部函数将 API 信号传递给正确客户端的客户端查找 TransporterFacade::deliver_signal()没有互斥保护，当其他客户端连接到同一TransporterFacade. （缺陷 #77225，缺陷 #21185585）

  • 当发送缓冲区成为限制资源时，可能会锁定发送缓冲区互斥锁，原因可能是发送缓冲区资源配置不足、通信缓慢或失败导致所有发送缓冲区耗尽的问题，或者接收器速度慢无法发送消耗发送的内容。在这种情况下，工作线程无法为信号分配发送缓冲区内存，并试图强制发送以释放空间，同时发送线程正忙于尝试发送到同一个或多个节点。所有这些线程都在争夺发送缓冲区互斥锁，这导致了已经描述过的锁，由看门狗报告为 Stuck in Send. 此修复分为两部分，在此处列出：

    1. 发送线程在获取发送缓冲区互斥量的同时不再持有全局发送线程互斥量；它现在在锁定发送缓冲区互斥锁之前释放全局互斥锁。这可以防止工作线程在这种情况下卡在发送中。

    2. 由发送线程完成的发送缓冲区互斥锁的锁定现在使用尝试锁。如果 try-lock 失败，发送到的节点将重新插入到发送节点列表的末尾，以便稍后重试。这消除了 Stuck in Send发送线程的条件。

    （缺陷 #77081，缺陷 #21109605）