MySQL8 中文参考（八十五）（2）

MySQL8 中文参考（八十五）（1）https://developer.aliyun.com/article/1566064

25.2.1 NDB 集群核心概念

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-basics.html

NDBCLUSTER（也称为NDB）是一种提供高可用性和数据持久性功能的内存存储引擎。

NDBCLUSTER存储引擎可以配置一系列故障转移和负载平衡选项，但最简单的方法是从集群级别开始配置存储引擎。NDB 集群的NDB存储引擎包含完整的数据集，仅依赖于集群内部的其他数据。

NDB 集群的“Cluster”部分独立于 MySQL 服务器进行配置。在 NDB 集群中，集群的每个部分被视为一个节点。

注意

在许多情境中，“节点”一词用于指代计算机，但在讨论 NDB 集群时，它指的是一个进程。可以在单台计算机上运行多个节点；对于运行一个或多个集群节点的计算机，我们使用术语集群主机。

有三种类型的集群节点，在最小的 NDB 集群配置中，至少有三个节点，每种类型一个：

• 管理节点：这种类型的节点的角色是管理 NDB 集群中的其他节点，执行提供配置数据、启动和停止节点以及运行备份等功能。由于这种节点类型管理其他节点的配置，因此应首先启动此类型的节点，然后再启动任何其他节点。管理节点使用命令ndb_mgmd启动。
  
• 数据节点：此类型节点存储集群数据。数据节点的数量与片段副本的数量相同，乘以片段的数量（参见第  25.2.2 节，“NDB Cluster  节点、节点组、片段副本和分区”）。例如，具有两个片段副本，每个副本有两个片段，您需要四个数据节点。一个片段副本足以用于数据存储，但不提供冗余；因此，建议具有两个（或更多）片段副本以提供冗余性，从而提供高可用性。数据节点使用命令ndbd（参见第 25.5.1 节，“ndbd — The NDB Cluster Data Node Daemon”）或ndbmtd")（参见第 25.5.3 节，“ndbmtd — The NDB Cluster Data Node Daemon (Multi-Threaded)”")）启动。
  NDB  Cluster 表通常完全存储在内存中，而不是在磁盘上（这就是为什么我们将 NDB Cluster 称为内存数据库）。然而，一些 NDB  Cluster 数据可以存储在磁盘上；有关更多信息，请参见第 25.6.11 节，“NDB Cluster 磁盘数据表”。
  
• SQL 节点：这是访问集群数据的节点。在 NDB Cluster 的情况下，SQL 节点是使用 NDBCLUSTER 存储引擎的传统 MySQL 服务器。SQL 节点是使用 --ndbcluster 和 --ndb-connectstring 选项启动的 mysqld 进程，这些选项在本章的其他地方有解释，可能还有其他 MySQL 服务器选项。
  SQL 节点实际上只是一种专门类型的 API 节点，用于指定任何访问 NDB Cluster 数据的应用程序。另一个 API 节点的示例是ndb_restore 实用程序，用于恢复集群备份。可以使用 NDB API 编写此类应用程序。有关 NDB API 的基本信息，请参见使用 NDB API 入门。
  

重要

在生产环境中不现实期望使用三节点设置。这种配置不提供冗余性；要从 NDB Cluster 的高可用性功能中受益，必须使用多个数据和 SQL 节点。强烈建议使用多个管理节点。

关于 NDB 集群中节点、节点组、片段副本和分区之间关系的简要介绍，请参见 Section 25.2.2, “NDB Cluster Nodes, Node Groups, Fragment Replicas, and Partitions”。

集群的配置涉及配置集群中的每个单独节点，并设置节点之间的单独通信链接。NDB 集群当前设计的目的是数据节点在处理器性能、内存空间和带宽方面是同质的。此外，为了提供单一的配置点，集群作为整体的所有配置数据都位于一个配置文件中。

管理服务器管理集群配置文件和集群日志。集群中的每个节点从管理服务器检索配置数据，因此需要一种确定管理服务器位置的方式。当数据节点发生有趣的事件时，节点会将有关这些事件的信息传输到管理服务器，然后管理服务器将信息写入集群日志。

此外，可以有任意数量的集群客户端进程或应用程序。这些包括标准 MySQL 客户端、NDB特定的 API 程序和管理客户端。下面几段将对这些进行描述。

标准 MySQL 客户端。 NDB 集群可以与使用 PHP、Perl、C、C++、Java、Python  等编写的现有 MySQL 应用程序一起使用。这些客户端应用程序向 MySQL 服务器发送 SQL 语句，并从充当 NDB 集群 SQL 节点的  MySQL 服务器接收响应，方式与它们与独立的 MySQL 服务器交互的方式基本相同。

