MySQL8 中文参考（八十五）

原文：docs.oracle.com/javase/tutorial/reallybigindex.html

22.5.7 监控 X 插件

译文：dev.mysql.com/doc/refman/8.0/en/x-plugin-system-monitoring.html

对于一般的 X 插件监控，请使用其公开的状态变量。参见第 22.5.6.3 节，“X 插件状态变量”。有关专门监视消息压缩效果的信息，请参见 X 插件的连接压缩监控。

监控 X 插件生成的 SQL

本节描述了如何监视运行 X DevAPI 操作时 X 插件生成的 SQL 语句。当您执行 CRUD 语句时，它会被转换为 SQL 并针对服务器执行。要能够监视生成的 SQL，必须启用 Performance Schema 表。SQL 注册在performance_schema.events_statements_current、performance_schema.events_statements_history和performance_schema.events_statements_history_long表下。以下示例使用了在本节快速入门教程中导入的world_x模式。我们在 Python 模式下使用 MySQL Shell，并使用\sql命令，该命令使您能够发出 SQL 语句而无需切换到 SQL 模式。这很重要，因为如果您尝试切换到 SQL 模式，该过程将显示此操作的结果而不是 X DevAPI 操作。如果您使用 JavaScript 模式下的 MySQL Shell，则\sql命令的使用方式相同。

检查events_statements_history消费者是否已启用。问题：

mysql-py> \sql SELECT enabled FROM performance_schema.setup_consumers WHERE NAME = 'events_statements_history'
+---------+
| enabled |
+---------+
| YES     |
+---------+

检查所有仪器是否向消费者报告数据。问题：

mysql-py> \sql SELECT NAME, ENABLED, TIMED FROM performance_schema.setup_instruments WHERE NAME LIKE 'statement/%' AND NOT (ENABLED and TIMED)

如果此语句报告至少一行，则需要启用仪器。请参见第 29.4 节，“Performance Schema 运行时配置”。

获取当前连接的线程 ID。问题：

mysql-py> \sql SELECT thread_id INTO @id FROM performance_schema.threads WHERE processlist_id=connection_id()

执行您想要查看生成的 SQL 的 X DevAPI CRUD 操作。例如，问题：

mysql-py> db.CountryInfo.find("Name = :country").bind("country", "Italy")

您必须不再发出任何操作，以便下一步显示正确的结果。

显示由此线程 ID 执行的最后一个 SQL 查询。问题：

mysql-py> \sql SELECT THREAD_ID, MYSQL_ERRNO,SQL_TEXT FROM performance_schema.events_statements_history WHERE THREAD_ID=@id ORDER BY TIMER_START DESC LIMIT 1;
+-----------+-------------+--------------------------------------------------------------------------------------+
| THREAD_ID | MYSQL_ERRNO | SQL_TEXT                                                                             |
+-----------+-------------+--------------------------------------------------------------------------------------+
|        29 |           0 | SELECT doc FROM `world_x`.`CountryInfo` WHERE (JSON_EXTRACT(doc,'$.Name') = 'Italy') |
+-----------+-------------+--------------------------------------------------------------------------------------+

结果显示了基于最近语句生成的 X 插件 SQL，本例中为上一步的 X DevAPI CRUD 操作。

第二十三章 InnoDB 集群

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

本章介绍了 MySQL InnoDB 集群，它结合了 MySQL 技术，使您能够部署和管理 MySQL 的完整集成高可用性解决方案。本内容是 InnoDB 集群的高级概述，有关完整文档，请参阅 MySQL InnoDB 集群。

重要

InnoDB 集群不支持 MySQL NDB 集群。有关 MySQL NDB 集群的更多信息，请参阅第二十五章 MySQL NDB 集群 8.0和第 25.2.6 节，“使用 InnoDB 的 MySQL 服务器与 NDB 集群比较”。

InnoDB 集群由至少三个 MySQL 服务器实例组成，并提供高可用性和扩展功能。InnoDB 集群使用以下 MySQL 技术：

• MySQL Shell，这是一个用于 MySQL 的高级客户端和代码编辑器。
• MySQL 服务器，以及组复制，使一组 MySQL 实例能够提供高可用性。InnoDB 集群提供了一种替代的、易于使用的编程方式来处理组复制。
• MySQL 路由器，一个轻量级中间件，提供应用程序与 InnoDB 集群之间的透明路由。

以下图表显示了这些技术如何共同工作的概述：

图 23.1 InnoDB 集群概述

三个 MySQL 服务器被组合在一起形成一个高可用性集群。其中一个服务器是读/写主实例，另外两个是只读次要实例。组复制用于将数据从主实例复制到次要实例。MySQL 路由器连接客户端应用程序（在本例中是 MySQL 连接器）到主实例。

基于 MySQL 组复制构建，提供了诸如自动成员管理、容错性、自动故障转移等功能。InnoDB 集群通常以单主模式运行，其中一个主实例（读写）和多个次要实例（只读）。高级用户还可以利用多主模式，其中所有实例都是主实例。甚至可以在 InnoDB 集群在线时更改集群的拓扑结构，以确保最高可能的可用性。

你可以使用 AdminAPI 来操作 InnoDB Cluster，该 API 作为 MySQL Shell 的一部分提供。AdminAPI 支持 JavaScript 和 Python，并且非常适合用于脚本编写和自动化部署 MySQL 以实现高可用性和可扩展性。通过使用 MySQL Shell 的 AdminAPI，你可以避免手动配置许多实例的需要。相反，AdminAPI 提供了一个有效的现代界面来管理一组 MySQL 实例，并使你能够从一个中央工具中进行部署、管理和监控。

要开始使用 InnoDB Cluster，你需要下载和安装 MySQL Shell。你需要一些安装了 MySQL Server 实例的主机，并且你也可以安装 MySQL Router。

InnoDB Cluster 支持 MySQL Clone，这使得实例的部署变得简单。在过去，为了在一个 MySQL 实例集合中加入一个新实例，你需要手动将事务传输到加入的实例中。这可能涉及制作文件副本、手动复制等操作。使用 InnoDB Cluster，你只需简单地添加一个实例到集群中，它就会自动部署。

同样，InnoDB Cluster 与 MySQL Router 紧密集成，你可以使用 AdminAPI 来与它们一起工作。MySQL Router 可以根据 InnoDB Cluster 自动配置自身，这个过程称为引导，这消除了你手动配置路由的需要。MySQL Router 然后透明地连接客户端应用程序到 InnoDB Cluster，为客户端连接提供路由和负载均衡。这种集成还使你能够使用 AdminAPI 管理针对 InnoDB Cluster 引导的一些 MySQL Router 的方面。InnoDB Cluster 状态信息包括针对集群引导的 MySQL Router 的详细信息。操作使你能够在集群级别创建 MySQL Router 用户，与引导到集群的 MySQL Router 一起工作等。

欲了解更多关于这些技术的信息，请参阅描述中链接的用户文档。除了这些用户文档外，还有所有 AdminAPI 方法的开发人员文档在 MySQL Shell JavaScript API 参考或 MySQL Shell Python API 参考中，可从 Connectors and APIs 获取。

第二十四章 InnoDB ReplicaSet

原文：dev.mysql.com/doc/refman/8.0/en/mysql-innodb-replicaset-introduction.html

本章介绍了 MySQL InnoDB ReplicaSet，它结合了 MySQL 技术，使您能够部署和管理第十九章，复制。本内容是 InnoDB ReplicaSet 的高级概述，有关完整文档，请参阅 MySQL InnoDB ReplicaSet。

一个 InnoDB ReplicaSet 至少由两个 MySQL 服务器实例组成，并提供您熟悉的所有 MySQL 复制功能，如读取扩展和数据安全。InnoDB ReplicaSet 使用以下 MySQL 技术：

• MySQL Shell，这是一个用于 MySQL 的高级客户端和代码编辑器。
• MySQL 服务器和第十九章，复制，使一组 MySQL 实例能够提供可用性和异步读取扩展。InnoDB ReplicaSet 提供了一种替代的、易于使用的编程方式来处理复制。
• MySQL Router，一个轻量级中间件，提供应用程序与 InnoDB ReplicaSet 之间的透明路由。

InnoDB ReplicaSet 的接口类似于 MySQL InnoDB Cluster，您可以使用 MySQL Shell 来操作 MySQL 服务器实例作为一个 ReplicaSet，并且 MySQL Router 也与 InnoDB Cluster 紧密集成。

基于 MySQL 复制，InnoDB ReplicaSet 有一个主实例，它复制到一个或多个次要实例。InnoDB ReplicaSet 不提供 InnoDB Cluster 提供的所有功能，如自动故障转移或多主模式。但是，它支持配置、添加和删除实例等功能的方式类似。例如，在发生故障时，您可以手动切换到或故障转移到次要实例。甚至可以采用现有的复制部署，然后将其管理为 InnoDB ReplicaSet。

您可以使用 AdminAPI 来操作 InnoDB ReplicaSet，该 API 作为 MySQL Shell 的一部分提供。AdminAPI 可用于 JavaScript 和 Python，并非常适合脚本编写和自动化部署 MySQL 以实现高可用性和可伸缩性。通过使用 MySQL Shell 的 AdminAPI，您可以避免手动配置许多实例的需要。相反，AdminAPI 提供了一种有效的现代接口来管理 MySQL 实例集，并使您能够从一个中心工具中进行部署、管理和监控。

要开始使用 InnoDB ReplicaSet，您需要下载和安装 MySQL Shell。您需要一些安装了 MySQL Server 实例的主机，并且您还可以安装 MySQL Router。

InnoDB ReplicaSet 支持 MySQL Clone，这使您可以简单地提供实例。过去，在新实例加入 MySQL 复制部署之前，您需要以某种方式手动将事务传输到加入实例。这可能涉及制作文件副本，手动复制它们等等。您只需添加一个实例到复制集中，它就会自动提供。

同样，InnoDB ReplicaSet 与 MySQL Router 紧密集成，您可以使用 AdminAPI 一起使用它们。MySQL Router 可以根据 InnoDB ReplicaSet 自动配置自身，在一个称为引导过程的过程中，这样您就无需手动配置路由。MySQL Router 然后透明地连接客户端应用程序到 InnoDB ReplicaSet，为客户端连接提供路由和负载平衡。这种集成还使您能够使用 AdminAPI 管理针对 InnoDB ReplicaSet 引导的 MySQL Router 的某些方面。InnoDB ReplicaSet 状态信息包括有关针对 ReplicaSet 引导的 MySQL Router 的详细信息。操作使您能够在 ReplicaSet 级别创建 MySQL Router 用户，与针对 ReplicaSet 引导的 MySQL Router 一起工作，等等。

关于这些技术的更多信息，请参阅描述中链接的用户文档。除了这些用户文档外，还有关于 MySQL Shell JavaScript API 参考或 MySQL Shell Python API 参考中所有 AdminAPI 方法的开发人员文档，可从 Connectors and APIs 获取。

第二十五章 MySQL NDB 集群 8.0

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

目录

25.1 通用信息

25.2 NDB 集群概述

25.2.1 NDB 集群核心概念

25.2.2 NDB 集群节点、节点组、片段副本和分区

25.2.3 NDB 集群的硬件、软件和网络要求

25.2.4 MySQL NDB 集群 8.0 中的新功能

25.2.5 NDB 8.0 中新增、弃用或移除的选项、变量和参数

25.2.6 使用 InnoDB 的 MySQL 服务器与 NDB 集群的比较

25.2.7 NDB 集群的已知限制

25.3 NDB 集群安装

25.3.1 在 Linux 上安装 NDB 集群

25.3.2 在 Windows 上安装 NDB 集群

25.3.3 NDB 集群的初始配置

25.3.4 NDB 集群的初始启动

25.3.5 具有表和数据的 NDB 集群示例

25.3.6 NDB 集群的安全关闭和重启

25.3.7 NDB 集群的升级和降级

25.3.8 NDB 集群自动安装程序（不再支持）

25.4 NDB 集群的配置

25.4.1 NDB 集群的快速测试设置

25.4.2 NDB 集群配置参数、选项和变量概述

25.4.3 NDB 集群配置文件

25.4.4 使用高速互连与 NDB 集群

25.5 NDB 集群程序

25.5.1 ndbd — NDB 集群数据节点守护程序

25.5.2 ndbinfo_select_all — 从 ndbinfo 表中选择

25.5.3 ndbmtd — NDB 集群数据节点守护程序（多线程）

25.5.4 ndb_mgmd — NDB 集群管理服务器守护程序

25.5.5 ndb_mgm — NDB 集群管理客户端

25.5.6 ndb_blob_tool — 检查和修复 NDB 集群表的 BLOB 和 TEXT 列

25.5.7 ndb_config — 提取 NDB 集群配置信息

25.5.8 ndb_delete_all — 从 NDB 表中删除所有行

25.5.9 ndb_desc — 描述 NDB 表

25.5.10 ndb_drop_index — 从 NDB 表中删除索引

25.5.11 ndb_drop_table — 删除 NDB 表

25.5.12 ndb_error_reporter — NDB 错误报告实用程序

25.5.13 ndb_import — 将 CSV 数据导入 NDB

25.5.14 ndb_index_stat — NDB 索引统计实用程序

25.5.15 ndb_move_data — NDB 数据复制实用程序

25.5.16 ndb_perror — 获取 NDB 错误消息信息

25.5.17 ndb_print_backup_file — 打印 NDB 备份文件内容

25.5.18 ndb_print_file — 打印 NDB 磁盘数据文件内容

25.5.19 ndb_print_frag_file — 打印 NDB 片段列表文件内容

25.5.20 ndb_print_schema_file — 打印 NDB 模式文件内容

25.5.21 ndb_print_sys_file — 打印 NDB 系统文件内容

25.5.22 ndb_redo_log_reader — 检查和打印集群重做日志的内容

25.5.23 ndb_restore — 恢复 NDB 集群备份

25.5.24 ndb_secretsfile_reader — 从加密的 NDB 数据文件中获取关键信息

25.5.25 ndb_select_all — 打印 NDB 表中的行

25.5.26 ndb_select_count — 打印 NDB 表的行计数

25.5.27 ndb_show_tables — 显示 NDB 表列表

25.5.28 ndb_size.pl — NDBCLUSTER 大小需求估算器

25.5.29 ndb_top — 查看 NDB 线程的 CPU 使用信息

25.5.30 ndb_waiter — 等待 NDB 集群达到给定状态

25.5.31 ndbxfrm — 压缩、解压、加密和解密由 NDB 集群创建的文件

25.6 NDB 集群的管理

25.6.1 NDB 集群管理客户端中的命令

25.6.2 NDB 集群日志消息

25.6.3 在 NDB 集群中生成的事件报告

25.6.4 NDB 集群启动阶段总结

25.6.5 执行 NDB Cluster 的滚动重启

25.6.6 NDB Cluster 单用户模式

25.6.7 在线添加 NDB Cluster 数据节点

25.6.8 NDB Cluster 的在线备份

25.6.9 将数据导入到 MySQL Cluster

25.6.10 NDB Cluster 的 MySQL 服务器用法

25.6.11 NDB Cluster 磁盘数据表

25.6.12 NDB Cluster 中使用 ALTER TABLE 的在线操作

25.6.13 权限同步和 NDB_STORED_USER

25.6.14 NDB Cluster 的文件系统加密

25.6.15 NDB API 统计计数器和变量

25.6.16 ndbinfo：NDB Cluster 信息数据库

25.6.17 NDB Cluster 的 INFORMATION_SCHEMA 表

25.6.18 NDB Cluster 和性能模式

25.6.19 快速参考：NDB Cluster SQL 语句

25.6.20 NDB Cluster 安全问题

25.7 NDB Cluster 复制

25.7.1 NDB Cluster 复制：缩写和符号

25.7.2 NDB Cluster 复制的一般要求

25.7.3 NDB Cluster 复制中已知问题

