Spec-Zone.ru › MySQL 9.2

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=password. password должно соответствовать всем следующим требованиям:

  • Использует любые печатные символы ASCII, кроме !, ', ", $, %, \ и ^

  • Имеет длину не более 256 символов

  • Заключается в одинарные или двойные кавычки

При использовании ENCRYPT PASSWORD='password' данные записи резервной копии и файлы журналов, записанные каждым узлом данных, шифруются с помощью ключа, полученного из предоставленного пользователем password и случайной соли, с использованием функции вывода ключа (KDF), которая использует алгоритм PBKDF2-SHA256 для генерации симметричного ключа шифрования для этого файла. Эта функция имеет вид, показанный здесь:

key = KDF(random_salt, password)

Полученный ключ затем используется для шифрования данных резервной копии с использованием AES 256 CBC inline, и симметричное шифрование используется для шифрования набора файлов резервной копии (с сгенерированным ключом).

Примечание

NDB Cluster никогда не сохраняет предоставленный пользователем пароль или сгенерированный ключ шифрования.

Опцию PASSWORD можно опустить из encryption_option. В этом случае клиент управления запросит пароль у пользователя.

Возможно использование PASSWORD для установки пустого пароля ('' или ""), но это не рекомендуется.

Зашифрованную резервную копию можно расшифровать с помощью следующих команд:

  • ndb_restore --decrypt --backup-password=password

  • ndbxfrm --decrypt-password=password input_file output_file

  • ndb_print_backup_file -P password file_name

  • ndb_restore --decrypt --backup-password-from-stdin

  • ndbxfrm --decrypt-password-from-stdin input_file output_file

  • ndb_print_backup_file --backup-password=password file_name

  • ndb_print_backup_file --backup-password-from-stdin file_name

  • ndb_mgm --backup-password-from-stdin --execute "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 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

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

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

    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, в каталоге резервных копий.

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

  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, а узел управления, к которому подключён клиент управления кластером, имеет идентификатор узла 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, клиент управления не отвечает, и в журнале кластера не указывается, что была отправлена неверная команда отмены.

© 2025 Oracle
Licensed under the GPLv2 License.
https://docs.oracle.com/cd/E17952_01/mysql-8.4-en/mysql-cluster-backup-using-management-client.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API