使用 NDB 集群作为数据源的 MySQL 客户端可以修改以利用与多个 MySQL 服务器连接以实现负载平衡和故障转移的能力。例如，使用 Connector/J 5.0.6 及更高版本的 Java 客户端可以使用jdbc:mysql:loadbalance:// URL（在 Connector/J 5.1.7 中改进）透明地实现负载平衡；有关使用 Connector/J 与 NDB 集群的更多信息，请参见 Using Connector/J with NDB Cluster。

NDB 客户端程序。 可以编写客户端程序，直接从NDBCLUSTER存储引擎访问 NDB 集群数据，绕过可能连接到集群的任何 MySQL 服务器，使用 NDB API，一个高级 C++ API。这样的应用程序可能对不需要数据的 SQL 接口的专用目的很有用。有关更多信息，请参见 The NDB API。

还可以使用 NDB Cluster Connector for Java 为 NDB Cluster 编写NDB特定的 Java 应用程序。这个 NDB Cluster Connector 包括 ClusterJ，一个类似于 Hibernate 和 JPA 等对象关系映射持久性框架的高级数据库 API，直接连接到NDBCLUSTER，因此不需要访问 MySQL 服务器。有关更多信息，请参阅 Java 和 NDB Cluster，以及 ClusterJ API 和数据对象模型。

NDB Cluster 还支持使用 Node.js 编写的 JavaScript 应用程序。MySQL Connector for JavaScript 包括适配器，用于直接访问NDB存储引擎以及 MySQL 服务器。使用此连接器的应用程序通常是事件驱动的，并且使用类似于 ClusterJ 所采用的领域对象模型。有关更多信息，请参阅 MySQL NoSQL Connector for JavaScript。

管理客户端。 这些客户端连接到管理服务器，并提供命令以优雅地启动和停止节点，启动和停止消息跟踪（仅限调试版本），显示节点版本和状态，启动和停止备份等。这种类型程序的示例是 NDB Cluster 提供的ndb_mgm管理客户端（请参阅  Section 25.5.5，“ndb_mgm — NDB Cluster 管理客户端”）。此类应用程序可以使用 MGM API  编写，这是一个与一个或多个 NDB Cluster 管理服务器直接通信的 C 语言 API。有关更多信息，请参阅 MGM API。

Oracle 还提供了 MySQL Cluster Manager，它提供了一个高级命令行界面，简化了许多复杂的 NDB Cluster  管理任务，比如重新启动具有大量节点的 NDB Cluster。MySQL Cluster Manager  客户端还支持获取和设置大多数节点配置参数以及与 NDB Cluster 相关的mysqld服务器选项和变量的命令。MySQL Cluster Manager 8.0 支持 NDB 8.0。有关更多信息，请参阅 MySQL Cluster Manager 8.0.36 用户手册。

事件日志。 NDB Cluster 按类别（启动、关闭、错误、检查点等）、优先级和严重性记录事件。所有可报告事件的完整列表可在 Section 25.6.3，“NDB Cluster 生成的事件报告”中找到。事件日志有以下两种类型：

• 集群日志：记录整个集群的所有所需报告事件。
  
• 节点日志：每个单独节点都保留的单独日志。
  

注意

在正常情况下，只需保留和检查集群日志即可。节点日志只需在应用程序开发和调试目的时进行查看。

检查点。 一般来说，当数据保存到磁盘时，就说达到了一个检查点。更具体地说，对于 NDB 集群，检查点是一个时间点，所有已提交的事务都存储在磁盘上。关于NDB存储引擎，有两种类型的检查点共同工作，以确保维护集群数据的一致视图。这些显示在以下列表中：

• 本地检查点（LCP）：这是特定于单个节点的检查点；然而，LCP 几乎同时发生在集群中的所有节点上。LCP 通常每隔几分钟发生一次；确切的间隔会有所变化，取决于节点存储的数据量、集群活动水平和其他因素。
  NDB 8.0 支持部分 LCP，可以在某些条件下显著提高性能。请参阅EnablePartialLcp和RecoveryWork配置参数的描述，这些参数启用部分 LCP 并控制它们使用的存储量。
  
• 全局检查点（GCP）：每隔几秒钟会发生一次 GCP，当所有节点的事务同步并且重做日志刷新到磁盘时。
  

有关本地检查点和全局检查点创建的文件和目录的更多信息，请参阅 NDB 集群数据节点文件系统目录。

传输器。 我们使用传输器一词来表示数据节点之间使用的数据传输机制。MySQL NDB 集群 8.0 支持以下三种传输器：

