17.5.3.2. Используя MySQL Cluster Management Client to Create Резервное копирование

Прежде, чем запустить резервное копирование, удостоверьтесь, что кластер должным образом конфигурируется для того, чтобы выполнить тот. (См. Раздел 17.5.3.3, "Конфигурация для MySQL Cluster Backups".)

START BACKUP команда используется, чтобы создать резервное копирование:

START BACKUP [backup_id] [wait_option] [snapshot_option]wait_option:WAIT {STARTED | COMPLETED} | NOWAITsnapshot_option:SNAPSHOTSTART | SNAPSHOTEND

Последовательные резервные копии автоматически идентифицируются последовательно, таким образом, backup_id, целое число, больше чем или равный 1, является дополнительным; если это опускается, следующее доступное значение используется. Если существующее backup_id значение используется, резервные сбои с ошибочным отказавшим Резервным копированием: файл уже существует. Если использующийся, backup_id должен следовать START BACKUP сразу, прежде, чем любые другие опции используются.

wait_option может использоваться, чтобы определить, когда управление возвращается клиенту управления после a START BACKUP команда дается, как показано в следующем списке:

Если NOWAIT определяется, клиент управления сразу выводит на экран подсказку, как замечено здесь:
```
ndb_mgm> START BACKUP
                    NOWAITndb_mgm>
```
В этом случае клиент управления может использоваться даже, в то время как это печатает информацию о продвижении от процесса резервного копирования.
С WAIT STARTED клиент управления ожидает, пока резервное копирование не запустилось перед возвращением управления пользователю, как показано здесь:
```
ndb_mgm> START BACKUP WAIT STARTEDWaiting for started, this may take several minutesNode 2: Backup 3 started from node 1ndb_mgm>
```
WAIT COMPLETED заставляет клиент управления ожидать, пока процесс резервного копирования не полон перед возвращением управления пользователю.

WAIT COMPLETED значение по умолчанию.

A snapshot_option может использоваться, чтобы определить, соответствует ли резервное копирование состояние кластера когда START BACKUP был выпущен, или когда это было завершено. SNAPSHOTSTART заставляет резервное копирование соответствовать состояние кластера, когда резервное копирование началось; SNAPSHOTEND заставляет резервное копирование отражать состояние кластера, когда резервное копирование было закончено. SNAPSHOTEND значение по умолчанию, и соответствует поведение, найденное в предыдущих выпусках MySQL Cluster.

Отметить

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

Если оба a wait_option и a snapshot_option используются, они могут быть определены в любом порядке. Например, все следующие команды допустимы, предполагая, что нет никакого существующего резервного копирования, имеющего 4 как его ID:

START BACKUP WAIT STARTED SNAPSHOTSTARTSTART BACKUP SNAPSHOTSTART WAIT STARTEDSTART BACKUP 4 WAIT COMPLETED SNAPSHOTSTARTSTART BACKUP SNAPSHOTEND WAIT COMPLETEDSTART BACKUP 4 NOWAIT SNAPSHOTSTART

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

Запустите клиент управления (ndb_mgm), если это не уже работающий.
Выполнитесь START BACKUP команда. Это продолжает несколько линий вывода, указывающего на продвижение резервного копирования, как показано здесь:
```
ndb_mgm> START BACKUPWaiting for completed, this may take several minutesNode 2: Backup 1 started from node 1Node 2: Backup 1 started from node 1 completed StartGCP: 177 StopGCP: 180 #Records: 7362 #LogRecords: 0 Data: 453648 bytes Log: 0 bytesndb_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 ID узла сервера управления, который координирует резервное копирование с узлами данных. Этот вывод сопровождается дополнительной информацией включая соответствующие глобальные контрольные точки, число записей, поддержанных, и размер данных, как показано сюда:
```
	Node 2: Backup 1 started from node 1 completed StartGCP: 177 StopGCP: 180 #Records: 7362 #LogRecords: 0Data: 453648 bytes Log: 0 bytes
```

Также возможно выполнить резервное копирование от системной оболочки, вызывая 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 в резервном каталоге.

Прерывать резервное копирование, которое уже происходит:

Запустите клиент управления.
Выполните эту команду:
```
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 errorNode 3: Backup 3 started from 5 has been aborted.   Error: 1323 - 1323: Permanent error: Internal errorNode 2: Backup 3 started from 5 has been aborted.   Error: 1323 - 1323: Permanent error: Internal errorNode 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 выполнение, когда ABORT BACKUP выпускается, клиент управления не делает ответа, и при этом это не обозначается в журнале кластера, который была отправлена недопустимая команда аварийного прекращения работы.