21.6.8.2 Using The NDB Cluster Management Client to Create a Backup — MySQL 5.7

21.6.8.2 Использование клиента управления NDB кластером для создания резервной копии

Перед началом резервного копирования убедитесь, что кластер должным образом настроен для его выполнения. (См. раздел 21.6.8.3 «Настройка резервного копирования 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 может использоваться для определения того, соответствует ли резервная копия состоянию кластера во время выдачи START BACKUP или во время её завершения. SNAPSHOTSTART заставляет резервную копию соответствовать состоянию кластера при её начале; SNAPSHOTEND заставляет резервную копию отражать состояние кластера при завершении резервного копирования. SNAPSHOTEND является значением по умолчанию и соответствует поведению, наблюдаемому в предыдущих выпусках NDB кластера.

Примечание

Если вы используете параметр SNAPSHOTSTART с START BACKUP, и параметр CompressedBackup включён, будут сжаты только файлы данных и управления — файл журнала не сжимается.

Если используются как wait_option, так и snapshot_option, их можно указать в любом порядке. Например, все следующие команды являются допустимыми, предполагая, что нет существующей резервной копии с идентификатором 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

Процедура создания резервной копии состоит из следующих шагов:

Запустите клиент управления (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 — идентификатор сервера управления, который координирует резервное копирование с узлами данных. На этом этапе процесса резервного копирования кластер получил и обработала запрос на резервное копирование. Это не означает, что резервное копирование завершено. Пример этого утверждения показан здесь:
```
Node 2: Backup 1 started from node 1
```
Клиент управления укажет с помощью сообщения, подобного этому, что резервное копирование началось:
```
Backup backup_id started from node node_id completed
```
Как и в случае с уведомлением о начале резервного копирования, backup_id является уникальным идентификатором этой конкретной резервной копии, а node_id — идентификатор узла сервера управления, который координирует резервное копирование с узлами данных. Этот вывод сопровождается дополнительной информацией, включая соответствующие глобальные контрольные точки, количество скопированных записей и размер данных, как показано здесь:
```
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 с параметром -e или --execute, как показано в этом примере:

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

При использовании START BACKUP таким образом, вы должны указать идентификатор резервной копии.

Резервные копии кластера по умолчанию создаются в подкаталоге BACKUP каталога DataDir на каждом узле данных. Это можно изменить для одного или нескольких узлов данных индивидуально или для всех узлов данных кластера в файле config.ini, используя параметр конфигурации BackupDataDir. Файлы резервной копии, созданные для резервной копии с заданным backup_id, хранятся в подкаталоге с именем BACKUP-backup_id в каталоге резервной копии.

Отмена резервного копирования. Чтобы отменить или прервать уже выполняющееся резервное копирование, выполните следующие шаги:

Запустите клиент управления.
Выполните эту команду:
```
ndb_mgm> ABORT BACKUP backup_id
```
Число backup_id — это идентификатор резервной копии, который был включён в ответ клиента управления при её запуске (в сообщении Backup backup_id started from node management_node_id).
Клиент управления подтверждает запрос на отмену с помощью Abort of backup backup_id ordered.

Примечание

На этом этапе клиент управления ещё не получил ответ от узлов данных кластера на этот запрос, и резервное копирование ещё не было фактически отменено.
После отмены резервного копирования клиент управления сообщает об этом факте, примерно так:
```
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, а узлу управления, к которому подключён клиент управления кластером, присвоен идентификатор узла 5. Первый узел, завершивший свою часть в отмене резервного копирования, сообщает, что причиной отмены было требование пользователя. (Остальные узлы сообщают, что резервное копирование было отменено из-за неопределённой внутренней ошибки.)

Примечание

Нет гарантии, что узлы кластера отреагируют на команду ABORT BACKUP в определённом порядке.

Сообщения Backup backup_id started from node management_node_id has been aborted означают, что резервное копирование было прервано, и все файлы, относящиеся к этой резервной копии, были удалены из файловой системы кластера.

Также можно отменить выполняющееся резервное копирование из системной оболочки, используя эту команду:

$> ndb_mgm -e "ABORT BACKUP backup_id"

Примечание

Если во время выдачи команды ABORT BACKUP нет резервной копии с идентификатором backup_id, клиент управления не отвечает, и в журнале кластера не указывается, что был отправлен неверный запрос на отмену.