25.7.4 NDB Cluster 复制模式和表

25.7.5 为复制准备 NDB Cluster

25.7.6 启动 NDB Cluster 复制（单一复制通道）

25.7.7 使用两个复制通道进行 NDB Cluster 复制

25.7.8 使用 NDB Cluster 复制实现故障切换

25.7.9 使用 NDB Cluster 复制进行 NDB Cluster 备份

25.7.10 NDB Cluster 复制：双向和循环复制

25.7.11 使用多线程应用程序的 NDB Cluster 复制

25.7.12 NDB Cluster 复制冲突解决

25.8 NDB Cluster 发行说明

本章提供关于 MySQL NDB Cluster 的信息，这是 MySQL 的高可用性、高冗余性版本，适用于分布式计算环境，使用NDB存储引擎（也称为NDBCLUSTER）来实现在集群中运行多台带有 MySQL 服务器和其他软件的计算机。NDB Cluster 8.0，现已作为通用可用性（GA）版本发布（从版本 8.0.19 开始），包含了NDB存储引擎的 8.0 版本。本章还提供了特定于 NDB Cluster 8.0 的信息，并覆盖了 8.0.34 版本。基于 NDB 存储引擎的 NDB Cluster 8.1（NDB 8.1.0）现已作为创新版本发布。请参阅 MySQL NDB Cluster 8.2 有什么新功能，了解 NDB 8.1 与早期版本的区别。NDB Cluster 7.6 和 NDB Cluster 7.5 仍作为 GA 版本提供，分别使用了 7.6 和 7.5 版本的NDB。NDB Cluster 7.6 和 7.5 是之前的 GA 版本，仍在生产中得到支持；有关 NDB Cluster 7.6 的信息，请参阅 NDB Cluster 7.6 有什么新功能。有关 NDB Cluster 7.5 的类似信息，请参阅 NDB Cluster 7.5 有什么新功能。之前的 GA 版本 NDB Cluster 7.4 和 NDB Cluster 7.3 分别包含了NDB的 7.4 和 7.3 版本。NDB 7.4 及更早版本系列不再得到支持或维护。NDB 8.0 和 NDB 8.1 都在生产中得到支持，并建议用于新部署。

25.1 常规信息

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

MySQL NDB Cluster 使用带有NDB存储引擎的 MySQL 服务器。 Oracle 构建的标准 MySQL Server 8.0 二进制版本不包含对NDB存储引擎的支持。 相反，Oracle 的 NDB Cluster 二进制版本用户应升级到支持平台上最新的 NDB Cluster 二进制版本 - 这些版本包括应该适用于大多数 Linux 发行版的 RPM。 从源代码构建的 NDB Cluster 8.0 用户应使用为 MySQL 8.0 提供 NDB 支持所需的选项构建提供的源代码。 （可以在本节后面列出的位置获取源代码的地点。）

重要

MySQL NDB Cluster 不支持 InnoDB Cluster，必须使用带有InnoDB存储引擎的 MySQL Server 8.0 部署，以及未包含在 NDB Cluster 发行版中的其他应用程序。 MySQL Server 8.0 二进制版本不能与 MySQL NDB Cluster 一起使用。 有关部署和使用 InnoDB Cluster 的更多信息，请参阅 MySQL AdminAPI。 第 25.2.6 节，“MySQL Server 使用 InnoDB 与 NDB Cluster 比较”，讨论了NDB和InnoDB存储引擎之间的差异。

支持的平台。 NDB Cluster 目前在许多平台上可用并受支持。 有关特定操作系统版本、操作系统发行版和硬件平台组合的确切支持级别，请参阅www.mysql.com/support/supportedplatforms/cluster.html。

可用性。 NDB Cluster 二进制和源代码包可在dev.mysql.com/downloads/cluster/上的支持平台上获得。

NDB Cluster 发行版本号。 NDB 8.0 遵循与 MySQL Server 8.0 系列发布相同的发布模式，从 MySQL 8.0.13 和 MySQL NDB Cluster 8.0.13 开始。 在本 手册 和其他 MySQL 文档中，我们使用以“NDB”开头的版本号来标识这些以及后续的 NDB Cluster 发行版，这个版本号是 NDB 8.0 发行版中使用的NDBCLUSTER存储引擎的版本号，并且与基于的 MySQL 8.0 服务器版本相同 NDB Cluster 8.0 发行版。

NDB Cluster 软件中使用的版本字符串。 MySQL NDB Cluster 发行版附带的mysql客户端显示的版本字符串使用此格式：

mysql-*mysql_server_version*-cluster

mysql_server_version 代表 NDB Cluster 发行版所基于的 MySQL Server 版本。对于所有 NDB Cluster 8.0 发行版，这是 8.0.*n*，其中 n 是发行号。使用 -DWITH_NDB 或等效选项从源代码构建时，会在版本字符串中添加 -cluster 后缀。（参见 第 25.3.1.4 节，“在 Linux 上从源代码构建 NDB Cluster”，以及 第 25.3.2.2 节，“在 Windows 上从源代码编译和安装 NDB Cluster”。）你可以在 mysql 客户端中看到这种格式的使用，如下所示：

$> mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 8.0.35-cluster Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> SELECT VERSION()\G
*************************** 1\. row ***************************
VERSION(): 8.0.35-cluster 1 row in set (0.00 sec)

使用 MySQL 8.0 的第一个正式发布的 NDB Cluster 版本是 NDB 8.0.19，使用 MySQL 8.0.19。

其他未包含在 MySQL 8.0 发行版中的 NDB Cluster 程序显示的版本字符串采用以下格式：

mysql-*mysql_server_version* ndb-*ndb_engine_version*

mysql_server_version 代表 NDB Cluster 发行版所基于的 MySQL Server 版本。对于所有 NDB Cluster 8.0 发行版，这是 8.0.*n*，其中 n 是发行号。 ndb_engine_version 是此 NDB Cluster 软件版本使用的 NDB 存储引擎的版本。对于所有 NDB 8.0 发行版，此数字与 MySQL Server 版本相同。你可以在 ndb_mgm 客户端的 SHOW 命令输出中看到这种格式的使用，如下所示：

ndb_mgm> SHOW
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @10.0.10.6  (mysql-8.0.35 ndb-8.0.35, Nodegroup: 0, *)
id=2    @10.0.10.8  (mysql-8.0.35 ndb-8.0.35, Nodegroup: 0)

[ndb_mgmd(MGM)] 1 node(s)
id=3    @10.0.10.2  (mysql-8.0.35 ndb-8.0.35)

[mysqld(API)]   2 node(s)
id=4    @10.0.10.10  (mysql-8.0.35 ndb-8.0.35)
id=5 (not connected, accepting connect from any host)

与标准 MySQL 8.0 版本的兼容性。 虽然许多标准 MySQL 架构和应用程序可以在 NDB Cluster 中运行，但未经修改的应用程序和数据库架构可能会略有不兼容或在使用 NDB Cluster 时性能不佳（参见《第 25.2.7 节，“NDB Cluster 的已知限制”》）。大多数问题都可以克服，但这也意味着您很难将当前使用例如 MyISAM 或 InnoDB 的现有应用程序数据存储切换到使用 NDB 存储引擎，而不考虑架构、查询和应用程序可能发生变化的可能性。没有使用 NDB 支持编译的 mysqld（即没有使用 -DWITH_NDB 或 -DWITH_NDBCLUSTER_STORAGE_ENGINE 构建的）无法作为使用它构建的 mysqld 的直接替代品。

NDB Cluster 开发源码树。 NDB Cluster 开发树也可以从 github.com/mysql/mysql-server 访问。

在 github.com/mysql/mysql-server 维护的 NDB Cluster 开发源代码受 GPL 许可。有关使用 Git 获取 MySQL 源代码并自行构建的信息，请参阅《第 2.8.5 节，“使用开发源码树安装 MySQL”》。

注意

与 MySQL Server 8.0 一样，NDB Cluster 8.0 版本是使用 CMake 构建的。

NDB Cluster 8.0 从 NDB 8.0.19 开始作为正式版本发布，建议用于新部署。NDB Cluster 7.6 和 7.5 是之前的正式版本，仍在生产中得到支持；有关 NDB Cluster 7.6 的信息，请参阅《NDB Cluster 7.6 有什么新特性》。有关 NDB Cluster 7.5 的类似信息，请参阅《NDB Cluster 7.5 有什么新特性》。NDB Cluster 7.4 和 7.3 是之前的正式版本，不再维护。我们建议新的生产部署使用 MySQL NDB Cluster 8.0。

本章内容可能会随着 NDB Cluster 的不断发展而进行修订。有关 NDB Cluster 的其他信息可以在 MySQL 网站上找到，网址为 www.mysql.com/products/cluster/。

额外资源。 关于 NDB Cluster 的更多信息可以在以下地方找到：

• 欲了解关于 NDB Cluster 的一些常见问题的答案，请参阅 Section A.10, “MySQL 8.0 FAQ: NDB Cluster”。
• NDB Cluster 论坛：forums.mysql.com/list.php?25。
• 许多 NDB Cluster 的用户和开发者在他们的博客中分享了他们与 NDB Cluster 的经验，并通过PlanetMySQL提供这些内容的订阅。

25.2 NDB Cluster 概述

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

25.2.1 NDB Cluster 核心概念

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

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

25.2.4 MySQL NDB Cluster 8.0 中的新功能

25.2.5 NDB 8.0 中添加、弃用或删除的选项、变量和参数

25.2.6 使用 InnoDB 的 MySQL 服务器与 NDB Cluster 比较

25.2.7 NDB Cluster 已知限制

NDB Cluster 是一种技术，可以在共享无关系统中对内存数据库进行集群化。共享无关架构使系统能够使用非常廉价的硬件，并且对硬件或软件的特定要求最少。

NDB Cluster 设计为没有任何单点故障。在共享无关系统中，预期每个组件都有自己的内存和磁盘，并且不建议或支持使用共享存储机制，如网络共享、网络文件系统和 SAN。

NDB Cluster 将标准 MySQL 服务器与名为NDB的内存集群存储引擎集成在一起（代表“Network DataBase”）。在我们的文档中，术语NDB指的是特定于存储引擎的设置部分，而“MySQL NDB Cluster”指的是一个或多个 MySQL 服务器与NDB存储引擎的组合。

一个 NDB Cluster 由一组计算机（称为主机）组成，每台主机运行一个或多个进程。这些进程称为节点，可能包括 MySQL 服务器（用于访问 NDB 数据）、数据节点（用于存储数据）、一个或多个管理服务器，以及可能的其他专门的数据访问程序。NDB Cluster 中这些组件的关系如下所示：

图 25.1 NDB Cluster 组件

在这个集群中，三个 MySQL 服务器（mysqld 程序）是提供对存储数据的四个数据节点（ndbd 程序）的 SQL 节点。SQL 节点和数据节点受 NDB 管理服务器（ndb_mgmd 程序）控制。各种客户端和 API 可以与 SQL 节点交互 - mysql 客户端、MySQL C API、PHP、Connector/J 和 Connector/NET。还可以使用 NDB API 创建自定义客户端与数据节点或 NDB 管理服务器交互。NDB 管理客户端（ndb_mgm 程序）与 NDB 管理服务器交互。

所有这些程序共同组成一个 NDB 集群（参见第 25.5 节，“NDB 集群程序”）。当数据由NDB存储引擎存储时，表格（和表格数据）存储在数据节点中。这样的表格可以直接从集群中的所有其他 MySQL 服务器（SQL 节点）访问。因此，在一个将数据存储在集群中的工资应用程序中，如果一个应用程序更新了员工的工资，所有查询这些数据的其他 MySQL 服务器都可以立即看到这一变化。

从 NDB 8.0.31 开始，NDB 集群 8.0 SQL 节点使用与 MySQL Server 8.0 发行版提供的相同的mysqld服务器守护程序。在 NDB 8.0.30 和之前的版本中，它与 MySQL Server 提供的mysqld二进制文件在许多关键方面有所不同，而且这两个版本的mysqld是不可互换的。您应该记住，一个未连接到 NDB 集群的任何版本的mysqld实例都无法使用NDB存储引擎，也无法访问任何 NDB 集群数据。

存储在 NDB 集群数据节点中的数据可以进行镜像；集群可以处理单个数据节点的故障，除了一小部分事务由于丢失事务状态而中止之外，没有其他影响。因为事务应用程序预计会处理事务失败，所以这不应该成为问题的源头。

单个节点可以停止和重新启动，然后重新加入系统（集群）。滚动重启（逐个重新启动所有节点）用于进行配置更改和软件升级（参见第 25.6.5 节，“执行 NDB 集群的滚动重启”）。滚动重启也用作在线添加新数据节点的过程的一部分（参见第 25.6.7 节，“在线添加 NDB 集群数据节点”）。有关数据节点、它们在 NDB 集群中的组织方式以及它们如何处理和存储 NDB 集群数据的更多信息，请参见第 25.2.2 节，“NDB 集群节点、节点组、片段副本和分区”。

备份和恢复 NDB Cluster 数据库可以使用 NDB Cluster 管理客户端中找到的 NDB-本地功能以及 NDB Cluster 发行版中包含的 ndb_restore 程序。更多信息，请参见 Section 25.6.8, “Online Backup of NDB Cluster”，以及 Section 25.5.23, “ndb_restore — Restore an NDB Cluster Backup”。您还可以使用标准 MySQL 功能提供的 mysqldump 和 MySQL 服务器来实现此目的。有关更多信息，请参见 Section 6.5.4, “mysqldump — A Database Backup Program”。

NDB Cluster 节点可以使用不同的传输机制进行节点间通信；在大多数实际部署中，使用标准 100 Mbps 或更快的以太网硬件上的 TCP/IP。

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）

使用 ndb_perror 获取错误信息。 已删除了perror的已弃用--ndb选项。请改用ndb_perror来从NDB错误代码获取错误消息信息。（Bug #81704, Bug #81705, Bug #23523926, Bug #23523957）

条件推送增强。 以前，条件推送仅限于将条件推送到引用来自与条件所推送的表相同的列值的谓词项。在 NDB 8.0 中，取消了此限制，使得可以从查询计划中较早的表中引用列值。NDB 8.0 支持比较列表达式的连接，以及在同一表中比较列。要比较的列和列表达式必须完全相同类型；这意味着它们在适用这些属性时也必须具有相同的符号、长度、字符集、精度和比例。在 NDB 8.0.27 之前，被推送的条件不能是推送连接的一部分，当解除此限制时。

下推更大部分条件允许数据节点过滤更多行，从而减少mysqld在连接处理期间必须处理的行数。这些增强的另一个好处是过滤可以在 LDM 线程中并行执行，而不是在 SQL 节点上的单个 mysqld 进程中执行；这有可能显著提高查询性能。

继续适用于被比较的列值之间的类型兼容性的现有规则（参见第 10.2.1.5 节，“引擎条件下推优化”）。

外连接和半连接的下推。 在 NDB 8.0.20 中完成的工作允许许多外连接和半连接（不仅仅是使用主键或唯一键查找的连接）被下推到数据节点（参见第 10.2.1.5 节，“引擎条件下推优化”）。

现在可以下推的扫描外连接包括符合以下条件的连接：

• 表中没有未下推的条件
• 在同一连接嵌套中的其他表或依赖它的上层连接嵌套中没有未下推的条件
• 同一连接嵌套中的所有其他表，或依赖它的上层连接嵌套，也被下推

如果半连接使用索引扫描，并且符合刚才提到的被下推外连接的条件，并且使用firstMatch策略，那么现在可以将其下推（参见第 10.2.2.1 节，“使用半连接转换优化 IN 和 EXISTS 子查询谓词”）。

这些额外的改进是在 NDB 8.0.21 中完成的：

