25.6.8.2 Использование клиента управления NDB Cluster для создания резервной копии
Перед началом создания резервной копии убедитесь, что кластер должным образом настроен для этого. (См. раздел 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
Последовательные резервные копии автоматически идентифицируются последовательно, поэтому backup_id, целое число, большее или равное 1, является необязательным; если его пропустить, используется следующее доступное значение. Если используется существующее значение backup_id, резервное копирование завершается с ошибкой Резервное копирование завершилось ошибкой: файл уже существует. Если используется, backup_id должен следовать непосредственно за ключевыми словами START BACKUP, перед любыми другими опциями.
START BACKUP поддерживает создание зашифрованных резервных копий с использованием ENCRYPT
PASSWORD=. passwordpassword должно соответствовать всем следующим требованиям:
Использует любые печатные символы ASCII, кроме
!,',",$,%,\и^Имеет длину не более 256 символов
Заключается в одинарные или двойные кавычки
При использовании ENCRYPT
PASSWORD=' данные записи резервной копии и файлы журналов, записанные каждым узлом данных, шифруются с помощью ключа, полученного из предоставленного пользователем password'password и случайной соли, с использованием функции вывода ключа (KDF), которая использует алгоритм PBKDF2-SHA256 для генерации симметричного ключа шифрования для этого файла. Эта функция имеет вид, показанный здесь:
key = KDF(random_salt, password)
Полученный ключ затем используется для шифрования данных резервной копии с использованием AES 256 CBC inline, и симметричное шифрование используется для шифрования набора файлов резервной копии (с сгенерированным ключом).
NDB Cluster никогда не сохраняет предоставленный пользователем пароль или сгенерированный ключ шифрования.
Опцию PASSWORD можно опустить из encryption_option. В этом случае клиент управления запросит пароль у пользователя.
Возможно использование PASSWORD для установки пустого пароля ('' или ""), но это не рекомендуется.
Зашифрованную резервную копию можно расшифровать с помощью следующих команд:
ndbxfrm
--decrypt-password=passwordinput_fileoutput_filendb_print_backup_file
-Ppasswordfile_namendbxfrm
--decrypt-password-from-stdininput_fileoutput_filendb_print_backup_file
--backup-password-from-stdinfile_namendb_mgm
--backup-password-from-stdin--execute "START BACKUP ..."
См. описания этих программ для получения дополнительной информации, включая дополнительные параметры, которые могут потребоваться.
wait_option можно использовать для определения момента возвращения управления клиенту управления после выполнения команды START BACKUP, как показано в следующем списке:
-
Если указан
NOWAIT, клиент управления сразу отображает приглашение, как показано здесь:ndb_mgm>
START BACKUP NOWAITndb_mgm>В этом случае клиент управления можно использовать даже во время вывода информации о ходе процесса резервного копирования.
-
С помощью
WAIT STARTEDклиент управления ожидает начала резервного копирования, прежде чем вернуть управление пользователю, как показано здесь:ndb_mgm>
START BACKUP WAIT STARTEDWaiting 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 Cluster.
Если используется параметр 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 BACKUPWaiting 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_idstarted from nodenode_idbackup_id— уникальный идентификатор данной резервной копии. Этот идентификатор сохраняется в журнале кластера, если не настроено иное.node_id— идентификатор сервера управления, который координирует резервное копирование с узлами данных. На данном этапе процесса резервного копирования кластер получил и обработает запрос на резервное копирование. Это не означает, что резервное копирование завершено. Пример этого сообщения показан здесь:Node 2: Backup 1 started from node 1
-
Клиент управления укажет о начале резервного копирования сообщением, подобным этому:
Backup
backup_idstarted from nodenode_idcompletedКак и в случае с уведомлением о начале резервного копирования,
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 BACKUPbackup_idЧисло
backup_id— это идентификатор резервной копии, который был включён в ответ клиента управления при запуске резервного копирования (в сообщенииBackup).backup_idstarted from nodemanagement_node_id -
Клиент управления подтверждает запрос об отмене с помощью
Abort of backup.backup_idorderedПримечаниеНа данном этапе клиент управления ещё не получил ответ от узлов данных кластера на этот запрос, и резервное копирование ещё не отменено фактически.
-
После отмены резервного копирования клиент управления сообщает об этом аналогично показанному здесь:
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_idstarted from nodemanagement_node_idhas been aborted
Также можно отменить резервное копирование, которое выполняется из системной оболочки, используя эту команду:
$> ndb_mgm -e "ABORT BACKUP backup_id"
Если в момент выдачи команды ABORT BACKUP нет резервной копии с идентификатором backup_id, клиент управления не отвечает, и в журнале кластера не указывается, что была отправлена неверная команда отмены.
© 2025 Oracle
Licensed under the GPLv2 License.