NDB客户端程序:对此版本有效，MySQL NDB集群自动安装程序（ndb_setup.py）已被弃用并在未来版本的NDB集群中删除。（bug＃31888835）

ndbmemcache:ndbmemcache已在本版本中弃用，并计划在下一个版本中移除。(错误# 31876970)

重要的变化:的Ndb_metadata_blacklist_size状态变量被重命名为ndb_metadata_excluded_count.。（bug＃31465469）

包装：提出了以下改进服务器最小RPM for NDB Cluster and the NDB Cluster Docker image:

（bug＃31838832）

NDB复制:对包含MySQL类型列的行进行批处理更新团,博尔布,LONGBLOB,文本,媒体下文字， 和量变(”团”)通过NDB Cluster。这影响到插入,更新， 和删除以下任何一种类型的陈述：

这是通过大大减少SQL或其他API节点之间所需的往目的数量和副本群集中的数据节点，在某些情况下大大减少了10个或更多的。

其他SQL陈述还可以看到这些改进的性能优势。此类陈述包括加载数据INFILE.和创建表……选择……在表现上包含一个或多个BLOB列的表上。另外，一个ALTER TABLE ......引擎= NDB语句，它改变了之前使用的表的存储引擎NDB.并且包含一个或多个Blob列的文件也可能比实现此增强之前执行得更有效率。

一些更新Blob列的SQL语句的性能并没有通过这种增强得到明显的改善，因为它们需要扫描表Blob列，这会打乱批处理。这些声明包括这里列出的类型:

仅修改类型列的语句TINYBLOB或者TinyText.(或两者)不受此增强的影响。

要最大限度地利用这种改进，您必须启用slave_allow_batching.。还建议您增加与之使用的值--ndb批量大小和--ndb-blob-write-batch-bytesMySQL服务器选项最小化复制集群应用epoch事务所需的往返次数。(错误# 27765184)

添加了CMake选项NDB_UTILS_LINK_DYNAMIC，允许动态连接NDB实用程序ndbclient。(错误# 31668306)

IPv6地址现在支持连接到管理节点和数据节点，包括管理节点和数据节点与SQL节点之间的连接。要实现IPv6寻址功能，集群所在的操作平台和网络必须支持IPv6。主机名解析到IPv6地址必须由操作平台提供(这与使用IPv4寻址时相同)。

不建议在同一集群中混合使用IPv4和IPv6地址，但在以下情况下也可以这样做- 地址不用于ndb_mgmd:

从不支持IPv6寻址到这样的版本的NDB版本的升级时，网络必须支持IPv4和IPv6。必须首先执行软件升级;在此之后，您可以更新用于的IPv4地址config.ini配置文件。最后，为了使配置更改生效，需要对集群执行一次系统重启。

重要的变化;NDB集群api:Node.js的NDB集群适配器是基于运行时的一个过时版本构建的。现在它是使用Node.js 12.18.3构建的，并且只有该版本或更高版本的Node.js被支持NDB.。（bug＃31783049）

重要的变化:为了同步排除的元数据对象，有必要纠正潜在的问题(如果有的话)，然后再次触发对象的同步。这可以通过发现单个表来实现，但随着表和SQL节点数量的增加，这种方法伸缩性不好。也可以通过将SQL节点重新连接到集群来实现，但是这样做也会引起额外的开销。

若要修复此问题，将清除由于同步失败而排除的数据库对象列表ndb_metadata_sync.由用户启用。这使得所有这样的对象在随后的检测运行中都有资格进行同步，从而简化了对所有被排除的对象重新尝试同步的过程。

此修复程序还删除了要重试的对象的验证，以前在每次检测运行开始时都要进行验证。因为这些对象只有当ndb_metadata_sync.已启用，在禁用此变量时清除要重回的对象列表，发出所有更改已同步的信号。（bug＃31569436）

包装：NDB Cluster中包含的Dojo库已经升级到版本1.15.4。(错误# 31559518)

NDB磁盘数据：ndbmtd在还原操作期间无法完成对日志文件组的查找时，有时会意外终止。(错误# 31284086)

NDB磁盘数据：在创建足够的磁盘数据对象以填充表空间后升级具有3或4个副本的群集时，并且在磁盘数据表上执行插入时，试图阻止某些数据节点导致其他数据节点不正确地退出。（bug＃30922322）

NDB复制:在基于UNIX的操作系统上，可以通过发送一个二进制日志来刷新SIGHUP给服务器发信号，但是NDBCLUSTER期望一个SQL语句fl,重启,或显示BINLOG的事件只要。（bug＃31242689）

NDB集群api:在某些情况下，表:: getColumn（）方法返回错误的列对象。当一个表列的完整名称是另一个表列的名称的前缀时，或者当两个列的名称具有相同的散列值时，就会发生这种情况。(错误# 31774685)

NDB集群api:使用blob可以使无效的NDB API方法调用序列。这是因为一些方法调用隐式地导致事务执行内联，以处理blob部分和其他问题，这可能导致用户定义的操作没有得到正确处理，因为使用了方法执行与blob相关的操作，而用户定义的blob操作仍然悬而未决。在这种情况下，NDB会抛出一个新的错误4558在此调用之前必须执行挂起的blob操作。（bug＃27772916）

ndb_restore.——remap-column没有处理包含的列空值值正确。现在，使用与此选项一起使用的映射函数指定的任何偏移量都不应用于空值,所以空值按预期保存。(错误# 31966676)

的ndb_print_backup_file实用程序不尊重行数据的字节顺序。该工具现在对行页信息执行字节交换，以确保在大端和小端平台上得到相同的结果。(错误# 31831438)

参考:参见Bug #32470157。

在某些情况下，从先前的NDB集群版本升级到8.0.18到稍后的一个情况下，写作sysfile.(见NDB集群数据节点文件系统目录)，从它读取不能正确工作。当显式地将节点组赋给数据节点时(使用节点组参数);节点组分配可以自发地更改，甚至可以添加配置文件中未引用的节点组。这是由于版本2的问题sysfile.格式在NDB 8.0.18中引入。（bug＃31828452，bug＃31820201）

参考:参见Bug #31726653。

在配置文件中遇到数据节点后使用节点组= 65536，管理服务器停止分配数据节点节点组设置为节点组。(错误# 31825181)

某些情况下的数据节点经历了致命的记忆损坏PGMAN由于无效假设页面为32KB对齐，当实际上，它们通常与系统页面大小（根据平台相比）对齐时。（bug＃31768450，bug＃31773234）

修复了在NDB 8.0.20中引入的拼写错误的定义，其使内部功能用于控制自适应旋转不运行的内部功能。（bug＃31765660）

当在撤消日志恢复期间执行撤消日志记录时，当碰到页面缓存丢失时，可以多次使用以前的撤消日志记录。(错误# 31750627)

当在模式分发期间，当协调器仍在等待参与者时发生SQL节点或集群关闭时，模式分发就会中途中止，但任何行都不会进入ndb_schema_result.与此模式操作有关未清除。如果具有使用相同节点ID的客户端的DDL操作源自来自客户端的DDL操作，则左侧打开这些行可能与参与者的未来回复发生冲突。

要保持这种情况，我们现在可以清除所有这些行ndb_schema_result.在NDB.二进制日志设置。这可以确保没有正在进行的DDL分发，以及保留在ndb_schema_result.表已经过时了。（bug＃31601674）

MySQL集群自动安装程序的帮助信息显示不正确的版本信息。(错误# 31589404)

在某些罕见的情况下，NDB.错过检查完成本地检查点，将其未完成，这意味着无法执行后续的本地检查点。（bug＃31577633）

数据定义语句有时涉及从表中读取或写入多行(或同时写入多行);NDBCLUSTER开始一个NdbTransaction执行这些操作。当这样的声明回滚时，NDBCLUSTER控件回滚之前，试图回滚模式更改NdbTransaction结束它;这导致了在群集等待的同时无限期地悬挂NdbTransaction对象在能够回滚模式更改之前关闭。

现在在这种情况下，NDBCLUSTER滚动后退和关闭任何打开的NDB后，才能滚动模式更改交易与变更相关。(错误# 31546868)

时，添加新用户并不总是正确地同步到所有SQL节点ndb_stored_user.给新用户授予特权。(错误# 31486931)

在某些情况下，QMGR返回冲突NDB.引擎和MySQL服务器版本信息，这可能会导致计划外的管理节点关闭。(错误# 31471959)

SUMA在一个正在启动的节点上不应该发送DICT_UNLOCK_ORD信号DICT阻塞主节点，直到所有SUMA_HANDOVER_REQ发送的信号已经过suma_handover_conf.响应发送信号，并在每个切换桶上设置接收asuma_handover_conf.已完成切换。在某些罕见的情况下使用noofreplicas.> 2，在全局检查点之间的延迟异常短的情况下，一些切换桶可以在其他切换桶之前准备好进行切换，即使是在这种情况下也可以继续进行切换。(错误# 31459930)

对象读取数据时，需要执行属性ID映射NDB.使用索引或主键的表，其列顺序与表不同。对于惟一索引，在打开表时创建一个缓存的属性ID映射，然后用于后续的每次读取，但对于主键读取，则为每次读取构建映射。这将被更改，以便在打开表时构建并缓存主键的属性ID映射，并在需要时用于任何后续读取。(错误# 31452597)

参考:参见Bug #24444899。

在恢复过程的不同阶段，ndb_restore.用于临时错误的不同重试数以及重试之间的睡眠时间。这是通过在所有恢复阶段实现一致的重试计数和睡眠时间来修复。（bug＃31372923）

删除编译时生成的警告NDBCLUSTER10的叮当声。(错误# 31344788)

的spj.块包含生成时使用的负载节流机制LQHKEYREQ信号。当这些是从父行扫描中生成的，并且该扫描具有多个执行键查找的子行的密集拓扑时，可能会使作业队列超载LQHKEYREQ信号，导致节点关闭由于完整的作业缓冲区。这个问题最初由bug修复＃14709490。进一步调查这个问题表明作业缓冲区已满即使spj.查询不密集。由于内部批号的增加spj.NDB 7.6.4的工人作为在发送时实施多个碎片的工作的一部分SCAN_FRAGREQ信号spj.块，甚至一个简单的查询可以填充作业缓冲区时，相对较少的此类查询并行运行。

为了解决这个问题，我们不再发送任何进一步LQHKEYREQ一旦给定请求中的未出现信号的数量超过256，则信号一旦超过256.而是来自哪个父行LQHKEYREQ的相关ID存储在稍后要恢复的操作集合中。(错误# 31343524)

参考：这个问题是一个回归的：bug＃14709490。

MaxDiskWriteSpeedOwnRestart在节点重新启动期间，未授予本地检查点写入的上限。（bug＃31337487）

参考:参见Bug #29943227。

在某些罕见的情况下，删除表anNDB.表触发了一个断言。（bug＃31336431）

在节点重启期间，SUMA正在启动的节点块必须获得订阅(带有订阅方的事件)和订阅方(NdbEventOperation正在执行的实例)。在复制完成之前，仍然开始忽略任何用户级别的节点SUB_START或者SUB_STOP请求;在复制完成后，他们可以参与这样的请求。当复制操作正在进行时，用户级SUB_START和SUB_STOP请求使用DICT锁。

发现了一个起始节点可以参与的问题SUB_START和SUB_STOP在请求锁之后，但在授予锁之前的请求，导致不成功SUB_START和SUB_STOP请求。此修复程序确保节点不能参与这些请求直到DICT锁实际上已经被授予了。(错误# 31302657)

备份错误FsErrInvalidParameters当文件系统运行时o_direct.并且数据文件写入未与512字节块大小对齐o_direct.写道。如果数据文件中的总片段大小未与之对齐o_direct.块大小,NDB.将最后一次写入的内容填充到所需的大小，但是当没有需要写入的片段时，备份仅将标题和页脚写入数据文件。由于页眉和页脚少于512个字节，因此导致问题o_direct.写。

如果有必要，可以使用EMPTY_ENTRY，当关闭数据文件时。(错误# 31180508)

当执行策略要求缓存接收到的键行以供以后使用时，DBSPJ现在一个树节点一个树节点管理缓冲区内存分配树，导致CPU使用的显著下降DBSPJ堵塞。（bug＃31174015）

DBSPJ现在使用线性内存代替分段内存进行存储和处理TRANSID_AI信号，这节省了大约10%之前消耗的CPU。由于这种变化，现在有可能DBSPJ接受TRANSID_AI信号格式短信号格式;这比需要分段存储器的长信号格式更有效。（bug＃31173582，bug＃31173766）

使用算法=原地导致一个断言。(错误# 31139313)

本地数据管理器（LDM）具有一种机制，可以确保在填充太少的行时不会在合理的时间内填充可用批次大小（例如，当ScanFilter最多评估为FALSE时，这是一种机制扫描的行）。当此时间限制时，设置dblqh.当10 ms过期时，将返回在该点之前找到的任何行，这与是否填充了指定的批大小无关。这作为数据和API节点之间的保持活动机制，并避免在扫描期间保持任何锁太长时间。

这样做的一个副作用是将结果行批返回给DBSPJ填充远低于预期限制的块可能会导致性能问题。这不仅是由于对预留给批次的空间利用率不高，需要更多的空间NEXTREQ往返，还因为它引起的DBSPJ内部并行统计数据变得不可靠。

自从此以来DBSPJblock在执行扫描时从不请求锁，过长的锁对于SPJ请求不是问题。因此，它被认为是安全的，让扫描请求DBSPJ继续超过先前允许的10毫秒，并设置限制dblqh.增加到100毫秒(Bug #31124065)

的输出解释格式=树没有表示表访问是否是索引范围扫描返回多行，或在主或唯一密钥上的单行查找。

此修复程序还提供了一个小的优化，例如，如果已知访问类型，则不会在尝试返回多个行时多次访问处理程序接口独特的。（bug＃31123930）

之前的一个更改(在NDB 8.0.20中做的)使表上的push join成为可能READ_BACKUP将两个SPJ工人放在本地的数据节点上DBTC在其他一些节点上放置没有SPJ工作者的同时块;这有时不平衡是故意的，因为与启用备份片段的更多本地读取的增益相比，SPJ工作负载（和可能引入的不平衡）通常相当低。作为同一变化的非预期副作用，这两个共同的SPJ工人可能并行扫描相同的片段子集;这突破了一个假设DBSPJ每个数据节点上只实例化一个SPJ工作者，确保每个SPJ工作者从不同的片段开始扫描的逻辑依赖于这些数据节点。

为了解决这个问题，现在基于工作人员从中开始的根片段ID计算每个SPJ工作者的起始片段，即使其中一些驻留在同一节点上，所有SPJ工人也是唯一的。（bug＃31113005）

参考文献：另见：Bug＃30639165。

当集群从NDB 8.0.17或之前升级到8.0.18或更高版本时，管理服务器(或管理服务器)升级到新软件版本后，尚未升级的数据节点可能会意外关闭。这发生在管理客户端停止命令发送到一个或多个仍然运行旧版本的数据节点和新的主节点(也运行旧版本的NDB.软件）随后经历了无计划的关机。

我们发现这是由于发送a时错误地设置了信号长度和信号段数GSN_STOP_REQ- 由于在NDB 8.0中，长度在NDB 8.0中增加了许多信号，以支持更大数量的数据节点 - 到新主站。这发生了由于使用陈旧的数据来源的陈旧数据GSN_STOP_REQ到以前的主节点。防止这种情况发生，ndb_mgmd现在，在发送一个GSN_STOP_REQ信号。(错误# 31019990)

在某些情况下，当重放日志和恢复元组时发生故障时，ndb_restore.终止而不是返回错误。此外，某些操作的重试次数由硬编码的值决定。(错误# 30928114)

在模式分发期间，如果在DDL操作已经登录到ndb_schema.表中，但是在参与者可以回答之前，客户端简单地将所有参与者标记为失败NDB_SCHEMA_OBJECT并返回。由于分发协议已经在进行中，协调员继续等待参与者，收到他们的ndb_schema_result.插入并处理它们;同时，客户开放才能发送另一个DDL操作;如果执行并且在协调器可以完成处理先前的模式更改之前开始分发它，则这触发了一个断言，应该只有在任何给定时间都有一个架构操作的一个分布。

此外，当客户端返回时检测到一个线程被终止，它还释放了全局模式锁(GSL);这也可能导致未定义的问题，因为与会者可以在假设全球服务标准仍由协调员持有的情况下作出更改。

在这种情况下，在将DDL操作记录到ndb_schema.桌子;从这一点来看，协调员有控制，客户应该等待它做出决定。现在，协调员仅在服务器或群集关闭时中止分发，否则等待所有参与者要么将所有参与者回复，或者将模式操作标记为已完成。（bug＃30684839）

在重新启动期间，数据节点收到GCP_SAVEREQ开始阶段9之前的信号，因此需要执行全局检查点索引写入本地数据管理器的本地检查点控制文件，它没有从DIH作为写入数据的一部分发送信号的节点发起的块。这意味着，在稍后的开始阶段9中，当试图发送一个GCP_SAVECONF响应信号GCP_SAVEREQ，该信息不可用，这意味着无法发送响应，导致数据节点意外关闭。(错误# 30187949)

设置EnableRedoControl来错误的没有完全禁用MaxDiskWriteSpeed,MaxDiskWriteSpeedOtherNodeRestart， 和MaxDiskWriteSpeedOwnRestart正如预期的那样。（bug＃29943227）

参考文献：另见：bug＃31337487。

一个团值由NDB.在多个部分;当读取这样的值时，每个部分执行一个读取操作。如果没有找到某个部件，则读取失败未找到错误错误，表示已损坏团，自A.团不应该有任何缺失的部分。可能会出现问题，因为这个错误被报告为读取操作的总体结果，这意味着mysqld没有看到任何错误，并且报告返回零行。

这个问题被修复了，通过添加一个特别的检查，在这种情况下，一个blob部分没有找到。现在，当这个发生时，重写找不到行错误损坏的团，这导致了起源选择声明失败预期。NDB API的用户应该意识到，尽管发生了这种变化，但ndbblob :: getValue（）方法继续将错误报告为找不到行在这种情况下。(错误# 28590428)

时数据节点未启动真实的帽子Configuration参数设置为1.这是由于启动期间的索引构建是通过临时转换为索引构建线程的I / O线程来执行的索引构建，并且这些线程继承了I / O线程的实时属性。当检查索引构建线程规范时，这导致冲突（视为致命错误）以确保它们不是实时线程。无论应用于其主机I / O线程的任何设置如何，都可以通过确保索引构建线程未被视为实时线程来修复这一点。（bug＃27533538）

使用就地ALTER TABLE删除索引可能会导致SQL节点的计划外关闭。(错误# 24444899)

作为执行时的最后一步ALTER表......算法= inplace,NDBCLUSTER中执行表元数据的读取NDB.字典，需要在SQL节点和数据节点之间进行额外的往返，这既不必要地减慢了语句的执行速度，也提供了出错的途径NDBCLUSTER没有准备好正确处理。通过删除读取NDB.表元数据在执行就地的最终阶段ALTER TABLE声明。(Bug #99898, Bug #31497026)

准备时可能会发生内存泄漏NDB.桌子为原位ALTER TABLE。（bug＃99739，bug＃31419144）

添加了AllowUnresolvedHostNames配置参数。当设置为真的，此参数覆盖通常提出的致命误差ndb_mgmd无法连接到给定的主机名，允许继续启动，而只生成一个警告。为了有效，参数必须在集群全局配置文件中设置[TCP默认]部分。