• 通过转换NOT EXISTS和NOT IN查询而由 MySQL 优化器生成的反连接（参见第 10.2.2.1 节，“使用半连接转换优化 IN 和 EXISTS 子查询谓词”）可以被NDB下推到数据节点。 当表中没有未下推的条件，并且查询满足外连接下推必须满足的任何其他条件时，可以执行此操作。
• NDB在尝试从附加的表中检索任何行之前，会尝试识别和评估一个非依赖标量子查询。当它能够这样做时，获得的值将作为下推条件的一部分使用，而不是使用提供值的子查询。

从 NDB 8.0.27 开始，作为下推查询的一部分下推的条件现在可以引用同一下推查询中祖先表的列，但必须满足以下条件：

• 推送的条件可能包括任何比较运算符<，<=，>，>=，=，和<>。
• 被比较的值必须是相同类型，包括长度、精度和比例。
• NULL处理根据 ISO SQL 标准指定的比较语义执行；任何与NULL的比较都返回NULL。

考虑使用此处所示语句创建的表：

CREATE TABLE t (
    x INT PRIMARY KEY, 
    y INT
) ENGINE=NDB;

查询语句如SELECT * FROM t AS m JOIN t AS n ON m.x >= n.y现在可以使用引擎条件推送优化来推送条件列y。

当无法推送连接时，EXPLAIN应提供原因或原因。

更多信息请参见 Section 10.2.1.5, “引擎条件推送优化”。

NDB API 方法branch_col_eq_param()，branch_col_ne_param()，branch_col_lt_param()，branch_col_le_param()，branch_col_gt_param()，和branch_col_ge_param()在 NDB 8.0.27 中作为这项工作的一部分添加。这些NdbInterpretedCode可用于比较列值与参数值。

此外，NdbScanFilter::cmp_param()，也在 NDB 8.0.27 中添加，使得可以定义列值和参数值之间的比较，用于执行扫描。

最大行大小增加。 NDB 8.0 将NDBCLUSTER表中可存储的最大字节数从 14000 增加到 30000 字节。

BLOB或TEXT列继续使用此总数的 264 字节，与以前一样。

NDB表的固定宽度列的最大偏移量为 8188 字节；这与之前的版本保持不变。

有关更多信息，请参见第 25.2.7.5 节，“NDB 集群中数据库对象相关的限制”。

ndb_mgm SHOW 命令和单用户模式。 在 NDB 8.0 中，当集群处于单用户模式时，管理客户端的 SHOW 命令的输出指示在此模式下哪个 API 或 SQL 节点具有独占访问权限。

在线列重命名。 现在可以在线重命名NDB表的列，使用ALGORITHM=INPLACE。有关更多信息，请参见第 25.6.12 节，“NDB 集群中 ALTER TABLE 的在线操作”。

改进的 ndb_mgmd 启动时间。 在 NDB 8.0 中，管理节点守护程序的启动时间已经得到显著改善，具体体现在以下方面：

• 由于将ndb_mgmd以前用于处理配置数据中节点属性的列表数据结构替换为哈希表，管理服务器的整体启动时间已经减少了 6 倍或更多。
• 此外，在集群配置文件中使用的数据和 SQL 节点主机名未出现在管理服务器的hosts文件中时，ndb_mgmd 的启动时间可能比以前短多达 20 倍。

NDB API 增强。 NdbScanFilter::cmp() 和 NdbInterpretedCode 的几种比较方法现在可以用于比较表列值。受影响的NdbInterpretedCode方法在此列出：

• branch_col_eq()
• branch_col_ge()
• branch_col_gt()
• branch_col_le()
• branch_col_lt()
• branch_col_ne()

对于上述列出的所有方法，要比较的表列值必须完全匹配类型，包括长度、精度、有符号性、比例、字符集和排序规则（如适用）。

有关更多信息，请参见各个 API 方法的描述。

离线多线程索引构建。 现在可以指定一组核心用于执行离线多线程构建有序索引的 I/O 线程，而不是执行正常的 I/O 任务，如文件 I/O，压缩或解压缩。在这种情况下，“离线”指的是在父表未被写入时执行有序索引构建；这种构建发生在NDB集群执行节点或系统重启时，或作为使用ndb_restore --rebuild-indexes从备份还原集群的一部分时。

此外，离线索引构建工作的默认行为已修改为使用所有可用于ndbmtd")的核心，而不仅限于为 I/O 线程保留的核心。这样做可以提高重启和还原时间以及性能、可用性和用户体验。

此增强功能的实现如下：

1. BuildIndexThreads的默认值从 0 更改为 128。这意味着离线有序索引构建现在默认是多线程的。
2. TwoPassInitialNodeRestartCopy的默认值从false更改为true。这意味着初始节点重启首先将所有数据从“活动”节点复制到正在启动的节点，而不创建任何索引，然后离线构建有序索引，然后再次将其数据与活动节点同步，即在两次同步之间进行离线索引构建。这使得初始节点重启的行为更像节点的正常重启，并减少了构建索引所需的时间。
3. 为ThreadConfig配置参数定义了一个新的线程类型（idxbld），以允许将离线索引构建线程锁定到特定的 CPU。

此外，NDB现在通过这两个标准区分可访问ThreadConfig的线程类型：

1. 线程是否是执行线程。main，ldm，recv，rep，tc和send类型的线程是执行线程；io，watchdog和idxbld类型的线程不是。
2. 线程分配给特定任务是永久的还是临时的。目前除了idxbld之外的所有线程类型都是永久的。

要获取更多信息，请参阅手册中指定参数的描述。（Bug #25835748, Bug #26928111）

logbuffers 表备份过程信息。 在执行 NDB 备份时，ndbinfo.logbuffers 表现在显示每个数据节点上备份过程中缓冲区使用情况的信息。这通过反映两种新的日志类型的行来实现，除了 REDO 和 DD-UNDO。其中一行具有日志类型 BACKUP-DATA，显示备份期间用于将片段复制到备份文件的数据缓冲区的使用量。另一行具有日志类型 BACKUP-LOG，显示备份期间用于记录备份开始后所做更改的日志缓冲区的使用量。在集群中的每个数据节点的 logbuffers 表中显示这两种 log_type 行。只有在 NDB 备份正在进行时，表中才存在具有这两种日志类型的行。 (Bug #25822988)

Windows 上的 ndbinfo.processes 表。 在 Windows 平台上由 RESTART 用于生成和重新启动 mysqld 的监视进程的进程 ID 现在在 processes 表中显示为 angel_pid。

字符串哈希改进。 在 NDB 8.0 之前，所有字符串哈希都是基于首先将字符串转换为规范化形式，然后对结果的二进制图像进行 MD5 哈希。由于以下原因，这可能会导致一些性能问题：

• 规范化字符串始终会被填充到其完整长度。对于 VARCHAR，这通常涉及添加比原始字符串中的字符更多的空格。
• 字符串库未针对这种空格填充进行优化，在某些情况下增加了相当大的开销。
• 填充语义在字符集之间有所不同，其中一些字符集没有填充到其完整长度。
• 转换后的字符串可能会变得非常庞大，即使没有空格填充；一些 Unicode 9.0 的排序规则可以将单个代码点转换为 100 字节甚至更多的字符数据。
• 后续的 MD5 哈希主要是通过填充空格来实现的，并且效率不是特别高，可能会通过刷新 L1 缓存的大部分内容导致额外的性能损失。

排序规则提供了自己的哈希函数，直接对字符串进行哈希而不是首先创建规范化字符串。此外，对于 Unicode 9.0 排序规则，哈希是在不填充的情况下计算的。NDB 现在在哈希一个被识别为使用 Unicode 9.0 排序规则的字符串时利用这个内置函数。

由于对于其他排序规则，存在着已经在转换后的字符串上进行哈希分区的现有数据库，NDB继续采用先前用于对这些字符串进行哈希的方法，以保持兼容性。（Bug #89590，Bug #89604，Bug #89609，Bug #27515000，Bug #27523758，Bug #27522732）

RESET MASTER 更改。 因为 MySQL 服务器现在使用全局读锁执行RESET MASTER，所以当与 NDB Cluster 一起使用时，此语句的行为在以下两个方面发生了变化：

• 不再保证是同步的；也就是说，现在可能会出现在发出RESET MASTER之前立即进行的读取操作可能要等到二进制日志被轮换后才被记录。
• 现在无论语句是在写入二进制日志的相同 SQL 节点上执行，还是在同一集群中的不同 SQL 节点上执行，它的行为都完全相同。

注意

SHOW BINLOG EVENTS，FLUSH LOGS，以及大多数数据定义语句继续像以前的NDB版本一样以同步方式运行。

ndb_restore 选项用法。 在调用ndb_restore时，现在需要同时使用--nodeid和--backupid选项。

ndb_log_bin 默认值。 NDB 8.0 将ndb_log_bin系统变量的默认值从TRUE更改为FALSE。

动态事务资源分配。 现在，事务协调器中的资源分配是使用动态内存池进行的。这意味着资源分配由数据节点配置参数决定，例如MaxDMLOperationsPerTransaction、MaxNoOfConcurrentIndexOperations、MaxNoOfConcurrentOperations、MaxNoOfConcurrentScans、MaxNoOfConcurrentTransactions、MaxNoOfFiredTriggers、MaxNoOfLocalScans和TransactionBufferMemory现在以这样的方式进行，即如果每个参数所代表的负载都在所有这些资源的目标负载范围内，那么其他这些资源可以被限制，以使总资源不超过可用资源。

作为这项工作的一部分，已添加了几个新的数据节点参数，用于控制DBTC中的事务资源，列在这里：

• ReservedConcurrentIndexOperations
• ReservedConcurrentOperations
• ReservedConcurrentScans
• ReservedConcurrentTransactions
• ReservedFiredTriggers
• ReservedLocalScans
• ReservedTransactionBufferMemory.

有关刚才列出的参数的更多信息，请参阅其描述。

每个数据节点使用多个本地数据管理器进行备份。 NDB 现在可以在每个数据节点上并行执行备份，使用多个本地数据管理器（LDMs）。 （以前，备份是在数据节点之间并行进行的，但在数据节点进程内部始终是串行的。）在 ndb_mgm 客户端的 START BACKUP 命令中不需要特殊的语法来启用此功能，但所有数据节点必须使用多个 LDMs。 这意味着数据节点必须运行 ndbmtd（ndbd 是单线程的，因此始终只有一个 LDM）并且在进行备份之前必须配置为使用多个 LDMs；您可以通过为多线程数据节点配置参数 MaxNoOfExecutionThreads 或 ThreadConfig 之一选择适当的设置来实现这一点。

使用多个 LDMs 进行备份会在 BACKUP/BACKUP-*backup_id*/ 目录下创建子目录，每个 LDM 一个。ndb_restore 现在会自动检测这些子目录，如果存在，则尝试并行恢复备份；详细信息请参见 第 25.5.23.3 节，“从并行备份中恢复”。 （单线程备份将像以前的 NDB 版本一样恢复。）还可以通过修改通常的恢复过程，使用先前版本的 NDB 集群的 ndb_restore 二进制文件来恢复并行备份；第 25.5.23.3.2 节，“串行恢复并行备份” 提供了如何执行此操作的信息。

您可以通过在集群的全局配置文件（config.ini）的 [ndbd default] 部分为所有数据节点将 EnableMultithreadedBackup 数据节点参数设置为 0 来强制创建单线程备份。

二进制配置文件增强。 NDB 8.0 使用了管理服务器二进制配置文件的新格式。以前，集群配置文件中最多可以出现 16381 个部分；现在，部分的最大数量为 4G。这旨在支持比以前更大数量的节点在集群中。

升级到新格式相对无缝，并且很少需要手动干预，因为管理服务器仍然可以无问题地读取旧格式。从 NDB 8.0 降级到旧版本的 NDB 集群软件需要手动删除任何二进制配置文件，或者使用--initial选项启动旧管理服务器二进制文件。

欲了解更多信息，请参阅第 25.3.7 节，“NDB 集群升级和降级”。

增加数据节点数量。 NDB 8.0 将每个集群支持的数据节点最大数量增加到 144（以前为 48）。数据节点现在可以使用范围为 1 到 144 的节点 ID。

以前，管理节点的推荐节点 ID 为 49 和 50。这些仍然支持用作管理节点，但将它们用作此类节点会限制数据节点的最大数量为 142；因此，现在建议将节点 ID 145 和 146 用于管理节点。

作为这项工作的一部分，用于数据节点sysfile的格式已更新为版本 2。该文件记录了每个节点的最后全局检查点索引、重启状态和节点组成员资格等信息（参见 NDB 集群数据节点文件系统目录）。

RedoOverCommitCounter 和 RedoOverCommitLimit 更改。 由于将它们设置为 0 的语义存在歧义，因此数据节点配置参数RedoOverCommitCounter和RedoOverCommitLimit的最小值已增加到 1。

ndb_autoincrement_prefetch_sz 更改。 ndb_autoincrement_prefetch_sz服务器系统变量的默认值增加到 512。

参数最大值和默认值的更改。 NDB 8.0 对配置参数的最大值和默认值进行了以下更改：

• DataMemory的最大值增加到 16TB。
• DiskPageBufferMemory的最大值也增加到 16TB。
• 默认值StringMemory已增加至 25%。
• LcpScanProgressTimeout的默认值已增加至 180 秒。

磁盘数据检查点改进。 NDB Cluster 8.0 提供了许多新的增强功能，有助于在使用非易失性内存设备（如固态硬盘和 NVMe 规范的设备）时减少磁盘数据表和表空间的检查点延迟。这些改进包括以下内容：

• 避免检查点磁盘写入的突发
• 加速当重做日志或撤销日志变满时的磁盘数据表空间检查点
• 在必要时平衡磁盘和内存检查点之间的检查点
• 保护磁盘设备免受过载，以确保在高负载下低延迟

作为这项工作的一部分，已添加了两个数据节点配置参数。MaxDiskDataLatency设定了磁盘访问允许的延迟上限，并导致超过此时间长度的事务被中止。DiskDataUsingSameDisk使得可以利用将磁盘数据表空间放置在不同磁盘上，从而增加这些表空间的检查点执行速度。

此外，ndbinfo数据库中的三个新表提供有关磁盘数据性能的信息：

• diskstat表报告过去一秒钟对磁盘数据表空间的写入
• diskstats_1sec表报告过去 20 秒对磁盘数据表空间的写入
• pgman_time_track_stats表报告与磁盘数据表空间相关的磁盘操作的延迟

内存分配和 TransactionMemory。 新的TransactionMemory参数简化了数据节点内存用于事务的分配，作为汇总事务和本地数据管理器（LDM）内存的工作的一部分。该参数旨在取代已被弃用的几个旧事务内存参数。

事务内存现在可以通过以下三种方式之一设置：

• 几个配置参数与TransactionMemory不兼容。如果设置了其中任何一个，就无法设置TransactionMemory（请参阅与 TransactionMemory 不兼容的参数），并且数据节点的事务内存将如同在 NDB 8.0 之前一样确定。 注意 尝试在config.ini文件中同时设置TransactionMemory和任何这些参数会阻止管理服务器启动。
• 如果设置了TransactionMemory，则该值用于确定事务内存。如果已设置了前面提到的任何不兼容参数，则无法设置TransactionMemory。
• 如果没有设置任何不兼容的参数，并且也没有设置TransactionMemory，则事务内存由NDB设置。

更多信息，请参阅TransactionMemory的描述，以及第 25.4.3.13 节，“数据节点内存管理”。

支持额外的片段副本。 NDB 8.0 将在生产中支持的片段副本的最大数量从两个增加到四个。（以前，可以将NoOfReplicas设置为 3 或 4，但这在测试中并未得到官方支持或验证。）

分片恢复。 从 NDB 8.0.20 开始，可以将备份分成大致相等的部分（片段），并使用两个新选项并行恢复这些片段，这两个选项已经在ndb_restore中实现：

• --num-slices确定备份应分成的片段数。
• --slice-id提供要由当前实例的ndb_restore恢复的片段的 ID。

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

更多信息，请参阅ndb_restore的--num-slices选项的描述。

从任何片段副本读取已启用。 对于所有NDB表，默认启用从任何片段副本读取。这意味着ndb_read_backup系统变量的默认值现在为 ON，并且在创建新的NDB表时，NDB_TABLE注释选项READ_BACKUP的值为 1。启用从任何片段副本读取显著提高了从NDB表读取的性能，对写入的影响很小。

欲了解更多信息，请参阅ndb_read_backup系统变量的描述，以及 Section 15.1.20.12，“设置 NDB 注释选项”。

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

欲了解更多信息，请参阅 Section 25.5.6，“ndb_blob_tool — 检查和修复 NDB Cluster 表的 BLOB 和 TEXT 列”。

ndbinfo 版本控制。 NDB 8.0.20 及更高版本支持ndbinfo表的版本控制，并在内部维护其表的当前定义。在启动时，NDB会将其支持的ndbinfo版本与数据字典中存储的版本进行比较。如果版本不同，NDB会删除任何旧的ndbinfo表，并使用当前定义重新创建它们。

对 Fedora Linux 的支持。 从 NDB 8.0.20 开始，Fedora Linux 是 NDB Cluster Community 版本的支持平台，并可以使用 Oracle 提供的 RPM 包进行安装。这些可以从NDB Cluster 下载页面获取。

NDB 程序—NDBT 依赖项移除。 已移除了许多NDB实用程序对NDBT库的依赖。该库在开发中内部使用，对于正常使用不需要；将其包含在这些程序中可能会导致测试时出现不希望的问题。

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

• ndb_restore
• ndb_delete_all
• ndb_show_tables (NDB 8.0.20)
• ndb_waiter (NDB 8.0.20)

这一变化对用户的主要影响是，这些程序在运行完成后不再打印NDBT_ProgramExit - *status*。依赖于这种行为的应用程序在升级到指定版本时应该进行更新。

外键和大小写。 NDB 使用外键名称的定义大小写存储这些名称。以前，当lower_case_table_names系统变量的值设置为 0 时，它对外键名称进行区分大小写比较，就像在SELECT和其他 SQL 语句中使用的名称与存储的名称一样。从 NDB 8.0.20 开始，无论lower_case_table_names的值如何，这样的比较现在总是以不区分大小写的方式进行。

多个传输器。 NDB 8.0.20 引入了支持多个传输器，用于处理数据节点之间的节点间通信。这有助于集群中每个节点组的更新操作速率更高，并有助于避免使用单个套接字进行节点间通信时系统或其他限制所施加的约束。

默认情况下，NDB现在根据本地数据管理（LDM）线程数或事务协调器（TC）线程数中较大的那个数来使用一定数量的传输器。默认情况下，传输器的数量等于这个数的一半。虽然默认情况下对大多数工作负载表现良好，但可以通过设置NodeGroupTransporters数据节点配置参数（也在 NDB 8.0.20 中引入）来调整每个节点组使用的传输器数量，最大值为 LDM 线程数或 TC 线程数中较大的那个数。将其设置为 0 会导致传输器的数量与 LDM 线程数相同。

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

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

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

要获取更多信息，请参阅ndb_restore选项--allow-pk-changes的描述。

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

--remap-column的参数是一个字符串，格式为*db*.*tbl*.*col*:*fn*:*args*，其中*db，tbl和col分别是数据库，表和列的名称，fn是重新映射函数的名称，args是一个或多个fn的参数。没有默认值。只支持offset作为函数名称，args*是要在从备份插入目标表时应用到列值的整数偏移量。此列必须是INT - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT")或BIGINT - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT")之一；偏移值的允许范围与该类型的有符号版本相同（如果需要，这允许偏移为负）。

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

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

