Существует два различных метода запуска резервного копирования.

Скопируйте файлы резервной копии кластера на реплику, которая запускается. Каждый компьютер, на котором запущен процесс ndbd для исходного кластера, имеет файлы резервной копии кластера, и все эти файлы должны быть скопированы на реплику, чтобы обеспечить успешное восстановление. Файлы резервной копии можно скопировать в любой каталог на компьютере, где находится хост управления реплики, при условии, что у бинарных файлов MySQL и NDB есть права чтения в этом каталоге. В этом случае мы предполагаем, что эти файлы были скопированы в каталог /var/BACKUPS/BACKUP-1.

Хотя не обязательно, чтобы реплицируемый кластер имел такое же количество процессов ndbd (узлов данных), как источник, настоятельно рекомендуется, чтобы их количество было одинаковым. Необходимо, чтобы реплика запускалась с опцией --skip-slave-start, чтобы предотвратить преждевременный запуск процесса репликации.

Создайте на реплике кластера любые базы данных, которые присутствуют в исходном кластере и должны быть реплицированы.

Сбросьте реплицируемый кластер, используя эту команду в клиенте mysql:

mysqlR> RESET SLAVE;

Теперь можно начать процесс восстановления кластера на реплике, используя команду ndb_restore для каждого файла резервной копии по очереди. Для первого из них необходимо использовать опцию -m для восстановления метаданных кластера, как показано здесь:

shellR> ndb_restore -c replica_host:port -n node-id \
        -b backup-id -m -r dir

dir — путь к каталогу, в котором файлы резервной копии были помещены на реплику. Для команд ndb_restore , соответствующих остальным файлам резервной копии, опцию -m не нужно использовать.

Для восстановления из исходного кластера с четырьмя узлами данных (как показано на рисунке в Разделе 21.7, «Репликация NDB Cluster»), где файлы резервной копии были скопированы в каталог /var/BACKUPS/BACKUP-1, последовательность команд для выполнения на реплике может выглядеть следующим образом:

shellR> ndb_restore -c replica-host:1186 -n 2 -b 1 -m \
        -r ./var/BACKUPS/BACKUP-1
shellR> ndb_restore -c replica-host:1186 -n 3 -b 1 \
        -r ./var/BACKUPS/BACKUP-1
shellR> ndb_restore -c replica-host:1186 -n 4 -b 1 \
        -r ./var/BACKUPS/BACKUP-1
shellR> ndb_restore -c replica-host:1186 -n 5 -b 1 -e \
        -r ./var/BACKUPS/BACKUP-1

Теперь необходимо получить последнюю эпоху из таблицы ndb_apply_status на реплике (как обсуждалось в Разделе 21.7.8, «Реализация резервного копирования с репликацией NDB Cluster»):

mysqlR> SELECT @latest:=MAX(epoch)
        FROM mysql.ndb_apply_status;

Используя @latest как значение эпохи, полученное на предыдущем шаге, можно получить правильную начальную позицию @pos в правильном двоичном журнале @file из таблицы mysql.ndb_binlog_index на источнике. Приведенный запрос получает эти значения из столбцов next_position и next_file из последней применённой эпохи перед логической позицией восстановления:

mysqlS> SELECT
     ->     @file:=SUBSTRING_INDEX(next_file, '/', -1),
     ->     @pos:=next_position
     -> FROM mysql.ndb_binlog_index
     -> WHERE epoch > @latest
     -> ORDER BY epoch ASC LIMIT 1;

В случае, если в настоящее время нет трафика репликации, подобную информацию можно получить, выполнив SHOW MASTER STATUS на источнике и используя значение, отображаемое в столбце Position вывода для файла, имя которого имеет суффикс с наибольшим значением для всех файлов, отображаемых в столбце File. В этом случае нужно определить, какой это файл, и вручную или с помощью скрипта предоставить его имя на следующем шаге.

Используя значения, полученные на предыдущем шаге, можно теперь выполнить соответствующую команду CHANGE MASTER TO в клиенте mysql реплики:

mysqlR> CHANGE MASTER TO
     ->     MASTER_LOG_FILE='@file',
     ->     MASTER_LOG_POS=@pos;

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

mysqlR> START SLAVE;