MySQL8 中文参考（九十四）

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

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

25.6.2.4 NDB Cluster: NDB Transporter Errors

此部分列出了在传输器错误发生时写入集群日志的错误代码、名称和消息。

0x00

TE_NO_ERROR

无错误

0x01

TE_ERROR_CLOSING_SOCKET

关闭套接字时发现错误

0x02

TE_ERROR_IN_SELECT_BEFORE_ACCEPT

在接受之前发现错误。传输器将重试

0x03

TE_INVALID_MESSAGE_LENGTH

在消息中发现错误（无效的消息长度）

0x04

TE_INVALID_CHECKSUM

在消息中发现错误（校验和）

0x05

TE_COULD_NOT_CREATE_SOCKET

创建套接字时发现错误（无法创建套接字）

0x06

TE_COULD_NOT_BIND_SOCKET

绑定服务器套接字时发现错误

0x07

TE_LISTEN_FAILED

监听服务器套接字时发现错误

0x08

TE_ACCEPT_RETURN_ERROR

在 accept 期间发现错误（接受返回错误）

0x0b

TE_SHM_DISCONNECT

远程节点已断开连接

0x0c

TE_SHM_IPC_STAT

无法检查 shm 段

0x0d

TE_SHM_UNABLE_TO_CREATE_SEGMENT

无法创建 shm 段

0x0e

TE_SHM_UNABLE_TO_ATTACH_SEGMENT

无法附加 shm 段

0x0f

TE_SHM_UNABLE_TO_REMOVE_SEGMENT

无法移除 shm 段

0x10

TE_TOO_SMALL_SIGID

Sig ID 太小

0x11

TE_TOO_LARGE_SIGID

Sig ID 太大

0x12

TE_WAIT_STACK_FULL

等待堆栈已满

0x13

TE_RECEIVE_BUFFER_FULL

接收缓冲区已满

0x14

TE_SIGNAL_LOST_SEND_BUFFER_FULL

发送缓冲区已满，并且尝试强制发送失败

0x15

TE_SIGNAL_LOST

发送失败原因未知（信号丢失）

0x16

TE_SEND_BUFFER_FULL

发送缓冲区已满，但睡一会解决了问题

0x21

TE_SHM_IPC_PERMANENT

Shm ipc Permanent 错误

注意

传输器错误代码 0x17 到 0x20 和 0x22 保留用于 SCI 连接，在此版本的 NDB Cluster 中不支持，因此未包含在此处。

25.6.3 在 NDB Cluster 中生成的事件报告

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

25.6.3.1 NDB Cluster Logging Management Commands

25.6.3.2 NDB Cluster Log Events

25.6.3.3 在 NDB Cluster 管理客户端中使用 CLUSTERLOG STATISTICS

在本节中，我们讨论 NDB Cluster 提供的事件日志类型，以及记录的事件类型。

NDB Cluster 提供两种类型的事件日志：

• 集群日志，其中包括所有集群节点生成的事件。集群日志是推荐用于大多数情况的日志，因为它提供了整个集群的日志信息。

  默认情况下，集群日志保存在名为ndb_*node_id*_cluster.log的文件中（其中*node_id*是管理服务器的节点 ID），位于管理服务器的DataDir中。

  集群日志信息也可以发送到stdout或syslog设施，而不是或除了保存到文件中，这取决于为DataDir和LogDestination配置参数设置的值。有关这些参数的更多信息，请参见 Section 25.4.3.5, “Defining an NDB Cluster Management Server”。

• 节点日志对每个节点是本地的。

  节点事件日志生成的输出被写入文件ndb_*node_id*_out.log（其中*node_id*是节点的节点 ID），位于节点的DataDir中。节点事件日志为管理节点和数据节点生成。

  节点日志仅用于应用程序开发或调试应用程序代码。

每个可报告事件可以根据三个不同的标准进行区分：

• 类别：可以是以下任一值之一：STARTUP、SHUTDOWN、STATISTICS、CHECKPOINT、NODERESTART、CONNECTION、ERROR或INFO。

• 优先级：表示为从 0 到 15 的数字之一，其中 0 表示“最重要”，15 表示“最不重要”。

• 严重级别：可以是以下任一值之一：ON、DEBUG、INFO、WARNING、ERROR、CRITICAL、ALERT或ALL。（有时也称为日志级别。）

可使用 NDB 管理客户端CLUSTERLOG命令在这些属性上过滤集群日志。此命令仅影响集群日志，并不影响节点日志；可以使用ndb_mgm NODELOG DEBUG 命令打开和关闭一个或多个节点日志中的调试日志记录。

NDB Cluster 生成的日志消息的格式（截至 NDB 8.0.26）如下所示：

*timestamp* [*node_type*] *level* -- Node *node_id*: *message*
1

日志中的每行，或日志消息，包含以下信息：

• 以*YYYY*-*MM*-*DD* *HH*:*MM*:*SS*格式的*timestamp*。时间戳值目前仅解析到整秒；不支持小数秒。

• node_type，即执行日志记录的节点或应用程序的类型。在集群日志中，这始终是[MgmSrvr]；在数据节点日志中，始终是[ndbd]。在由 NDB API 应用程序和工具生成的日志中可能出现[NdbApi]和其他值。

• 事件的*level*，有时也称为其严重级别或日志级别。有关严重级别的更多信息，请参见本节前面以及第 25.6.3.1 节，“NDB Cluster 日志管理命令”。

• 报告事件的节点的 ID（node_id）。

• 包含事件描述的*message*。日志中出现的最常见事件类型是集群中不同节点之间的连接和断开连接，以及发生检查点时。在某些情况下，描述可能包含状态或其他信息。

这里显示了实际集群日志中的示例：

2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 5: Start phase 5 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 6: Start phase 5 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 5: Start phase 6 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 6: Start phase 6 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 5: President restarts arbitration thread [state=1]
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 5: Start phase 7 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 6: Start phase 7 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 5: Start phase 8 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 6: Start phase 8 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 5: Start phase 9 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 6: Start phase 9 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 5: Start phase 50 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 6: Start phase 50 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 5: Start phase 101 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 6: Start phase 101 completed (system restart)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 5: Started (mysql-8.0.35 ndb-8.0.35)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 6: Started (mysql-8.0.35 ndb-8.0.35)
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 5: Node 50: API mysql-8.0.35 ndb-8.0.35
2021-06-10 10:01:07 [MgmtSrvr] INFO     -- Node 6: Node 50: API mysql-8.0.35 ndb-8.0.35
2021-06-10 10:01:08 [MgmtSrvr] INFO     -- Node 6: Prepare arbitrator node 50 [ticket=75fd00010fa8b608]
2021-06-10 10:01:08 [MgmtSrvr] INFO     -- Node 5: Started arbitrator node 50 [ticket=75fd00010fa8b608]
2021-06-10 10:01:08 [MgmtSrvr] INFO     -- Node 6: Communication to Node 100 opened
2021-06-10 10:01:08 [MgmtSrvr] INFO     -- Node 6: Communication to Node 101 opened
2021-06-10 10:01:08 [MgmtSrvr] INFO     -- Node 5: Communication to Node 100 opened
2021-06-10 10:01:08 [MgmtSrvr] INFO     -- Node 5: Communication to Node 101 opened
2021-06-10 10:01:36 [MgmtSrvr] INFO     -- Alloc node id 100 succeeded
2021-06-10 10:01:36 [MgmtSrvr] INFO     -- Nodeid 100 allocated for API at 127.0.0.1
2021-06-10 10:01:36 [MgmtSrvr] INFO     -- Node 100: mysqld --server-id=1
2021-06-10 10:01:36 [MgmtSrvr] INFO     -- Node 5: Node 100 Connected
2021-06-10 10:01:36 [MgmtSrvr] INFO     -- Node 6: Node 100 Connected
2021-06-10 10:01:36 [MgmtSrvr] INFO     -- Node 5: Node 100: API mysql-8.0.35 ndb-8.0.35
2021-06-10 10:01:36 [MgmtSrvr] INFO     -- Node 6: Node 100: API mysql-8.0.35 ndb-8.0.35
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

有关更多信息，请参见第 25.6.3.2 节，“NDB Cluster 日志事件”。

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

25.6.3.1 NDB Cluster Logging Management Commands

ndb_mgm支持与集群日志和节点日志相关的许多管理命令。在接下来的列表中，*node_id*表示存储节点 ID 或关键字ALL，表示该命令应用于所有集群的数据节点。

• CLUSTERLOG ON

  打开集群日志。

• CLUSTERLOG OFF

  关闭集群日志。

• CLUSTERLOG INFO

  提供有关集群日志设置的信息。

• *node_id* CLUSTERLOG *category*=*threshold*

  在集群日志中记录*category事件，其优先级小于或等于threshold*。

• CLUSTERLOG FILTER *severity_level*

  切换指定*severity_level*事件的集群日志记录。

以下表描述了集群日志类别阈值的默认设置（所有数据节点）。如果事件的优先级值低于或等于优先级阈值，则会在集群日志中报告。

注意

事件按数据节点报告，并且阈值可以在不同节点上设置为不同值。

表 25.54 集群日志类别，默认阈值设置

STATISTICS类别可以提供大量有用的数据。有关更多信息，请参见第 25.6.3.3 节，“在 NDB Cluster 管理客户端中使用 CLUSTERLOG STATISTICS”。

阈值用于过滤每个类别中的事件。例如，具有优先级 3 的STARTUP事件除非STARTUP的阈值设置为 3 或更高，否则不会记录。如果阈值为 3，则只发送优先级为 3 或更低的事件。

以下表显示了事件严重级别。

注意

这些对应于 Unix 的syslog级别，除了未使用或映射的LOG_EMERG和LOG_NOTICE。

表 25.55 事件严重级别

事件严重级别可以通过CLUSTERLOG FILTER（见上文）打开或关闭。如果打开了一个严重级别，那么所有优先级小于或等于类别阈值的事件都会被记录下来。如果关闭了严重级别，则不会记录属于该严重级别的任何事件。

重要提示

集群日志级别是根据每个ndb_mgmd、每个订阅者的基础进行设置。这意味着，在具有多个管理服务器的 NDB 集群中，使用连接到一个管理服务器的ndb_mgm实例中的CLUSTERLOG命令仅影响由该管理服务器生成的日志，而不影响其他任何管理服务器生成的日志。这也意味着，如果其中一个管理服务器重新启动，那么只有由该管理服务器生成的日志会受到由重新启动引起的日志级别重置的影响。

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

25.6.3.2 NDB 集群日志事件

事件日志中报告的事件报告具有以下格式：

*datetime* [*string*] *severity* -- *message*
1

例如：

09:19:30 2005-07-24 [NDB] INFO -- Node 4 Start phase 4 completed
1

本节讨论按类别和每个类别内的严重级别排序的所有可报告事件。

在事件描���中，GCP 和 LCP 分别表示“全局检查点”和“本地检查点”。

连接事件

这些事件与集群节点之间的连接相关联。

表 25.56 与集群节点之间连接相关的事件

检查点事件

此处显示的日志消息与检查点相关。

表 25.57 与检查点相关的事件

启动事件

以下事件是响应节点或集群启动及其成功或失败而生成的。它们还提供与启动过程的进展相关的信息，包括有关日志活动的信息。

表 25.58 与节点或集群启动相关的事件

NODERESTART 事件

当重新启动节点并与节点重新启动过程的成功或失败相关时，将生成以下事件。

表 25.59 与重新启动节点相关的事件

| ArbitState | 6 | INFO | 报告是否找到仲裁者；在寻找仲裁者时有七种不同的可能结果，列在此处：

• 管理服务器重新启动仲裁线程 [状态=X]

• 准备仲裁节点 X [票=Y]

• 接收仲裁节点 X [票=Y]

• 启动仲裁节点 X [票=Y]

• 丢失仲裁节点 X - 进程失败 [状态=Y]

• 丢失仲裁节点 X - 进程退出 [状态=Y]

• 丢失仲裁���点 X <错误消息> [状态=Y]

|

| ArbitResult | 2 | ALERT | 报告仲裁结果；仲裁尝试有八种不同的可能结果，列在此处：

• 仲裁检查失败：少于 1/2 的节点剩余

• 仲裁检查成功：节点组多数