• --auto-inc（简写形式-a）：如果表具有AUTO_INCREMENT列，则在输出中包含下一个自增值。
• --context（简写形式-x）：提供有关表的额外信息，包括模式，数据库名称，表名称和内部 ID。

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

发送线程改进。 从 NDB 8.0.20 开始，每个发送线程现在处理发送到一组传输器的发送，并且每个块线程现在只辅助一个发送线程，导致更多的发送线程，从而提高性能和数据节点的可伸缩性。

使用 SpinMethod 进行自适应自旋控制。 在支持的平台上设置自适应 CPU 自旋的简单接口，使用SpinMethod数据节点参数。该参数（在 NDB 8.0.20 中添加，从 NDB 8.0.24 开始生效）有四个设置，分别用于静态自旋、基于成本的自适应自旋、优化延迟的自适应自旋以及针对每个线程都有自己 CPU 的数据库机器进行优化的自适应自旋。这些设置中的每一个都会使数据节点使用一组预定值来设置一个或多个自旋参数，从而实现自适应自旋，设置自旋时间和自旋开销，适用于特定场景，从而无需为常见用例直接设置这些值。

为了对自旋行为进行微调，还可以直接设置这些和其他自旋参数，使用现有的SchedulerSpinTimer数据节点配置参数以及在ndb_mgm客户端中的以下DUMP命令：

• DUMP 104000 (SetSchedulerSpinTimerAll): 设置所有线程的自旋时间
• DUMP 104001 (SetSchedulerSpinTimerThread): 设置指定线程的自旋时间
• DUMP 104002 (SetAllowedSpinOverhead): 设置自旋开销，即允许获得 1 单位延迟所需的 CPU 时间单位数
• DUMP 104003 (SetSpintimePerCall): 设置调用的自旋时间
• DUMP 104004 (EnableAdaptiveSpinning): 启用或禁用自适应自旋

NDB 8.0.20 还添加了一个新的 TCP 配置参数TcpSpinTime，用于设置给定 TCP 连接的自旋时间。

ndb_top 工具也得到增强，以提供每个线程的自旋时间信息。

欲了解更多信息，请参阅SpinMethod参数的描述，列出的DUMP命令以及 Section 25.5.29, “ndb_top — 查看 NDB 线程的 CPU 使用信息”。

磁盘数据和集群重启。 从 NDB 8.0.21 开始，集群的初始重启会强制删除所有磁盘数据对象，如表空间和日志文件组，包括与这些对象相关联的任何数据文件和撤销日志文件。

更多信息请参见第 25.6.11 节，“NDB 集群磁盘数据表”。

磁盘数据范围分配。 从 NDB 8.0.20 开始，在数据文件中分配范围是在给定表空间中使用的所有数据文件之间以循环方式进行的。这有望改善在使用多个存储设备进行磁盘数据存储时数据的分布。

更多信息请参见第 25.6.11.1 节，“NDB 集群磁盘数据对象”。

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

AllowUnresolvedHostNames 参数。 默认情况下，管理节点在无法解析全局配置文件中存在的主机名时拒绝启动，这在某些环境（如 Kubernetes）中可能会有问题。从 NDB 8.0.22 开始，可以通过在集群全局配置文件（config.ini 文件）的 [tcp default] 部分中将 AllowUnresolvedHostNames 设置为 true 来覆盖此行为。这样做会将此类错误视为警告，并允许 ndb_mgmd 继续启动

Blob 写入性能增强。 NDB 8.0.22 实现了一些改进，允许在同一行中修改多个 blob 列或在同一语句中修改包含 blob 列的多行时更有效地进行批处理，从而减少 SQL 或其他 API 节点与数据节点之间在应用这些修改时所需的往返次数。因此，许多 INSERT、UPDATE 和 DELETE 语句的性能可以得到改善。这里列出了一些这样的语句示例，其中 table 是包含一个或多个 Blob 列的 NDB 表：

• INSERT INTO *table* VALUES ROW(1, *blob_value1*, *blob_value2*, ...)，即插入包含一个或多个 Blob 列的一行数据
• INSERT INTO *table* VALUES ROW(1, *blob_value1*), ROW(2, *blob_value2*), ROW(3, *blob_value3*), ...，即插入包含一个或多个 Blob 列的多行数据
• UPDATE *table* SET *blob_column1* = *blob_value1*, *blob_column2* = *blob_value2*, ...
• UPDATE *table* SET *blob_column* = *blob_value* WHERE *primary_key_column* in (*value_list*)，其中主键列不是 Blob 类型
• DELETE FROM *table* WHERE *primary_key_column* = *value*，其中主键列不是 Blob 类型
• DELETE FROM *table* WHERE *primary_key_column* IN (*value_list*)，其中主键列不是 Blob 类型

其他 SQL 语句也可能从这些改进中受益。这些包括 LOAD DATA INFILE 和 CREATE TABLE ... SELECT ...。此外，ALTER TABLE *table* ENGINE = NDB，其中 table 在执行语句之前使用的存储引擎不是 NDB，也可能执行得更有效率。

这种改进适用于影响 MySQL 类型 BLOB、MEDIUMBLOB、LONGBLOB、TEXT、MEDIUMTEXT 和 LONGTEXT 列的语句。仅更新 TINYBLOB 或 TINYTEXT 列（或两种类型）的语句不受此工作的影响，不应期望其性能发生变化。

由于某些 SQL 语句需要扫描表格 Blob 列，这会破坏批处理，因此这种改进对某些 SQL 语句的性能没有明显提升。这些语句包括以下类型：

• SELECT FROM *table* [WHERE *key_column* IN (*blob_value_list*)]，其中通过匹配使用 Blob 类型的主键或唯一键列来选择行
• UPDATE *table* SET *blob_column* = *blob_value* WHERE *condition*，使用一个不依赖于唯一值的 condition
• DELETE FROM *table* WHERE *condition* 用于删除包含一个或多个 Blob 列的行，使用一个不依赖于唯一值的 condition
• 在执行语句之前已经使用 NDB 存储引擎的表上执行复制 ALTER TABLE 语句，并且在执行语句之前或之后（或两者都有）表的行包含一个或多个 Blob 列

为了充分利用这一改进，您可能希望增加用于 mysqld 的 --ndb-batch-size 和 --ndb-blob-write-batch-bytes 选项的值，以最小化修改 blob 所需的往返次数。对于复制，还建议启用 slave_allow_batching 系统变量，以最小化副本集群应用时代事务所需的往返次数。

注意

从 NDB 8.0.30 版本开始，您还应该使用 ndb_replica_batch_size 替代 --ndb-batch-size，以及 ndb_replica_blob_write_batch_bytes 而不是 --ndb-blob-write-batch-bytes。有关这些变量的描述以及更多信息，请参见这些变量的描述，以及 第 25.7.5 节，“为复制准备 NDB 集群”。

Node.js 更新。 从 NDB 8.0.22 版本开始，Node.js 的 NDB 适配器使用的是版本 12.18.3，并且现在仅支持该版本（或更高版本的 Node.js）。

加密备份。 NDB 8.0.22 版本新增了对使用 AES-256-CBC 加密的备份文件的支持；这旨在防止未经授权的人员从已被访问的备份中恢复数据。当备份数据加密时，会由用户提供的密码进行保护。密码可以是任何由可打印 ASCII 字符范围内除了 !, ', ", $, %, \, 和 ^ 之外的最多 256 个字符组成的字符串。对于加密任何给定 NDB 集群备份所使用的密码的保留必须由用户或应用程序执行；NDB 不保存密码。密码可以为空，尽管这并不推荐。

在进行 NDB 集群备份时，可以使用管理客户端 START BACKUP 命令，并通过 ENCRYPT PASSWORD=*password* 进行加密。MGM API 的用户也可以通过调用 ndb_mgm_start_backup4() 来启动加密备份。

你可以使用ndbxfrm实用程序对现有的备份文件进行加密，该实用程序已添加到 NDB Cluster 发行版中的 8.0.22 版本中；该程序还可用于解密加密的备份文件。此外，ndbxfrm可以使用与 NDB Cluster 在设置CompressedBackup配置参数为 1 时创建备份时所使用的相同方法来压缩备份文件和解压缩压缩备份文件。

要从加密备份中恢复，请使用ndb_restore与选项--decrypt和--backup-password。这两个选项是必需的，以及任何其他在未加密情况下恢复相同备份所需的选项。ndb_print_backup_file和ndbxfrm也可以分别使用-P *password*和--decrypt-password=*password*读取加密文件。

在提供密码以及加密或解密选项的所有情况下，密码必须用引号括起来；您可以使用单引号或双引号来界定密码。

从 NDB 8.0.24 开始，这里列出的几个NDB程序还支持从标准输入输入密码，类似于在与mysql客户端交互登录时使用--password选项（不包括在命令行中输入密码）的方式：

• 对于ndb_restore和ndb_print_backup_file，--backup-password-from-stdin选项使得可以以安全的方式输入密码，类似于mysql客户端的--password选项。对于ndb_restore，与--decrypt选项一起使用；对于ndb_print_backup_file，使用该选项代替 -P 选项。
• 对于ndb_mgm，选项--backup-password-from-stdin与--execute "START BACKUP [*选项*]"一起支持从系统 shell 启动集群备份。
• 两个ndbxfrm选项，--encrypt-password-from-stdin和--decrypt-password-from-stdin，在使用该程序加密或解密备份文件时会导致类似的行为。

有关刚列出的程序的更多信息，请参阅其描述。

从 NDB 8.0.22 开始，还可以通过在集群全局配置文件的 [ndbd default] 部分中设置RequireEncryptedBackup=1来强制备份加密。这样做时，ndb_mgm客户端将拒绝任何未加密的备份尝试。

从 NDB 8.0.24 开始，您可以通过使用--encrypt-backup启动ndb_mgm来使其在创建备份时使用加密。在这种情况下，如果未提供密码，则在调用START BACKUP时会提示用户输入密码。

IPv6 支持。 从 NDB 8.0.22 开始，IPv6 寻址支持与管理和数据节点的连接；这包括管理和数据节点与 SQL 节点之间的连接。在配置集群时，可以使用数字 IPv6 地址、解析为 IPv6 地址的主机名或两者兼用。

要使 IPv6 寻址正常工作，部署集群的操作平台和网络必须支持 IPv6。与使用 IPv4 寻址时一样，主机名解析为 IPv6 地址必须由操作平台提供。

在 Linux 平台上运行 NDB 8.0.22 及更高版本时已知的问题是，即使没有使用 IPv6 地址，操作系统内核也需要提供 IPv6 支持。这个问题在 NDB 8.0.34 及更高版本中已修复，如果不打算使用 IPv6 寻址，则可以安全地在 Linux 内核中禁用 IPv6 支持（Bug #33324817，Bug #33870642）。

IPv4 addressing continues to be supported by NDB. Using IPv4 and IPv6 addresses concurrently is not recommended, but can be made to work in the following cases:

• 当管理节点配置为 IPv6，数据节点配置为 IPv4 地址在config.ini文件中时：如果未使用--bind-address与mgmd一起使用，并且数据节点启动时使用--ndb-connectstring设置为管理节点的 IPv4 地址，则可以正常工作。
• 当管理节点配置为 IPv4，数据节点配置为 IPv6 地址在config.ini文件中时：类似于另一种情况，如果未传递--bind-address给mgmd，并且数据节点启动时使用--ndb-connectstring设置为管理节点的 IPv6 地址，则可以正常工作。

这些情况之所以有效，是因为ndb_mgmd默认不绑定到任何 IP 地址。

要从不支持 IPv6 寻址的NDB版本升级到支持 IPv6 寻址的版本，前提是网络支持 IPv4 和 IPv6，首先执行软件升级；完成后，可以使用 IPv6 地址更新config.ini文件中使用的 IPv4 地址。之后，为使配置更改生效并使集群开始使用 IPv6 地址，需要对集群进行系统重启。

自动安装程序弃用和移除。 MySQL NDB Cluster 自动安装程序基于 Web 的安装工具（ndb_setup.py）在 NDB 8.0.22 中已被弃用，并在 NDB 8.0.23 及更高版本中被移除。不再受支持。

ndbmemcache 弃用和移除。 ndbmemcache不再受支持。ndbmemcache在 NDB 8.0.22 中已被弃用，并在 NDB 8.0.23 中被移除。

