新的磁盘数据表文件格式。  NDB 7.6 中为 NDB 磁盘数据表使用了一种新的文件格式，这使得每个磁盘数据表都可以被唯一标识，而无需重复使用任何表 ID。这应该有助于解决页面和范围处理问题，这些问题对用户来说是快速创建和删除磁盘数据表的问题，而旧格式没有提供现成的修复方法。

每当创建新的撤消日志文件组和表空间数据文件时，都会使用新格式。与现有磁盘数据表相关的文件继续使用旧格式，直到重新创建它们的表空间和撤消日志文件组。

为避免与格式更改相关的问题，您应该在升级到 NDB 7.6 时重新创建任何现有的表空间和撤消日志文件组。--initial作为升级过程的一部分，您可以通过执行每个数据节点的初始重启（即使用该选项）来完成此操作。作为从 NDB 7.5 或更早版本系列升级到 NDB 7.6 或更高版本的一部分，您可以期望此步骤是强制性的。

如果您使用的是磁盘数据表，则从 任何NDB 7.6 版本（不考虑版本状态）降级到任何 NDB 7.5 或更早版本需要您重新启动所有数据节点， --initial作为降级过程的一部分。这是因为 NDB 7.5 和更早版本系列无法读取新的磁盘数据文件格式。

有关更多信息，请参阅 第 21.3.7 节，“升级和降级 NDB Cluster”。

数据内存池和动态索引内存。  表列索引所需的内存NDB 现在从为 分配的内存中动态分配 DataMemory。出于这个原因， IndexMemory 配置参数现已弃用，并在未来的版本系列中删除。

索引内存与数据内存的合并简化了NDB; 这些更改的另一个好处是，通过增加 LDM 线程的数量来扩展不再受限于为 设置的值不够大 IndexMemory。这是因为索引内存不再是仅分配一次的静态数量（当集群开始），但现在可以根据需要分配和取消分配。以前，有时增加 LDM 线程的数量可能会导致索引内存耗尽，但 DataMemory仍有大量可用。

作为这项工作的一部分，许多 DataMemory与表数据存储不直接相关的使用实例现在改用事务内存。

出于这个原因，在某些系统上可能需要增加 SharedGlobalMemory 以允许事务内存在需要时增加，例如在使用 NDB Cluster Replication 时，这需要在数据节点上进行大量缓冲。在执行初始批量数据加载的系统上，可能需要将非常大的事务分解成较小的部分。

此外，数据节点现在生成 MemoryUsage事件（请参阅 第 21.6.3.2 节，“NDB 集群日志事件”）并在资源使用率达到 99% 以及达到 80%、90% 或100%，和以前一样。

此处列出了其他相关更改：

ndbinfo 进程和 config_nodes 表。  NDB 7.6 在 ndbinfo信息数据库中增加了两个表来提供集群节点的信息；这些表列在这里：

系统名称。  NDB 集群的系统名称可用于标识特定集群。在 NDB 7.6 中，MySQL 服务器将此名称显示为 Ndb_system_name状态变量的值；NDB API 应用程序可以使用 Ndb_cluster_connection::get_system_name() 在同一版本中添加的方法。

自动生成基于管理服务器启动时间的系统名称>；[system]在启动管理服务器之前，您可以通过向集群的配置文件添加一个部分并将 Name参数设置为您在该部分中选择的值 来覆盖此值。

ndb_import CSV 导入工具。  ndb_import，在 NDB Cluster 7.6 中添加，使用 NDB API 将 CSV 格式的数据直接加载到 NDB表中（只需要一个 MySQL 服务器来创建它所在的表和数据库）。 ndb_import可以看作是mysqlimport或 LOAD DATASQL 语句的模拟，并支持许多相同或相似的数据格式化选项。

假设数据库和目标NDB 表存在，ndb_import只需要连接到集群的管理服务器（ndb_mgmd）来执行导入；因此，在集群的文件用途 中必须有一个[api] 可供该工具使用的插槽 。config.ini

