MySQL NDB Cluster 7.5.21 是 MySQL NDB Cluster 7.5 的新版本,它基于 MySQL Server 5.7,包括NDB
存储引擎 7.5 版中的功能,并修复了最近在以前的 NDB Cluster 版本中发现的错误。
获取 MySQL NDB Cluster 7.5。 MySQL NDB Cluster 7.5 源代码和二进制文件可以从https://mysql.net.cn/downloads/cluster/获得。
有关 MySQL NDB Cluster 7.5 中所做更改的概述,请参阅 NDB Cluster 7.5 中的新增功能。
此版本还合并了以前 NDB Cluster 版本中所做的所有错误修复和更改,以及通过 MySQL 5.7.33 在主线 MySQL 5.7 中添加的所有错误修复和功能更改(请参阅MySQL 5.7.33 中的更改(2021-01- 18, 一般可用性) )。
-
NDB 客户端程序: 从此版本开始生效,MySQL NDB Cluster 自动安装程序 ( ndb_setup.py ) 已从 NDB Cluster 二进制文件和源代码分发中删除,不再受支持。(缺陷号 32084831)
参考资料:另请参阅:Bug #31888835。
ndbmemcache:
ndbmemcache
在之前版本的 NDB Cluster 中被弃用,现在已经从 NDB Cluster 中删除,不再受支持。(缺陷号 32106576)
NDB 复制: 发出后
RESET SLAVE ALL
,NDB
未能检测到副本已重新启动。(缺陷号 31515760)ORDER BY
使用index
访问方法(和不使用 ) 从下推连接检索排序结果时filesort
,SQL 节点有时会意外终止。(错误号 32203548)重做日志初始化的日志记录显示日志部分索引而不是日志部分编号。(缺陷号 32200635)
-
使用索引统计信息支持的最大索引键大小(3056 字节)会导致数据节点出现缓冲区问题。(缺陷号 32094904)
参考资料:另请参阅:Bug #25038373。
与写入重做日志记录一样,当当前用于写入全局检查点记录的文件变满时,写入切换到下一个文件。在新文件实际准备好接收记录之前,不应该发生这种切换,但没有进行检查以确保情况确实如此。这可能导致计划外的数据节点关闭使用ndb_restore从备份恢复数据。(缺陷号 31585833)
ndb_restore在重放删除 blob 值的备份日志时遇到间歇性错误;这是由于删除包含 blob 一个或多个值的主表行时删除了 blob 部分。这是通过修改 ndb_restore以使用异步 API 进行 blob 删除来解决的,这不会在删除 blob 主表行时触发 blob 部分删除(与同步 API 不同),因此主表的删除日志事件仅删除来自主表的行。(缺陷号 31546136)
-
当表创建模式事务准备好时,表处于状态,并在模式事务提交到块时
TS_CREATING
更改为 状态。如果在提交模式事务时充当 协调器的节点发生故障,则另一个节点开始接管协调器。处理此节点故障时会采取以下操作:TS_ACTIVE
DBDIH
DBDIH
DBDICT
向前滚动表创建模式事务并提交,导致涉及的表更改为TS_ACTIVE
状态。DBDIH
通过将故障节点上的活动表副本从存储的片段副本列表移动到另一个列表,开始从表中删除故障节点。
这些动作多次异步执行,交错时可能会导致竞争条件。因此,故障节点的副本所在的副本列表变得不确定,并且可能在恢复节点(即新协调器)和其他
DIH
参与节点之间有所不同。这种差异违反了了解在其他参与者的故障节点恢复过程中可以找到故障节点副本的列表的要求。为了解决这个问题,移动活动表副本现在不仅涵盖处于
TS_ACTIVE
状态的表,还包括处于TS_CREATING
(准备好的)状态的表,因为准备好的模式事务总是前滚。此外,正在中止的表创建模式事务的状态现在从
TS_CREATING
或更改TS_IDLE
为TS_DROPPING
,以避免出现任何竞争条件。(缺陷号 30521812)