ndbinfo 备份 ID 表。 NDB 8.0.24 向ndbinfo信息数据库添加了一个backup_id表。这旨在作为通过使用ndb_select_all来转储内部SYSTAB_0表的内容获取此信息的替代方法，后者容易出错且执行时间过长。

这个表有一列和一行，包含使用START BACKUP管理客户端命令对集群进行的最新备份的 ID。如果找不到此集群的备份，则表中包含一个列值为0的单行。

表分区增强。 NDB 8.0.23 引入了一种新的处理表分区和片段的方法，可以独立于重做日志部分的数量确定给定数据节点的本地数据管理器（LDMs）的数量。这意味着现在 LDMs 的数量可以高度变化。当ClassicFragmentation数据节点配置参数设置为false时，NDB可以使用这种方法；在这种情况下，不再使用 LDMs 的数量来确定每个数据节点为表创建多少个分区，而是由PartitionsPerNode参数的值（也在 NDB 8.0.23 中引入）来确定这个数量，这个数量也用于计算表使用的片段数量。

当ClassicFragmentation具有其默认值true时，将使用传统方法来确定表应具有的片段数，即使用 LDM 数。

更多信息，请参阅之前引用的新参数的描述，在多线程配置参数（ndbmtd）中。

术语更新。 为了与 MySQL 8.0.21 和 NDB 8.0.21 中开始的工作保持一致，NDB 8.0.23 实施了一些术语上的更改，列在此处：

• 系统变量ndb_slave_conflict_role现已弃用。它被ndb_conflict_role替代。
• 许多NDB状态变量已被弃用。这些变量及其替代项在下表中列出： 表 25.1 已弃用的 NDB 状态变量及其替代项 已弃用变量替代项Ndb_api_adaptive_send_deferred_count_slaveNdb_api_adaptive_send_deferred_count_replicaNdb_api_adaptive_send_forced_count_slaveNdb_api_adaptive_send_forced_count_replicaNdb_api_adaptive_send_unforced_count_slaveNdb_api_adaptive_send_unforced_count_replicaNdb_api_bytes_received_count_slaveNdb_api_bytes_received_count_replicaNdb_api_bytes_sent_count_slaveNdb_api_bytes_sent_count_replicaNdb_api_pk_op_count_slaveNdb_api_pk_op_count_replicaNdb_api_pruned_scan_count_slaveNdb_api_pruned_scan_count_replicaNdb_api_range_scan_count_slaveNdb_api_range_scan_count_replicaNdb_api_read_row_count_slaveNdb_api_read_row_count_replicaNdb_api_scan_batch_count_slaveNdb_api_scan_batch_count_replicaNdb_api_table_scan_count_slaveNdb_api_table_scan_count_replicaNdb_api_trans_abort_count_slaveNdb_api_trans_abort_count_replicaNdb_api_trans_close_count_slaveNdb_api_trans_close_count_replicaNdb_api_trans_commit_count_slaveNdb_api_trans_commit_count_replicaNdb_api_trans_local_read_row_count_slaveNdb_api_trans_local_read_row_count_replicaNdb_api_trans_start_count_slaveNdb_api_trans_start_count_replicaNdb_api_uk_op_count_slaveNdb_api_uk_op_count_replicaNdb_api_wait_exec_complete_count_slaveNdb_api_wait_exec_complete_count_replicaNdb_api_wait_meta_request_count_slaveNdb_api_wait_meta_request_count_replicaNdb_api_wait_nanos_count_slaveNdb_api_wait_nanos_count_replicaNdb_api_wait_scan_result_count_slaveNdb_api_wait_scan_result_count_replicaNdb_slave_max_replicated_epochNdb_replica_max_replicated_epoch弃用变量替换弃用的状态变量仍然显示在SHOW STATUS的输出中，但应用程序应尽快更新，不再依赖于它们，因为它们在未来的发布系列中的可用性不能保证。
• 先前在ndbinfo ndbinfo.table_distribution_status表的tab_copy_status列中显示的ADD_TABLE_MASTER和ADD_TABLE_SLAVE已被弃用。分别由ADD_TABLE_COORDINATOR和ADD_TABLE_PARTICIPANT替代。
• 一些NDB客户端和实用程序的--help输出，如ndb_restore已经修改。

ThreadConfig 增强。 从 NDB 8.0.23 开始，ThreadConfig参数的可配置性已经扩展，增加了两种新的线程类型，列在这里：

• query: 查询线程仅处理READ COMMITTED查询。查询线程还充当恢复线程。查询线程的数量必须是 LDM 线程数量的 0、1、2 或 3 倍。 0（默认值，除非启用ThreadConfig或AutomaticThreadConfig）会导致 LDM 表现为 NDB 8.0.23 之前的行为。
• recover: 恢复线程从本地检查点检索数据。指定为恢复线程的恢复线程永远不会充当查询线程。

还可以以两种方式组合现有的main和rep线程：

• 通过将这两个参数中的一个设置为 0 来将其合并为一个线程。这样做时，生成的合并线程在ndbinfo.threads表中显示为main_rep。
• 通过将ldm和tc都设置为 0，并将recv设置为 1，与recv线程一起。在这种情况下，组合线程被命名为main_rep_recv。

此外，许多现有线程类型的最大数量已增加。包括查询线程和恢复线程在内的新最大值在此处列出：

• LDM：332
• 查询：332
• 恢复：332
• TC：128
• 接收：64
• 发送：64
• 主要：2

其他线程类型的最大值保持不变。

此外，作业缓冲区在使用超过 32 个块线程时，NDB现在使用互斥锁来保护。虽然这可能会导致性能略微下降（在大多数情况下为 1 到 2％），但也显着减少了非常大配置所需的内存量。例如，在 NDB 8.0.23 之前，使用 2 GB 作业缓冲区内存的 64 个线程设置，现在在 NDB 8.0.23 及更高版本中只需要约 1 GB。在我们的测试中，这导致非常复杂查询的执行整体改善约 5％。

欲了解更多信息，请参阅ThreadConfig参数和ndbinfo.threads表的描述。

ThreadConfig 线程计数更改。 由于 NDB 8.0.30 中的工作结果，需要在ThreadConfig值字符串中明确包含main、rep、recv和ldm的值，以及在此后的 NDB 集群版本中。此外，必须明确设置count=0以表示不使用的每个线程类型（main、rep或ldm），并且为复制线程（rep）设置count=1还需要为main设置count=1。

这些更改可能对使用此参数的 NDB 集群的升级产生重大影响；有关更多信息，请参阅第 25.3.7 节，“NDB 集群升级和降级”。

ndbmtd 线程自动配置。 从 NDB 8.0.23 开始，可以使用 ndbmtd") 配置参数 AutomaticThreadConfig 来实现多线程数据节点的自动线程配置。当此参数设置为 1 时，NDB 根据应用程序可用的处理器数量自动设置线程分配，适用于所有支持线程类型，包括前一项中描述的新的 query 和 recover 线程类型。如果系统不限制处理器数量，您可以通过设置 NumCPUs（也在 NDB 8.0.23 中添加）来限制处理器数量。否则，自动线程配置支持最多 1024 个处理器。

无论在 config.ini 中设置了 ThreadConfig 或 MaxNoOfExecutionThreads 的值如何，自动线程配置都会发生；这意味着不需要设置这两个参数。

此外，NDB 8.0.23 实现了许多新的 ndbinfo 信息数据库表，提供有关硬件和 CPU 可用性以及 NDB 数据节点的 CPU 使用情况的信息。这些表列在此处：

• cpudata
• cpudata_1sec
• cpudata_20sec
• cpudata_50ms
• cpuinfo
• hwinfo

这些表中的一些在 NDB Cluster 支持的每个平台上都不可用；有关更多信息，请参阅它们的各自描述。

NDB 数据库对象的分层视图。 dict_obj_tree 表是在 NDB 8.0.24 中添加到 ndbinfo 信息数据库中的，可以提供许多 NDB 数据库对象的分层和树状视图，包括以下内容：

• 表和相关索引
• 表空间和相关数据文件
• 日志文件组和相关的撤销日志文件

有关更多信息和示例，请参见 第 25.6.16.25 节，“ndbinfo dict_obj_tree 表”。

索引统计增强。 NDB 8.0.24 实现了以下改进，用于计算索引统计信息：

• 以前仅从一个片段收集索引统计信息；现在已更改为将此外推扩展到其他片段。
• 用于非常小的表的算法已经改进，例如那些具有非常少行且结果被丢弃的表，因此对于这些表的估计应该比以前更准确。

从 NDB 8.0.27 开始，默认情况下索引统计表会自动创建和更新，IndexStatAutoCreate 和 IndexStatAutoUpdate 都默认为 1（启用），而不是 0（禁用），因此不再需要运行 ANALYZE TABLE 来更新统计信息。

有关更多信息，请参见 第 25.6.15 节，“NDB API 统计计数器和变量”。

在恢复操作期间 NULL 和 NOT NULL 之间的转换。 从 NDB 8.0.26 开始，ndb_restore 可以支持将 NULL 列恢复为 NOT NULL，反之亦然，使用以下列出的选项：

• 要将 NULL 列恢复为 NOT NULL，请使用 --lossy-conversions 选项。 最初声明为 NULL 的列不得包含任何 NULL 行；如果包含，ndb_restore 将以错误退出。
• 要将 NOT NULL 列恢复为 NULL，请使用 --promote-attributes 选项。

有关指定的 ndb_restore 选项的描述，请参见更多信息。

NdbScanFilter 的 SQL 兼容 NULL 比较模式。 传统上，在涉及 NULL 的比较时，NdbScanFilter 将 NULL 视为等于 NULL（因此认为 NULL == NULL 为 TRUE）。这与 SQL 标准规定不同，SQL 标准要求任何与 NULL 的比较都返回 NULL，包括 NULL == NULL。

以前，NDB API 应用程序无法覆盖此行为；从 NDB 8.0.26 开始，您可以在创建扫描过滤器之前调用 NdbScanFilter::setSqlCmpSemantics() 来实现。这样做会导致下一个 NdbScanFilter 对象在其生命周期内执行的所有比较操作都采用符合 SQL 标准的 NULL 比较。您必须为每个应使用符合 SQL 标准比较的 NdbScanFilter 对象调用该方法。

欲了解更多信息，请参阅 NdbScanFilter::setSqlCmpSemantics()。

NDB API .FRM 文件方法的弃用。 MySQL 8.0 和 NDB 8.0 不再使用 .FRM 文件存储表元数据。因此，NDB API 方法 getFrmData()，getFrmLength()，和 setFrm() 在 NDB 8.0.27 中已被弃用，并可能在未来的版本中移除。要读取和写入表元数据，请改用 getExtraMetadata() 和 setExtraMetadata()。

IPv4 或 IPv6 寻址偏好。 NDB 8.0.26 添加了 PreferIPVersion 配置参数，用于控制 DNS 解析的寻址偏好。IPv4（PreferIPVersion=4）是默认设置。由于 NDB 中的配置检索要求所有 TCP 连接的偏好设置相同，因此您应该仅在集群全局配置文件（config.ini）的 [tcp default] 部分中设置它。

有关更多信息，请参阅 Section 25.4.3.10, “NDB Cluster TCP/IP Connections”。

日志增强。 以前，NDB Cluster 数据节点和管理节点日志的分析可能会受到不同日志消息使用不同格式以及不是所有日志消息都包含时间戳的影响。这些问题部分是由于日志记录是通过多种不同机制执行的，如函数 printf，fprintf，ndbout 和 ndbout_c，<< 操作符的重载等。

我们通过标准化 EventLogger 机制来解决这些问题，该机制已经存在于 NDB 中，并且每条日志消息以 YYYY-MM-DD HH:MM:SS 格式的时间戳开头。

有关 NDB Cluster 事件日志和 EventLogger 日志消息格式的更多信息，请参见 第 25.6.3 节，“NDB Cluster 生成的事件报告”。

复制 ALTER TABLE 改进。 从 NDB 8.0.27 开始，在 NDB 表上执行复制的 ALTER TABLE 会比较执行复制前后源表的片段提交计数。这使得执行此语句的 SQL 节点可以确定是否有任何并发写入活动对正在更改的表进行了操作；如果有，SQL 节点可以终止操作。

当检测到对正在更改的表进行并发写入时，ALTER TABLE 语句将被拒绝，并显示错误消息 Detected change to data in source table during copying ALTER TABLE. Alter aborted to avoid inconsistency (ER_TABLE_DEF_CHANGED)。停止更改操作，而不是允许其继续进行并发写入，可以帮助防止数据丢失或损坏。

ndbinfo index_stats 表。 NDB 8.0.28 添加了 index_stats 表，提供关于 NDB 索引统计信息的基本信息。它主要用于内部测试，但可能作为 ndb_index_stat 的补充。

ndb_import --table 选项。 在 NDB 8.0.28 之前，ndb_import 总是将从 CSV 文件中读取的数据导入到一个表中，该表的名称是根据正在读取的文件的名称派生而来的。NDB 8.0.28 添加了一个 --table 选项（简写形式：-t）用于指定目标表的名称，并覆盖先前的行为。

ndb_import 的默认行为��然是使用输入文件的基本名称作为目标表的名称。

ndb_import --missing-ai-column 选项。 从 NDB 8.0.29 开始，ndb_import 可以使用在该版本中引入的 --missing-ai-column 选项导入包含 AUTO_INCREMENT 列的 CSV 文件中的空值数据。该选项可用于包含此类列的一个或多个表。

为使此选项生效，CSV 文件中的 AUTO_INCREMENT 列不得包含任何值。否则，导入操作无法继续。

ndb_import 和空行。 ndb_import 一直会拒绝在传入的 CSV 文件中遇到的任何空行。NDB 8.0.30 添加了支持，可以将空行导入到单个列中，前提是可以将空值转换为列值。

ndb_restore --with-apply-status 选项。 从 NDB 8.0.29 开始，可以使用 ndb_restore 和该版本中添加的 --with-apply-status 选项从 NDB 备份中恢复 ndb_apply_status 表。要使用此选项，调用 ndb_restore 时还必须使用 --restore-data。

--with-apply-status 会恢复除了具有 server_id = 0 的行之外的所有 ndb_apply_status 表的行；要恢复此行，请使用 --restore-epoch。有关更多信息，请参阅 ndb_apply_status 表，以及 --with-apply-status 选项的描述。

具有缺失索引的表的 SQL 访问。 在 NDB 8.0.29 之前，当用户查询尝试打开具有缺失或损坏索引的 NDB 表时，MySQL 服务器会引发 NDB 错误 4243（索引未找到）。当约束违规或缺失数据使得无法在 NDB 表上恢复索引时，会出现这种情况，并且使用 ndb_restore 的 --disable-indexes 用于在没有索引的情况下恢复数据。

从 NDB 8.0.29 开始，针对一个具有缺失索引的 NDB 表的 SQL 查询，如果查询不使用任何缺失的索引，则成功。否则，查询将被拒绝，并显示 ER_NOT_KEYFILE。在这种情况下，您可以使用 ALTER TABLE ... ALTER INDEX ... INVISIBLE 来阻止 MySQL 优化器尝试使用该索引，或者使用适当的 SQL 语句删除该索引（然后可能重新创建）。

NDB API List::clear() 方法。 NDB API Dictionary 方法 listEvents(), listIndexes() 和 listObjects() 每个都需要一个空的 List 对象的引用。以前，使用任何这些方法重用现有的 List 都会因为这个原因出现问题。NDB 8.0.29 通过实现一个 clear() 方法来简化这个过程，该方法会从列表中删除所有数据。

作为这项工作的一部分，List 类析构函数现在在从列表中删除任何元素或属性之前调用 List::clear()。

NDB 字典表在 ndbinfo 中。 NDB 8.0.29 在 ndbinfo 数据库中引入了几个新表，提供了以前需要使用 ndb_desc, ndb_select_all 和其他 NDB 实用程序程序来获取的来自 NdbDictionary 的信息。

