MySQL NDB Cluster 8.0.13 是 NDB 8.0 的新开发版本,它基于 MySQL Server 8.0,包括NDB
存储引擎 8.0 版中的功能,并修复了最近在以前的 NDB Cluster 版本中发现的错误。
获取 NDB Cluster 8.0。 NDB Cluster 8.0 源代码和二进制文件可以从 https://mysql.net.cn/downloads/cluster/获得。
有关 NDB Cluster 8.0 中所做更改的概述,请参阅 NDB Cluster 中的新增功能。
此版本还合并了以前 NDB Cluster 版本中所做的所有错误修复和更改,以及通过 MySQL 8.0.13 在主线 MySQL 8.0 中添加的所有错误修复和功能更改(请参阅MySQL 8.0.13 中的更改(2018-10- 22,一般可用性))。
-
重要变更;NDB Disk Data: 对表中Disk Data文件的信息显示做了如下改动
INFORMATION_SCHEMA.FILES
:表空间和日志文件组不再显示在
FILES
表中。(这些构造实际上不是文件。)每个数据文件现在由表中的一行表示
FILES
。每个撤消日志文件现在在该表中也仅由一行表示。(以前,每个数据节点上的每个文件的每个副本都显示一行。)-
对于数据文件或undo log文件对应的行,节点ID和undo log buffer信息不再显示在表的
EXTRA
列中FILES
。重要的在 NDB 8.0.15 中恢复了撤消日志缓冲区信息的删除。(缺陷 #92796,缺陷 #28800252)
-
重要变更;NDB 客户端程序:删除了perror 的弃用
--ndb
选项 。改为使用ndb_perror从 错误代码中获取错误消息信息(缺陷 #81705,缺陷 #23523957)NDB
参考资料:另请参阅:Bug #81704、Bug #23523926。
-
重要变化: 从这个版本开始,MySQL NDB Cluster 在新的统一发布模型下与标准 MySQL 8.0 服务器并行开发,具有以下特性:
NDB 8.0 是在 MySQL 8.0 源代码树中开发、构建和发布的。
NDB Cluster 8.0 版本的编号方案遵循 MySQL 8.0 的方案,从当前的 MySQL 版本(8.0.13)开始。
-
使用 NDB 支持构建源附加 到mysql
-cluster
返回的版本字符串,如下所示:-V
shell≫ mysql -V mysql Ver 8.0.13-cluster for Linux on x86_64 (Source distribution)
NDB 二进制文件继续显示 MySQL 服务器版本和 NDB 引擎版本,如下所示:
shell> ndb_mgm -V MySQL distrib mysql-8.0.13 ndb-8.0.13-dmr, for Linux (x86_64)
在 MySQL Cluster NDB 8.0 中,这两个版本号始终相同。
要构建支持 NDB Cluster 的 MySQL 8.0.13(或更高版本)源,请使用 CMake 选项
-DWITH_NDBCLUSTER
。 NDB Cluster API: 添加了
Table
方法getExtraMetadata()
和setExtraMetadata()
.INFORMATION_SCHEMA
表现在填充了 MySQL 集群表的表空间统计信息。(漏洞#27167728)-
现在可以指定一组核心用于 I/O 线程执行离线多线程构建有序索引,而不是正常的 I/O 任务,如文件 I/O、压缩或解压缩。“离线”在此上下文中是指在未写入父表时执行的有序索引的构建;这种构建发生在
NDB
集群执行节点或系统重启时,或者作为使用 ndb_restore--rebuild-indexes
从备份恢复集群的一部分。此外,离线索引构建工作的默认行为被修改为使用 ndbmtd可用的所有内核,而不是将其自身限制为为 I/O 线程保留的内核。这样做可以改善重启和恢复时间以及性能、可用性和用户体验。
此增强功能的实现方式如下:
默认值
BuildIndexThreads
从 0 更改为 128。这意味着离线有序索引构建现在默认是多线程的。的默认值
TwoPassInitialNodeRestartCopy
从更改false
为true
。这意味着初始节点重启首先将所有数据从“活” 节点复制到正在启动的节点——不创建任何索引——离线构建有序索引,然后再次将其数据与活节点同步,即同步两次和在两个同步之间离线构建索引。这会导致初始节点重启的行为更像节点的正常重启,并减少构建索引所需的时间。idxbld
为配置参数定义了 一个新的线程类型 ( )ThreadConfig
,以允许将离线索引构建线程锁定到特定的 CPU。
此外,现在通过以下两个标准 来区分“ ThreadConfig ”
NDB
可访问的线程类型:该线程是否为执行线程。
main
,ldm
,recv
,rep
,tc
, 和类型send
的线程是执行线程;线程类型io
、watchdog
和idxbld
不是。给定任务的线程分配是永久的还是临时的。
idxbld
目前,除永久性之外的 所有线程类型 。
有关其他信息,请参阅手册中的参数说明。(错误#25835748,错误#26928111)
在执行 NDB 备份时,该 表现在
ndbinfo.logbuffers
显示有关每个数据节点上备份进程的缓冲区使用情况的信息。这被实现为反映除了REDO
和之外的两种新日志类型的行DD-UNDO
。其中一行的日志类型为BACKUP-DATA
,它显示备份期间用于将片段复制到备份文件的数据缓冲区量。另一行的日志类型为BACKUP-LOG
,它显示备份期间用于记录备份开始后所做更改的日志缓冲区的数量。这些log_type
行中的每一行都显示在logbuffers
集群中每个数据节点的表。具有这两种日志类型的行仅在当前正在进行 NDB 备份时才会出现在表中。(缺陷号 25822988)-
添加了
ODirectSyncFlag
数据节点的配置参数。启用后,数据节点会将所有已完成的文件系统写入重做日志,就好像它们是使用fsync
.(缺陷号 25428560)
添加了ndbd和ndbmtd
--logbuffer-size
的选项,用于调试大量日志消息。这控制了数据节点日志缓冲区的大小;默认值 (32K) 用于正常操作。(漏洞 #89679,漏洞 #27550943)-
在 NDB 8.0 之前,所有字符串散列都是基于首先将字符串转换为规范化形式,然后对生成的二进制图像进行 MD5 散列。这可能会导致一些性能问题,原因如下:
规范化的字符串总是用空格填充到它的全长。对于 a
VARCHAR
,这通常涉及添加比原始字符串中的字符更多的空格。字符串库未针对此空间填充进行优化,并且在某些用例中增加了相当大的开销。
字符集之间的填充语义各不相同,其中一些字符集没有填充到它们的全长。
即使没有空格填充,转换后的字符串也会变得非常大;一些 Unicode 9.0 归类可以将单个代码点转换为 100 个字节或更多的字符数据。
随后的 MD5 散列主要由空格填充组成,效率不是特别高,可能会因刷新 L1 缓存的重要部分而导致额外的性能损失。
排序规则提供了自己的哈希函数,可以直接对字符串进行哈希处理,而无需先创建规范化字符串。此外,对于 Unicode 9.0 归类,哈希值的计算没有填充。
NDB
现在,每当对标识为使用 Unicode 9.0 排序规则的字符串进行哈希处理时,都会利用此内置函数。因为,对于其他排序规则,存在在转换后的字符串上进行散列分区的现有数据库,因此
NDB
继续采用以前的方法对使用这些的字符串进行散列,以保持兼容性。(漏洞 #89609,漏洞 #27523758)参考资料:另请参阅:Bug #89590、Bug #27515000、Bug #89604、Bug #27522732。
-
在 NDB 7.6 及更早版本中创建的表包含压缩
.frm
文件形式的元数据,MySQL 8.0 不再支持该格式。为了方便在线升级到 NDB 8.0,NDB
执行此元数据的即时转换并将其写入 MySQL 服务器的数据字典,这使得 NDB Cluster 8.0 中的mysqld可以使用该表,而不会阻止后续使用该表以前版本的NDB
软件。重要的一旦在 NDB 8.0 中修改了表的结构,其元数据将使用数据字典存储,NDB 7.6 及更早版本将无法再访问它。
此增强功能还可以将
NDB
使用早期版本制作的备份还原到运行 NDB 8.0(或更高版本)的集群。
重要变更;NDB 磁盘数据: 可以发出
CREATE TABLE
引用不存在的表空间的语句。现在这样的声明失败并出现错误。(缺陷 #85859,缺陷 #25860404)-
重要变更;NDB 复制: 因为 MySQL 服务器现在
RESET MASTER
使用全局读锁执行,所以与 NDB Cluster 一起使用时此语句的行为在以下两个方面发生了变化:不再保证是同步的;也就是说,现在有可能
RESET MASTER
在二进制日志轮转之后才记录紧接在发出之前的读取。现在,无论语句是在写入二进制日志的同一个 SQL 节点上发出,还是在同一集群中的不同 SQL 节点上发出,它现在的行为都是一样的。
笔记SHOW BINLOG EVENTS
、 和大多数数据定义语句继续以同步方式运行FLUSH LOGS
,就像它们在以前的 版本中所做的那样。NDB
(缺陷 #89976,缺陷 #27665565)
重要更改: 语句选项
NDB
支持以下三个值中的任何一个、和 。以前,除了这些之外的任何值都被接受但导致 被使用。现在,尝试创建表的语句失败并出现错误(如果使用),并且没有列出的三个值之一。(漏洞 #88803,漏洞 #27230898)CREATE TABLE
ROW_FORMAT
DEFAULT
FIXED
DYNAMIC
DYNAMIC
CREATE TABLE
NDB
ROW_FORMAT
微软Windows; ndbinfo 信息数据库:
RESTART
在 Windows 平台上用于生成和重新启动 mysqld 的监视进程的进程 ID现在在ndbinfo.processes
表中显示为angel_pid
. (缺陷 #90235,缺陷 #27767237)-
NDB Cluster APIs: 示例 NDB API 程序
ndbapi_array_simple
并且ndbapi_array_using_adapter
在执行后没有执行清理;另外,示例程序ndbapi_simple_dual
没有检查本示例使用的表是否已经存在。由于这些问题,这些示例中没有一个可以连续运行多次。刚刚描述的问题已在示例源中得到纠正,并且 NDB API 文档中的相关代码清单已更新以匹配。(错误号 27009386)
-
NDB Cluster APIs: 之前修复的一个问题,在部分重启期间多个数据节点的故障可能导致 API 节点失败,在继续之前没有正确检查关联
NdbReceiver
对象的有效性。现在在这种情况下,无效对象会触发对无效信号的处理,而不是节点故障。(漏洞 #25902137)参考资料:此问题是 Bug #25092498 的回归。
NDB Cluster API:
setBound()
在用于指定NULL
边界 时返回不正确的结果,通常是空结果集 这个问题似乎是由 gcc 中的问题引起的,仅限于使用此方法的旧版本(不使用NdbRecord
)的情况,并且通过在旧实现中重写有问题的内部逻辑来解决。(漏洞 #89468,漏洞 #27461752)-
NDB Cluster APIs: 发布的 NDB API 对象保存在一个或多个
Ndb_free_list
结构中以供以后重用。每个列表还跟踪从它那里夺取的所有对象,并确保这些对象最终被释放回给它。如果内部函数NdbScanOperation::init()
失败,则可能会泄漏NdbApiSignal
已分配的NdbOperation
现在在这种情况下,NdbScanOperation::release()
调用以释放由失败分配的任何对象,NdbScanOperation
然后再将其返回到空闲列表。此修复程序还处理了与 类似的问题
NdbOperation::init()
,其中失败的调用也可能会泄漏信号。(漏洞 #89249,漏洞 #27389894) NDB Cluster APIs: 删除了未使用的
TFSentinel
实现类,它在 32 位系统上引发了编译器警告。(缺陷 #89005,缺陷 #27302881)NDB Cluster APIs: 并不总是检查通过 API 调用创建线程是否成功,这在某些情况下可能导致超时。(漏洞 #88784,漏洞 #27225714)
NDB Cluster API: 文件
storage/ndb/src/ndbapi/ndberror.c
已重命名为ndberror.cpp
. (漏洞 #87725,漏洞 #26781567)-
ndbinfo 信息数据库: 一些表使用的每个片段的已提交行和已提交操作的计数是
ndbinfo
从DBACC
块中获取的,但由于提交信号可能无序到达,瞬态计数器值可能为负。例如,如果一个事务在同一行上包含多个交错的插入和删除操作,则可能会发生这种情况;在这种情况下,删除操作的提交信号可能先于相应插入操作的提交信号到达,从而导致DBACC
.此问题已通过使用保留在中的已提交行的计数来
DBTUP
解决,这些行没有此问题。(错误#88087,错误#26968613) NDB 客户端程序: 当传递无效的连接字符串时, ndb_mgm客户端并不总是在退出前释放所有使用的内存。(漏洞 #90179,漏洞 #27737906)
NDB 客户端程序: ndb_show_tables并不总是释放它使用的所有内存。(缺陷 #90152,缺陷 #27727544)
NDB 客户端程序:在 Unix 平台上,当ndb_mgmd安装在默认目录以外的目录中 时,自动安装程序无法停止集群(漏洞 #89624,漏洞 #27531186)
NDB 客户端程序: 自动安装程序没有提供设置
ServerPort
参数的机制。(漏洞 #89623,漏洞 #27539823)MySQL NDB ClusterJ: 当使用 ClusterJ 查询包含一个
BLOB
或一个TEXT
字段的表以获得不存在的记录时,抛出异常( “该方法在当前 blob 状态下无效”)。(漏洞#28536926)MySQL NDB ClusterJ:
scanIndex()
ClusterJ 意外退出,因为在类的函数中 没有错误处理 方法在ClusterTransactionImpl
内部返回给它的 null。(错误#27297681,错误#88989)scanIndex()
ndbTransaction
-
本地检查点并不总是
DROP TABLE
正确处理操作。(漏洞 #27926532)参考资料:此问题是 Bug #26908347、Bug #26968613 的回归。
在某些情况下,当
DBTC
块中的事务中止时,仍然存在指向尚未引用计数的操作记录的触发记录的链接,但是当这样的操作记录被释放时,触发引用计数仍然递减。(缺陷号 27629680)-
内部缓冲区在释放后立即被重用可能会导致数据节点意外关闭。(漏洞#27622643)
参考资料:另请参阅:Bug #28698831。
-
联机备份由
NDB
模糊数据以及重做和撤消日志组成。要恢复到一致的状态,有必要确保日志包含跨越模糊数据部分捕获和一致快照点的所有更改。这是通过在数据捕获完成后等待通过 GCI 边界来实现的,但在停止更改日志记录和在备份元数据中记录停止 GCI 之前。在恢复时,日志会重播到停止 GCI,将系统恢复到一致停止 GCI 时的状态。当在负载下,可能会选择出现得太早且未跨越所有捕获数据的 GCI 边界时,就会出现问题。这可能会导致恢复备份时出现不一致;这些可能会被视为破坏约束或损坏的
BLOB
条目。现在选择停止 GCI,以便它跨越模糊数据捕获过程的整个持续时间,以便备份日志始终包含给定停止 GCI 内的所有数据。(漏洞#27497461)
参考资料:另请参阅:Bug #27566346。
-
对于
NDB
表,当外键作为 DDL 语句的一部分添加或删除时,所有引用的父表的外键元数据应重新加载到连接到集群的所有 SQL 节点上的处理程序中,但这仅在执行语句的mysqld 。因此,任何依赖于来自相应父表的外键元数据的后续查询都可能返回不一致的结果。(漏洞#27439587)参考资料:另请参阅:Bug #82989、Bug #24666177。
ANALYZE TABLE
在大型低基数表上使用过多的 CPU。(漏洞#27438963)-
使用非常大的列表的查询
IN
没有得到正确处理,这可能导致数据节点故障。(缺陷号 27397802)参考资料:另请参阅:Bug #28728603。
-
数据节点过载在某些情况下可能会导致数据节点意外关闭,从而导致所有数据节点与管理和节点断开连接。
这是由于
API_FAILREQ
在节点故障之前不是最后接收到的信号的情况。作为此修复的一部分,事务协调
SCAN_TABREQ
器对处于不正确状态的信号 的处理ApiConnectRecord
也得到了改进。(漏洞 #27381901)参考资料:另请参阅:Bug #47039、Bug #11755287。
在双节点集群中,当 ID 最低的节点开始使用
--nostart
时,API 客户端无法连接,失败并显示Could not alloc node id at HOST port PORT_NO: No free node id found for mysqld(API)。(漏洞 #27225212)-
MaxNoOfExecutionThreads
在没有初始系统重启的情况下进行 更改 会导致数据节点意外关闭。(缺陷号 27169282)参考资料:此问题是 Bug #26908347、Bug #26968613 的回归。
-
在大多数情况下,尤其是在错误情况下,
NDB
命令行程序在退出时无法释放选项处理所使用的内存,并且无法调用ndb_end()
. 这是通过删除内部方法ndb_load_defaults()
和ndb_free_defaults()
from 来 解决的storage/ndb/include/util/ndb_opts.h
,并将它们替换为一个Ndb_opts
自动释放此类资源的类作为其析构函数的一部分。(缺陷号 26930148)参考资料:另请参阅:Bug #87396、Bug #26617328。
INFORMATION_SCHEMA.FILES
当表包含一个ORDER BY
子句时,对该表 的查询 未返回任何结果。(漏洞#26877788)ClusterJ 无法连接到使用 utf8mb4_800_ci_ai 作为其默认连接字符集的 MySQL 节点。此外,ClusterJ 在处理字符集数为 255 或更大的表时意外退出。此修复更正了这两个问题。(漏洞 #26027722)
-
在重新启动期间
DBLQH
,从一个或多个重做日志文件加载它管理的每个重做日志部分的重做日志部分元数据。由于每个文件的元数据容量有限,因此必须查阅的文件数量取决于重做日志部分的大小。这些文件按顺序打开、读取和关闭,但一个文件的关闭与下一个文件的打开同时发生。在文件关闭速度很慢的情况下,每个重做日志部分可能同时打开超过 4 个文件;由于这些文件是使用该
OM_WRITE_BUFFER
选项打开的,因此在这种情况下,每个部分分配了 4 个以上的写入缓冲区块。写缓冲池不是无限的;如果所有重做日志部分都处于相似状态,则池已耗尽,导致数据节点关闭。这个问题通过避免
OM_WRITE_BUFFER
在元数据重新加载期间使用来解决,这样每个日志文件部分超过 4 个重做日志文件的任何瞬时打开都不会再导致数据节点失败。(错误号 25965370) -
在某些情况下,数据节点在执行期间不必要地重新启动
ALTER TABLE... REORGANIZE PARTITION
。(漏洞#25675481)参考资料:另请参阅:Bug #26735618、Bug #27191468。
-
竞争条件有时会在传输器异步断开连接和重新连接期间发生,而其他线程同时将信号数据插入发送缓冲区,导致集群意外关闭。
作为解决此问题的工作的一部分,Transporter Registry 在准备发送时使用的内部模板函数被重构为使用可能或不太可能的逻辑来加快执行速度,并删除了一些对 NULL 的重复检查。(错误#24444908,错误#25128512)
参考资料:另请参阅:Bug #20112700。
ndb_restore有时记录的数据文件和日志文件进度值远大于 100%。(缺陷号 20989106)
从内部函数中删除了不需要的调试打印输出
ha_ndbcluster::copy_fk_for_offline_alter()
。(缺陷 #90991,缺陷 #28069711)内部函数
BitmaskImpl::setRange()
设置比指定的少一位。(缺陷 #90648,缺陷 #27931995)-
将一行插入到
NDB
具有自引用外键的表中,该外键引用了表上的唯一索引而不是主键,失败并返回ER_NO_REFERENCED_ROW_2
。这是因为在NDB
更新唯一索引之前检查了外键约束,导致约束检查无法使用索引来定位行。现在,在这种情况下,NDB
等到所有唯一索引值都已更新,然后再检查插入行的外键约束。(缺陷 #90644,缺陷 #27930382)参考资料:另请参阅:Bug #91965、Bug #28486390。
删除
register
了 NDB Cluster 源中对 C++ 存储类的所有引用;使用此说明符(在 C++11 中已弃用并在 C++17 中删除)在使用最新编译器构建时会引发警告。(缺陷 #90110,缺陷 #27705985)-
无法 使用set to 、 或 来创建
NDB
表 。(缺陷 #89811,缺陷 #27602352)PARTITION_BALANCE
FOR_RA_BY_LDM_X_2
FOR_RA_BY_LDM_X_3
FOR_RA_BY_LDM_X_4
参考:此问题是 Bug #81759、Bug #23544301 的回归。
为具有多个数据节点的集群向全局配置文件添加一个
[tcp]
或[shm]
部分导致默认 TCP 连接丢失到使用单个部分的节点。(漏洞 #89627,漏洞 #27532407)删除了配置文件解析器中的内存泄漏。(漏洞 #89392,漏洞 #27440614)
-
修复了一些隐式失败警告、未初始化值引发的警告以及
NDB
使用 GCC 7.2.0 编译时遇到的其他警告。(错误#89254、错误#89255、错误#89258、错误#89259、错误#89270、错误#27390714、错误#27390745、错误#27390684、错误#27390816、错误#27396662)参考资料:另请参阅:Bug #88136、Bug #26990244。
节点连接状态并不总是
ClusterMgr
在报告断开连接后立即正确报告。(缺陷 #89121,缺陷 #27349285)由于在执行辅助发送时重用了用于发送线程的代码,所有本地释放发送缓冲区都被释放到全局池中,这导致本地发送缓冲池的预期级别被忽略。现在发送线程和辅助工作线程遵循它们自己的策略来维护它们的本地缓冲池。(错误#89119,错误#27349118)
当
PGMAN
块使用 获取新Page_request
记录seizeLast
时,未检查其返回值,这可能导致访问无效内存。(缺陷 #89009,缺陷 #27303191)TCROLLBACKREP
DBTC
内核块未正确处理信号。(漏洞 #89004,漏洞 #27302734)当发送优先级 A 信号时,我们现在确保显式初始化未决信号的数量。(错误#88986,错误#27294856)
内部函数
ha_ndbcluster::unpack_record()
没有执行正确的错误处理。(漏洞 #88587,漏洞 #27150980)CHECKSUM
表不支持NDB
,但这并没有反映在表的CHECKSUM
列中INFORMATION_SCHEMA.TABLES
,在这种情况下可能会假定一个随机值。现在此列的值始终设置NULL
为NDB
表,就像表一样InnoDB
。(漏洞 #88552,漏洞 #27143813)删除了运行ndb_mgm -e "CLUSTERLOG ..."时检测到的内存泄漏。(错误#88517,错误#27128846)
终止时,ndb_config没有释放它使用的所有内存。(漏洞 #88515,漏洞 #27128398)
ndb_restore在退出前没有正确释放内存。(漏洞 #88514,漏洞 #27128361)
在某些情况下,从 API 节点并行使用多个对象时,即使请求来自
Ndb
API 节点,从块引用中提取的块编号与块的编号DBLQH
相同 。SUMA
由于这种歧义,DBLQH
将来自 API 节点的请求误认为是来自SUMA
区块的请求而失败。这是通过在检查块号之前检查节点 ID 来解决的。(缺陷 #88441,缺陷 #27130570)-
完全在半连接的具体化部分内的连接不会被推送,即使它本来可以被推送。此外,
EXPLAIN
没有提供有关为什么未推送连接的信息。(错误#88224,错误#27022925)参考资料:另请参阅:Bug #27067538。
-Werror
构建源代码时 引发的所有已知编译器警告NDB
均已修复。(漏洞 #88136,漏洞 #26990244)-
当重复剔除算法用于评估半连接时,结果有缺失的行。(错误#88117,错误#26984919)
参考资料:另请参阅:Bug #87992、Bug #26926666。
NDB
没有用 GCC 7 编译。(错误 #88011,错误 #26933472)松散扫描中使用的表可以用作推送连接查询中的子项,从而可能导致不正确的结果。(错误#87992,错误#26926666)
当在查询计划中表示物化半连接时,MySQL 优化器插入额外的
QEP_TAB
和JOIN_TAB
对象来表示对物化子查询结果的访问。连接下推分析器没有为这些正确设置其内部数据结构,而是让它们未初始化。这意味着以后使用任何引用物化半连接的项目对象tableno
在访问 64 位位tableno
掩码时会访问已初始化的列,可能引用超出其末尾的点,从而导致 SQL 节点意外关闭。(漏洞 #87971,漏洞 #26919289)在某些情况下,在发送带有关闭标志的
SCAN_FRAGCONF
信号后会收到信号,从而清除计时器。SCAN_FRAGREQ
发生这种情况时,下一个SCAN_FRAGREF
到达会导致时间跟踪失败。SCAN_FRAGREF
现在在这种情况下,会在处理消息之前检查已清除的计时器 。(错误#87942,错误#26908347)-
在删除 中的元素
Dbacc
或在哈希表扩展或缩减期间移动它时,使用的方法 (getLastAndRemove()
) 可以返回对已释放页面上已删除元素的引用,稍后可以从调用它的函数中引用该元素。这是由于 NDB 7.6.2 中动态索引内存的实现带来的变化;以前,该页面始终属于单个Dbacc
实例,因此访问它是安全的。更改后不再是这种情况;释放的页面Dbacc
可以直接放入全局页面池中,然后任何其他线程都可以分配它。现在我们确保新释放的页面
Dbacc
保留在当前Dbacc
实例中,而不是直接交给全局页面池。此外,已删除对已发布页面的引用;受影响的内部方法现在按值而不是按引用返回最后一个元素。(漏洞 #87932,漏洞 #26906640)参考资料:另请参阅:Bug #87987、Bug #26925595。
创建不存在冲突检测函数的表时,
NDB
返回不正确的错误信息。(漏洞 #87628,漏洞 #26730019)ndb_top构建失败,错误 为“HAVE_NCURSESW_H”未定义。(缺陷 #87035,缺陷 #26429281)
在一个配置有一个 MySQL 服务器的 MySQL 集群中,当创建和使用
NDB
具有非存储生成列的表时发生二进制日志失败。只有当产品是在调试支持下构建时才会出现问题。(漏洞 #86084,漏洞 #25957586)STORAGE MEMORY
可以使用不存在 的表空间创建或更改表而不会产生任何错误。这样的操作现在会ER_TABLESPACE_MISSING_WITH_NAME
按预期失败并出现 Error 3510 。(错误#82116,错误#23744378)ndb_restore 没有打印 值的尾随 0。(漏洞 #65560,漏洞 #14198580)
--print-data
--hex
LONGVARBINARY
当内部函数
ha_ndbcluster::copy_fk_for_offline_alter()
检查应该从中删除外键的表上的依赖对象时,它没有对外键执行任何过滤,这使得它有可能尝试检索索引或触发器,从而导致虚假错误 723(没有这样的表)。