• 以太网上的 TCP/IP。参见第 25.4.3.10 节，“NDB 集群 TCP/IP 连接”。
  
• 直接 TCP/IP。使用机器到机器的连接。参见第 25.4.3.11 节，“NDB 集群使用直接连接的 TCP/IP 连接”。
  尽管这个传输器使用与前一项提到的相同的 TCP/IP 协议，但需要不同的硬件设置和不同的配置。因此，它被认为是 NDB 集群的一个独立传输机制。
  
• 共享内存（SHM）。参见第 25.4.3.12 节，“NDB 集群共享内存连接”。
  

由于它是无处不在的，大多数用户在 NDB 集群中使用 TCP/IP over Ethernet。

无论使用何种传输器，NDB 都会尽力确保数据节点进程之间的通信使用尽可能大的块进行，因为这有利于所有类型的数据传输。

25.2.2 NDB Cluster 节点、节点组、分片副本和分区

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-nodes-groups.html

本节讨论了 NDB Cluster 如何划分和复制数据以进行存储。

下面几段讨论了理解这个主题所需的一些核心概念。

数据节点。 一个存储一个或多个分片副本的ndbd或ndbmtd")进程，即分配给节点组的分区的副本（稍后在本节中讨论）。

每个数据节点应位于单独的计算机上。虽然也可以在单台计算机上托管多个数据节点进程，但通常不建议这样配置。

当提到ndbd或ndbmtd")进程时，通常会将“节点”和“数据节点”这两个术语互换使用；在本讨论中，管理节点(ndb_mgmd进程)和 SQL 节点(mysqld进程)在提到时会明确指出。

节点组。 节点组由一个或多个节点组成，并存储分区或分片副本集（见下一项）。

NDB Cluster 中的节点组数量不是直接可配置的；它是数据节点数量和分片副本数量(NoOfReplicas配置参数)的函数，如下所示：