• 仲裁检查失败：缺少节点组

• 网络分区：需要仲裁

• 仲裁成功：来自节点 X 的肯定回应

• 仲裁失败：来自节点 X 的负面回应

• 网络分区：没有可用的仲裁节点

• 网络分区：未配置仲裁节点

|

统计事件

以下事件具有统计性质。它们提供诸如事务数和其他操作数、单个节点发送或接收的数据量以及内存使用情况等信息。

表 25.60 统计性质事件

模式事件

这些事件涉及 NDB 集群模式操作。

表 25.61 与 NDB 集群模式操作相关的事件

错误事件

这些事件涉及集群错误和警告。其中一个或多个的存在通常表示发生了重大故障或失败。

表 25.62 与集群错误和警告相关的事件

信息事件

这些事件提供有关集群状态和与集群维护相关活动的一般信息，例如日志记录和心跳传输。

表 25.63 信息事件

注意

SentHeartbeat 事件仅在使用 VM_TRACE 编译的 NDB Cluster 中可用。

单用户事件

这些事件与进入和退出单用户模式相关联。

表 25.64 与单用户模式相关的事件

备份事件

这些事件提供有关创建或恢复备份的信息。

表 25.65 备份事件

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

25.6.3.3 在 NDB Cluster 管理客户端中使用 CLUSTERLOG STATISTICS

NDB管理客户端的CLUSTERLOG STATISTICS命令可以在其输出中提供许多有用的统计信息。提供有关集群状态的计数器每 5 秒由事务协调器 (TC) 和本地查询处理程序 (LQH) 更新一次，并写入集群日志。

事务协调器统计信息。 每个事务都有一个事务协调器，可以通过以下方法之一选择：

• 以轮询方式

• 通过通信接近度

• 在事务启动时提供数据放置提示

注意

你可以通过ndb_optimized_node_selection系统变量确定从给定 SQL 节点开始的事务使用哪种 TC 选择方法。

同一事务内的所有操作使用相同的事务协调器，报告以下统计信息：

• 事务计数。 这是在上一个间隔内使用此 TC 作为事务协调器启动的事务数量。这些事务中的任何一个可能已提交、已中止或在报告间隔结束时仍未提交。

  注意

  事务不会在 TC 之间迁移。

• 提交计数。 这是在上一个报告间隔内使用此 TC 作为事务协调器提交的事务数量。因为一些在此报告间隔内提交的事务可能在之前的报告间隔内启动，所以提交计数可能大于事务计数。

• 读取计数。 这是在上一个报告间隔内使用此 TC 作为事务协调器启动的主键读取操作次数，包括简单读取。此计数还包括作为唯一索引操作的读取。唯一索引读取操作生成 2 个主键读取操作——一个用于隐藏的唯一索引表，一个用于读取发生的表。

• 简单读取计数。 这是在上一个报告间隔内使用此 TC 作为事务协调器启动的简单读取操作次数。

• 写入计数。 这是在上一个报告间隔内以此 TC 作为事务协调器启动的主键写入操作次数。这包括所有插入、更新、写入和删除操作，以及作为唯一索引操作的写入。

  注意

  唯一索引更新操作可能在索引表和基表上生成多个主键读取和写入操作。

• **AttrInfoCount. ** 这是在上一个报告间隔中接收的 32 位数据字的数量，用于使用此 TC 作为事务协调器的主键操作。对于读取操作，这与请求的列数成比例。对于插入和更新操作，这与写入的列数以及它们的数据大小成比例。对于删除操作，这通常为零。

  唯一索引操作会生成多个 PK 操作，因此会增加此计数。但是，用于描述 PK 操作本身的数据字以及发送的关键信息在此处不计入。用于描述扫描读取的列或描述 ScanFilters 的属性信息也不计入 AttrInfoCount。

• **Concurrent Operations. ** 这是在上一个报告间隔中启动但未完成的使用此 TC 作为事务协调器的主键或扫描操作的数量。当操作启动时，此计数器会递增，并在操作完成后递减；这发生在事务提交后。脏读和写操作以及失败的操作会递减此计数器。

  Concurrent Operations 可以达到的最大值是 TC 块可以支持的操作数的最大值；目前，这是 (2 * MaxNoOfConcurrentOperations) + 16 + MaxNoOfConcurrentTransactions。（有关这些配置参数的更多信息，请参见 25.4.3.6 节，“定义 NDB 集群数据节点”的事务参数部分。）

• **Abort count. ** 这是在上一个报告间隔中被中止的使用此 TC 作为事务协调器的事务的数量。因为在上一个报告间隔中被中止的一些事务可能在先前的报告间隔中开始，Abort count 有时可能大于 Trans count。

• **Scans. ** 这是在上一个报告间隔中启动的使用此 TC 作为事务协调器的表扫描的数量。这不包括范围扫描（即，有序索引扫描）。

• **Range scans. ** 这是在上一个报告间隔中启动的使用此 TC 作为事务协调器的有序索引扫描的数量。

• **Local reads. ** 这是在一个节点上使用事务协调器执行的主键读取操作的数量，该节点还保存记录的主键片段副本。此计数也可以从ndbinfo.counters表中的 LOCAL_READS 计数器中获取。

• 本地写入。 这包含使用事务协调器在同时还持有记录主要片段副本的节点上执行的主键读取操作的数量。此计数也可以从ndbinfo.counters表中的LOCAL_WRITES计数器中获取。

本地查询处理程序统计信息（操作）。 每个本地查询处理程序块（即每个数据节点进程）有 1 个集群事件。操作记录在数据所在的 LQH 中。

注意

单个事务可能操作存储在多个 LQH 块中的数据。

Operations统计数据提供了此 LQH 块在上一个报告间隔中执行的本地操作数量，并包括所有类型的读取和写入操作（插入、更新、写入和删除操作）。这还包括用于复制写入的操作。例如，在具有两个片段副本的集群中，对主要片段副本的写入记录在主 LQH 中，对备份的写入记录在备份 LQH 中。唯一键操作可能导致多个本地操作；但是，这不包括由于表扫描或有序索引扫描而生成的本地操作，这些操作不计入统计。

进程调度器统计信息。 除了事务协调器和本地查询处理程序报告的统计信息外，每个ndbd进程都有一个调度程序，还提供与 NDB Cluster 性能相关的有用指标。此调度程序在无限循环中运行；在每个循环期间，调度程序执行以下任务：

1. 从套接字中读取任何传入的消息到作业缓冲区中。

2. 检查是否有任何定时消息需要执行；如果有，也将这些放入作业缓冲区中。

3. 执行（循环执行）作业缓冲区中的任何消息。

4. 发送通过执行作业缓冲区中的消息生成的任何分布式消息。

5. 等待任何新到来的消息。

进程调度器统计信息包括以下内容：

• 平均循环计数器。 这是从前述列表的第三步中执行的循环次数。随着 TCP/IP 缓冲区的利用率提高，此统计数据会增加。您可以使用此功能来监视随着添加新数据节点进程而发生的性能变化。

• 平均发送大小和平均接收大小。 这些统计数据使您能够衡量节点之间的写入和读取的效率。这些值以字节为单位给出。较高的值意味着每个字节发送或接收的成本较低；最大值为 64K。

要导致记录所有集群日志统计信息，您可以在NDB管理客户端中使用以下命令：

ndb_mgm> ALL CLUSTERLOG STATISTICS=15
1

注意

将STATISTICS的阈值设置为 15 会导致集群日志变得非常冗长，并且随着集群节点数量和 NDB 集群中活动量的增加而迅速增长。

有关与日志记录和报告相关的 NDB 集群管理客户端命令的更多信息，请参见第 25.6.3.1 节，“NDB 集群日志管理命令”。

25.6.4 NDB 集群启动阶段摘要

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

本节提供了 NDB 集群数据节点启动时涉及的步骤的简化概述。更完整的信息可以在 NDB 集群启动阶段中找到，NDB内部指南中。

这些阶段与管理客户端中*node_id* STATUS命令输出中报告的相同（请参见第 25.6.1 节，“NDB 集群管理客户端中的命令”）。这些启动阶段也在ndbinfo.nodes表的start_phase列中报告。

启动类型。 有几种不同的启动类型和模式，如下列表所示：

• 初始启动。 集群在所有数据节点上都有一个干净的文件系统启动。这要么是当集群第一次启动时发生，要么是当所有数据节点使用--initial选项重新启动时发生。

  注意

  使用--initial重新启动节点时，磁盘数据文件不会被删除。

• 系统重新启动。 集群启动并读取存储在数据节点中的数据。当集群在使用后关闭后，希望集群从离开的地方恢复操作时发生。

• 节点重新启动。 这是在集群本身正在运行时对集群节点进行在线重新启动。

• 初始节点重新启动。 这与节点重新启动相同，只是节点被重新初始化并以干净的文件系统启动。

设置和初始化（阶段-1）。 在启动之前，每个数据节点（ndbd进程）必须被初始化。初始化包括以下步骤：

1. 获取节点 ID

2. 获取配置数据

3. 为节点间通信分配端口

4. 根据配置文件中的设置分配内存

当数据节点或 SQL 节点首次连接到管理节点时，它会保留一个集群节点 ID。为了确保没有其他节点分配相同的节点 ID，此 ID 将保留，直到节点成功连接到集群并至少一个ndbd报告此节点已连接。此节点 ID 的保留由问题节点与ndb_mgmd之间的连接保护。

在每个数据节点初始化后，集群启动过程可以继续进行。集群在此过程中经历的阶段如下：

• 第 0 阶段。 NDBFS 和 NDBCNTR 块启动。对于使用 --initial 选项启动的数据节点，这些数据节点的文件系统会被清除。

• 第 1 阶段。 在此阶段，所有剩余的 NDB 内核块启动。建立 NDB 集群连接，建立块间通信，并启动心跳。在节点重新启动的情况下，还会检查 API 节点连接。

  注意

  当一个或多个节点在第 1 阶段挂起，而其余节点在第 2 阶段挂起时，通常表示存在网络问题。造成此类问题的一个可能原因是一个或多个集群主机具有多个网络接口。导致此条件的问题的另一个常见来源是阻止集群节点之间通信所需的 TCP/IP 端口。在后一种情况下，这通常是由于防火墙配置错误造成的。

• 第 2 阶段。 NDBCNTR 内核块检查所有现有节点的状态。选择主节点，并初始化集群模式文件。

• 第 3 阶段。 DBLQH 和 DBTC 内核块之间建立通信。确定启动类型；如果这是一个重新启动，DBDIH 块获得执行重新启动的权限。

• 第 4 阶段。 对于初始启动或初始节点重新启动，会创建重做日志文件。这些文件的数量等于 NoOfFragmentLogFiles。

  对于系统重新启动：

  • 读取模式或模式。

  • 从本地检查点读取数据。

  • 应用所有重做信息，直到达到最新可恢复的全局检查点。

  对于节点重新启动，找到重做日志的尾部。

• 第 5 阶段。 数据节点启动的大部分与数据库相关的工作在此阶段完成。对于初始启动或系统重新启动，会执行本地检查点，然后是全局检查点。在此阶段开始定期检查内存使用情况，并执行任何必要的节点接管。

• 第 6 阶段。 在此阶段，定义并设置节点组。

• 第 7 阶段。 选择仲裁节点并开始运行。设置下一个备份 ID，以及备份磁盘写入速度。达到此启动阶段���节点被标记为已启动。现在 API 节点（包括 SQL 节点）可以连接到集群。

• 第 8 阶段。 如果这是系统重新启动，所有索引都将被重建（由DBDIH）。

• 第 9 阶段。 节点内部启动变量被重置。

• 第 100 阶段（已过时）。 以前，在节点重新启动或初始节点重新启动期间，API 节点可以连接到节点并开始接收事件。目前，此阶段为空。

• 第 101 阶段。 在节点重新启动或初始节点重新启动期间，事件传递被移交给加入集群的节点。新加入的节点负责将其主要数据传递给订阅者。这个阶段也被称为SUMA移交阶段。

初始启动或系统重新启动完成后，事务处理被启用。对于节点重新启动或初始节点重新启动，启动过程的完成意味着节点现在可以充当事务协调器。

25.6.5 执行 NDB Cluster 的滚动重启

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

