NDB集群在线备份

接下来的几节描述了如何使用ndb_mgm管理客户端中找到的用于此目的的功能进行准备，然后创建NDB群集备份。为了将这种类型的备份与使用mysqldump进行的备份区分开来，有时我们将其称为“本机” NDB群集备份。（有关使用mysqldump创建备份的信息，请参见“mysqldump-数据库备份程序”。）NDB Cluster备份的还原是使用NDB Cluster发行版随附的ndb_restore实用程序完成的；有关的信息ndb_restore及其在还原NDB群集备份中的用途，请参见“ndb_restore-还原NDB群集备份”。

从NDB 8.0.16开始，可以使用多个LDM创建备份以实现数据节点上的并行性。

NDB群集备份概念

备份是给定时间的数据库快照。备份包括三个主要部分：

• 元数据。所有数据库表的名称和定义
• 表记录。进行备份时实际存储在数据库表中的数据
• 交易记录。顺序记录，说明如何以及何时将数据存储在数据库中

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

• BACKUP-backup_id.node_id.ctl

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

• BACKUP-backup_id-0.node_id.data

  包含表记录的数据文件，这些记录按碎片保存。即，不同的节点在备份期间保存不同的片段。每个节点保存的文件均以标头开头，该标头指出了记录所属的表。在记录列表之后，有一个页脚，其中包含所有记录的校验和。

• BACKUP-backup_id.node_id.log

  包含已提交事务记录的日志文件。日志中仅存储备份中存储的表上的事务。备份中涉及的节点保存不同的记录，因为不同的节点承载不同的数据库片段。

在刚刚显示的清单中，backup_id代表备份标识符，并且node_id是创建文件的节点的唯一标识符。

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

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

开始备份之前，请确保已正确配置群集以执行一个备份。（请参见“ NDB群集备份的配置”。）

该START BACKUP命令用于创建备份：

START BACKUP [backup_id] [wait_option] [snapshot_option]

wait_option:
WAIT {STARTED | COMPLETED} | NOWAIT

snapshot_option:
SNAPSHOTSTART | SNAPSHOTEND

连续备份将自动顺序识别，因此backup_id，大于或等于1的整数是可选的；如果省略，则使用下一个可用值。如果使用现有backup_id值，则备份失败，并显示错误备份失败：文件已存在。如果使用，backup_id必须START BACKUP立即遵循，然后再使用其他任何选项。

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

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

  ndb_mgm> START BACKUP NOWAIT
  ndb_mgm>
  

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

• 随着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>
  

• WAIT COMPLETED使管理客户端等待备份过程完成，然后再将控制权还给用户。

WAIT COMPLETED是默认值。

snapshot_option可以使用 A 确定备份START BACKUP在发布时或完成时是否与群集的状态匹配。SNAPSHOTSTART使备份开始时备份与群集的状态匹配；SNAPSHOTEND导致备份完成后，备份反映群集的状态。SNAPSHOTEND是默认设置，并且与以前的NDB Cluster版本中发现的行为匹配。

注意

如果将此SNAPSHOTSTART选项与结合使用START BACKUP，并且CompressedBackup启用了参数，则仅压缩数据和控制文件-不压缩日志文件。

如果同时使用a wait_option和a 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. 启动管理客户端（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>
   

3. 备份启动后，管理客户端将显示以下消息：

   Backup backup_id started from node node_id
   

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

   Node 2: Backup 1 started from node 1
   

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

   Backup backup_id started from node node_id completed
   

   与备份已开始的通知一样，它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
   

也可以通过使用 or 选项调用ndb_mgm从系统外壳执行备份，如本示例所示：-e--execute

shell>ndb_mgm -e "START BACKUP 6 WAIT COMPLETED SNAPSHOTSTART"

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

默认情况下，群集备份是在每个数据节点上的BACKUP子目录中创建的DataDir。可以config.ini使用BackupDataDir配置参数分别为一个或多个数据节点或文件中的所有群集数据节点覆盖此属性。为使用给定备份创建的备份文件backup_id存储在备份目录中命名的子目录中。BACKUP-backup_id

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