有关更多信息，请参阅第 21.5.14 节，“ndb_import — 将 CSV 数据导入 NDB”。

ndb_top 监控工具。  添加了ndb_topNDB实用程序，它实时显示数据节点的 CPU 负载和使用信息 。此信息可以文本格式、ASCII 图形或两者显示。图形可以彩色显示，也可以使用灰度显示。

ndb_top连接到 NDB Cluster SQL 节点（即 MySQL 服务器）。出于这个原因，该程序必须能够作为 SELECT对数据库中的表具有特权ndbinfo。

ndb_top适用于 Linux、Solaris 和 macOS 平台，但目前不适用于 Windows 平台。

有关详细信息，请参阅 第 21.5.29 节，“ndb_top — 查看 NDB 线程的 CPU 使用信息”。

代码清理。  大量正常操作不需要的调试语句和打印输出已移入仅在测试或调试时使用的代码 NDB，或者完全放弃。在许多情况下，这种开销的消除应该会导致 LDM 和 TC 线程的性能显着提高大约 10%。

LDM 线程和 LCP 改进。  以前，当本地数据管理线程遇到 I/O 延迟时，它写入本地检查点的速度会更慢。例如，在磁盘过载情况下可能会发生这种情况。可能会出现问题，因为其他 LDM 线程并不总是观察到此状态，或者也不会这样做。 NDB现在全局跟踪 I/O 滞后模式，以便在至少一个线程以 I/O 滞后模式写入时立即报告此状态；然后它确保在减速条件期间对所有 LDM 线程强制执行此 LCP 的降低写入速度。因为写入速度的降低现在被其他 LDM 实例观察到，所以整体容量增加了；这使得在这种情况下比以前更快地克服磁盘过载（或其他导致 I/O 滞后的情况）。

NDB 错误识别。  可以使用 NDB 7.6 中 的mysql客户端从信息数据库中的新error_messages表中获取错误消息和信息。ndbinfo此外，NDB 7.6 引入了一个新的命令行客户端ndb_perror，用于从 NDB 错误代码中获取信息；这取代了 using perror with --ndb，现在已弃用并在未来的版本中删除。

有关更多信息，请参阅 第 21.6.15.21 节，“ndbinfo error_messages 表”和 第 21.5.17 节，“ndb_perror — 获取 NDB 错误消息信息”。

SPJ 改进。  当作为推送连接执行扫描时（即，查询的根是扫描）， DBTC块将 SPJ 请求发送到DBSPJ 与要扫描的片段相同的节点上的实例。以前，为节点的每个片段发送一个这样的请求。由于数量 DBTC和DBSPJ instances 通常设置为小于 LDM 实例的数量，这意味着所有 SPJ 实例都参与了单个查询的执行，事实上，一些 SPJ 实例可以（并且确实）从同一查询接收多个请求。NDB 7.6 使单个 SPJ 请求可以处理一组要扫描的根片段，因此只需将单个 SPJ 请求 ( SCAN_FRAGREQ) 发送到DBSPJ每个节点上的任何给定 SPJ 实例 (块)。

由于DBSPJ在评估推送连接时消耗的总 CPU 数量相对较少，与 LDM 块（负责大部分 CPU 使用）不同，引入多个 SPJ 块会增加一些并行性，但也会增加额外的开销。通过启用单个 SPJ 请求来处理一组要扫描的根片段，这样只有一个 SPJ 请求被发送到每个DBSPJ每个节点上的实例和每个片段分配的批量大小，多片段扫描可以获得更大的总批量大小，允许在 SPJ 块内进行一些调度优化，它可以一次扫描单个片段（给它总批大小分配），使用较小的子批或两者的某种组合并行扫描所有片段。

由于以下原因，这项工作有望提高下推连接的性能：