[# of node groups] = [# of data nodes] / NoOfReplicas

因此，如果在config.ini文件中将NoOfReplicas设置为 1，则具有 4 个数据节点的 NDB Cluster 有 4 个节点组，如果将NoOfReplicas设置为 2，则有 2 个节点组，如果将NoOfReplicas设置为 4，则有 1 个节点组。分片副本将在本节后面讨论；有关NoOfReplicas的更多信息，请参见第 25.4.3.6 节，“定义 NDB Cluster 数据节点”。

注意

NDB Cluster 中的所有节点组必须具有相同数量的数据节点。

您可以在线向运行中的 NDB Cluster 添加新的节点组（因此添加新的数据节点）；有关更多信息，请参见第 25.6.7 节“在线添加 NDB Cluster 数据节点”。

分区。 这是集群中存储的数据的一部分。每个节点负责至少保留分配给它的任何分区（即至少一个片段副本）可供集群使用。

默认情况下，NDB Cluster 使用的分区数量取决于数据节点的数量和数据节点使用的 LDM 线程数量，如下所示：

[# of partitions] = [# of data nodes] * [# of LDM threads]

当使用运行ndbmtd的数据节点时，LDM 线程的数量由MaxNoOfExecutionThreads的设置控制。当使用ndbd时，只有一个 LDM 线程，这意味着参与集群的节点数量与集群分区数量相同。当使用ndbmtd且MaxNoOfExecutionThreads设置为 3 或更少时也是如此。（您应该注意，LDM 线程的数量随着此参数的值增加，但不是严格线性增加，并且对设置它有额外的约束；有关更多信息，请参阅MaxNoOfExecutionThreads的描述。）

NDB 和用户定义的分区。 NDB Cluster 通常会自动对NDBCLUSTER表进行分区。但是，也可以使用NDBCLUSTER表进行用户定义的分区。这受以下限制：

1. 仅支持在生产环境中使用KEY和LINEAR KEY分区方案与NDB表。
   
2. 任何NDB表明确定的显式分区的最大数量为8 * [*线程数*] * [*节点组数*]，NDB 集群中的节点组数量如本节前面讨论的那样确定。在运行ndbd进行数据节点进程时，设置 LDM 线程数不会产生影响（因为ThreadConfig仅适用于ndbmtd）；在这种情况下，为了进行此计算，可以将此值视为等于 1。
   查看第 25.5.3 节，“ndbmtd — NDB 集群数据节点守护程序（多线程）”，获取更多信息。
   

有关 NDB 集群和用户定义分区的更多信息，请参阅第 25.2.7 节，“NDB 集群的已知限制”和第 26.6.2 节，“与存储引擎相关的分区限制”。

分片副本。 这是集群分区的副本。每个节点组中的每个节点都存储一个分片副本。有时也称为分区副本。分片副本的数量等于每个节点组中的节点数。

一个分片副本完全属于一个节点；一个节点可以（通常也会）存储多个分片副本。

以下图示说明了一个具有四个数据节点的 NDB 集群，运行ndbd，排列在两个每个两个节点的节点组中；节点 1 和 2 属于节点组 0，节点 3 和 4 属于节点组 1。

注意

这里只显示数据节点；尽管工作中的 NDB 集群需要一个用于集群管理的ndb_mgmd进程和至少一个 SQL 节点来访问集群存储的数据，但出于清晰起见，这些在图中被省略。

图 25.2 NDB 集群与两个节点组

集群存储的数据分为四个分区，编号为 0、1、2 和 3。每个分区都存储在同一节点组中的���个副本中。分区存储在交替的节点组中，如下所示：

• 分区 0 存储在节点组 0 上；主分片副本（主分区的备份）存储在节点 1 上，备份分片副本（分区的备份副本）存储在节点 2 上。
  
• 第 1 分区存储在另一个节点组（节点组 1）上；该分区的主要片段副本位于节点 3 上，备份片段副本位于节点 4 上。
  
• 第 2 分区存储在节点组 0。然而，其两个片段副本的放置与第 0 分区相反；对于第 2 分区，主要片段副本存储在节点 2 上，备份存储在节点 1 上。
  
• 第 3 分区存储在节点组 1 上，其两个片段副本的放置与第 1 分区相反。也就是说，其主要片段副本位于节点 4 上，备份位于节点 3 上。
  

关于 NDB 集群的持续运行意味着：只要参与集群的每个节点组至少有一个节点在运行，集群就拥有所有数据的完整副本并保持可用。这在下一个图表中有所说明。

图 25.3 2x2 NDB 集群所需的节点

在这个例子中，集群由两个节点组组成，每个节点组包含两个数据节点。每个数据节点都在运行一个实例的ndbd。从节点组  0 中至少选择一个节点和从节点组 1  中至少选择一个节点的任意组合就足以保持集群“活跃”。然而，如果来自单个节点组的两个节点都失败了，那么另一个节点组中剩余的两个节点组成的组合是不够的。在这种情况下，集群已经丢失了一个完整的分区，因此无法再提供对所有  NDB 集群数据的完整访问。

单个 NDB 集群实例支持的最大节点组数为 48。

25.2.3 NDB Cluster 硬件、软件和网络要求

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-overview-requirements.html

NDB Cluster 的一个优势是它可以在通用硬件上运行，并且在这方面没有不寻常的要求，除了需要大量的  RAM，因为所有实时数据存储都是在内存中进行的。（可以使用 Disk Data 表来减少此要求—有关这些信息，请参见 Section  25.6.11, “NDB Cluster Disk Data Tables”。其他 NDB Cluster 进程的内存需求相对较小。

NDB Cluster 的软件要求也很简单。主机操作系统不需要任何不寻常的模块、服务、应用程序或配置来支持 NDB  Cluster。对于支持的操作系统，标准安装应该足够了。MySQL 的软件要求很简单：只需要一个 NDB Cluster  的生产版本。不一定要自己编译 MySQL，只是为了能够使用 NDB Cluster。我们假设您正在使用适合您平台的二进制文件，可从 NDB  Cluster 软件下载页面获取，网址为 dev.mysql.com/downloads/cluster/。

对于节点之间的通信，NDB Cluster 支持任何标准拓扑结构的 TCP/IP 网络，并且每个主机的最低要求是一个标准的 100  Mbps 以太网卡，再加上一个交换机、集线器或路由器，为整个集群提供网络连接。我们强烈建议将 NDB Cluster  运行在其自己的子网上，不与不属于集群的机器共享，原因如下：

• 安全性。 NDB Cluster 节点之间的通信没有加密或屏蔽。保护 NDB  Cluster 内部传输的唯一方法是在受保护的网络上运行您的 NDB Cluster。如果您打算将 NDB Cluster 用于 Web  应用程序，那么集群肯定应该位于防火墙后，而不是在您网络的非军事区（DMZ）或其他地方。
  更多信息请参见 Section 25.6.20.1, “NDB Cluster Security and Networking Issues”。
  
• 效率。 在私有或受保护网络上设置 NDB Cluster 可使集群独占集群主机之间的带宽。为您的 NDB Cluster  使用单独的交换机不仅有助于防止未经授权访问 NDB Cluster 数据，还确保 NDB Cluster  节点免受网络上其他计算机之间传输引起的干扰。为了增强可靠性，您可以使用双交换机和双卡来消除网络作为单点故障；许多设备驱动程序支持此类通信链路的故障转移。
  

网络通信和延迟。 NDB Cluster 需要数据节点和 API 节点（包括 SQL  节点）之间的通信，以及数据节点与其他数据节点之间的通信，以执行查询和更新。这些进程之间的通信延迟可以直接影响用户查询的性能和延迟。此外，为了在节点静默失败时保持一致性和服务，NDB  Cluster  使用心跳和超时机制，将来自节点的长时间通信丢失视为节点故障。这可能导致冗余性降低。请记住，为了保持数据一致性，当节点组中的最后一个节点失败时，NDB  Cluster 会关闭。因此，为了避免增加强制关闭的风险，应尽可能避免节点之间的通信中断。

数据或 API 节点的故障会导致所有涉及失败节点的未提交事务中止。数据节点恢复需要从存活的数据节点同步失败节点的数据，并重新建立基于磁盘的重做和检查点日志，然后数据节点才能恢复服务。在此恢复过程中，集群以降低的冗余运行。

心跳依赖于所有节点及时生成心跳信号。如果节点过载、由于与其他程序共享而导致机器 CPU 不足，或由于交换而导致延迟，则可能无法及时生成心跳。如果心跳生成被延迟足够长，其他节点会将响应缓慢的节点视为失败。

在某些情况下，将慢速节点视为失败节点可能是可取的，这取决于节点的缓慢操作对集群其余部分的影响。在设置 NDB Cluster 的超时值（如 HeartbeatIntervalDbDb 和 HeartbeatIntervalDbApi）时，必须小心确保快速检测、故障转移和恢复服务，同时避免可能昂贵的误报。

在数据节点之间的通信延迟预计会高于局域网环境（大约 100 微秒），必须增加超时参数，以确保任何允许的延迟期限都远远在配置的超时范围内。以这种方式增加超时会对检测故障的最坏情况时间以及服务恢复时间产生相应影响。

局域网环境通常可以配置为稳定的低延迟，并且可以提供具有快速故障切换的冗余。个别链路故障可以在 TCP 级别（NDB  集群通常运行的级别）上以最小和受控的延迟恢复。广域网环境可能提供一系列的延迟，以及具有较慢故障切换时间的冗余。个别链路故障可能需要路由更改才能传播，然后才能恢复端到端的连通性。在  TCP 级别上，这可能会表现为个别通道上的大延迟。在这些情况下观察到的最坏情况 TCP 延迟与 IP 层围绕故障重新路由的最坏情况时间有关。

25.2.4 MySQL NDB Cluster 8.0 中的新功能

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-what-is-new.html

以下各节描述了与早期版本系列相比，MySQL NDB Cluster 在 NDB Cluster 8.0 至 8.0.35  中的实现变化。NDB Cluster 8.0 作为一个通用可用性（GA）版本发布，从 NDB 8.0.19 开始。NDB Cluster 7.6  和 7.5 是之前的 GA 版本，仍在生产中得到支持；有关 NDB Cluster 7.6 的信息，请参阅 What is New in  NDB Cluster 7.6。有关 NDB Cluster 7.5 的类似信息，请参阅 What is New in NDB Cluster  7.5。NDB Cluster 7.4 和 7.3 是之前的 GA 版本，已经到达生命周期终点，不再得到支持或维护。我们建议新的生产部署使用  MySQL NDB Cluster 8.0。

MySQL NDB Cluster 8.0 中的新功能

NDB Cluster 8.0 中的重大变化和新功能可能会引起兴趣，如下列表所示：

• 兼容性增强。 以下更改减少了NDB行为与其他 MySQL 存储引擎相比的长期非必要差异：

• 与 MySQL 服务器并行开发。 从此版本开始，MySQL NDB Cluster 正在与标准 MySQL 8.0 服务器并行开发，采用新的统一发布模型，具有以下特点：

• NDB 8.0 是在 MySQL 8.0 源代码树中开发、构建和发布的。
  
• NDB Cluster 8.0 的编号方案遵循 MySQL 8.0 的方案。
  
• 使用NDB支持构建源代码会在mysql -V返回的版本字符串末尾添加-cluster，如下所示：

$> mysql -V
mysql  Ver 8.0.35-cluster for Linux on x86_64 (Source distribution)

• NDB二进制文件继续显示 MySQL 服务器版本和NDB引擎版本，如下所示：

$> ndb_mgm -V
MySQL distrib mysql-8.0.35 ndb-8.0.35, for Linux (x86_64)

• 在 MySQL Cluster NDB 8.0 中，这两个版本号始终相同。

• 要使用 NDB Cluster 支持构建 MySQL 源代码，请使用 CMake 选项-DWITH_NDB（NDB 8.0.31 及更高版本；对于早期版本，请改用-DWITH_NDBCLUSTER）。
  
• 平台支持说明。 NDB 8.0 在平台支持方面做出以下更改：

• NDBCLUSTER不再支持 32 位平台。从 NDB 8.0.21 开始，NDB 构建过程会检查系统架构，并在不是 64 位平台时中止。
  
• 现在可以为 64 位ARM CPU 从源代码构建NDB。目前，此支持仅限源代码，我们不为此平台提供任何预编译的二进制文件。
  

• 数据库和表名。 NDB 8.0 删除了先前对数据库和表标识符的 63 字节限制。这些标识符现在可以使用最多 64 字节，就像使用其他 MySQL  存储引擎的对象一样。请参阅 Section 25.2.7.11, “Previous NDB Cluster Issues Resolved  in NDB Cluster 8.0”。
  
• 外键生成的名称。 NDB 现在使用模式 *tbl_name*_fk_*N* 用于内部生成的外键命名。这类似于 InnoDB 使用的模式。
  

• 模式和元数据的分发和同步。 NDB 8.0 使用 MySQL 数据字典将模式信息分发给加入集群的 SQL 节点，并在现有 SQL 节点之间同步新的模式更改。以下列表描述了与此集成工作相关的各个增强功能：

• 模式分发增强。 NDB  模式分发协调器，负责处理模式操作并跟踪其进度，在 NDB 8.0  中已扩展，以确保在模式操作结束时释放使用的资源。以前，一些工作是由模式分发客户端完成的；由于客户端并非总是具有所有所需的状态信息，这可能导致在客户端决定在完成之前放弃模式操作并且未通知协调器的情况下导致资源泄漏。
  为了帮助解决这个问题，模式操作超时检测已从模式分发客户端移至协调器，使协调器有机会在模式操作期间清理任何使用的资源。协调器现在定期检查正在进行的模式操作是否超时，并在检测到超时时将尚未完成给定模式操作的参与者标记为失败。每当发生模式操作超时时，它还会提供适当的警告。（值得注意的是，在检测到超时后，模式操作本身会继续进行。）每当一个或多个这些操作正在进行时，定期打印活动模式操作列表以进行额外报告。
  作为这项工作的额外部分，一个新的 mysqld 选项 --ndb-schema-dist-timeout 可以设置等待模式操作被标记为超时的时间长度。
  
• 磁盘数据文件分发。 NDB Cluster 8.0.14 使用 MySQL 数据字典确保磁盘数据文件和相关构造（如表空间和日志文件组）在所有连接的 SQL 节点之间正确分发。
  
• 表空间对象的模式同步。 当 MySQL 服务器作为 SQL 节点连接到 NDB 集群时，它会将其数据字典与NDB数据字典中的信息进行比较。
  以前，新 SQL 节点连接时同步的唯一NDB对象是数据库和表；MySQL NDB Cluster 8.0 还实现了磁盘数据对象的模式同步，包括表空间和日志文件组。除其他好处外，这消除了在本地备份和恢复后 MySQL 数据字典和NDB数据字典之间不匹配的可能性，其中表空间和日志文件组被恢复到NDB数据字典，但未恢复到 MySQL 服务器的数据字典。
  现在不再可能发出引用不存在表空间的CREATE TABLE语句。这样的语句现在会失败并显示错误。
  
• 数据库 DDL 同步增强。 为 NDB 8.0 所做的工作确保了新加入（或重新加入）SQL 节点与现有 SQL 节点上的数据库的同步现在正确地利用数据字典，以便任何可能被该 SQL 节点忽略的数据库级操作（CREATE DATABASE、ALTER DATABASE或DROP DATABASE）在连接（或重新连接）到集群时现在在其上正确地复制。
  作为启动时执行的模式同步过程的一部分，SQL 节点现在会将集群数据节点上的所有数据库与其自己的数据字典进行比较，如果发现任何数据库在 SQL 节点的数据字典中缺失，则 SQL 节点通过执行CREATE DATABASE语句在本地安装它。因此，所创建的数据库使用的是在执行该语句时在此 SQL 节点上生效的默认 MySQL 服务器数据库属性（例如由character_set_database和collation_database确定的属性）。
  
• NDB 元数据更改检测和同步。 NDB 8.0 实现了一种新的机制，用于检测数据对象（如表、表空间和日志文件组）的元数据更新与 MySQL 数据字典之间的不一致。这是通过一个线程，即NDB元数据更改监视线程，在后台定期检查NDB数据字典和 MySQL 数据字典之间的不一致性来完成的。默认情况下，监视器每隔60 秒执行一次元数据检查。可以通过设置ndb_metadata_check_interval系统变量的值来调整轮询间隔；通过将ndb_metadata_check系统变量设置为OFF可以完全禁用轮询。状态变量Ndb_metadata_detected_count显示自上次启动mysqld以来检测到不一致性的次数。NDB确保在启动后的操作期间，由元数据更改监视器线程提交的NDB数据库、表、日志文件组和表空间对象会被NDB binlog 线程自动检查不匹配并同步。NDB 8.0 增加了两个与自动同步相关的状态变量：Ndb_metadata_synced_count显示自动同步的对象数量；Ndb_metadata_excluded_count指示同步失败的对象数量（在 NDB 8.0.22 之前，此变量名为Ndb_metadata_blacklist_size）。此外，您可以通过检查集群日志查看已同步的对象。将ndb_metadata_sync系统变量设置为true会覆盖为ndb_metadata_check_interval和ndb_metadata_check所做的任何设置，导致更改监视器线程开始连续元数据更改检测。在 NDB 8.0.22 及更高版本中，将ndb_metadata_sync设置为true会清除先前同步失败的对象列表，这意味着不再需要发现单个表或通过重新连接 SQL 节点到集群来重新触发同步。此外，将此变量设置为false会清除等待重新尝试的对象列表。从 NDB 8.0.21 开始，比日志消息或状态变量提供有关自动同步当前状态的更详细信息的两个新表已添加到 MySQL 性能模式中。这些表在此列出：

• ndb_sync_pending_objects：包含在NDB字典和 MySQL 数据字典之间检测到不匹配的数据库对象信息（且未被排除在自动同步之外）。
  
• ndb_sync_excluded_objects：包含由于无法在 NDB 字典和 MySQL 数据字典之间同步而被排除的 NDB 数据库对象的信息，因此需要手动干预。
  

• 这些表中的一行提供了数据库对象的父模式、名称和类型。对象类型包括模式、表空间、日志文件组和表。 （如果对象是日志文件组或表空间，则父模式为 NULL。）此外，ndb_sync_excluded_objects 表显示了对象被排除的原因。
  这些表仅在启用了 NDBCLUSTER 存储引擎支持时存在。有关这些表的更多信息，请参阅 第 29.12.12 节，“性能模式 NDB Cluster 表”。
  
• NDB 表额外元数据的更改。 NDB 表的额外元数据属性用于存储来自 MySQL 数据字典的序列化元数据，而不是像以前版本中那样存储表的二进制表示。（这是一个 .frm 文件，MySQL Server 不再使用—参见 第十六章，MySQL 数据字典。）作为支持此更改的一部分，表的额外元数据的可用大小已增加。这意味着在 NDB Cluster 8.0 中创建的 NDB 表与以前的 NDB Cluster 版本不兼容。在以前的版本中创建的表可以在 NDB 8.0 中使用，但之后不能被较早版本打开。
  可以使用 NDB API 方法 getExtraMetadata() 和 setExtraMetadata() 访问此元数据。
  欲了解更多信息，请参阅 第 25.3.7 节，“NDB Cluster 升级和降级”。
  
• 使用 .frm 文件进行表的即时升级。 在 NDB 7.6 及更早版本中创建的表包含以压缩的 .frm 文件形式存储的元数据，而这在 MySQL 8.0 中已不再支持。为了方便在线升级到 NDB 8.0，NDB 对此元数据进行即时转换，并将其写入 MySQL Server 的数据字典中，从而使 NDB Cluster 8.0 中的 mysqld 能够与该表一起工作，而不会阻止先前版本的 NDB 软件继续使用该表。
  重要提示
  一旦表的结构在 NDB 8.0 中被修改，其元数据将使用数据字典存储，之后将无法被 NDB 7.6 及更早版本访问。
  这一增强还使得可以将使用早期版本创建的NDB备份还原到运行 NDB 8.0（或更高版本）的集群中。
  
• 元数据一致性检查错误日志。 作为之前在 NDB 8.0 中完成的工作的一部分，元数据检查作为在 NDB 字典中的NDB表与其在 MySQL 数据字典中的对应之间的自动同步的一部分执行，包括表的名称、存储引擎和内部 ID。 从 NDB 8.0.23 开始，所检查的属性范围扩展到包括以下数据对象的属性：

• 列
  
• 索引
  
• 外键
  

• 此外，现在任何元数据属性不匹配的详细信息都将写入 MySQL 服务器错误日志。 根据不一致性是在表级别还是在列、索引或外键级别发现的，错误日志消息的格式略有不同。 表级属性不匹配导致的日志错误的格式如下，其中*property是属性名称，ndb_value是存储在 NDB 字典中的属性值，mysqld_value*是存储在 MySQL 数据字典中的属性值：

Diff in '*property*' detected, '*ndb_value*' != '*mysqld_value*'

• 对于列、索引和外键属性不匹配的情况，格式如下，其中*obj_type是column、index或foreign key之一，obj_name*是对象的名称：

Diff in *obj_type* '*obj_name*.*property*' detected, '*ndb_value*' != '*mysqld_value*'

• 在将NDB表安装到充当 NDB 集群中 SQL 节点的任何mysqld的数据字典中时，将执行元数据检查。 如果mysqld是调试编译的，则还会在执行CREATE TABLE语句时进行检查，并在打开NDB表时进行检查。

• 与 NDB_STORED_USER 同步用户权限。 在 NDB 8.0 中提供了一种新的机制，使用NDB_STORED_USER权限在 SQL 节点之间共享和同步用户、角色和权限。 NDB 7.6 及更早版本中实现的分布式权限（请参阅使用共享授权表进行分布式权限）不再受支持。
  一旦在 SQL 节点上创建了用户帐户，用户及其权限可以存储在NDB中，并通过发出类似于以下语句的GRANT语句在集群中的所有 SQL 节点之间共享：

GRANT NDB_STORED_USER ON *.* TO 'jon'@'localhost';

• NDB_STORED_USER始终具有全局范围，并且必须使用ON *.*授予。 诸如mysql.session@localhost或mysql.infoschema@localhost之类的系统保留帐户不能被分配此权限。
  通过发出适当的 GRANT NDB_STORED_USER 语句，角色也可以在 SQL 节点之间共享。将此类角色分配给用户不会导致用户共享；必须显式地向每个用户授予 NDB_STORED_USER 权限。
  拥有 NDB_STORED_USER 的用户或角色及其权限会在加入给定 NDB 集群的所有 SQL 节点之后立即共享。可以从任何连接的 SQL 节点进行此类更改，但建议仅从指定的 SQL 节点进行，因为无法保证不同 SQL 节点影响权限的语句执行顺序在所有 SQL 节点上相同。
  在 NDB 8.0.27 之前，用户或角色的权限更改会立即与所有连接的 SQL 节点同步。从 MySQL 8.0.27 开始，更新权限时，SQL 节点会获取全局读锁，以防止多个 SQL 节点执行的并发更改导致死锁。
  升级的影响。 由于 MySQL 服务器权限系统的更改（请参阅第 8.2.3 节，“授权表”），在 NDB 8.0 中，使用 NDB 存储引擎的权限表无法正常运行。保留在 NDB 7.6 或更早版本中创建的此类权限表是安全的，但不是必需的，因为它们不再用于访问控制。在 NDB 8.0 中，作为 SQL 节点的 mysqld 检测到这些表在 NDB 中时，会向 MySQL 服务器日志写入警告，并在本地创建 InnoDB 阴影表；这样的阴影表会在连接到集群的每个 MySQL 服务器上创建。在从 NDB 7.6 或更早版本升级时，可以在所有作为 SQL 节点的 MySQL 服务器升级后安全地使用 ndb_drop_table 删除使用 NDB 的权限表（请参阅第 25.3.7 节，“升级和降级 NDB 集群”）。
  ndb_restore 实用程序的 --restore-privilege-tables 选项已被弃用，但在 NDB 8.0 中仍然受到尊重，并且仍然可以用于将从先前版本的 NDB 集群备份中获取的分布式权限表恢复到运行 NDB 8.0 的集群中。这些表的处理方式如前一段所述。
  共享用户和授权存储在ndb_sql_metadata表中，默认情况下，ndb_restore在 NDB 8.0 中不会恢复这些内容；您可以指定--include-stored-grants选项来执行此操作。
  更多信息请参见第 25.6.13 节，“特权同步和 NDB_STORED_USER”。
• INFORMATION_SCHEMA 更改。 在 Information Schema FILES表中关于磁盘数据文件信息的显示进行了以下更改：

• 表空间和日志文件组不再在FILES表中表示。（这些构造实际上不是文件。）
  
• 每个数据文件现在在FILES表中由一行表示。每个撤销日志文件也仅由一行在此表中表示。（以前，在每个数据节点上的每个这些文件的副本都显示为一行。）
  

• 此外，INFORMATION_SCHEMA表现在为 MySQL Cluster 表填充表空间统计信息。（Bug #27167728）

MySQL8 中文参考（八十五）（3）https://developer.aliyun.com/article/1566066