这些表中有两个实际上是视图。hash_maps 表提供了 NDB 使用的哈希映射的信息；files 表显示了关于在磁盘上存储数据的文件的信息（参见 第 25.6.11 节，“NDB 集群磁盘数据表”）。

NDB 8.0.29 中添加的剩余六个 ndbinfo 表都是基本表。这些表不是隐藏的，也不使用 ndb$ 前缀命名。这些表在此列出，包括每个表中表示的对象的描述：

• blobs: 用于存储 BLOB 和 TEXT 列的可变大小部分的 Blob 表
• dictionary_columns: NDB 表的列
• dictionary_tables: NDB 表
• events: NDB API 中的事件订阅
• foreign_keys: NDB 表上的外键
• index_columns：NDB 表上的索引

NDB 8.0.29 还对 ndbinfo 存储引擎的主键实现进行了更改，以提高与 NdbDictionary 的兼容性。

ndbcluster 插件和性能模式。 从 NDB 8.0.29 开始，ndbcluster 插件线程显示在性能模式 threads 和 setup_threads 中，可以获取有关这些线程性能的信息。在 performance_schema 表中公开的三个线程列在此处：

• ndb_binlog：二进制日志线程
• ndb_index_stat：索引统计线程
• ndb_metadata：元数据线程

有关更多信息和示例，请参阅 ndbcluster 插件线程。

在 NDB 8.0.30 及更高版本中，事务批处理内存使用情况可在性能模式 memory_summary_by_thread_by_event_name 和 setup_instruments 中以 memory/ndbcluster/Thd_ndb::batch_mem_root 的形式显示。您可以使用这些信息来查看事务使用了多少内存。有关更多信息，请参阅 事务内存使用。

可配置的 blob 内联大小。 从 NDB 8.0.30 开始，可以在 CREATE TABLE 或 ALTER TABLE 中设置 blob 列的内联大小。NDB Cluster 支持的最大内联大小为 29980 字节。

有关更多信息和示例，请参阅 NDB_COLUMN 选项，以及 字符串类型存储要求。

replica_allow_batching 默认启用。 复制写批处理极大地提高了 NDB 集群复制性能，特别是在复制 blob 类型列（TEXT、BLOB 和 JSON）时，因此通常在使用 NDB 集群进行复制时应启用。因此，从 NDB 8.0.30 开始，默认启用了replica_allow_batching系统变量，并将其设置为OFF会引发警告。

冲突解析插入操作支持。 在 NDB 8.0.30 之前，仅有两种可用于解决主键冲突的策略，用作更新和删除操作的函数为 NDBMAX() 和 NDBMAX_DELETE_WIN()。这两者对写操作没有任何影响，除非具有与先前写入相同主键的写操作总是被拒绝，并且仅在没有具有相同主键的操作存在时才被接受和应用。NDB 8.0.30 引入了两个新的冲突解析函数 NDBMAX_INS()") 和 NDB

1. 如果没有冲突写入，应用此操作（与 NDB$MAX() 相同）。
2. 否则，应用“最大时间戳获胜”冲突解析，如下所示：
   1. 如果传入写入的时间戳大于冲突写入的时间戳，则应用传入操作。
   2. 如果传入写入的时间戳不大，则拒绝传入写入操作。

对于冲突的更新和删除操作，NDBMAX_INS() 的行为类似于 NDBMAX()")，而 NDBMAX_DEL_WIN_INS() 的行为与 NDBMAX_DELETE_WIN()") 相同。

此增强功能提供了在处理冲突的复制写操作时配置冲突检测的支持，因此具有更高时间戳列值的复制INSERT会被幂等地应用，而具有较低时间戳列值的复制INSERT会被拒绝。

与其他冲突解决函数一样，拒绝的操作可以选择记录在异常表中；拒绝的操作会增加一个计数器（状态变量Ndb_conflict_fn_max 用于“最大时间戳获胜”，以及Ndb_conflict_fn_old 用于“相同时间戳获胜”）。

欲了解更多信息，请参阅新冲突解决函数的描述，以及第 25.7.12 节，“NDB 集群复制冲突解决”。

复制应用程序批处理大小控制。 以前，写入到副本 NDB 集群时使用的批处理大小由 --ndb-batch-size 控制，而写入 blob 数据到副本时使用的批处理大小由 ndb-blob-write-batch-bytes 确定。这种安排的一个问题是，副本使用这些变量的全局值，这意味着更改其中一个变量对于副本也会影响所有其他会话使用的值。此外，不可能为这些值设置专门适用于副本的不同默认值，副本的默认值应该比其他会话的默认值更高。

NDB 8.0.30 添加了两个新的系统变量，这些变量专门用于复制应用程序。ndb_replica_batch_size 现在控制用于复制应用程序的批处理大小，而 ndb_replica_blob_write_batch_bytes 变量现在确定用于在复制上执行批量 blob 写入的 blob 写入批处理大小。

此更改应该改善使用默认设置的 MySQL NDB 集群复制的行为，并允许用户微调 NDB 复制性能，而不会影响用户线程，例如执行 SQL 查询处理的线程。

欲了解更多信息，请参阅新变量的描述。另请参阅第 25.7.5 节，“准备 NDB 集群进行复制”。

二进制日志事务压缩。 NDB 8.0.31 增加了对使用ZSTD压缩的压缩事务的二进制日志的支持。要启用此功能，请将此版本中引入的ndb_log_transaction_compression系统变量设置为ON。使用的压缩级别可以通过ndb_log_transaction_compression_level_zstd系统变量进行控制，该系统变量也在该版本中添加；默认压缩级别为 3。

尽管binlog_transaction_compression和binlog_transaction_compression_level_zstd服务器系统变量对NDB表的二进制日志记录没有影响，但使用--binlog-transaction-compression=ON启动mysqld会自动启用ndb_log_transaction_compression。在服务器启动完成后，你可以在 MySQL 客户端会话中使用SET @@global.ndb_log_transaction_compression=OFF来禁用它。

查看ndb_log_transaction_compression的描述以及第 7.4.4.5 节，“二进制日志事务压缩”，以获取更多信息。

NDB 复制：多线程应用程序。 从 NDB 8.0.33 开始，NDB Cluster 复制支持副本服务器上的 MySQL 多线程应用程序（MTA）（以及replica_parallel_workers的非零值），这使得副本可以并行应用二进制日志事务，从而提高吞吐量。（有关 MySQL 服务器中多线程应用程序的更多信息，请参阅第 19.2.3 节，“复制线程”。）

在副本上启用此功能需要源数据库使用--ndb-log-transaction-dependency参数设置为ON（此选项也在 NDB 8.0.33 中实现）。此外，源数据库还需要将binlog_transaction_dependency_tracking设置为WRITESET。另外，你必须确保副本上的replica_parallel_workers的值大于 1，从而确保副本使用多个工作线程。

有关更多信息和要求，请参见第 25.7.11 节，“使用多线程应用程序复制的 NDB 集群复制”。

构建选项的更改。 NDB 8.0.31 对用于构建 MySQL 集群的 CMake 选项进行了以下更改。

• WITH_NDBCLUSTER选项已被弃用，WITH_PLUGIN_NDBCLUSTER已被移除。
• 要从源代码构建 MySQL 集群，请使用新添加的WITH_NDB选项。
• WITH_NDBCLUSTER_STORAGE_ENGINE仍然受支持，但对于大多数构建而言不再需要。

有关更多信息，请参见用于编译 NDB 集群的 CMake 选项。

文件系统加密。 透明数据加密（TDE）通过加密在静止状态下的NDB数据，即所有持久化到磁盘的NDB表数据和日志文件。这旨在防止在未经授权访问 NDB 集群数据文件（如表空间文件或日志）后恢复数据。

加密由数据节点上的 NDB 文件系统层（NDBFS）透明实现；数据在读取和写入文件时进行加密和解密，NDBFS内部客户端块像正常操作文件一样。

NDBFS可以从用户提供的密码直接透明加密文件，但将单个文件的加密和解密与用户提供的密码分离可能有助于提高效率、可用性、安全性和灵活性。请参见第 25.6.14.2 节，“NDB 文件系统加密实现”。

TDE 使用两种类型的密钥。一个秘密密钥用于加密存储在磁盘上的实际数据和日志文件（包括 LCP、重做、撤销和表空间文件）。然后使用主密钥加密秘密密钥。

数据节点配置参数EncryptedFileSystem，从 NDB 8.0.29 开始提供，设置为1时，强制对存储表数据的文件进行加密。这包括 LCP 数据文件、重做日志文件、表空间文件和撤销日志文件。

在启动或重新启动每个数据节点时，还需要为其提供密码，使用--filesystem-password或--filesystem-password-from-stdin选项之一。请参见第 25.6.14.1 节，“NDB 文件系统加密设置和使用”。此密码使用相同格式，并受到与用于加密NDB备份的密码相同的约束（有关加密NDB备份的详细信息，请参见ndb_restore --backup-password选项的描述）。

只有使用NDB存储引擎的表才会受到此功能的加密影响；参见第 25.6.14.3 节，“NDB 文件系统加密限制”。其他表，如用于NDB模式分发、复制和二进制日志的表，通常使用InnoDB；参见第 17.13 节，“InnoDB 数据静止时加密”。有关二进制日志文件加密的信息，请参见第 19.3.2 节，“加密二进制日志文件和中继日志文件”。

由NDB进程生成或使用的文件，如操作系统日志、崩溃日志和核心转储，不会被加密。由NDB使用但不包含任何用户表数据的文件也不会被加密；这些文件包括 LCP 控制文件、模式文件和系统文件（参见 NDB 集群数据节点文件系统）。管理服务器配置缓存也不会被加密。

此外，NDB 8.0.31 添加了一个新的实用程序ndb_secretsfile_reader，用于从秘密文件（S0.sysfile）中提取密钥信息。

此增强功能建立在 NDB 8.0.22 中实现加密NDB备份的工作基础之上。有关加密备份的更多信息，请参见RequireEncryptedBackup配置参数的描述，以及第 25.6.8.2 节，“使用 NDB 集群管理客户端创建备份”。

移除不必要的程序选项。 在 NDB Cluster 8.0.31 版本中，删除了一些“垃圾”命令行选项，这些选项从未被实现过。以下列出了被删除选项和程序：

• --ndb-optimized-node-selection: ndbd, ndbmtd, ndb_mgm, ndb_delete_all, ndb_desc, ndb_drop_index, ndb_drop_table, ndb_show_table, ndb_blob_tool, ndb_config, ndb_index_stat, ndb_move_data, ndbinfo_select_all, ndb_select_count
• --character-sets-dir: ndb_mgm, ndb_mgmd, ndb_config, ndb_delete_all, ndb_desc, ndb_drop_index, ndb_drop_table, ndb_show_table, ndb_blob_tool, ndb_config, ndb_index_stat, ndb_move_data, ndbinfo_select_all, ndb_select_count, ndb_waiter
• --core-file: ndb_mgm, ndb_mgmd, ndb_config, ndb_delete_all, ndb_desc, ndb_drop_index, ndb_drop_table, ndb_show_table, ndb_blob_tool, ndb_config, ndb_index_stat, ndb_move_data, ndbinfo_select_all, ndb_select_count, ndb_waiter
• --connect-retries 和 --connect-retry-delay： ndb_mgmd
• --ndb-nodeid： ndb_config

更多信息，请参阅第 25.5 节，“NDB 集群程序”中相关程序和选项的描述。

读取配置缓存文件。 从 NDB 8.0.32 开始，可以使用该版本引入的 --config-binary-file 选项，通过ndb_mgmd创建的二进制配置缓存文件。这可以简化确定给定配置文件中的设置是否已应用于集群的过程，或在 config.ini 文件在某种方式受损或丢失后，从二进制缓存中恢复设置。

有关更多信息和示例，请参阅第 25.5.7 节，“ndb_config — 提取 NDB 集群配置信息”中对此选项的描述。

ndbinfo transporter_details 表。 这个ndbinfo表提供了关于 NDB 集群中使用的各个传输器的信息。在 NDB 8.0.37 中添加，与 ndbinfo transporters表类似。

有关更多信息，请参阅第 25.6.16.64 节，“ndbinfo transporter_details 表”。

MySQL Cluster Manager 支持 NDB 集群 8.0。MySQL Cluster Manager 具有先进的命令行界面，可以简化许多复杂的 NDB 集群管理任务。有关更多信息，请参阅 MySQL Cluster Manager 8.0.36 用户手册。

25.2.5 NDB 8.0 中新增、弃用或移除的选项、变量和参数

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-added-deprecated-removed.html

• NDB 8.0 中引入的参数
• NDB 8.0 中弃用的参数
• NDB 8.0 中移除的参数
• NDB 8.0 中引入的选项和变量
• NDB 8.0 中弃用的选项和变量
• NDB 8.0 中移除的选项和变量

接下来的几节包含有关 NDB 节点配置参数和 NDB 特定的 mysqld 选项和变量的信息，这些信息已经在 NDB 8.0 中新增、弃用或移除。

NDB 8.0 中引入的参数

以下是在 NDB 8.0 中新增的节点配置参数。

• AllowUnresolvedHostNames: 当为 false（默认）时，管理节点无法解析主机名会导致致命错误；当为 true 时，未解析的主机名仅报告警告。NDB 8.0.22 中添加。
• AutomaticThreadConfig: 使用自动线程配置；覆盖任何 ThreadConfig 和 MaxNoOfExecutionThreads 的设置，并禁用 ClassicFragmentation。NDB 8.0.23 中添加。
• ClassicFragmentation: 当为 true 时，使用传统表碎片化；设置为 false 以启用碎片在 LDM 之间的灵活分布。被 AutomaticThreadConfig 禁用。NDB 8.0.23 中添加。
• DiskDataUsingSameDisk: 如果磁盘数据表空间位于不同物理磁盘上，则设置为 false。NDB 8.0.19 中添加。
• EnableMultithreadedBackup: 启用多线程备份。NDB 8.0.16 中添加。
• EncryptedFileSystem: 加密本地检查点和表空间文件。实验性功能；不支持生产环境使用。NDB 8.0.29 中添加。
• KeepAliveSendInterval: 数据节点之间链接上保持活动信号之间的时间间隔，以毫秒为单位。设置为 0 以禁用。在 NDB 8.0.27 中添加。
• MaxDiskDataLatency: 允许的磁盘访问平均延迟的最大值（毫秒），在开始中止事务之前。在 NDB 8.0.19 中添加。
• NodeGroupTransporters: 同一节点组中节点之间使用的传输器数量。在 NDB 8.0.20 中添加。
• NumCPUs: 指定与 AutomaticThreadConfig 一起使用的 CPU 数量。在 NDB 8.0.23 中添加。
• PartitionsPerNode: 确定在每个数据节点上创建的表分区数；如果启用了 ClassicFragmentation，则不使用。在 NDB 8.0.23 中添加。
• PreferIPVersion: 指示 IP 版本 4 或 6 的 DNS 解析器首选项。在 NDB 8.0.26 中添加。
• RequireEncryptedBackup: 备份是否必须加密（1 = 需要加密，否则为 0）。在 NDB 8.0.22 中添加。
• ReservedConcurrentIndexOperations: 在一个数据节点上具有专用资源的同时索引操作数量。在 NDB 8.0.16 中添加。
• ReservedConcurrentOperations: 在一个数据节点上事务协调器中具有专用资源的同时操作数量。在 NDB 8.0.16 中添加。
• ReservedConcurrentScans: 在一个数据节点上具有专用资源的同时扫描数量。在 NDB 8.0.16 中添加。
• ReservedConcurrentTransactions: 在一个数据节点上具有专用资源的同时事务数量。在 NDB 8.0.16 中添加。
• ReservedFiredTriggers: 在一个数据节点上具有专用资源的触发器数量。在 NDB 8.0.16 中添加。
• ReservedLocalScans: 在一个数据节点上具有专用资源的同时片段扫描数量。在 NDB 8.0.16 中添加。
• ReservedTransactionBufferMemory: 分配给每个数据节点的键和属性数据的动态缓冲空间（以字节为单位）。在 NDB 8.0.16 中添加。
• SpinMethod: 确定数据节点使用的旋转方法；详细信息请参阅文档。在 NDB 8.0.20 中添加。
• TcpSpinTime: 在接收时进入休眠之前旋转的时间。在 NDB 8.0.20 中添加。
• TransactionMemory: 每个数据节点上为事务分配的内存。在 NDB 8.0.19 中添加。