改进了重做日志的 O_DIRECT 处理。  NDB 7.6 提供了一个新的数据节点配置参数 ODirectSyncFlag ，该参数导致完成的重做日志写入使用 O_DIRECT作为 fsync调用处理。 ODirectSyncFlag默认情况下禁用；要启用它，请将其设置为true。

您应该记住，当至少满足以下条件之一时，将忽略此参数的设置：

将 CPU 锁定到离线索引构建线程。  在 NDB 7.6 中，离线索引构建默认使用ndbmtd可用的所有内核，而不是仅限于为 I/O 线程保留的单个内核。还可以指定一组所需的核心用于 I/O 线程，这些线程执行有序索引的离线多线程构建。这可以改善重启和恢复时间、性能以及可用性。

此改进涉及几个相关的更改。第一个是更改 BuildIndexThreads 配置参数的默认值（从 0 到 128），这意味着离线有序索引构建现在默认是多线程的。的默认值 TwoPassInitialNodeRestartCopy 也发生了变化（从false到 true），因此初始节点重新启动首先复制所有数据，而不从 “实时”创建任何索引node到正在启动的节点，复制数据后离线建立有序索引，然后再次与live节点同步；这可以显着减少构建索引所需的时间。此外，为了便于将离线索引构建线程显式锁定到特定 CPU，为 配置参数 idxbld定义了一个新的线程类型 ( ) 。ThreadConfig

作为这项工作的一部分，NDB现在可以区分执行线程类型和其他类型的线程，以及永久分配给特定任务的线程类型和仅临时分配的线程类型。

NDB 7.6 还引入nosend 了 ThreadCOnfig. 通过将其设置为 1，您可以阻止main、 ldm、rep或 tc线程协助发送线程。此参数默认为 0，不能与 I/O 线程、发送线程、索引构建线程或看门狗线程一起使用。

有关其他信息，请参阅参数说明。

DDL 批量数据操作的可变批量大小。  作为ndbmtd优化批量 DDL 性能的工作的一部分，现在可以通过增加使用扫描处理数据的 DDL 操作的批量数据部分的批量大小来获得性能改进。通过设置此处列出的相应数据节点配置参数，现在可以为唯一索引构建、外键构建和在线重组配置批量大小：

对于刚刚列出的每个参数，默认值为 64，最小值为 16，最大值为 512。

增加适当的批量大小可以帮助分摊线程间和节点间延迟，并利用更多并行资源（本地和远程）来帮助扩展 DDL 性能。在每种情况下，都可以与正在进行的流量进行权衡。

部分 LCP。  NDB 7.6 实现了部分本地检查点。以前，LCP 总是制作整个数据库的副本。当处理数 TB 的数据时，此过程可能需要大量时间，尤其会对节点和集群重启产生不利影响，并且需要更多空间用于重做日志。现在，LCP 不再严格需要执行此操作——相反，LCP 现在默认仅保存一定数量的记录，这些记录基于自上一个 LCP 以来更改的数据量。这可以在完整检查点和完全不更改的检查点之间变化。如果检查点反映任何更改，

作为此更改的一部分，此版本中引入了两个新的数据节点配置参数：（ EnablePartialLcp 默认true或启用）启用部分 LCP。 RecoveryWork 控制分配给 LCP 的空间百分比；它随着重新启动期间必须在 LCP 上执行的工作量的增加而增加，而不是在正常操作期间执行的工作量。提高此值会导致 LCP 在正常操作期间需要写入较少的记录，从而减少通常的工作量。提高此值还意味着重新启动可能需要更长的时间。

您必须通过设置明确禁用部分 LCP EnablePartialLcp=false。这使用最少的磁盘，但也往往会最大化 LCP 的写入负载。要在正常操作期间针对 LCP 上的最低工作负载进行优化，请使用 EnablePartialLcp=true和 RecoveryWork=100。要为部分 LCP 使用最少的磁盘空间，但写入有限制，请使用 EnablePartialLcp=true和 RecoveryWork=25，这是 RecoveryWork. 默认为 EnablePartialLcp=truewith RecoveryWork=50，表示LCP文件大约需要1.5倍 DataMemory；使用 CompressedLcp=1，这可以进一步减少一半。EnablePartialLcp使用默认设置的恢复时间也应该比设置 为时快得多 false。