1. 启动管理客户端。

2. 执行以下命令：

   ndb_mgm> ABORT BACKUP backup_id
   

   该数字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
   

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

   注意

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

   该消息表示备份已终止，并且已从群集文件系统中删除了与该备份有关的所有文件。Backup backup_id started from node management_node_id has been aborted

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

shell>ndb_mgm -e "ABORT BACKUP backup_id"

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

NDB群集备份的配置

备份必不可少的五个配置参数：

• BackupDataBufferSize

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

• BackupLogBufferSize

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

• BackupMemory

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

• BackupWriteSize

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

• BackupMaxWriteSize

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

有关这些参数的更多详细信息，请参见“ndb_restore-还原NDB群集备份”。

您还可以使用BackupDataDir配置参数设置备份文件的位置。默认值为。FileSystemPath/BACKUP/BACKUP-backup_id

NDB群集备份故障排除

如果在发出备份请求时返回错误代码，则最可能的原因是内存或磁盘空间不足。您应检查是否为备份分配了足够的内存。

重要

如果已设置BackupDataBufferSize并且BackupLogBufferSize它们的总和大于4MB，则还必须进行设置BackupMemory。

您还应确保备份目标的硬盘驱动器分区上有足够的空间。

NDB不支持可重复读取，这可能会导致还原过程出现问题。尽管备份过程是“热”的，但从备份还原NDB群集并不是100％“热”的过程。这是由于以下事实：在还原过程中，正在运行的事务会从还原的数据中获取不可重复的读取。这意味着在还原过程中数据状态不一致。

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

从NDB 8.0.16开始，可以在数据节点上并行执行多个本地数据管理器（LDM）进行备份。为此，群集中的所有数据节点必须使用多个LDM，并且每个数据节点必须使用相同数量的LDM。这意味着所有数据节点都必须运行ndbmtd（ndbd是单线程的，因此始终只有一个LDM），并且必须将它们配置为使用多个LDM，然后再进行备份。默认情况下，ndbmtd在单线程模式下运行。你可以使它们通过选择适当的设置用于多线程数据节点的配置参数中的一个来使用多个的LDM这个MaxNoOfExecutionThreads或ThreadConfig。请记住，更改这些参数需要重新启动集群。这可以是滚动重启。

根据LDM的数量和其他因素，您可能还需要增加NoOfFragmentLogParts。如果您使用大的磁盘数据表，则可能还需要增加DiskPageBufferMemory。与单线程的备份，你也想要或需要作出调整设置BackupDataBufferSize，BackupMemory以及与备份其它配置参数（见备份参数）。

一旦所有数据节点都使用多个LDM，就可以使用START BACKUPNDB管理客户端中的命令进行并行备份，就像数据节点正在运行ndbd（或以单线程模式运行ndbmtd）一样。不需要其他或特殊语法，并且可以根据需要或期望以任何组合指定备份ID，等待选项或快照选项。

使用多个LDM的备份会在每个数据节点上的目录（又位于之下）下创建子目录（每个LDM子目录一个）；这些子目录被命名为，等等，以此类推，直到，其中是用于此备份的备份ID，并且是每个数据节点的LDM数量。这些子目录中的每一个都包含常用的备份文件，和，其中是此数据节点的节点ID。BACKUP/BACKUP-backup_id/BackupDataDirBACKUP-backup_id-PART-1-OF-N/BACKUP-backup_id-PART-2-OF-N/BACKUP-backup_id-PART-N-OF-N/backup_idNBACKUP-backup_id-0.node_id.DataBACKUP-backup_id.node_id.ctlBACKUP-backup_id.node_id.lognode_id

在NDB 8.0.16和更高版本中，ndb_restore自动检查刚才描述的子目录是否存在；如果找到它们，它将尝试并行还原备份。有关恢复使用多个LDM进行的备份的信息，