在 NDB 8.0 中已弃用的参数

在 NDB 8.0 中已弃用以下节点配置参数。

• BatchSizePerLocalScan: 用于计算具有保持锁的扫描的锁记录数量。在 NDB 8.0.19 中已弃用。
• MaxAllocate: 不再使用；没有效果。在 NDB 8.0.27 中已弃用。
• MaxNoOfConcurrentIndexOperations: 在一个数据节点上可以同时执行的索引操作的总数。在 NDB 8.0.19 中已弃用。
• MaxNoOfConcurrentTransactions: 此数据节点上同时执行的事务数的最大值，可以同时执行的事务总数是此值乘以集群中数据节点的数量。在 NDB 8.0.19 中已弃用。
• MaxNoOfFiredTriggers: 在一个数据节点上可以同时触发的触发器总数。在 NDB 8.0.19 中已弃用。
• MaxNoOfLocalOperations: 此数据节点上定义的操作记录的最大数量。在 NDB 8.0.19 中已弃用。
• MaxNoOfLocalScans: 此数据节点上并行片段扫描的最大数量。在 NDB 8.0.19 中已弃用。
• ReservedTransactionBufferMemory: 为每个数据节点分配的用于键和属性数据的动态缓冲空间（以字节为单位）。在 NDB 8.0.19 中已弃用。
• UndoDataBuffer: 未使用；没有效果。在 NDB 8.0.27 中已弃用。
• UndoIndexBuffer: 未使用；没有效果。在 NDB 8.0.27 中已弃用。

在 NDB 8.0 中删除的参数

在 NDB 8.0 中没有删除任何节点配置参数。

在 NDB 8.0 中引入的选项和变量

在 NDB 8.0 中已添加以下系统变量、状态变量和服务器选项。

• Ndb_api_adaptive_send_deferred_count_replica: 该副本未实际发送的自适应发送调用次数。NDB 8.0.23 中添加。
• Ndb_api_adaptive_send_forced_count_replica: 该副本发送的强制发送的自适应发送次数。NDB 8.0.23 中添加。
• Ndb_api_adaptive_send_unforced_count_replica: 该副本发送的非强制发送的自适应发送次数。NDB 8.0.23 中添加。
• Ndb_api_bytes_received_count_replica: 该副本从数据节点接收的数据量（以字节为单位）。NDB 8.0.23 中添加。
• Ndb_api_bytes_sent_count_replica: 该副本发送到数据节点的数据量（以字节为单位）。NDB 8.0.23 中添加。
• Ndb_api_pk_op_count_replica: 该副本基于或使用主键��操作次数。NDB 8.0.23 中添加。
• Ndb_api_pruned_scan_count_replica: 该副本将扫描修剪为一个分区的次数。NDB 8.0.23 中添加。
• Ndb_api_range_scan_count_replica: 该副本启动的范围扫描次数。NDB 8.0.23 中添加。
• Ndb_api_read_row_count_replica: 该副本读取的总行数。NDB 8.0.23 中添加。
• Ndb_api_scan_batch_count_replica: 该副本接收的行批次数。NDB 8.0.23 中添加。
• Ndb_api_table_scan_count_replica: 该副本启动的表扫描次数，包括内部表的扫描。NDB 8.0.23 中添加。
• Ndb_api_trans_abort_count_replica: 该副本中事务被中止的次数。NDB 8.0.23 中添加。
• Ndb_api_trans_close_count_replica: 该副本中事务被中止的次数（可能大于 TransCommitCount 和 TransAbortCount 之和）。NDB 8.0.23 中添加。
• Ndb_api_trans_commit_count_replica: 该副本提交的事务数。NDB 8.0.23 中添加。
• Ndb_api_trans_local_read_row_count_replica: 此副本已读取的总行数。在 NDB 8.0.23 中添加。
• Ndb_api_trans_start_count_replica: 此副本启动的事务次数。在 NDB 8.0.23 中添加。
• Ndb_api_uk_op_count_replica: 此副本基于或使用唯一键的操作次数。在 NDB 8.0.23 中添加。
• Ndb_api_wait_exec_complete_count_replica: 等待此副本操作执行完成而被阻塞的线程次数。在 NDB 8.0.23 中添加。
• Ndb_api_wait_meta_request_count_replica: 等待此副本通过元数据信号而被阻塞的线程次数。在 NDB 8.0.23 中添加。
• Ndb_api_wait_nanos_count_replica: 此副本等待数据节点发出某种类型信号的总时间（以纳秒为单位）。在 NDB 8.0.23 中添加。
• Ndb_api_wait_scan_result_count_replica: 等待此副本通过扫描信号而被阻塞的线程次数。在 NDB 8.0.23 中添加。
• Ndb_config_generation: 集群当前配置的生成编号。在 NDB 8.0.24 中添加。
• Ndb_conflict_fn_max_del_win_ins: 基于 NDB$MAX_DEL_WIN_INS()结果的冲突解决机制在插入操作中被应用的次数。在 NDB 8.0.30 中添加。
• Ndb_conflict_fn_max_ins: "greater timestamp wins"冲突解决机制在插入操作中被应用的次数。在 NDB 8.0.30 中添加。
• Ndb_metadata_blacklist_size: NDB 二进制日志线程未能同步的 NDB 元数据对象数量；在 NDB 8.0.22 中更名为 Ndb_metadata_excluded_count。在 NDB 8.0.18 中添加。
• Ndb_metadata_detected_count: NDB 元数据更改监视线程检测到更改的次数。在 NDB 8.0.16 中添加。
• Ndb_metadata_excluded_count: NDB 二进制日志线程未能同步的 NDB 元数据对象数量。在 NDB 8.0.22 中添加。
• Ndb_metadata_synced_count: 已同步的 NDB 元数据对象数量。在 NDB 8.0.18 中添加。
• Ndb_trans_hint_count_session: 在此会话中启动的使用提示的事务数量。在 NDB 8.0.17 中添加。
• ndb-applier-allow-skip-epoch: 允许复制应用程序跳过时代。在 NDB 8.0.28 中添加。
• ndb-log-fail-terminate: 如果无法完全记录所有找到的行事件，则终止 mysqld 进程。在 NDB 8.0.21 中添加。
• ndb-log-transaction-dependency: 使二进制日志线程为写入二进制日志的每个事务计算事务依赖关系。在 NDB 8.0.33 中添加。
• ndb-schema-dist-timeout: 在检测到模式分发超时之前等待多长时间。在 NDB 8.0.17 中添加。
• ndb_conflict_role: 副本在冲突检测和解决中扮��的角色。值为 PRIMARY、SECONDARY、PASS 或 NONE（默认）。只能在停止复制 SQL 线程时更改。有关更多信息，请参阅文档。在 NDB 8.0.23 中添加。
• ndb_dbg_check_shares: 检查任何残留的共享（仅限调试构建）。在 NDB 8.0.13 中添加。
• ndb_log_transaction_compression: 是否压缩 NDB 二进制日志；也可以通过启用–binlog-transaction-compression 选项在启动时启用。在 NDB 8.0.31 中添加。
• ndb_log_transaction_compression_level_zstd: 写入压缩事务到 NDB 二进制日志时要使用的 ZSTD 压缩级别。在 NDB 8.0.31 中添加。
• ndb_metadata_check: 启用自动检测 NDB 元数据与 MySQL 数据字典的更改；默认启用。在 NDB 8.0.16 中添加。
• ndb_metadata_check_interval: 每隔多少秒执行一次检查 NDB 元数据与 MySQL 数据字典的更改。在 NDB 8.0.16 中添加。
• ndb_metadata_sync: 触发立即同步 NDB 字典和 MySQL 数据字典之间的所有更改；导致忽略 ndb_metadata_check 和 ndb_metadata_check_interval 值。同步完成后重置为 false。在 NDB 8.0.19 中添加。
• ndb_replica_batch_size: 副本应用程序的批处理大小（以字节为单位）。在 NDB 8.0.30 中添加。
• ndb_schema_dist_lock_wait_timeout: 在模式分发期间等待锁定的时间，超时后返回错误。在 NDB 8.0.18 中添加。
• ndb_schema_dist_timeout: 在模式分发期间检测超时之前等待的时间。在 NDB 8.0.16 中添加。
• ndb_schema_dist_upgrade_allowed: 当连接到 NDB 时允许模式分发表升级。在 NDB 8.0.17 中添加。
• ndbinfo: 启用 ndbinfo 插件（如果支持）。在 NDB 8.0.13 中添加。
• replica_allow_batching: 为副本打开或关闭更新批处���。在 NDB 8.0.26 中添加。

在 NDB 8.0 中已弃用的选项和变量

以下系统变量、状态变量和选项已在 NDB 8.0 中弃用。

• Ndb_api_adaptive_send_deferred_count_slave: 此副本未实际发送的自适应发送调用次数。在 NDB 8.0.23 中已弃用。
• Ndb_api_adaptive_send_forced_count_slave: 此副本发送的强制发送自适应发送次数。在 NDB 8.0.23 中已弃用。
• Ndb_api_adaptive_send_unforced_count_slave: 此副本发送的非强制发送自适应发送次数。在 NDB 8.0.23 中已弃用。
• Ndb_api_bytes_received_count_slave: 此副本从数据节点接收的数据量（以字节为单位）。在 NDB 8.0.23 中已弃用。
• Ndb_api_bytes_sent_count_slave: 此副本发送到数据节点的数据量（以字节为单位）。在 NDB 8.0.23 中已弃用。
• Ndb_api_pk_op_count_slave: 此副本基于或使用主键的操作次数。在 NDB 8.0.23 中已弃用。
• Ndb_api_pruned_scan_count_slave: 此副本已被修剪到一个分区的扫描次数。在 NDB 8.0.23 中已弃用。
• Ndb_api_range_scan_count_slave: 此副本启动的范围扫描次数。在 NDB 8.0.23 中已弃用。
• Ndb_api_read_row_count_slave: 该副本已读取的总行数。在 NDB 8.0.23 中已弃用。
• Ndb_api_scan_batch_count_slave: 该副本接收的行批次数量。在 NDB 8.0.23 中已弃用。
• Ndb_api_table_scan_count_slave: 该副本开始的表扫描次数，包括内部表的扫描。在 NDB 8.0.23 中已弃用。
• Ndb_api_trans_abort_count_slave: 该副本中被中止的事务数量。在 NDB 8.0.23 中已弃用。
• Ndb_api_trans_close_count_slave: 该副本中被中止的事务数量（可能大于 TransCommitCount 和 TransAbortCount 之和）。在 NDB 8.0.23 中已弃用。
• Ndb_api_trans_commit_count_slave: 该副本提交的事务数量。在 NDB 8.0.23 中已弃用。
• Ndb_api_trans_local_read_row_count_slave: 该副本已读取的总行数。在 NDB 8.0.23 中已弃用。
• Ndb_api_trans_start_count_slave: 该副本开始的事务数量。在 NDB 8.0.23 中已弃用。
• Ndb_api_uk_op_count_slave: 该副本基于或使用唯一键的操作次数。在 NDB 8.0.23 中已弃用。
• Ndb_api_wait_exec_complete_count_slave: 该副本中线程被阻塞等待操作执行完成的次数。在 NDB 8.0.23 中已弃用。
• Ndb_api_wait_meta_request_count_slave: 该副本中线程被阻塞等待基于元数据的信号的次数。在 NDB 8.0.23 中已弃用。
• Ndb_api_wait_nanos_count_slave: 该副本等待来自数据节点某种类型信号的总时间（以纳秒为单位）。在 NDB 8.0.23 中已弃用。
• Ndb_api_wait_scan_result_count_slave: 该副本中线程被阻塞等待基于扫描的信号的次数。在 NDB 8.0.23 中已弃用。
• Ndb_metadata_blacklist_size: NDB 二进制日志线程未能同步的 NDB 元数据对象数量；在 NDB 8.0.22 中更名为 Ndb_metadata_excluded_count。在 NDB 8.0.21 中已弃用。
• Ndb_replica_max_replicated_epoch: 此副本上最近提交的 NDB 时代。当此值大于或等于 Ndb_conflict_last_conflict_epoch 时，尚未检测到冲突。在 NDB 8.0.23 中已弃用。
• ndb_slave_conflict_role: 副本在冲突检测和解决中扮演的角色。值为 PRIMARY、SECONDARY、PASS 或 NONE（默认）。只能在停止复制 SQL 线程时更改。有关更多信息，请参阅文档。在 NDB 8.0.23 中已弃用。
• slave_allow_batching: 打开或关闭副本的更新批处理。在 NDB 8.0.26 中已弃用。

在 NDB 8.0 中移除的选项和变量

以下系统变量、状态变量和选项已在 NDB 8.0 中移除。

• Ndb_metadata_blacklist_size: NDB 二进制日志线程未能同步的 NDB 元数据对象数量；在 NDB 8.0.22 中更名为 Ndb_metadata_excluded_count。在 NDB 8.0.22 中已移除。

25.2.6 MySQL Server 使用 InnoDB 与 NDB Cluster 比较

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

25.2.6.1 NDB 和 InnoDB 存储引擎之间的差异

25.2.6.2 NDB 和 InnoDB 工作负载

25.2.6.3 NDB 和 InnoDB 特性使用总结

MySQL Server 提供了多种存储引擎选择。由于 NDB 和 InnoDB 都可以作为 MySQL 的事务性存储引擎，因此 MySQL Server 的用户有时会对 NDB Cluster 感兴趣。他们将 NDB 视为 MySQL 8.0 默认的 InnoDB 存储引擎的可能替代品或升级。虽然 NDB 和 InnoDB 共享一些共同特性，但在架构和实现上存在差异，因此一些现有的 MySQL Server 应用程序和使用场景可能非常适合 NDB Cluster，但并非所有情况都适用。

在本节中，我们讨论并比较了 NDB 8.0 使用的 NDB 存储引擎与 MySQL 8.0 中使用的 InnoDB 的一些特性。接下来的几节提供了技术比较。在许多情况下，关于何时何地使用 NDB Cluster 必须根据具体情况做出决策，考虑所有因素。虽然本文档无法为每种可能的使用场景提供具体细节，但我们也尝试就一些常见应用类型相对适用于 NDB 而非 InnoDB 后端提供一些非常一般性的指导。

NDB Cluster 8.0 使用基于 MySQL 8.0 的 mysqld，包括对 InnoDB 1.1 的支持。虽然可以在 NDB Cluster 中使用 InnoDB 表，但这些表不是集群化的。不可能使用 NDB Cluster 8.0 发行版中的程序或库与 MySQL Server 8.0，或者反过来。

尽管一些常见的商业应用程序可以在 NDB Cluster 或 MySQL 服务器上运行（最有可能使用InnoDB存储引擎），但存在一些重要的架构和实现差异。 第 25.2.6.1 节，“NDB 和 InnoDB 存储引擎之间的差异”提供了这些差异的摘要。由于这些差异，一些使用场景显然更适合其中一个引擎；请参见第 25.2.6.2 节，“NDB 和 InnoDB 工作负载”。这反过来影响了更适合与NDB或InnoDB一起使用的应用程序类型。请参见第 25.2.6.3 节，“NDB 和 InnoDB 特性使用摘要”，以比较它们在常见类型的数据库应用程序中的相对适用性。