本节讨论如何执行 NDB Cluster 安装的滚动重启，因为它涉及逐个停止和启动（或重启）每个节点，以确保集群本身保持运行。这通常作为滚动升级或滚动降级的一部分进行，其中集群的高可用性是必需的，整个集群不允许停机。在我们提到升级时，这里提供的信息通常也适用于降级。

有许多原因可能希望进行滚动重启。这些原因在接下来的几段中描述。

配置更改。 对集群的配置进行更改，例如向集群添加 SQL 节点，或将配置参数设置为新值。

NDB Cluster 软件升级或降级。 将集群升级到 NDB Cluster 软件的新版本（或将其降级到旧版本）。这通常被称为“滚动升级”（或“滚动降级”，当恢复到 NDB Cluster 的旧版本时）。

节点主机更改。 对运行一个或多个 NDB Cluster 节点进程的硬件或操作系统进行更改。

系统重置（集群重置）。 重置集群，因为它已经达到一个不良状态。在这种情况下，通常希望重新加载一个或多个数据节点的数据和元数据。这可以通过以下三种方式之一完成：

• 使用--initial选项启动每个数据节点进程（ndbd或可能是ndbmtd），该选项强制数据节点清除其文件系统，并从其他数据节点重新加载所有 NDB Cluster 数据和元数据。

  从 NDB 8.0.21 开始，这还会强制删除与这些对象相关的所有磁盘数据对象和文件。

• 使用ndb_mgm客户端的START BACKUP命令创建备份，然后执行重启操作。升级后，使用ndb_restore来恢复节点或节点。

  查看 Section 25.6.8, “Online Backup of NDB Cluster”和 Section 25.5.23, “ndb_restore — Restore an NDB Cluster Backup”获取更多信息。

• 使用mysqldump在升级之前创建备份；之后，使用LOAD DATA来恢复备份。

资源回收。 通过连续的INSERT和DELETE操作释放先前分配给表的内存，以便其他 NDB Cluster 表重复使用。

执行滚动重启的过程可以概括如下：

1. 停止所有集群管理节点（ndb_mgmd进程），重新配置它们，然后重新启动它们。 （参见使用多个管理服务器进行滚动重启.）

2. 依次停止、重新配置，然后重新启动每个集群数据节点（ndbd进程）。

   通过在前一步骤之后在ndb_mgm客户端为每个数据节点发出RESTART来更新一些节点配置参数。其他参数要求使用管理客户端STOP命令完全停止数据节点，然后通过在系统 shell 中调用适当的ndbd或ndbmtd")可执行文件来重新启动。 （在大多数 Unix 系统上，也可以使用类似kill的 shell 命令来停止数据节点进程，但通常更倾向于使用STOP命令，通常更简单。）

   注意

   在 Windows 上，您还可以使用SC STOP和SC START命令，NET STOP和NET START命令，或 Windows 服务管理器来停止和启动已安装为 Windows 服务的节点（参见 Section 25.3.2.4, “Installing NDB Cluster Processes as Windows Services”）。

   所需的重启类型在��个节点配置参数的文档中指示。请参阅 Section 25.4.3, “NDB Cluster Configuration Files”。

3. 依次停止、重新配置，然后重新启动每个集群 SQL 节点（mysqld进程）。

NDB Cluster 支持一种相对灵活的节点升级顺序。在升级 NDB Cluster 时，您可以在升级管理节点、数据节点或两者之前先升级 API 节点（包括 SQL 节点）。换句话说，您可以按任意顺序升级 API 和 SQL 节点。但需遵守以下规定：

• 此功能仅用于在线升级。不打算也不支持在生产环境中连续长期使用来自不同 NDB Cluster 版本的节点二进制文件的混合。

• 必须在升级任何不同类型节点（管理、数据或 API 节点）之前先升级所有相同类型的节点。无论节点升级顺序如何，这一点始终成立。

• 必须在升级任何数据节点之前升级所有管理节点。无论您以何种顺序升级集群的 API 和 SQL 节点，这一点始终成立。

• 在升级所有管理节点和数据节点之前，不能使用“新”版本特有的功能。

  这也适用于可能适用的任何 MySQL Server 版本更改，除了 NDB 引擎版本更改，因此在规划升级时不要忘记考虑这一点。（这对于一般 NDB Cluster 的在线升级也是适用的。）

任何 API 节点在节点重新启动期间都无法执行模式操作（如数据定义语句）。部分由于此限制，模式操作在在线升级或降级期间也不受支持。此外，在升级或降级进行时也无法执行本地备份。

使用多个管理服务器进行滚动重启。 在对具有多个管理节点的 NDB Cluster 执行滚动重启时，应注意ndb_mgmd会检查是否有其他管理节点正在运行，并尝试使用该节点的配置数据。为防止这种情况发生，并强制ndb_mgmd重新读取其配置文件，请执行以下步骤：

1. 停止所有 NDB Cluster 的ndb_mgmd进程。

2. 更新所有config.ini文件。

3. 启动一个单独的ndb_mgmd，使用所需的--reload、--initial或两个选项。

4. 如果您使用--initial选项启动了第一个ndb_mgmd，您还必须使用--initial启动任何剩余的ndb_mgmd进程。

   无论在启动第一个ndb_mgmd时使用了哪些其他选项，您都不应该在第一个使用--reload之后启动任何剩余的ndb_mgmd进程。

5. 按照正常流程完成数据节点和 API 节点的滚动重启。

在执行滚动重启以更新集群配置时，您可以使用ndbinfo.nodes表的config_generation列来跟踪哪些数据节点已成功使用新配置重新启动。请参阅 Section 25.6.16.47, “The ndbinfo nodes Table”。

25.6.6 NDB 集群单用户模式

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

单用户模式使数据库管理员能够将对数据库系统的访问限制为单个 API 节点，例如 MySQL 服务器（SQL 节点）或一个 ndb_restore 实例。进入单用户模式时，所有其他 API 节点的连接将被优雅地关闭，所有正在运行的事务都将被中止。不允许启动新事务。

一旦集群进入单用户模式，只有指定的 API 节点被授予对数据库的访问权限。

您可以使用 ndb_mgm 客户端中的 ALL STATUS 命令来查看集群何时进入单用户模式。您还可以检查 ndbinfo.nodes 表的 status 列（有关更多信息，请参见 第 25.6.16.47 节，“ndbinfo nodes 表”）。

示例:

ndb_mgm> ENTER SINGLE USER MODE 5
1

执行此命令后，集群进入单用户模式，其节点 ID 为 5 的 API 节点成为集群唯一允许的用户。

在上述命令中指定的节点必须是 API 节点；尝试指定任何其他类型的节点都将被拒绝。

注意

当调用上述命令时，运行在指定节点上的所有事务都将被中止，连接将被关闭，服务器必须重新启动。

命令 EXIT SINGLE USER MODE 将集群的数据节点从单用户模式更改为正常模式。等待连接的 API 节点（例如 MySQL 服务器）再次被允许连接（即等待集群准备就绪并可用）。在状态更改期间和之后，被指定为单用户节点的 API 节点继续运行（如果仍然连接）。

示例:

ndb_mgm> EXIT SINGLE USER MODE
1

在单用户模式下运行时，有两种推荐的处理节点故障的方法：

• 方法 1:

  1. 完成所有单用户模式事务

  2. 发出 EXIT SINGLE USER MODE 命令

  3. 重新启动集群的数据节点

• 方法 2:

  在进入单用户模式之前重新启动存储节点。

25.6.7 添加 NDB 集群数据节点在线

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

25.6.7.1 添加 NDB 集群数据节点在线：一般问题

25.6.7.2 添加 NDB 集群数据节点在线：基本过程

25.6.7.3 添加 NDB 集群数据节点在线：详细示例

本节描述了如何“在线”添加 NDB 集群数据节点，即在不需要完全关闭集群并重新启动的情况下进行该过程。

重要提示

目前，您必须将新数据节点添加到 NDB 集群作为新节点组的一部分。此外，无法在线更改片段副本数（或节点组中的节点数）。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-online-add-node-remarks.html

25.6.7.1 添加 NDB 集群数据节点在线：一般问题

本节提供关于在线添加 NDB 集群节点的行为和当前限制的一般信息。

数据重新分布。 添加新节点的在线功能包括通过ALTER TABLE ... REORGANIZE PARTITION语句重新组织NDBCLUSTER表数据和索引，使其分布在所有数据节点上，包括新节点。支持内存和磁盘数据表的表重组。此重新分布目前不包括唯一索引（只重新分布有序索引）。

在添加新数据节点之前已存在的NDBCLUSTER表的重新分布不是自动的，但可以通过mysql或其他 MySQL 客户端应用程序中的简单 SQL 语句来完成。但是，在添加新节点组后创建的表中添加的所有数据和索引会自动分布在所有集群数据节点中，包括作为新节点组的一部分添加的节点。

部分启动。 可以添加一个新节点组，而不是所有新数据节点都已启动。也可以将新节点组添加到降级集群中，即只部分启动的集群，或其中一个或多个数据节点未运行。在后一种情况下，必须有足够的节点运行以使集群可行，然后才能添加新节点组。

对正在进行的操作的影响。 使用 NDB 集群数据的正常 DML 操作不会受到新节点组的创建或添加，或表重组的影响。但是，在表重组期间无法同时执行 DDL，也就是说，在执行ALTER TABLE ... REORGANIZE PARTITION语句时无法发出其他 DDL 语句。此外，在执行ALTER TABLE ... REORGANIZE PARTITION（或执行任何其他 DDL 语句）期间，无法重新启动集群数据节点。

故障处理。 在节点组创建和表重组期间数据节点的故障处理如下表所示：

表 25.66 节点组创建和表重组期间数据节点故障处理

• 如果非主节点失败： 节点组的创建总是向前滚动。

• 如果主节点失败：

  • 如果内部提交点已经达到： 节点组的创建将被前滚。

  • 如果内部提交点尚未达到。 节点组的创建将被回滚。

|

• 如果除主节点之外的节点失败： 节点组的创建总是被前滚。

• 如果主节点失败：

  • 如果内部提交点已经达到： 节点组的创建将被前滚。

  • 如果内部提交点尚未达到。 节点组的创建将被回滚。

|

• 如果执行 CREATE NODEGROUP 已经达到内部提交点： 当重新启动时，集群将包括新的节点组。否则不包括。

• 如果执行 CREATE NODEGROUP 尚未达到内部提交点： 当重新启动时，集群不包括新的节点组。

|

• 如果除主节点之外的节点失败： 表重新组织总是被前滚。

• 如果主节点失败：

  • 如果内部提交点已经达到： 表重新组织将被前滚。

  • 如果内部提交点尚未达到。 表重新组织将被回滚。

|

• 如果除主节点之外的节点失败： 表重新组织总是被前滚。

• 如果主节点失败：

  • 如果内部提交点已经达到： 表重新组织将被前滚。

  • 如果内部提交点尚未达到。 表重新组织将被回滚。

|

• 如果执行 ALTER TABLE … REORGANIZE PARTITION 语句已经达到内部提交点： 当集群重新启动时，属于*table*的数据和索引将使用“新”数据节点进行分发。

• 如果执行 ALTER TABLE … REORGANIZE PARTITION 语句尚未达到内部提交点： 当集群重新启动时，属于*table*的数据和索引将仅使用“旧”数据节点进行分发。

|

删除节点组。 ndb_mgm客户端支持DROP NODEGROUP命令，但只有当节点组中的数据节点不包含任何数据时才能删除节点组。由于目前没有办法“清空”特定数据节点或节点组，此命令仅适用于以下两种情况：

1. 在ndb_mgm客户端中发出CREATE NODEGROUP命令之后，在mysql客户端中发出任何ALTER TABLE ... REORGANIZE PARTITION语句之前。

2. 在使用 DROP TABLE 删除所有 NDBCLUSTER 表之后。

   TRUNCATE TABLE 不适用于此目的，因为数据节点继续存储表定义。

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

25.6.7.2 在线添加 NDB Cluster 数据节点：基本过程

在本节中，我们列出了向 NDB Cluster 添加新数据节点所需的基本步骤。此过程适用于数据节点进程使用 ndbd 或 ndbmtd") 二进制文件。有关更详细的示例，请参见 第 25.6.7.3 节，“在线添加 NDB Cluster 数据节点：详细示例”。

