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

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

Хотя не обязательно, чтобы у реплицируемого кластера было такое же количество узлов данных, как у исходного, настоятельно рекомендуется, чтобы их количество было одинаковым. Необходимо, чтобы процесс репликации был остановлен при запуске сервера реплики. Это можно сделать, запустив реплику с параметром --skip-replica-start.

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

Сбросьте реплику кластера с помощью этой команды в клиенте mysql:

mysqlR> RESET REPLICA;

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

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

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

Для восстановления из исходного кластера с четырьмя узлами данных (как показано на рисунке в разделе 25.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 на реплике (как обсуждалось в разделе 25.7.8 «Реализация переключения на резервную копию с репликацией NDB Cluster»):

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

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

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

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

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

mysqlR> CHANGE REPLICATION SOURCE TO
     ->     SOURCE_LOG_FILE='@file',
     ->     SOURCE_LOG_POS=@pos;

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

mysqlR> START REPLICA;