此外，数据节点配置参数 BackupDataBufferSize、 BackupWriteSize和 BackupMaxWriteSize 现在都已弃用，并且可能会在 MySQL NDB Cluster 的未来版本中删除。

作为此增强功能的一部分，已完成工作以纠正节点重启的几个问题，其中在各种情况下可能会用完撤消日志，最常见的是在密集期间恢复已关闭很长时间的节点时写活动。

通过在此过程中更新 LCP 看门狗，并更好地跟踪磁盘数据同步的进度，完成了额外的工作以提高长时间同步的数据节点存活率而不会超时。以前，如果同步时间超过 LCP 看门狗超时时间，则可能会出现虚假警告甚至节点故障。

并行撤销日志记录处理。  以前，数据节点 LGMAN内核块串行处理撤销日志记录；现在这是并行完成的。将撤消记录移交给 LDM 线程的 rep 线程等待 LDM 完成应用一条记录，然后再获取下一条记录；现在 rep 线程不再等待，而是立即处理下一条记录和 LDM。

保留每个 LDM 的未完成日志记录数的计数LGMAN，并在 LDM 完成记录的执行时递减。属于一个页面的所有记录都被发送到同一个 LDM 线程，但不保证按顺序处理，因此具有未完成记录的页面的哈希映射为这些页面中的每一个维护一个队列。当页面在页面缓存中可用时，将按顺序应用队列中所有挂起的记录。

一些类型的记录继续按顺序处理： UNDO_LCP、 UNDO_LCP_FIRST、 UNDO_LOCAL_LCP、 UNDO_LOCAL_LCP_FIRST、 UNDO_DROP和 UNDO_END。

与此性能增强直接相关的功能没有用户可见的变化；这是改进撤消长处理以支持 NDB Cluster 7.6 中的部分本地检查点的工作的一部分。

从撤销日志应用程序的范围中读取表和片段 ID。  应用undo log时，需要从page ID中获取table ID和fragment ID。之前这是通过 PGMAN使用额外的PGMAN工作线程从内核块读取页面来完成的，但是在应用撤消日志时，有必要再次读取页面。

使用O_DIRECT它时效率非常低，因为页面没有缓存在操作系统内核中。为了纠正这个问题，从页面 ID 到表 ID 和片段 ID 的映射现在是使用来自给定范围内使用的页面的表 ID 和片段 ID 的扩展头信息来完成的。扩展页面总是存在于页面缓存中，因此执行映射不需要额外的磁盘读取。此外，已经可以使用现有的 TSMAN内核块数据结构读取信息。

有关详细信息，请参阅 ODirect数据节点配置参数的说明。

共享内存传输器。  NDB 7.6 完全支持同一台主机上的数据节点和 API 节点之间的用户定义共享内存 (SHM) 连接，并且不再被视为实验性的。UseShm 您可以通过将配置参数设置1为相关数据节点来启用显式共享内存连接 。当显式定义共享内存作为连接方式时，还需要数据节点和API节点都由 标识 HostName。

SHM 连接的性能可以通过 在集群配置文件 ( )的或部分中设置ShmSize、 ShmSpintime和 等参数来增强。SHM 的配置在其他方面类似于 TCP 传输器的配置。 SendBufferMemory[shm][shm default]config.ini

该SigNum参数未在新的 SHM 实现中使用，现在将忽略为其所做的任何设置。 第 21.4.3.12 节，“NDB Cluster 共享内存连接”，提供了有关这些参数的更多信息。此外，作为这项工作的一部分，NDB与旧 SCI 转运蛋白相关的代码已被删除。