假设您已经有一个运行中的 NDB Cluster，添加在线数据节点需要以下步骤：

1. 编辑集群配置 config.ini 文件，添加新的与要添加的节点对应的 [ndbd] 部分。如果集群使用多个管理服务器，则需要对所有管理服务器使用的 config.ini 文件进行更改。

   您必须小心，确保在 config.ini 文件中添加的任何新数据节点的节点 ID 不重叠使用现有节点的节点 ID。如果您有使用动态分配的节点 ID 的 API 节点，并且这些 ID 与您要用于新数据节点的节点 ID 匹配，那么可以强制任何此类 API 节点“迁移”，如本过程后面所述。

2. 对所有 NDB Cluster 管理服务器执行滚动重启。

   重要提示

   所有管理服务器必须使用 --reload 或 --initial 选项重新启动，以强制读取新配置。

3. 对所有现有的 NDB Cluster 数据节点执行滚动重启。在重新启动现有数据节点时，通常不需要（甚至不建议）使用--initial。

   如果您正在使用具有动态分配的 ID 的 API 节点，这些 ID 与您希望分配给新数据节点的任何节点 ID 匹配，那么在重新启动此步骤中的任何数据节点进程之前，必须重新启动所有 API 节点（包括 SQL 节点）。这将导致任何具有先前未明确分配的节点 ID 的 API 节点放弃这些节点 ID 并获取新的节点 ID。

4. 对连接到 NDB Cluster 的任何 SQL 或 API 节点执行滚动重启。

5. 启动新数据节点。

   新数据节点可以以任何顺序启动。只要在所有现有数据节点的滚动重启完成后启动它们，并在进行下一步之前启动它们即可。

6. 在 NDB Cluster 管理客户端中执行一个或多个CREATE NODEGROUP命令，以创建新数据节点所属的新节点组或节点组。

7. 重新分配集群的数据到所有数据节点，包括新节点。通常通过在mysql客户端中为每个NDBCLUSTER表发出一个ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITION语句来完成此操作。

   异常：对于使用MAX_ROWS选项创建的表，此语句不起作用；而是使用ALTER TABLE ... ALGORITHM=INPLACE MAX_ROWS=...来重新组织这些表。您还应该记住，以这种方式使用MAX_ROWS设置分区数量已被弃用，应该使用PARTITION_BALANCE代替；有关更多信息，请参见第 15.1.20.12 节，“设置 NDB 注释选项”。

   注意

   这仅适用于在添加新节点组时已经存在的表。在添加新节点组后创建的表中的数据会自动分布；但是，在添加新节点之前存在的表tbl中添加的数据直到重新组织该表后才会使用新节点进行分布。

8. ALTER TABLE ... REORGANIZE PARTITION ALGORITHM=INPLACE重新组织分区但不会回收“旧”节点上释放的空间。您可以通过为每个NDBCLUSTER表在mysql客户端中发出一个OPTIMIZE TABLE语句来执行此操作。

   这适用于内存中NDB表的可变宽度列使用的空间。OPTIMIZE TABLE不支持内存表的固定宽度列；也不支持磁盘数据表。

您可以添加所有所需的节点，然后连续发出几个CREATE NODEGROUP命令来将新节点组添加到集群中。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-online-add-node-example.html

25.6.7.3 在线添加 NDB 集群数据节点：详细示例

在本节中，我们提供了一个详细的示例，说明如何在线添加新的 NDB 集群数据节点，从一个单节点组中有 2 个数据节点的 NDB 集群开始，最终形成一个有 2 个节点组中有 4 个数据节点的集群。

开始配置。 为了说明，我们假设一个最小配置，并且集群使用一个只包含以下信息的config.ini文件：

[ndbd default]
DataMemory = 100M
IndexMemory = 100M
NoOfReplicas = 2
DataDir = /usr/local/mysql/var/mysql-cluster

[ndbd]
Id = 1
HostName = 198.51.100.1

[ndbd]
Id = 2
HostName = 198.51.100.2

[mgm]
HostName = 198.51.100.10
Id = 10

[api]
Id=20
HostName = 198.51.100.20

[api]
Id=21
HostName = 198.51.100.21
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

注意

我们在数据节点 ID 和其他节点之间的序列中留下了一个间隔。这样可以更容易地在以后为新添加的数据节点分配尚未使用的��点 ID。

我们还假设您已经使用适当的命令行或my.cnf选项启动了集群，并且在管理客户端中运行SHOW会产生类似于这里显示的输出：

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

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (8.0.35-ndb-8.0.35)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (8.0.35-ndb-8.0.35)
id=21   @198.51.100.21  (8.0.35-ndb-8.0.35)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

最后，我们假设集群包含一个单NDBCLUSTER表，如下所示创建：

USE n;

CREATE TABLE ips (
    id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    country_code CHAR(2) NOT NULL,
    type CHAR(4) NOT NULL,
    ip_address VARCHAR(15) NOT NULL,
    addresses BIGINT UNSIGNED DEFAULT NULL,
    date BIGINT UNSIGNED DEFAULT NULL
)   ENGINE NDBCLUSTER;
1
2
3
4
5
6
7
8
9
10

后面显示的内存使用情况和相关信息是在将大约 50000 行插入到这个表后生成的。

注意

在这个示例中，我们展示了单线程的ndbd用于数据节点进程。如果您使用多线程的ndbmtd")，则可以通过在后续步骤中出现的地方用ndbmtd")替换ndbd来应用此示例。

步骤 1：更新配置文件。 在文本编辑器中打开集群全局配置文件，并添加与 2 个新数据节点对应的[ndbd]部分。（我们给这些数据节点分配 ID 3 和 4，并假设它们分别在地址 198.51.100.3 和 198.51.100.4 的主机上运行。）添加新部分后，config.ini文件的内容应该如下所示，文件的添加部分以粗体显示：

[ndbd default]
DataMemory = 100M
IndexMemory = 100M
NoOfReplicas = 2
DataDir = /usr/local/mysql/var/mysql-cluster

[ndbd]
Id = 1
HostName = 198.51.100.1

[ndbd]
Id = 2
HostName = 198.51.100.2

[ndbd]
Id = 3
HostName = 198.51.100.3

[ndbd]
Id = 4
HostName = 198.51.100.4

[mgm]
HostName = 198.51.100.10
Id = 10

[api]
Id=20
HostName = 198.51.100.20

[api]
Id=21
HostName = 198.51.100.21
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

一旦您做出必要的更改，请保存文件。

步骤 2：重新启动管理服务器。 重新启动集群管理服务器需要您发出停止管理服务器和然后再次启动的单独命令，如下所示：

1. 使用管理客户端STOP命令停止管理服务器，如下所示：

   ndb_mgm> 10 STOP
   Node 10 has shut down.
   Disconnecting to allow Management Server to shutdown
   
   $>
   1
   2
   3
   4
   5

2. 由于关闭管理服务器会导致管理客户端终止，您必须从系统 shell 中启动管理服务器。为简单起见，我们假设config.ini与管理服务器二进制文件位于同一目录中，但实际上，您必须提供正确的配置文件路径。您还必须提供--reload或--initial选项，以便管理服务器从文件而不是其配置缓存中读取新配置。如果您的 shell 当前目录也与管理服务器二进制文件所在的目录相同，则可以按照以下方式调用管理服务器：

   $> ndb_mgmd -f config.ini --reload
   2008-12-08 17:29:23 [MgmSrvr] INFO     -- NDB Cluster Management Server. 8.0.35-ndb-8.0.35
   2008-12-08 17:29:23 [MgmSrvr] INFO     -- Reading cluster configuration from 'config.ini'
   1
   2
   3

在重新启动ndb_mgm进程后，在管理客户端中检查SHOW的输出，您现在应该看到类似于以下内容：

-- NDB Cluster -- Management Client --
ndb_mgm> SHOW
Connected to Management Server at: 198.51.100.10:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (8.0.35-ndb-8.0.35, Nodegroup: 0, *)
id=2    @198.51.100.2  (8.0.35-ndb-8.0.35, Nodegroup: 0)
id=3 (not connected, accepting connect from 198.51.100.3)
id=4 (not connected, accepting connect from 198.51.100.4)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (8.0.35-ndb-8.0.35)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (8.0.35-ndb-8.0.35)
id=21   @198.51.100.21  (8.0.35-ndb-8.0.35)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

步骤 3：对现有数据节点执行滚动重启。 可以在集群管理客户端中完全通过使用RESTART命令来完成此步骤，如下所示：

ndb_mgm> 1 RESTART
Node 1: Node shutdown initiated
Node 1: Node shutdown completed, restarting, no start.
Node 1 is being restarted

ndb_mgm> Node 1: Start initiated (version 8.0.35)
Node 1: Started (version 8.0.35)

ndb_mgm> 2 RESTART
Node 2: Node shutdown initiated
Node 2: Node shutdown completed, restarting, no start.
Node 2 is being restarted

ndb_mgm> Node 2: Start initiated (version 8.0.35)

ndb_mgm> Node 2: Started (version 8.0.35)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

重要

在发出每个*X* RESTART命令后，请等待管理客户端报告Node *X*: Started (version ...) 之后 再继续进行任何操作。

通过检查mysql客户端中的ndbinfo.nodes表，您可以验证所有现有数据节点是否使用更新的配置重新启动。

步骤 4：对所有集群 API 节点执行滚动重启。 关闭并重新启动充当集群中 SQL 节点的每个 MySQL 服务器，使用mysqladmin shutdown后跟mysqld_safe（或另一个启动脚本）。这应该类似于下面显示的内容，其中*password*是给定 MySQL 服务器实例的 MySQL root密码：

$> mysqladmin -uroot -p*password* shutdown
081208 20:19:56 mysqld_safe mysqld from pid file
/usr/local/mysql/var/tonfisk.pid ended
$> mysqld_safe --ndbcluster --ndb-connectstring=198.51.100.10 &
081208 20:20:06 mysqld_safe Logging to '/usr/local/mysql/var/tonfisk.err'.
081208 20:20:06 mysqld_safe Starting mysqld daemon with databases
from /usr/local/mysql/var
1
2
3
4
5
6
7

当然，确切的输入和输出取决于 MySQL 在系统上的安装方式和位置，以及您选择以何种选项启动它（以及是否在my.cnf文件中指定了一些或所有这些选项）。

步骤 5：执行新数据节点的初始启动。 在每个新数据节点的主机上的系统 shell 中，按照这里显示的方式启动数据节点，使用--initial选项：

$> ndbd -c 198.51.100.10 --initial
1

注意

与重新启动现有数据节点的情况不同，您可以同时启动新数据节点；您无需等待一个启动完成后再启动另一个。

在继续下一步之前，请等待新的数据节点都已启动。一旦新的数据节点启动，您可以在管理客户端SHOW命令的输出中看到它们尚未属于任何节点组（如此处以粗体显示）：

ndb_mgm> SHOW
Connected to Management Server at: 198.51.100.10:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (8.0.35-ndb-8.0.35, Nodegroup: 0, *)
id=2    @198.51.100.2  (8.0.35-ndb-8.0.35, Nodegroup: 0)
id=3    @198.51.100.3  (8.0.35-ndb-8.0.35, no nodegroup)
id=4    @198.51.100.4  (8.0.35-ndb-8.0.35, no nodegroup)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (8.0.35-ndb-8.0.35)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (8.0.35-ndb-8.0.35)
id=21   @198.51.100.21  (8.0.35-ndb-8.0.35)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

步骤 6：创建新的节点组。 您可以通过在集群管理客户端中发出CREATE NODEGROUP命令来执行此操作。此命令以逗号分隔的数据节点的节点 ID 列表作为参数，如下所示：

ndb_mgm> CREATE NODEGROUP 3,4
Nodegroup 1 created
1
2

再次执行SHOW，您可以验证数据节点 3 和 4 已加入新的节点组（再次以粗体显示）：

