21.5.8.2 使用 NDB 群集 ManagementClient 端创建备份
开始备份之前，请确保已正确配置群集以执行一个备份。 (请参阅第 21.5.8.3 节“ NDB 群集备份的配置”。)
START BACKUP命令用于创建备份：
START BACKUP [backup_id] [wait_option] [snapshot_option]
wait_option:
WAIT {STARTED | COMPLETED} | NOWAIT
snapshot_option:
SNAPSHOTSTART | SNAPSHOTEND
连续备份将被自动 Sequences 识别，因此* backup_id (一个大于或等于 1 的整数)是可选的；如果省略，则使用下一个可用值。如果使用现有 backup_id 值，则备份将失败，并显示错误“备份失败：文件已存在”。如果使用， backup_id *必须紧随START BACKUP，然后再使用其他任何选项。
wait_option*可用于确定发出START BACKUP命令后何时将控制权返回给 ManagementClient 端，如以下列 table 所示：
ndb_mgm> START BACKUP NOWAIT
ndb_mgm>
在这种情况下，即使 ManagementClient 端打印备份过程中的进度信息，也可以使用它。
ndb_mgm> START BACKUP WAIT STARTED
Waiting for started, this may take several minutes
Node 2: Backup 3 started from node 1
ndb_mgm>
WAIT COMPLETED是默认值。
A * snapshot_option *可用于确定在发出START BACKUP或完成备份时，备份是否与群集的状态匹配。 SNAPSHOTSTART使备份开始时备份与群集的状态匹配； SNAPSHOTEND使备份完成后，备份反映群集的状态。 SNAPSHOTEND是默认值，它与以前的 NDB Cluster 版本中的行为匹配。
Note
如果将SNAPSHOTSTART选项与START BACKUP一起使用，并且启用了CompressedBackup参数，则仅压缩数据和控制文件，而不压缩日志文件。
如果同时使用* wait_option 和 snapshot_option *，则可以按任意 Sequences 指定它们。例如，假设没有现有备份的 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
创建备份的过程包括以下步骤：
-
启动 ManagementClient 端(ndb_mgm)(如果尚未运行)。
-
执行
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>
Backup backup_id started from node node_id
backup_id*是此特定备份的唯一标识符。如果未进行其他配置，则此标识符将保存在群集日志中。 *node_id*是协调备份与数据节点的 Management 服务器的标识符。此时，在备份过程中，集群已接收并处理了备份请求。这并不意味着备份已完成。此语句的示例如下所示：
Node 2: Backup 1 started from node 1
- ManagementClient 端通过类似这样的消息指示备份已开始：
Backup backup_id started from node node_id completed
与通知备份已开始的情况一样，* backup_id 是此特定备份的唯一标识符，而 node_id *是正在与数据节点进行协调的 Management 服务器的节点 ID。此输出随附其他信息，包括相关的全局检查点，备份的记录数和数据大小，如下所示：
Node 2: Backup 1 started from node 1 completed
StartGCP: 177 StopGCP: 180
#Records: 7362 #LogRecords: 0
Data: 453648 bytes Log: 0 bytes
也可以通过使用-e或--execute选项调用ndb_mgm从系统 Shell 执行备份，如以下示例所示：
shell> ndb_mgm -e "START BACKUP 6 WAIT COMPLETED SNAPSHOTSTART"
以这种方式使用START BACKUP时，必须指定备份 ID。
默认情况下，在每个数据节点上DataDir的BACKUP子目录中创建群集备份。可以使用BackupDataDir配置参数分别为一个或多个数据节点或config.ini文件中的所有群集数据节点覆盖此参数。为给定* backup_id *备份创建的备份文件存储在备份目录中名为BACKUP-backup_id的子目录中。
-
启动 ManagementClient 端。
-
执行以下命令：
ndb_mgm> ABORT BACKUP backup_id
backup_id*是备份的标识符，备份的标识符包含在备份开始时 ManagementClient 端的响应中(在消息Backup backup_id started from node management_node_id中)。
- ManagementClient 端将使用
Abort of backup backup_id ordered确认中止请求。
Note
此时，ManagementClient 端尚未从群集数据节点收到对此请求的响应，并且备份实际上尚未中止。
- 备份中止后，ManagementClient 端将以类似于以下所示的方式报告此事实：
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
在此示例中，我们显示了具有 4 个数据节点的集群的示例输出，其中要中止的备份的序列号为3，与集群 ManagementClient 端连接的 Management 节点的节点 ID 为5。第一个完成中止备份的部分的节点报告中止的原因是由于用户的请求。 (其余节点报告由于未指定的内部错误导致备份已中止.)
Note
不能保证群集节点以任何特定 Sequences 响应ABORT BACKUP命令。
Backup backup_id started from node management_node_id has been aborted消息 table 示备份已终止，并且已从群集文件系统中删除了与该备份有关的所有文件。
也可以使用以下命令从系统 Shell 中止正在进行的备份：
shell> ndb_mgm -e "ABORT BACKUP backup_id"
Note
如果在发出ABORT BACKUP时不存在 ID * backup_id *正在运行的备份，则 ManagementClient 端不会做出响应，也不会在群集日志中指示已发送了无效的中止命令。