有关NDB和MEMORY存储引擎的相对特性的信息，请参见何时使用 MEMORY 或 NDB Cluster。

有关 MySQL 存储引擎的其他信息，请参见第十八章，替代存储引擎。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndb-innodb-engines.html

25.2.6.1 NDB 和 InnoDB 存储引擎之间的差异

NDB 存储引擎采用分布式、无共享架构实现，这导致它在许多方面的行为与 InnoDB 有所不同。对于不习惯使用 NDB 的人来说，由于其分布式特性涉及事务、外键、表限制和其他特性，可能会出现意外行为。这些情况如下表所示：

表 25.2 InnoDB 和 NDB 存储引擎之间的差异

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndb-innodb-workloads.html

25.2.6.2 NDB 和 InnoDB 工作负载

NDB Cluster 具有一系列独特属性，使其非常适合提供需要高可用性、快速故障转移、高吞吐量和低延迟的应用程序。由于其分布式架构和多节点实现，NDB Cluster 还具有特定的约束条件，可能会导致某些工作负载性能不佳。关于一些常见类型的基于数据库驱动的应用程序工作负载，NDB和InnoDB存储引擎之间行为上的一些主要差异显示在以下表格中：

表 25.3 InnoDB 和 NDB 存储引擎之间的差异，常见类型的数据驱动应用程序工作负载。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndb-innodb-usage.html

25.2.6.3 NDB 和 InnoDB 特性使用摘要

当将应用程序特性要求与InnoDB和NDB的能力进行比较时，有些特性显然与一个存储引擎更兼容。

下表列出了根据每个特性通常更适合的存储引擎支持的应用程序特性。

表 25.4 根据每个特性通常更适合的存储引擎支持的应用程序特性

|

• 外键 注意 NDB Cluster 8.0 支持外键
• 完整表扫描
• 非常大的数据库、行或事务
• 除了READ COMMITTED之外的事务

|

• 写扩展
• 99.999% 的正常运行时间
• 节点的在线添加和在线模式操作
• 多个 SQL 和 NoSQL API（参见 NDB 集群 API：概述和概念）
• 实时性能
• 有限使用BLOB列
• 支持外键，尽管它们的使用可能会对高吞吐量的性能产生影响

|

25.2.7 NDB Cluster 的已知限制

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

25.2.7.1 NDB Cluster 中与 SQL 语法不符的限制

25.2.7.2 NDB Cluster 与标准 MySQL 限制的限制和差异

25.2.7.3 NDB Cluster 中与事务处理相关的限制

25.2.7.4 NDB Cluster 错误处理

25.2.7.5 NDB Cluster 中与数据库对象相关的限制

25.2.7.6 NDB Cluster 中不支持或缺失的功能

25.2.7.7 NDB Cluster 中与性能相关的限制

25.2.7.8 仅限于 NDB Cluster 的问���

25.2.7.9 NDB Cluster 磁盘数据存储相关的限制

25.2.7.10 与多个 NDB Cluster 节点相关的限制

25.2.7.11 在 NDB Cluster 8.0 中已解决的以前的 NDB Cluster 问题

在接下来的章节中，我们将讨论当前 NDB Cluster 版本中已知的限制，与使用 MyISAM 和 InnoDB 存储引擎时可用功能的比较。如果您在 MySQL bugs 数据库的“Cluster”类别中检查 bugs.mysql.com，您可以找到以下类别下的已知 bug：“MySQL Server:”，我们打算在即将发布的 NDB Cluster 版本中进行修正：

• NDB Cluster
• Cluster 直接 API (NDBAPI)
• Cluster 磁盘数据
• Cluster 复制
• ClusterJ

此信息旨在完整地描述刚刚设置的条件。您可以按照 第 1.5 节, “如何报告错误或问题” 中给出的说明，将您遇到的任何差异报告给 MySQL bugs 数据库。我们不打算在 NDB Cluster 8.0 中修复的任何问题都将添加到列表中。

查看 第 25.2.7.11 节, “在 NDB Cluster 8.0 中已解决的以前的 NDB Cluster 问题”，列出了在 NDB Cluster 8.0 中已解决的早期版本中的问题。

注意

NDB Cluster 复制特定的限制和其他问题在 第 25.7.3 节, “NDB Cluster 复制中已知问题” 中有描述。

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

25.2.7.1 NDB Cluster 中与 SQL 语法不符

与某些 MySQL 功能相关的某些 SQL 语句在与NDB表一起使用时会产生错误，如下列表所述：

临时表。 不支持临时表。尝试创建使用NDB存储引擎的临时表或更改现有临时表以使用NDB都会失败，并显示错误消息表存储引擎’ndbcluster’不支持创建选项’TEMPORARY’。

NDB 表中的索引和键。 NDB Cluster 表上的键和索引受以下限制：

列宽。 尝试在宽度大于 3072 字节的NDB表列上创建索引会成功，但实际上只有前 3072 字节用于索引。在这种情况下，会发出警告 Specified key was too long; max key length is 3072 bytes，并且SHOW CREATE TABLE语句显示索引的长度为 3072。

TEXT 和 BLOB 列。 你不能在使用NDB表列的TEXT或BLOB数据类型上创建索引。

FULLTEXT 索引。 NDB存储引擎不支持FULLTEXT索引，这仅适用于MyISAM和InnoDB表。

但是，你可以在NDB表的VARCHAR列上创建索引。

使用 HASH 键和 NULL。 在唯一键和主键中使用可空列意味着使用这些列的查询将被处理为全表扫描。要解决此问题，请使列NOT NULL，或重新创建索引而不使用USING HASH选项。

前缀。 没有前缀索引；只能对整个列进行索引。（NDB列索引的大小始终与列的宽度相同，以字节为单位，最多为 3072 字节，如本节前面描述的那样。另请参阅 Section 25.2.7.6, “Unsupported or Missing Features in NDB Cluster”，获取更多信息。）

BIT 列。 BIT列不能作为主键、唯一键或索引，也不能成为复合主键、唯一键或索引的一部分。

AUTO_INCREMENT 列。 与其他 MySQL 存储引擎一样，NDB存储引擎每个表最多只能处理一个AUTO_INCREMENT列，并且这个列必须被索引。然而，在没有显式主键的 NDB 表中，一个AUTO_INCREMENT列会被自动定义并用作“隐藏”主键。因此，你不能创建一个具有AUTO_INCREMENT列但没有显式主键的NDB表。

下面的CREATE TABLE语句不起作用，如下所示：

# No index on AUTO_INCREMENT column; table has no primary key
# Raises ER_WRONG_AUTO_KEY
mysql> CREATE TABLE n (
 ->     a INT,
 ->     b INT AUTO_INCREMENT
 ->     )
 -> ENGINE=NDB;
ERROR 1075 (42000): Incorrect table definition; there can be only one auto
column and it must be defined as a key 

# Index on AUTO_INCREMENT column; table has no primary key
# Raises NDB error 4335
mysql> CREATE TABLE n (
 ->     a INT,
 ->     b INT AUTO_INCREMENT,
 ->     KEY k (b)
 ->     )
 -> ENGINE=NDB;
ERROR 1296 (HY000): Got error 4335 'Only one autoincrement column allowed per
table. Having a table without primary key uses an autoincr' from NDBCLUSTER

下面的语句创建了一个具有主键、一个AUTO_INCREMENT列以及对该列的索引的表，并成功：

# Index on AUTO_INCREMENT column; table has a primary key
mysql> CREATE TABLE n (
 ->     a INT PRIMARY KEY,
 ->     b INT AUTO_INCREMENT,
 ->     KEY k (b)
 ->     )
 -> ENGINE=NDB;
Query OK, 0 rows affected (0.38 sec)

外键的限制。 NDB 8.0 中对外键约束的支持与InnoDB提供的相似，但受以下限制：

• 每个作为外键引用的列都需要一个显式的唯一键，如果它不是表的主键。
• 当引用是指向父表的主键时，不支持ON UPDATE CASCADE。 这是因为对主键的更新被实现为删除旧行（包含旧主键的行）以及插入新行（带有新主键）。这对于NDB内核来说是不可见的，它将这两行视为相同，因此无法知道应该级联执行此更新。
• 当子表包含一个或多个TEXT或BLOB类型的列时，也不支持ON DELETE CASCADE。（Bug #89511, Bug #27484882）
• 不支持SET DEFAULT。（InnoDB也不支持。）
• NO ACTION关键字被接受但被视为RESTRICT。NO ACTION是标准 SQL 关键字，在 MySQL 8.0 中是默认的。（与InnoDB相同。）
• 在早期版本的 NDB Cluster 中，当创建一个具有外键引用另一张表中索引的表时，有时似乎可以创建外键，即使索引中列的顺序不匹配，这是因为并不总是返回适当的错误。对于这个问题的部分修复改进了内部使用的错误以在大多数情况下工作；然而，在父索引是唯一索引的情况下，仍然可能发生这种情况。（Bug #18094360）

有关更多信息，请参见第 15.1.20.5 节，“外键约束”和第 1.6.3.2 节，“外键约束”。

NDB 集群和几何数据类型。 几何数据类型（WKT和WKB）支持NDB表。但是，不支持空间索引。

字符集和二进制日志文件。 目前，ndb_apply_status和ndb_binlog_index表使用latin1（ASCII）字符集创建。由于二进制日志的名称记录在此表中，因此使用非拉丁字符命名的二进制日志文件在这些表中无法正确引用。这是一个已知问题，我们正在努力解决。（Bug #50226）

要解决此问题，请在命名二进制日志文件或设置--basedir、--log-bin或--log-bin-index选项时仅使用 Latin-1 字符。

使用用户定义的分区创建 NDB 表。 NDB 集群中对用户定义的分区的支持仅限于[LINEAR] KEY分区。在CREATE TABLE语句中使用ENGINE=NDB或ENGINE=NDBCLUSTER与任何其他分区类型会导致错误。

可以覆盖此限制，但不支持在生产环境中使用。有关详细信息，请参见用户定义的分区和 NDB 存储引擎（NDB 集群）")。

默认分区方案。 所有 NDB 集群表默认通过使用表的主键作为分区键进行KEY分区。如果未为表明确设置主键，则由NDB存储引擎自动创建的“隐藏”主键将被使用。有关这些和相关问题的更多讨论，请参见第 26.2.5 节，“KEY 分区”。

CREATE TABLE和ALTER TABLE语句如果导致用户分区的NDBCLUSTER表不满足以下两个要求中的任何一个或两个都不允许，并将失败并显示错误：

1. 表必须有显式的主键。
2. 表中分区表达式中列出的所有列必须是主键的一部分。

例外。 如果使用空列列表（即使用PARTITION BY [LINEAR] KEY()）创建用户分区的NDBCLUSTER表，则不需要显式主键。

NDBCLUSTER 表的最大分区数。 当使用用户定义的分区时，NDBCLUSTER表可以定义的最大分区数为每个节点组 8 个。（有关 NDB Cluster 节点组的更多信息，请参见第 25.2.2 节，“NDB Cluster 节点、节点组、片段副本和分区”）。

不支持 DROP PARTITION。 无法使用ALTER TABLE ... DROP PARTITION从NDB表中删除分区。对于 NDB 表，支持其他分区扩展——ADD PARTITION、REORGANIZE PARTITION和COALESCE PARTITION，但使用复制，因此不是优化的。请参见第 26.3.1 节，“RANGE 和 LIST 分区的管理”和第 15.1.9 节，“ALTER TABLE 语句”。

分区选择。 不支持为NDB表选择分区。有关更多信息，请参见第 26.5 节，“分区选择”。

JSON 数据类型。 MySQL 中的JSON数据类型在 NDB 8.0 中的mysqld中支持NDB表。

一个NDB表最多可以有 3 个JSON列。

NDB API 没有专门用于处理JSON数据的功能，它将其简单地视为BLOB数据。处理数据为JSON必须由应用程序执行。

这是因为对主键的更新被实现为删除旧行（包含旧主键的行）以及插入新行（带有新主键）。这对于`NDB`内核来说是不可见的，它将这两行视为相同，因此无法知道应该级联执行此更新。

• 当子表包含一个或多个TEXT或BLOB类型的列时，也不支持ON DELETE CASCADE。（Bug #89511, Bug #27484882）
• 不支持SET DEFAULT。（InnoDB也不支持。）
• NO ACTION关键字被接受但被视为RESTRICT。NO ACTION是标准 SQL 关键字，在 MySQL 8.0 中是默认的。（与InnoDB相同。）
• 在早期版本的 NDB Cluster 中，当创建一个具有外键引用另一张表中索引的表时，有时似乎可以创建外键，即使索引中列的顺序不匹配，这是因为并不总是返回适当的错误。对于这个问题的部分修复改进了内部使用的错误以在大多数情况下工作；然而，在父索引是唯一索引的情况下，仍然可能发生这种情况。（Bug #18094360）

有关更多信息，请参见第 15.1.20.5 节，“外键约束”和第 1.6.3.2 节，“外键约束”。

NDB 集群和几何数据类型。 几何数据类型（WKT和WKB）支持NDB表。但是，不支持空间索引。

字符集和二进制日志文件。 目前，ndb_apply_status和ndb_binlog_index表使用latin1（ASCII）字符集创建。由于二进制日志的名称记录在此表中，因此使用非拉丁字符命名的二进制日志文件在这些表中无法正确引用。这是一个已知问题，我们正在努力解决。（Bug #50226）

要解决此问题，请在命名二进制日志文件或设置--basedir、--log-bin或--log-bin-index选项时仅使用 Latin-1 字符。

使用用户定义的分区创建 NDB 表。 NDB 集群中对用户定义的分区的支持仅限于[LINEAR] KEY分区。在CREATE TABLE语句中使用ENGINE=NDB或ENGINE=NDBCLUSTER与任何其他分区类型会导致错误。

可以覆盖此限制，但不支持在生产环境中使用。有关详细信息，请参见用户定义的分区和 NDB 存储引擎（NDB 集群）")。

默认分区方案。 所有 NDB 集群表默认通过使用表的主键作为分区键进行KEY分区。如果未为表明确设置主键，则由NDB存储引擎自动创建的“隐藏”主键将被使用。有关这些和相关问题的更多讨论，请参见第 26.2.5 节，“KEY 分区”。

CREATE TABLE和ALTER TABLE语句如果导致用户分区的NDBCLUSTER表不满足以下两个要求中的任何一个或两个都不允许，并将失败并显示错误：

1. 表必须有显式的主键。
2. 表中分区表达式中列出的所有列必须是主键的一部分。

例外。 如果使用空列列表（即使用PARTITION BY [LINEAR] KEY()）创建用户分区的NDBCLUSTER表，则不需要显式主键。

NDBCLUSTER 表的最大分区数。 当使用用户定义的分区时，NDBCLUSTER表可以定义的最大分区数为每个节点组 8 个。（有关 NDB Cluster 节点组的更多信息，请参见第 25.2.2 节，“NDB Cluster 节点、节点组、片段副本和分区”）。

不支持 DROP PARTITION。 无法使用ALTER TABLE ... DROP PARTITION从NDB表中删除分区。对于 NDB 表，支持其他分区扩展——ADD PARTITION、REORGANIZE PARTITION和COALESCE PARTITION，但使用复制，因此不是优化的。请参见第 26.3.1 节，“RANGE 和 LIST 分区的管理”和第 15.1.9 节，“ALTER TABLE 语句”。

分区选择。 不支持为NDB表选择分区。有关更多信息，请参见第 26.5 节，“分区选择”。

JSON 数据类型。 MySQL 中的JSON数据类型在 NDB 8.0 中的mysqld中支持NDB表。

一个NDB表最多可以有 3 个JSON列。

NDB API 没有专门用于处理JSON数据的功能，它将其简单地视为BLOB数据。处理数据为JSON必须由应用程序执行。