ndb_mgm> SHOW
Connected to Management Server at: 198.51.100.10:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (8.0.35-ndb-8.0.35, Nodegroup: 0, *)
id=2    @198.51.100.2  (8.0.35-ndb-8.0.35, Nodegroup: 0)
id=3    @198.51.100.3  (8.0.35-ndb-8.0.35, Nodegroup: 1)
id=4    @198.51.100.4  (8.0.35-ndb-8.0.35, Nodegroup: 1)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (8.0.35-ndb-8.0.35)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (8.0.35-ndb-8.0.35)
id=21   @198.51.100.21  (8.0.35-ndb-8.0.35)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

步骤 7：重新分配集群数据。 创建节点组时，现有数据和索引不会自动分配给新节点组的数据节点，您可以通过在管理客户端中发出适当的REPORT命令来查看：

ndb_mgm> ALL REPORT MEMORY

Node 1: Data usage is 5%(177 32K pages of total 3200)
Node 1: Index usage is 0%(108 8K pages of total 12832)
Node 2: Data usage is 5%(177 32K pages of total 3200)
Node 2: Index usage is 0%(108 8K pages of total 12832)
Node 3: Data usage is 0%(0 32K pages of total 3200)
Node 3: Index usage is 0%(0 8K pages of total 12832)
Node 4: Data usage is 0%(0 32K pages of total 3200)
Node 4: Index usage is 0%(0 8K pages of total 12832)
1
2
3
4
5
6
7
8
9
10

通过使用ndb_desc的-p选项，使输出包含分区信息，您可以看到该表仍然仅使用 2 个分区（在输出的Per partition info部分中以粗体显示）：

$> ndb_desc -c 198.51.100.10 -d n ips -p
-- ips --
Version: 1
Fragment type: 9
K Value: 6
Min load factor: 78
Max load factor: 80
Temporary table: no
Number of attributes: 6
Number of primary keys: 1
Length of frm data: 340
Row Checksum: 1
Row GCI: 1
SingleUserMode: 0
ForceVarPart: 1
FragmentCount: 2
TableStatus: Retrieved
-- Attributes --
id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCR
country_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
type Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
ip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORY
addresses Bigunsigned NULL AT=FIXED ST=MEMORY
date Bigunsigned NULL AT=FIXED ST=MEMORY

-- Indexes --
PRIMARY KEY(id) - UniqueHashIndex
PRIMARY(id) - OrderedIndex

-- Per partition info --
Partition   Row count   Commit count  Frag fixed memory   Frag varsized memory
0           26086       26086         1572864             557056
1           26329       26329         1605632             557056
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

您可以通过为每个NDB表执行ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITION语句在mysql客户端中使数据重新分布到所有数据节点。

重要提示

ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITION不适用于使用MAX_ROWS选项创建的表。相反，使用ALTER TABLE ... ALGORITHM=INPLACE, MAX_ROWS=...来重新组织这些表。

请注意，使用MAX_ROWS设置每个表的分区数已被弃用，您应该使用PARTITION_BALANCE代替；有关更多信息，请参阅 Section 15.1.20.12, “Setting NDB Comment Options”。

执行语句ALTER TABLE ips ALGORITHM=INPLACE, REORGANIZE PARTITION后，您可以使用ndb_desc查看该表的数据现在使用 4 个分区存储，如下所示（相关部分以粗体显示）：

$> ndb_desc -c 198.51.100.10 -d n ips -p
-- ips --
Version: 16777217
Fragment type: 9
K Value: 6
Min load factor: 78
Max load factor: 80
Temporary table: no
Number of attributes: 6
Number of primary keys: 1
Length of frm data: 341
Row Checksum: 1
Row GCI: 1
SingleUserMode: 0
ForceVarPart: 1
FragmentCount: 4
TableStatus: Retrieved
-- Attributes --
id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCR
country_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
type Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
ip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORY
addresses Bigunsigned NULL AT=FIXED ST=MEMORY
date Bigunsigned NULL AT=FIXED ST=MEMORY

-- Indexes --
PRIMARY KEY(id) - UniqueHashIndex
PRIMARY(id) - OrderedIndex

-- Per partition info --
Partition   Row count   Commit count  Frag fixed memory   Frag varsized memory
0           12981       52296         1572864             557056
1           13236       52515         1605632             557056
2           13105       13105         819200              294912
3           13093       13093         819200              294912
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

注意

通常，ALTER TABLE *table_name* [ALGORITHM=INPLACE,] REORGANIZE PARTITION用于具有显式分区的表创建新的分区方案时会使用分区标识符列表和一组分区定义。在这种情况下，将数据重新分布到新的 NDB Cluster 节点组是一个例外；在这种情况下使用时，REORGANIZE PARTITION后不跟随其他关键字或标识符。

更多信息，请参见第 15.1.9 节，“ALTER TABLE Statement”。

另外，对于每个表，ALTER TABLE语句后应该跟着一个OPTIMIZE TABLE来回收浪费的空间。您可以通过以下查询在信息模式TABLES表中获取所有NDBCLUSTER表的列表：

SELECT TABLE_SCHEMA, TABLE_NAME
    FROM INFORMATION_SCHEMA.TABLES
    WHERE ENGINE = 'NDBCLUSTER';
1
2
3

注意

对于 NDB Cluster 表，INFORMATION_SCHEMA.TABLES.ENGINE值始终为NDBCLUSTER，无论用于创建表的CREATE TABLE语句（或用于将现有表从不同存储引擎转换为 NDB Cluster 的ALTER TABLE语句）中是否在ENGINE选项中使用了NDB或NDBCLUSTER。

在执行这些语句后，您可以在ALL REPORT MEMORY的输出中看到数据和索引现在在所有集群数据节点之间重新分布，如下所示：

ndb_mgm> ALL REPORT MEMORY

Node 1: Data usage is 5%(176 32K pages of total 3200)
Node 1: Index usage is 0%(76 8K pages of total 12832)
Node 2: Data usage is 5%(176 32K pages of total 3200)
Node 2: Index usage is 0%(76 8K pages of total 12832)
Node 3: Data usage is 2%(80 32K pages of total 3200)
Node 3: Index usage is 0%(51 8K pages of total 12832)
Node 4: Data usage is 2%(80 32K pages of total 3200)
Node 4: Index usage is 0%(50 8K pages of total 12832)
1
2
3
4
5
6
7
8
9
10

注意

由于在NDBCLUSTER表上只能执行一个 DDL 操作，您必须等待每个ALTER TABLE ... REORGANIZE PARTITION语句完成后再发出下一个。

对于在添加新数据节点之后创建的NDBCLUSTER表，不需要发出ALTER TABLE ... REORGANIZE PARTITION语句；添加到这些表中的数据会自动分布在所有数据节点之间。然而，在添加新节点之前存在的NDBCLUSTER表中，无论是现有数据还是新数据都不会使用新节点进行分布，直到使用ALTER TABLE ... REORGANIZE PARTITION重新组织这些表。

另一种过程，无需滚动重启。 可以通过在首次启动集群时配置额外的数据节点（但不启动它们）来避免需要滚动重启的需要。我们假设，与之前一样，您希望从两个数据节点（节点 1 和 2）开始，然后通过添加由节点 3 和 4 组成的第二个节点组来将集群扩展到四个数据节点：

[ndbd default]
DataMemory = 100M
IndexMemory = 100M
NoOfReplicas = 2
DataDir = /usr/local/mysql/var/mysql-cluster

[ndbd]
Id = 1
HostName = 198.51.100.1

[ndbd]
Id = 2
HostName = 198.51.100.2

[ndbd]
Id = 3
HostName = 198.51.100.3
Nodegroup = 65536

[ndbd]
Id = 4
HostName = 198.51.100.4
Nodegroup = 65536

[mgm]
HostName = 198.51.100.10
Id = 10

[api]
Id=20
HostName = 198.51.100.20

[api]
Id=21
HostName = 198.51.100.21
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

要稍后上线的数据节点（节点 3 和 4）可以配置为NodeGroup = 65536，在这种情况下，节点 1 和 2 可以按照这里所示启动：

$> ndbd -c 198.51.100.10 --initial
1

配置为NodeGroup = 65536的数据节点被管理服务器视为在等待由StartNoNodeGroupTimeout数据节点配置参数设置确定的一段时间后，使用--nowait-nodes=3,4启动节点 1 和 2。默认情况下，这是 15 秒（15000 毫秒）。

注意

StartNoNodegroupTimeout 必须对集群中的所有数据节点保持一致；因此，您应该始终在config.ini文件的[ndbd default]部分中设置它，而不是为单独的数据节点设置。

当您准备添加第二个节点组时，只需执行以下额外步骤：

1. 启动数据节点 3 和 4，为每个新节点调用一次数据节点进程：

   $> ndbd -c 198.51.100.10 --initial
   1

2. 在管理客户端中发出适当的CREATE NODEGROUP命令：

   ndb_mgm> CREATE NODEGROUP 3,4
   1

3. 在mysql客户端中，为每个现有的NDBCLUSTER表发出ALTER TABLE ... REORGANIZE PARTITION和OPTIMIZE TABLE语句。（正如本节其他地方所述，现有的 NDB Cluster 表在执行此操作之前无法使用新节点进行数据分发。）

25.6.8 NDB 集群在线备份

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

25.6.8.1 NDB 集群备份概念

25.6.8.2 使用 NDB 集群管理客户端创建备份

25.6.8.3 NDB 集群备份配置

25.6.8.4 NDB 集群备份故障排除

25.6.8.5 使用并行数据节点进行 NDB 备份

接下来的几节描述了如何准备并创建 NDB 集群备份，使用专门用于此目的的 ndb_mgm 管理客户端的功能。为了区分这种类型的备份与使用 mysqldump 创建的备份，我们有时将其称为“本地” NDB 集群备份。（有关使用 mysqldump 创建备份的信息，请参见 第 6.5.4 节，“mysqldump — 数据库备份程序”。）NDB 集群备份的恢复使用 NDB 集群分发提供的 ndb_restore 实用程序完成；有关 ndb_restore 及其在恢复 NDB 集群备份中的使用的信息，请参见 第 25.5.23 节，“ndb_restore — 恢复 NDB 集群备份”。

NDB 8.0 可以使用多个 LDM 来创建备份，以实现数据节点的并行性。参见 第 25.6.8.5 节，“使用并行数据节点进行 NDB 备份”。

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

25.6.8.1 NDB Cluster 备份概念

备份是数据库在特定时间的快照。备份由三个主要部分组成：

• 元数据。 所有数据库表的名称和定义

• 表记录。 实际存储在数据库表中的数据，在备份时

• 事务日志。 顺序记录了数据是如何以及何时存储在数据库中的

每个部分都保存在参与备份的所有节点上。在备份过程中，每个节点将这三个部分保存到磁盘上的三个文件中：

• BACKUP-*backup_id*.*node_id*.ctl

  包含控制信息和元数据的控制文件。每个节点将相同的表定义（对于集群中的所有表）保存到自己版本的此文件中。

• BACKUP-*backup_id*-0.*node_id*.data

  包含表记录的数据文件，按片段保存。也就是说，在备份过程中，不同的节点保存不同的片段。每个节点保存的文件以表明记录所属表的标题开头。在记录列表之后，有一个包含所有记录校验和的页脚。

• BACKUP-*backup_id*.*node_id*.log

  包含已提交事务记录的日志文件。只有备份中存储的表上的事务才会存储在日志中。参与备份的节点保存不同的记录，因为不同的节点托管不同的数据库片段。

在刚才显示的列表中，*backup_id代表备份标识符，node_id*是创建文件的节点的唯一标识符。

备份文件的位置由BackupDataDir参数确定。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-backup-using-management-client.html

25.6.8.2 使用 NDB 集群管理客户端创建备份

在开始备份之前，请确保集群已正确配置以执行备份。（参见第 25.6.8.3 节，“NDB 集群备份配置”.）

START BACKUP 命令用于创建备份，其语法如下所示：

START BACKUP [*backup_id*]
    [*encryption_option*]
    [*wait_option*]
    [*snapshot_option*]

*encryption_option*:
ENCRYPT [PASSWORD=*password*]

*password*:
{'*password_string*' | "*password_string*"}

*wait_option*:
WAIT {STARTED | COMPLETED} | NOWAIT

*snapshot_option*:
SNAPSHOTSTART | SNAPSHOTEND
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