有关更多信息，请参阅 第 21.4.3.12 节，“NDB Cluster 共享内存连接”。

SPJ 块内连接优化。  在 NDB 7.6 中，SPJ 内核块在评估至少有一些表是内部连接的连接请求时可以考虑在内。这意味着一旦知道一个或多个前面的请求没有返回父行的任何结果，它就可以消除对行、范围或两者的请求。这使数据节点和SPJ块不必处理从不参与 INNER-joined 结果行的请求和结果行。

考虑这个连接查询，其中pk是表 t2、t3 和 t4 上的主键，列 x、y 和 z 是非索引列：

SELECT * FROM t1
  JOIN t2 ON t2.pk = t1.x
  JOIN t3 ON t3.pk = t1.y
  JOIN t4 ON t4.pk = t1.z;

以前，这会导致SPJ 请求包括对表的扫描，以及对每个表、 和t1的查找；这些是针对从返回的每一行进行评估的。为此，创建了 对表、和 的请求 。现在考虑到这样的要求，即要生成任何结果行，内部联接必须在所有联接的表中找到匹配项；一旦没有找到其中一个表的匹配项，现在将跳过对具有相同父表的表的任何进一步请求。 t2t3t4t1SPJLQHKEYREQt2t3t4SPJ

NDB 唤醒线程。  NDB使用轮询接收器从套接字读取数据、执行来自套接字的消息以及唤醒其他线程。当仅间歇性地使用接收线程时，在开始唤醒其他线程之前放弃轮询所有权，这在接收线程中提供了一定程度的并行性，但是，当持续使用接收线程时，线程可能会负担过重通过任务，包括唤醒其他线程。

NDB 7.6 支持接收线程将唤醒其他线程的任务卸载到一个新线程，该线程根据请求唤醒其他线程（否则只是休眠），从而可以将单个集群连接的容量提高大约十到百分之二十。

自适应 LCP 控制。  NDB 7.6.7 实现了自适应 LCP 控制机制，该机制响应重做日志空间使用情况的变化。通过控制 LCP 磁盘写入速度，您可以帮助防止许多与资源相关的问题，包括：

这项工作包括以下与 NDB配置参数相关的更改：

这项工作主要实现了对 LCP 速度的控制，以最大限度地减少重做日志用完的风险。这是以自适应方式完成的，基于使用的重做日志空间量，使用警报级别，以及在达到这些级别时采取的响应，如下所示：

提高等级也有增加计算出的目标关卡速度的效果。

LCP 控制对安装有以下好处 NDB：

ndb_restore 选项。  从 NDB 7.6.9 开始， 调用ndb_restore时都需要 --nodeid和 选项。 --backupid

分片还原。  从 NDB 7.6.13 开始，可以将备份分成大致相等的部分（切片）并使用为ndb_restore实现的两个新选项并行恢复这些切片：

这使得使用 ndb_restore的多个实例并行恢复备份的子集成为可能，从而可能减少执行恢复操作所需的时间。

有关详细信息，请参阅 ndb_restore --num-slices选项的说明。

ndb_restore：主键架构更改。 NDB 7.6.14（及更高版本）在使用选项运行时 使用ndb_restoreNDB还原本机备份 时 ，支持源表和目标表的不同主键定义 。支持增加和减少构成原始主键的列数。 --allow-pk-changes

当使用一个或多个附加列扩展主键时，添加的任何列都必须定义为 NOT NULL，并且在进行备份期间不得更改任何此类列中的值。因为一些应用程序在更新它时将所有列值设置在一行中，无论所有值是否实际更改，这都可能导致恢复操作失败，即使要添加到主键的列中的值没有更改。--ignore-extended-pk-updates 您可以使用也在 NDB 7.6.14 中添加的选项覆盖此行为 ；在这种情况下，您必须确保没有更改此类值。

可以从表的主键中删除一列，无论该列是否仍然是表的一部分。

