-
NDB Cluster APIs: 当从集群连接启动事务时,
Table
模式Index
对象可能会传递给此事务以供使用。如果这些模式对象是从不同的连接(Ndb_cluster_connection
对象)获取的,则可以通过删除或断开所属连接随时删除它们。这可能会留下与无效模式对象的连接,这会导致 NDB API 应用程序在取消引用这些对象时失败。NdbTransaction::setSchemaObjectOwnerChecks()
为避免此问题,如果您的应用程序使用多个连接,您现在可以使用此版本中添加 的方法设置检查以检测在将模式对象传递给事务时连接之间的模式对象共享 。启用此检查后,将从连接中获取具有相同名称的模式对象,并将其与传递给事务的模式对象进行比较。匹配失败会导致应用程序失败并出现错误。(漏洞 #19785977) -
NDB Cluster API:在 MySQL NDB Cluster 7.2.11 中,hashmap 桶的默认数量(
DefaultHashMapSize
API 节点配置参数)从 240 增加到 3480,大大增加了内部DictHashMapInfo::HashMap
类型的大小。此类型在某些getTable()
调用中分配在堆栈上,这可能会导致 NDB API 用户出现堆栈溢出问题。为了避免这个问题,hashmap 现在是从堆中动态分配的。(漏洞 #19306793)
将 MySQL NDB Cluster 从 NDB 7.3 升级到 NDB 7.4 时,使用 NDB 7.4 数据节点二进制文件启动的第一个数据节点导致主节点(仍在运行 NDB 7.3)失败并出现错误 2301,然后在启动阶段 5 期间自身失败。(漏洞 #20608889)
NDB 事件缓冲区分配中的内存泄漏导致每个时期都泄漏一个事件。(由于一个 SQL 节点使用 3 个事件缓冲区,每个 SQL 节点每个时期泄漏 3 个事件。)这意味着 MySQL NDB Cluster mysqld泄漏的内存量与大小成反比
TimeBetweenEpochs
——也就是说,此参数的值越小,单位时间内泄漏的内存量就越大。(缺陷号 20539452)在某些平台上错误地报告了
Ndb_last_commit_epoch_server
和 状态变量 的值 。Ndb_last_commit_epoch_session
为更正此问题,这些值现在在内部存储为long long
,而不是long
。(缺陷号 20372169)从备份还原 MySQL NDB Cluster 时,在另一个节点还原过程中发生故障并重新启动的节点变得无响应,随后导致 ndb_restore失败并退出。(缺陷号 20069066)
-
当数据节点发生故障或正在重新启动时,同一节点组中的其余节点会向订阅者重新发送它们确定故障节点尚未发送的任何数据。通常,当一个数据节点(实际上是
SUMA
内核块)发送了属于它负责的一个时期的所有数据时,它会向SUB_GCP_COMPLETE_REP
所有订阅者发送一个信号和一个计数,每个订阅者都以一个SUB_GCP_COMPLETE_ACK
. 什么时候SUMA
从所有订阅者收到此确认后,它会将此报告给同一节点组中的其他节点,以便他们知道在后续节点发生故障的情况下无需重新发送此数据。如果一个节点在所有订阅者发送此确认之前但在同一节点组中的所有其他节点从故障节点接收到它之前发生故障,则某些时期的数据可能会发送(并报告为完整)两次,这可能会导致计划外关闭。此问题的修复增加了
SUB_GCP_COMPLETE_ACK
标识符列表报告的计数,接收器可以使用该列表来跟踪哪些桶已完成,并忽略为已完成的桶报告的任何重复项。(漏洞#17579998) 节点重新启动后,该
ndbinfo.restart_info
表未包含预期的新行。(缺陷 #75825,缺陷 #20504971)SHOW CREATE TABLE
包含外键约束的表 的输出格式NDB
与等效表的输出格式不匹配InnoDB
,这可能会导致某些第三方应用程序出现问题。(错误#75515,错误#20364309)ALTER TABLE
包含针对表的注释和分区选项 的 语句NDB
导致执行该语句的 SQL 节点失败。(错误#74022,错误#19667566)