连续备份会自动按顺序识别，因此*backup_id，一个大于或等于 1 的整数，是可选的；如果省略，则使用下一个可用值。如果使用现有的backup_id值，则备份将失败，并显示错误消息备份失败：文件已存在。如果使用backup_id*，则必须紧跟在START BACKUP关键字之后，在使用任何其他选项之前。

在 NDB 8.0.22 及更高版本中，START BACKUP 支持使用 ENCRYPT PASSWORD=*password* 创建加密备份。password 必须满足以下所有要求：

• 使用除 !、'、"、$、%、\ 和 ^ 之外的任何可打印 ASCII 字符。

• 长度不超过 256 个字符

• 用单引号或双引号括起来

当使用 ENCRYPT PASSWORD='*password*' 时，由每个数据节点写入的备份数据记录和日志文件会使用从用户提供的*password*和随机生成的盐派生的密钥进行加密，使用 PBKDF2-SHA256 算法的密钥派生函数（KDF）生成用于该文件的对称加密密钥。此函数的形式如下所示：

key = KDF(*random_salt*, *password*)
1

然后使用生成的密钥使用 AES 256 CBC 内联加密备份数据，并对备份文件集（使用生成的密钥）使用对称加密。

注意

NDB 集群永远不会保存用户提供的密码或生成的加密密钥。

从 NDB 8.0.24 开始，可以从*encryption_option*中省略 PASSWORD 选项。在这种情况下，管理客户端会提示用户输入密码。

可以使用 PASSWORD 设置空密码（'' 或 ""），但不建议这样做。

可以使用以下任一命令解密加密备份：

• ndb_restore --decrypt --backup-password=*password*

• ndbxfrm --decrypt-password=*password* input_file output_file

• ndb_print_backup_file -P password file_name

NDB 8.0.24 及更高版本支持以下附加命令：

• ndb_restore --decrypt --backup-password-from-stdin

• ndbxfrm --decrypt-password-from-stdin input_file output_file

• ndb_print_backup_file --backup-password=*password* file_name

• ndb_print_backup_file --backup-password-from-stdin file_name

• ndb_mgm --backup-password-from-stdin --execute "START BACKUP ..."

查看这些程序的描述以获取更多信息，例如可能需要的其他选项。

wait_option 可用于确定在发出 START BACKUP 命令后何时将控制权返回给管理客户端，如下列表所示：

• 如果指定了 NOWAIT，管理客户端会立即显示提示，如下所示：

  ndb_mgm> START BACKUP NOWAIT
  ndb_mgm>
  1
  2

  在这种情况下，管理客户端可以在打印备份过程的进度信息的同时使用。

• 使用 WAIT STARTED，管理客户端会等到备份开始后再将控制权返回给用户，如下所示：

  ndb_mgm> START BACKUP WAIT STARTED
  Waiting for started, this may take several minutes
  Node 2: Backup 3 started from node 1
  ndb_mgm>
  1
  2
  3
  4

• WAIT COMPLETED 导致管理客户端在备份过程完成之前等待，然后将控制权返回给用户。

WAIT COMPLETED 是默认选项。

*snapshot_option*可用于确定备份是否与发出START BACKUP命令时的集群状态匹配，或者与备份完成时的状态匹配。SNAPSHOTSTART导致备份与备份开始时的集群状态匹配；SNAPSHOTEND导致备份反映备份完成时的集群状态。SNAPSHOTEND是默认值，并与以前的 NDB Cluster 版本中找到的行为相匹配。

注意

如果在START BACKUP中使用SNAPSHOTSTART选项，并且启用了CompressedBackup参数，则只有数据和控制文件会被压缩，日志文件不会被压缩。

如果同时使用*wait_option和snapshot_option*，它们可以以任何顺序指定。例如，假设不存在 ID 为 4 的现有备份，则以下所有命令都是有效的：

START BACKUP WAIT STARTED SNAPSHOTSTART
START BACKUP SNAPSHOTSTART WAIT STARTED
START BACKUP 4 WAIT COMPLETED SNAPSHOTSTART
START BACKUP SNAPSHOTEND WAIT COMPLETED
START BACKUP 4 NOWAIT SNAPSHOTSTART
1
2
3
4
5

创建备份的过程包括以下步骤：

1. 启动管理客户端（ndb_mgm），如果尚未运行。

2. 执行**START BACKUP**命令。这将产生几行输出，指示备份的进度，如下所示：

   ndb_mgm> START BACKUP
   Waiting for completed, this may take several minutes
   Node 2: Backup 1 started from node 1
   Node 2: Backup 1 started from node 1 completed
    StartGCP: 177 StopGCP: 180
    #Records: 7362 #LogRecords: 0
    Data: 453648 bytes Log: 0 bytes
   ndb_mgm>
   1
   2
   3
   4
   5
   6
   7
   8

3. 当备份开始时，管理客户端显示此消息：

   Backup *backup_id* started from node *node_id*
   1

   *backup_id是此特定备份的唯一标识符。如果未配置其他方式保存此标识符，则将其保存在集群日志中。node_id*是协调备份与数据节点的管理服务器的标识符。在备份过程的这一点上，集群已经接收并处理了备份请求。这并不意味着备份已经完成。这种情况的示例如下：

   Node 2: Backup 1 started from node 1
   1

4. 管理客户端通过类似于这样的消息指示备份已经开始：

   Backup *backup_id* started from node *node_id* completed
   1

   与指示备份已经开始的通知一样，*backup_id是此特定备份的唯一标识符，而node_id*是协调备份与数据节点的管理服务器的节点 ID。此输出还附带其他信息，包括相关的全局检查点、备份的记录数以及数据的大小，如下所示：

   Node 2: Backup 1 started from node 1 completed
    StartGCP: 177 StopGCP: 180
    #Records: 7362 #LogRecords: 0
    Data: 453648 bytes Log: 0 bytes
   1
   2
   3
   4

也可以通过在系统 shell 中调用ndb_mgm并使用-e或--execute选项来执行备份，如下例所示：

$> ndb_mgm -e "START BACKUP 6 WAIT COMPLETED SNAPSHOTSTART"
1

在这种方式下使用START BACKUP时，必须指定备份 ID。

集群备份默认创建在每个数据节点的BACKUP子目录中。这可以通过DataDir中的一个或多个数据节点，或者在config.ini文件中使用BackupDataDir配置参数来覆盖。为具有给定*backup_id*的备份创建的备份文件存储在备份目录中名为BACKUP-*backup_id*的子目录中。

取消备份。 要取消或中止已经进行中的备份，请执行以下步骤：

1. 启动管理客户端。

2. 执行此命令：

   ndb_mgm> ABORT BACKUP *backup_id*
   1

   数字*backup_id*是在备份启动时管理客户端的响应中包含的备份标识符（在消息Backup *backup_id* started from node *management_node_id*中）。

3. 管理客户端使用Abort of backup *backup_id* ordered确认中止请求。

   注意

   此时，管理客户端尚未收到集群数据节点对此请求的响应，备份实际上尚未被中止。

4. 备份被中止后，管理客户端以类似于以下所示的方式报告此事实：

   Node 1: Backup 3 started from 5 has been aborted.
     Error: 1321 - Backup aborted by user request: Permanent error: User defined error
   Node 3: Backup 3 started from 5 has been aborted.
     Error: 1323 - 1323: Permanent error: Internal error
   Node 2: Backup 3 started from 5 has been aborted.
     Error: 1323 - 1323: Permanent error: Internal error
   Node 4: Backup 3 started from 5 has been aborted.
     Error: 1323 - 1323: Permanent error: Internal error
   1
   2
   3
   4
   5
   6
   7
   8

   在此示例中，我们展示了一个具有 4 个数据节点的集群的示例输出，要中止的备份的序列号为3，并且集群管理客户端连接的管理节点具有节点 ID5。完成中止备份的第一个节点报告中止的原因是由于用户的请求。（其余节点报告备份由于未指定的内部错误而中止。）

   注意

   不能保证集群节点以任何特定顺序响应ABORT BACKUP命令。

   备份 *backup_id* 从节点 *management_node_id* 开始已中止消息意味着备份已终止，并且与此备份相关的所有文件已从集群文件系统中删除。

也可以使用以下命令从系统 shell 中中止正在进行的备份：

$> ndb_mgm -e "ABORT BACKUP *backup_id*"
1

注意

如果在发出ABORT BACKUP时没有正在运行 ID 为*backup_id*的备份，管理客户端不会做出响应，也不会在集群日志中指示发送了无效的中止命令。

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

25.6.8.3 NDB 集群备份配置

备份需要五个配置参数：

• 备份数据缓冲区大小

  在数据写入磁盘之前用于缓冲数据的内存量。

• 备份日志缓冲区大小

  在将日志记录写入磁盘之前用于缓冲日志记录的内存量。

• 备份内存

  为备份在数据节点中分配的总内存。这应该是为备份数据缓冲区和备份日志缓冲区分配的内存总和。

• 备份写入大小

  写入磁盘的块的默认大小。这适用于备份数据缓冲区和备份日志缓冲区。

• 备份最大写入大小

  写入磁盘的块的最大大小。这适用于备份数据缓冲区和备份日志缓冲区。

此外，压缩备份使NDB在创建和写入备份文件时使用压缩。

关于这些参数的更详细信息可以在备份参数中找到。

您还可以使用备份数据目录配置参数为备份文件设置位置。默认值为文件系统路径``/BACKUP/BACKUP-*backup_id*。

在 NDB 8.0.22 及更高版本中，您可以通过启用要求加密备份来强制备份文件加密。当此参数设置为 1 时，备份不能在未指定ENCRYPT PASSWORD=*password*作为START BACKUP命令的一部分时创建。

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

25.6.8.4 NDB 集群备份故障排除

如果在发出备份请求时返回错误代码，最有可能的原因是内存或磁盘空间不足。你应该检查备份所需的内存是否足够。

重要提示

如果你已经设置了BackupDataBufferSize和BackupLogBufferSize，它们的总和大于 4MB，那么你还必须设置BackupMemory。

你还应确保备份目标的硬盘分区有足够的空间。

NDB 不支持可重复读，这可能会导致恢复过程中出现问题。尽管备份过程是“热”进行的，但从备份中恢复 NDB 集群并非完全“热”过程。这是因为在恢复过程中，正在运行的事务从恢复的数据中获得不可重复读。这意味着在恢复过程中数据的状态是不一致的。

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

25.6.8.5 使用并行数据节点进行 NDB 备份

在 NDB 8.0 中，可以使用多个本地数据管理器（LDM）并行在数据节点上进行备份。为了使其工作，集群中的所有数据节点必须使用多个 LDM，并且每个数据节点必须使用相同数量的 LDM。这意味着所有数据节点必须运行ndbmtd（ndbd是单线程的，因此始终只有一个 LDM）并且在进行备份之前必须配置为使用多个 LDM；ndbmtd默认以单线程模式运行。您可以通过选择多线程数据节点配置参数MaxNoOfExecutionThreads或ThreadConfig的适当设置来使它们使用多个 LDM。请记住，更改这些参数需要重新启动集群；这可以是滚动重启。此外，每个数据节点的EnableMultithreadedBackup参数必须设置为 1（这是默认值）。

根据 LDM 的数量和其他因素，您可能还需要增加NoOfFragmentLogParts。如果您正在使用大型磁盘数据表，您可能还需要增加DiskPageBufferMemory。与单线程备份一样，您可能还希望或需要调整BackupDataBufferSize、BackupMemory和其他与备份相关的配置参数（参见备份参数）。

一旦所有数据节点都使用多个 LDM，您可以使用 NDB 管理客户端中的START BACKUP命令进行并行备份，就像数据节点正在运行ndbd（或单线程模式下的ndbmtd")）一样；不需要额外或特殊的语法，您可以根据需要或愿望指定备份 ID、等待选项或快照选项的任意组合。

使用多个 LDM 进行备份会在每个数据节点的目录BACKUP/BACKUP-*backup_id*/（该目录位于BackupDataDir下）下创建子目录，这些子目录分别命名为BACKUP-*backup_id*-PART-1-OF-*N*/、BACKUP-*backup_id*-PART-2-OF-*N*/，依此类推，直到BACKUP-*backup_id*-PART-*N*-OF-*N*/，其中*backup_id是此备份使用的备份 ID，N是每个数据节点的 LDM 数。每个子目录包含常规备份文件BACKUP-*backup_id*-0.*node_id*.Data、BACKUP-*backup_id*.*node_id*.ctl和BACKUP-backup_id.node_id.log，其中node_id*是此数据节点的节点 ID。