有关详细信息，请参阅 ndb_restore--allow-pk-changes 选项的描述。

ndb_blob_tool 增强功能。  从 NDB 7.6.14 开始， ndb_blob_tool实用程序可以检测存在内联部分的缺失 blob 部分，并将其替换为长度正确的占位符 blob 部分（由空格字符组成）。要检查是否缺少 blob 部分，请使用 --check-missing 此程序的选项。要用占位符替换任何缺失的 blob 部分，请使用该 --add-missing 选项。

有关详细信息，请参阅 第 21.5.6 节，“ndb_blob_tool - 检查和修复导航台集群表的 BLOB 和 TEXT 列”。

使用 ndb_restore 合并备份。  在某些情况下，可能需要将最初存储在 NDB Cluster 的不同实例中的数据（全部使用相同的模式）合并到单个目标 NDB Cluster 中。现在支持使用在ndb_mgm客户端中创建的备份（请参阅 第 21.6.8.2 节，“使用 NDB Cluster Management Client 创建备份”）并使用ndb_restore恢复它们，使用 --remap-columnNDB 7.6.14 中添加的选项以及 --restore-data（以及可能根据需要或期望的其他兼容选项）。--remap-column可用于处理主键值和唯一键值在源集群之间重叠的情况，并且它们在目标集群中不重叠是必要的，以及保留表之间的其他关系，例如外键。

--remap-column将具有格式 的字符串作为其参数 ，其中、 和 分别是数据库、表和列 的名称，是重映射函数的名称，并且是 的一个或多个参数。没有默认值。仅支持作为函数名称， 作为将列值从备份插入目标表时应用于列值的整数偏移量。此列必须是以下之一 或 db.tbl.col:fn:argsdbtblcolfnargsfnoffsetargsINTBIGINT; 偏移值的允许范围与该类型的有符号版本相同（如果需要，这允许偏移为负）。

新选项可以在ndb_restore的同一次调用中多次使用，这样您就可以将同一个表、不同表或两者的多个列重新映射到新值。选项的所有实例的偏移值不必相同。

此外 ，还从 NDB 7.6.14 开始 为ndb_desc提供了两个新选项：

有关更多信息和示例，请参阅--remap-column 选项的说明。

--ndb-log-fail-terminate 选项。  从 NDB 7.6.14 开始，您可以在 SQL 节点无法完全记录所有行事件时终止它。这可以通过 使用 选项 启动mysqld来完成。--ndb-log-fail-terminate

NDB 程序 - NDBT 依赖项删除。 NDB 许多实用程序对库 的依赖性NDBT已被删除。该库内部用于开发，正常使用不需要；它包含在这些程序中可能会在测试时导致不必要的问题。

此处列出了受影响的程序，以及 NDB删除了依赖项的版本：

此更改对用户的主要影响是这些程序在运行完成后不再打印。依赖于此类行为的应用程序应更新以反映升级到指定版本时的更改。 NDBT_ProgramExit - status

自动安装程序弃用和删除。  MySQL NDB Cluster Auto-Installer 基于 Web 的安装工具 ( ndb_setup.py ) 在 NDB 7.6.16 中已弃用，并在 NDB 7.6.17 及更高版本中删除。它不再受支持。

ndbmemcache 弃用和删除。  ndbmemcache不再受支持。 ndbmemcache在 NDB 7.6.16 中已弃用，并在 NDB 7.6.17 中删除。

移除了 Node.js 支持。  从 NDB Cluster 7.6.16 版本开始，NDB 7.6 对 Node.js 的支持已被删除。

NDB Cluster 对 Node.js 的支持仅在 NDB 8.0 中得到维护。

还原操作期间 NULL 和 NOT NULL 之间的转换。  从 NDB 7.6.19 开始，ndb_restoreNULL可以使用此处列出的选项支持按原样NOT NULL和反向 恢复列：

有关详细信息，请参阅指示的 ndb_restore选项的描述。