ndb_restore会自动检查刚才描述的子目录是否存在；如果找到它们，它将尝试并行恢复备份。有关使用多个 LDM 进行备份的恢复信息，请参阅第 25.5.23.3 节，“从并行备份中恢复”。

要强制创建一个单线程备份，以便可以轻松地由 NDB 8.0 之前的版本的ndb_restore导入，您可以为所有数据节点设置EnableMultithreadedBackup = 0（您可以通过在config.ini全局配置文件的[ndbd default]部分中设置该参数来执行此操作）。还可以将并行备份恢复到运行较旧版本NDB的集群中。有关更多信息，请参阅第 25.5.23.1.1 节，“将 NDB 备份恢复到较旧版本的 NDB 集群”。

25.6.9 将数据导入到 MySQL 集群

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

在设置新的 NDB 集群实例时，通常需要从现有 NDB 集群、MySQL 实例或其他来源导入数据。这些数据通常以以下一种或多种格式提供：

• 由mysqldump或mysqlpump生成的 SQL 转储文件。可以使用mysql客户端导入此文件，如本节后面所示。

• 由mysqldump或其他导出程序生成的 CSV 文件。这些文件可以使用mysql客户端中的LOAD DATA INFILE导入到NDB中，或者使用 NDB 集群分发的ndb_import实用程序。有关后者的更多信息，请参见第 25.5.13 节，“ndb_import — 将 CSV 数据导入 NDB”。

• 使用START BACKUP在NDB管理客户端中生成的本机NDB备份。要导入本机备份，必须使用作为 NDB 集群一部分提供的ndb_restore程序。有关使用此程序的更多信息，请参见第 25.5.23 节，“ndb_restore — 恢复 NDB 集群备份”。

从 SQL 文件导入数据时，通常不需要强制执行事务或外键，并临时禁用这些功能可以极大加快导入过程。可以使用mysql客户端来执行此操作，可以从客户端会话中执行，也可以在命令行上调用。在mysql客户端会话中，可以使用以下 SQL 语句执行导入：

SET ndb_use_transactions=0;
SET foreign_key_checks=0;

source *path/to/dumpfile*;

SET ndb_use_transactions=1;
SET foreign_key_checks=1;
1
2
3
4
5
6
7

以这种方式执行导入时，必须在执行mysql客户端的source命令后再次启用ndb_use_transaction和foreign_key_checks。否则，同一会话中后续语句可能也会在不执行事务或外键约束的情况下执行，这可能导致数据不一致。

从系统 shell 中，您可以使用 mysql 客户端的 --init-command 选项，在禁用事务和外键强制执行的情况下导入 SQL 文件，就像这样：

$> mysql --init-command='SET ndb_use_transactions=0; SET foreign_key_checks=0' < *path/to/dumpfile*
1

还可以将数据加载到一个 InnoDB 表中，然后使用 ALTER TABLE … ENGINE NDB) 将其转换为使用 NDB 存储引擎。特别是对于许多表，您应该考虑到这可能需要多次操作；此外，如果使用外键，您必须仔细注意 ALTER TABLE 语句的顺序，因为外键在使用不同 MySQL 存储引擎的表之间不起作用。

您应该意识到，在本节中之前描述的方法并不针对非常大的数据集或大型事务进行优化。如果一个应用程序确实需要大型事务或许多并发事务作为正常操作的一部分，您可能希望增加 MaxNoOfConcurrentOperations 数据节点配置参数的值，这将保留更多内存以允许数据节点在其事务协调器意外停止时接管事务。

在执行 NDB Cluster 表的批量 DELETE 或 UPDATE 操作时，您可能也希望这样做。如果可能的话，尝试让应用程序以块的方式执行这些操作，例如，通过在这些语句中添加 LIMIT。

如果数据导入操作由于任何原因未能成功完成，您应该准备好执行任何必要的清理工作，包括可能一个或多个 DROP TABLE 语句，DROP DATABASE 语句，或两者都有。如果不这样做，可能会导致数据库处于不一致状态。

25.6.10 NDB Cluster 的 MySQL 服务器用法

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

mysqld是传统的 MySQL 服务器进程。要与 NDB Cluster 一起使用，mysqld需要构建支持NDB存储引擎，就像在dev.mysql.com/downloads/提供的预编译二进制文件中一样。如果您从源代码构建 MySQL，您必须使用-DWITH_NDB=1或（已弃用）-DWITH_NDBCLUSTER=1选项调用CMake以包含对NDB的支持。

有关从源代码编译 NDB Cluster 的更多信息，请参阅 Section 25.3.1.4, “Building NDB Cluster from Source on Linux”，以及 Section 25.3.2.2, “Compiling and Installing NDB Cluster from Source on Windows”。

（有关mysqld选项和变量的信息，除了本节讨论的内容外，与 NDB Cluster 相关的内容，请参阅 Section 25.4.3.9, “MySQL Server Options and Variables for NDB Cluster”。）

如果mysqld二进制文件已经构建支持集群，NDBCLUSTER存储引擎仍然默认禁用。您可以使用以下两种选项之一来启用此引擎：

• 在启动mysqld时，在命令行上使用--ndbcluster作为启动选项。

• 在您的my.cnf文件的[mysqld]部分中插入一行包含ndbcluster。

通过在 MySQL Monitor（mysql）中发出 SHOW ENGINES 语句，您可以轻松验证服务器是否启用了 NDBCLUSTER 存储引擎。您应该在 NDBCLUSTER 的行中看到 Support 值为 YES。如果在此行中看到 NO 或者输出中没有显示这样的行，则表示您没有运行启用了 NDB 的 MySQL 版本。如果在此行中看到 DISABLED，则需要按照刚才描述的两种方式之一启用它。

要读取集群配置数据，MySQL 服务器至少需要三个信息：

• MySQL 服务器自身的集群节点 ID

• 管理服务器的主机名或 IP 地址

• 它可以连接到管理服务器的 TCP/IP 端口号

节点 ID 可以动态分配，因此不一定需要显式指定。

mysqld 参数 ndb-connectstring 用于在启动 mysqld 时的命令行或在 my.cnf 中指定连接字符串。连接字符串包含管理服务器的主机名或 IP 地址，以及其使用的 TCP/IP 端口。

在下面的示例中，ndb_mgmd.mysql.com 是管理服务器所在的主机，管理服务器在端口 1186 上监听集群消息：

$> mysqld --ndbcluster --ndb-connectstring=ndb_mgmd.mysql.com:1186
1

更多关于连接字符串的信息，请参阅 Section 25.4.3.3, “NDB Cluster Connection Strings”。

有了这些信息，MySQL 服务器可以作为集群中的完整参与者。在这种方式下运行的 mysqld 进程通常被称为 SQL 节点。它完全了解所有集群数据节点及其状态，并与所有数据节点建立连接。在这种情况下，它能够使用任何数据节点作为事务协调器，并读取和更新节点数据。

您可以在 mysql 客户端中使用 SHOW PROCESSLIST 查看 MySQL 服务器是否连接到集群。如果 MySQL 服务器连接到集群，并且您具有 PROCESS 权限，则输出的第一行如下所示：

mysql> SHOW PROCESSLIST \G
*************************** 1\. row ***************************
     Id: 1
   User: system user
   Host:
     db:
Command: Daemon
   Time: 1
  State: Waiting for event from ndbcluster
   Info: NULL
1
2
3
4
5
6
7
8
9
10

重要提示

要参与 NDB Cluster，必须使用both选项--ndbcluster和--ndb-connectstring（或它们在my.cnf中的等效选项）启动mysqld进程。如果只使用--ndbcluster选项启动mysqld，或者无法联系到集群，就无法使用NDB表，也无法创建任何新表，无论存储引擎如何。后一限制是一项安全措施，旨在防止在 SQL 节点未连接到集群时创建与NDB表同名的表。如果希望在mysqld进程未参与 NDB Cluster 时使用不同的存储引擎创建表，必须在不使用--ndbcluster选项的情况下重新启动服务器。

25.6.11 NDB Cluster 磁盘数据表

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

25.6.11.1 NDB Cluster 磁盘数据对象

25.6.11.2 NDB Cluster 磁盘数据存储要求

NDB Cluster 支持将NDB表的非索引列存储在磁盘上，而不是在 RAM 中。列数据和日志元数据保存在数据文件和撤销日志文件中，概念化为表空间和日志文件组，如下一节所述—参见第 25.6.11.1 节，“NDB Cluster 磁盘数据对象”。

NDB Cluster 磁盘数据性能可能受多个配置参数的影响。有关这些参数及其影响的信息，请参见磁盘数据配置参数，以及磁盘数据和 GCP 停止错误。

当使用单独的磁盘存储磁盘数据文件时，您还应将DiskDataUsingSameDisk数据节点配置参数设置为false。

参见磁盘数据文件系统参数。

NDB 8.0 在使用固态硬盘的磁盘数据表时提供了改进的支持，特别是使用 NVMe 的硬盘。有关更多信息，请参阅以下文档：

• 磁盘数据延迟参数

• 第 25.6.16.31 节，“ndbinfo diskstat 表”

• 第 25.6.16.32 节，“ndbinfo diskstats_1sec 表”

• 第 25.6.16.49 节，“ndbinfo pgman_time_track_stats 表”

译文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-disk-data-objects.html

25.6.11.1 NDB Cluster 磁盘数据对象

NDB Cluster 磁盘数据存储是使用以下对象实现的：

• 表空间：作为其他磁盘数据对象的容器。一个表空间包含一个或多个数据文件和一个或多个撤销日志文件组。

• 数据文件：存储列数据。数据文件直接分配给表空间。

• 撤销日志文件：包含用于回滚事务所需的撤销信息。分配给一个撤销日志文件组。

• 日志文件组：包含一个或多个撤销日志文件。分配给一个表空间。

撤销日志文件和数据文件是每个数据节点文件系统中的实际文件；默认情况下，它们放置在ndb_*node_id*_fs中，在 NDB Cluster config.ini文件中指定的*DataDir中，其中node_id*是数据节点的节点 ID。可以通过在创建撤销日志或数据文件时指定绝对或相对路径的方式将其放置在其他位置。创建这些文件的语句稍后在本节中显示。

撤销日志文件仅用于磁盘数据表，并且不需要或不用于仅存储在内存中的NDB表。

NDB Cluster 表空间和日志文件组并非实现为文件。

尽管并非所有磁盘数据对象都实现为文件，但它们都共享相同的命名空间。这意味着每个磁盘数据对象必须具有唯一的名称（而不仅仅是给定类型的每个磁盘数据对象）。例如，您不能同时命名一个表空间和一个日志文件组为dd1。

假设您已经设置好了包括管理节点和 SQL 节点在内的 NDB Cluster，创建 NDB Cluster 磁盘上的表的基本步骤如下：

1. 创建一个日志文件组，并将一个或多个撤销日志文件分配给它（有时也称为撤销日志文件）。

2. 创建一个表空间；将日志文件组以及一个或多个数据文件分配给表空间。

3. 创建一个使用此表空间进行数据存储的磁盘数据表。

可以使用 SQL 语句在mysql客户端或其他 MySQL 客户端应用程序中完成这些任务，如下面的示例所示。

1. 我们使用CREATE LOGFILE GROUP创建一个名为lg_1的日志文件组。该日志文件组由两个撤销日志文件组成，我们将它们命名为undo_1.log和undo_2.log，它们的初始大小分别为 16 MB 和 12 MB。（撤销日志文件的默认初始大小为 128 MB。）可选地，您还可以为日志文件组的撤销缓冲区指定大小，或允许其采用默认值 8 MB。在本例中，我们将 UNDO 缓冲区的大小设置为 2 MB。必须使用撤销日志文件创建日志文件组；因此，在此CREATE LOGFILE GROUP语句中，我们将undo_1.log添加到lg_1中：

   CREATE LOGFILE GROUP lg_1
       ADD UNDOFILE 'undo_1.log'
       INITIAL_SIZE 16M
       UNDO_BUFFER_SIZE 2M
       ENGINE NDBCLUSTER;
   1
   2
   3
   4
   5

   要将undo_2.log添加到日志文件组中，请使用以下ALTER LOGFILE GROUP语句：

   ALTER LOGFILE GROUP lg_1
       ADD UNDOFILE 'undo_2.log'
       INITIAL_SIZE 12M
       ENGINE NDBCLUSTER;
   1
   2
   3
   4

   一些需要注意的事项：

   • 此处使用的.log文件扩展名并非必需。我们仅使用它使日志文件易于识别。

   • 每个CREATE LOGFILE GROUP和ALTER LOGFILE GROUP语句必须包含一个ENGINE选项。此选项的唯一允许值为NDBCLUSTER和NDB。

     重要

     在同一个 NDB 集群中最多只能存在一个日志文件组。

   • 当您使用ADD UNDOFILE '*filename*'将撤销日志文件添加到日志文件组时，将在集群中每个数据节点的ndb_*node_id*_fs目录中创建一个名为*filename的文件，其中node_id*是数据节点的节点 ID。每个撤销日志文件的大小与 SQL 语句中指定的大小相同。例如，如果一个 NDB 集群有 4 个数据节点，则刚刚显示的ALTER LOGFILE GROUP语句将创建 4 个撤销日志文件，每个数据节点的数据目录中各有一个；每个文件的名称为undo_2.log，大小为 12 MB。

   • UNDO_BUFFER_SIZE受系统可用内存量的限制。

   • 有关这些语句的更多信息，请参见 Section 15.1.16, “CREATE LOGFILE GROUP Statement”和 Section 15.1.6, “ALTER LOGFILE GROUP Statement”。

2. 现在我们可以创建一个表空间——用于存储数据的磁盘数据表使用的文件的抽象容器。表空间与特定的日志文件组相关联；在创建新表空间时，必须指定其用于撤销日志记录的日志文件组。还必须指定至少一个数据文件；在创建表空间后，可以向表空间添加更多数据文件。还可以从表空间中删除数据文件（请参见本节后面的示例）。

   假设我们希望创建一个名为ts_1的表空间，该表空间使用lg_1作为其日志文件组。我们希望表空间包含两个数据文件，分别命名为data_1.dat和data_2.dat，其初始大小分别为 32 MB 和 48 MB。（INITIAL_SIZE的默认值为 128 MB。）我们可以使用两个 SQL 语句来实现这一点，如下所示：

   CREATE TABLESPACE ts_1
       ADD DATAFILE 'data_1.dat'
       USE LOGFILE GROUP lg_1
       INITIAL_SIZE 32M
       ENGINE NDBCLUSTER;
   
   ALTER TABLESPACE ts_1
       ADD DATAFILE 'data_2.dat'
       INITIAL_SIZE 48M;
   1
   2
   3
   4
   5
   6
   7
   8
   9

   CREATE TABLESPACE语句创建一个名为ts_1的表空间，其中包含数据文件data_1.dat，并将ts_1与日志文件组lg_1关联。ALTER TABLESPACE添加了第二个数据文件（data_2.dat）。

   一些需要注意的事项：

   • 就像在此示例中用于撤销日志文件的.log文件扩展名一样，在.dat文件扩展名中没有特殊意义；它仅用于便于识别。

   • 当您使用ADD DATAFILE '*filename*'向表空间添加数据文件时，将在集群中每个数据节点的ndb_*node_id*_fs目录中创建一个名为*filename的文件，其中node_id*是数据节点的节点 ID。每个数据文件的大小与 SQL 语句中指定的大小相同。例如，如果一个 NDB 集群有 4 个数据节点，则刚刚显示的ALTER TABLESPACE语句将创建 4 个数据文件，每个数据节点的数据目录中各有一个；每个文件的名称为data_2.dat，每个文件的大小为 48 MB。

   • NDB为每个表空间保留 4%的空间，用于在数据节点重新启动期间使用。此空间不可用于存储数据。

   • CREATE TABLESPACE语句必须包含一个ENGINE子句；只有使用与表空间相同存储引擎的表才能在表空间中创建。对于ALTER TABLESPACE，ENGINE子句被接受但已被弃用，并可能在将来的版本中被移除。对于NDB表空间，此选项的唯一允许值为NDBCLUSTER和NDB。

   • 在 NDB 8.0.20 及更高版本中，对于给定表空间使用的所有数据文件，范围的分配是以循环方式进行的。

   • 有关CREATE TABLESPACE和ALTER TABLESPACE语句的更多信息，请参见第 15.1.21 节，“CREATE TABLESPACE Statement”和第 15.1.10 节，“ALTER TABLESPACE Statement”。

3. 现在可以创建一个表，其未索引的列存储在使用表空间ts_1中的文件中：

   CREATE TABLE dt_1 (
       member_id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
       last_name VARCHAR(50) NOT NULL,
       first_name VARCHAR(50) NOT NULL,
       dob DATE NOT NULL,
       joined DATE NOT NULL,
       INDEX(last_name, first_name)
       )
       TABLESPACE ts_1 STORAGE DISK
       ENGINE NDBCLUSTER;
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10

   TABLESPACE ts_1 STORAGE DISK告诉NDB存储引擎在磁盘上使用表空间ts_1进行数据存储。

   一旦像所示创建了表ts_1，您可以执行INSERT、SELECT、UPDATE和DELETE语句，就像对任何其他 MySQL 表一样。

   通过在CREATE TABLE或ALTER TABLE语句中作为列定义的一部分使用STORAGE子句，还可以指定单个列是存储在磁盘上还是存储在内存中。STORAGE DISK导致列存储在磁盘上，而STORAGE MEMORY导致使用内存存储。有关更多信息，请参见第 15.1.20 节，“CREATE TABLE Statement”。

您可以通过查询INFORMATION_SCHEMA数据库中的FILES表来获取刚刚创建的NDB磁盘数据文件和撤销日志文件的信息，如下所示：

mysql> SELECT
              FILE_NAME AS File, FILE_TYPE AS Type,
              TABLESPACE_NAME AS Tablespace, TABLE_NAME AS Name,
              LOGFILE_GROUP_NAME AS 'File group',
              FREE_EXTENTS AS Free, TOTAL_EXTENTS AS Total
          FROM INFORMATION_SCHEMA.FILES
          WHERE ENGINE='ndbcluster';
+--------------+----------+------------+------+------------+------+---------+
| File         | Type     | Tablespace | Name | File group | Free | Total   |
+--------------+----------+------------+------+------------+------+---------+
| ./undo_1.log | UNDO LOG | lg_1       | NULL | lg_1       |    0 | 4194304 |
| ./undo_2.log | UNDO LOG | lg_1       | NULL | lg_1       |    0 | 3145728 |
| ./data_1.dat | DATAFILE | ts_1       | NULL | lg_1       |   32 |      32 |
| ./data_2.dat | DATAFILE | ts_1       | NULL | lg_1       |   48 |      48 |
+--------------+----------+------------+------+------------+------+---------+
4 rows in set (0.00 sec)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

有关更多信息和示例，请参见第 28.3.15 节，“The INFORMATION_SCHEMA FILES Table”。

隐式存储在磁盘上的列的索引。 对于刚刚显示的示例中定义的表dt_1，只有dob和joined列存储在磁盘上。这是因为id、last_name和first_name列上有索引，因此属于这些列的数据存储在 RAM 中。只有非索引列可以存储在磁盘上；索引和索引列数据继续存储在内存中。在设计磁盘数据表时，您必须牢记索引使用和 RAM 保留之间的权衡。

不能向明确声明为STORAGE DISK的列添加索引，必须先将其存储类型更改为MEMORY；任何尝试这样做的操作都会失败并显示错误。可以对隐式使用磁盘存储的列进行索引；在这种情况下，列的存储类型会自动更改为MEMORY。所谓“隐式”，指的是存储类型未声明但是从父表继承的列。在以下 CREATE TABLE 语句中（使用先前定义的表空间ts_1），列c2和c3隐式使用磁盘存储：

mysql> CREATE TABLE ti (
 ->     c1 INT PRIMARY KEY,
 ->     c2 INT,
 ->     c3 INT,
 ->     c4 INT
 -> )
 ->     STORAGE DISK
 ->     TABLESPACE ts_1
 ->     ENGINE NDBCLUSTER;
Query OK, 0 rows affected (1.31 sec)
1
2
3
4
5
6
7
8
9
10

因为c2、c3和c4本身没有声明为STORAGE DISK，所以可以对它们进行索引。在这里，我们分别对c2和c3添加索引，使用CREATE INDEX和ALTER TABLE：

mysql> CREATE INDEX i1 ON ti(c2);
Query OK, 0 rows affected (2.72 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> ALTER TABLE ti ADD INDEX i2(c3);
Query OK, 0 rows affected (0.92 sec)
Records: 0  Duplicates: 0  Warnings: 0
1
2
3
4
5
6
7

SHOW CREATE TABLE确认已添加索引。

mysql> SHOW CREATE TABLE ti\G
*************************** 1\. row ***************************
       Table: ti
Create Table: CREATE TABLE `ti` (
  `c1` int(11) NOT NULL,
  `c2` int(11) DEFAULT NULL,
  `c3` int(11) DEFAULT NULL,
  `c4` int(11) DEFAULT NULL,
  PRIMARY KEY (`c1`),
  KEY `i1` (`c2`),
  KEY `i2` (`c3`)
) /*!50100 TABLESPACE `ts_1` STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 1 row in set (0.00 sec)
1
2
3
4
5
6
7
8
9
10
11
12

可以使用ndb_desc查看，已强调的索引列现在使用内存而不是磁盘存储：

$> ./ndb_desc -d test t1
-- t1 --
Version: 33554433
Fragment type: HashMapPartition
K Value: 6
Min load factor: 78
Max load factor: 80
Temporary table: no
Number of attributes: 4
Number of primary keys: 1
Length of frm data: 317
Max Rows: 0
Row Checksum: 1
Row GCI: 1
SingleUserMode: 0
ForceVarPart: 1
PartitionCount: 4
FragmentCount: 4
PartitionBalance: FOR_RP_BY_LDM
ExtraRowGciBits: 0
ExtraRowAuthorBits: 0
TableStatus: Retrieved
Table options:
HashMap: DEFAULT-HASHMAP-3840-4
-- Attributes --
c1 Int PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY
*c2 Int NULL AT=FIXED ST=MEMORY
c3 Int NULL AT=FIXED ST=MEMORY* c4 Int NULL AT=FIXED ST=DISK
-- Indexes --
PRIMARY KEY(c1) - UniqueHashIndex
i2(c3) - OrderedIndex
PRIMARY(c1) - OrderedIndex
i1(c2) - OrderedIndex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

性能注意。 使用磁盘数据存储的集群的性能会大大提高，如果将磁盘数据文件与数据节点文件系统分开存放。必须为集群中的每个数据节点执行此操作才能获得任何明显的好处。

可以在ADD UNDOFILE和ADD DATAFILE中使用绝对和相对文件系统路径；相对路径是相对于数据节点的数据目录计算的。

日志文件组、表空间以及使用这些对象的任何磁盘数据表必须按特定顺序创建。对于删除这些对象也是如此，受以下约束条件限制：

• 只要任何表空间使用日志文件组，就无法删除日志文件组。

• 只要表空间包含任何数据文件，就无法删除表空间。

• 只要仍然有任何使用该表空间的表，就无法从表空间中删除任何数据文件。

• 无法删除与创建文件时使用不同表空间相关联的文件。

例如，要删除本节中到目前为止创建的所有对象，可以使用以下语句：

mysql> DROP TABLE dt_1;

mysql> ALTER TABLESPACE ts_1
 -> DROP DATAFILE 'data_2.dat'
 -> ENGINE NDBCLUSTER;

mysql> ALTER TABLESPACE ts_1
 -> DROP DATAFILE 'data_1.dat'
 -> ENGINE NDBCLUSTER;

mysql> DROP TABLESPACE ts_1
 -> ENGINE NDBCLUSTER;

mysql> DROP LOGFILE GROUP lg_1
 -> ENGINE NDBCLUSTER;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

这些语句必须按照显示的顺序执行，除了两个ALTER TABLESPACE ... DROP DATAFILE语句可以以任意顺序执行。