17.6.9. MySQL Cluster Replication MySQL Cluster Backups With

Есть два различных метода, которыми может быть запущено резервное копирование.

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

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

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

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

mysqlS> RESET SLAVE;

Важно удостовериться что ведомое устройство apply_status таблица не содержит записей до выполнения процесса восстановления. Можно выполнить это, выполняя этот SQL-оператор на ведомом устройстве:

mysqlS> DELETE FROM mysql.ndb_apply_status;

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

shellS> ndb_restore -c slave_host:port -n node-id
                    \        -b backup-id -m -r dir

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

Для того, чтобы восстановить от основного кластера с четырьмя узлами данных (как показано в числе в Разделе 17.6, "MySQL Cluster Replication"), где файлы резервных копий были скопированы в каталог /var/BACKUPS/BACKUP-1, надлежащая последовательность команд, которые будут выполнены на ведомом устройстве, могла бы быть похожей на это:

shellS> ndb_restore -c rep-slave:1186 -n 2 -b 1 -m
                    \        -r ./var/BACKUPS/BACKUP-1shellS> ndb_restore -c
                    rep-slave:1186 -n 3 -b 1 \        -r
                    ./var/BACKUPS/BACKUP-1shellS> ndb_restore -c rep-slave:1186 -n 4 -b 1 \        -r ./var/BACKUPS/BACKUP-1shellS> ndb_restore -c
                    rep-slave:1186 -n 5 -b 1 -e \        -r
                    ./var/BACKUPS/BACKUP-1

Теперь Вы должны получить новую эпоху из ndb_apply_status таблица на ведомом устройстве (как обсуждено в Разделе 17.6.8, "Реализовывая Failover с MySQL Cluster Replication"):

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

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

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

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

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

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

Теперь, когда ведомое устройство "знает" от какой точка в который binlog файл, чтобы начать читать данные от ведущего устройства, можно заставить ведомое устройство начинать тиражироваться с этим стандартным оператором MySQL:

mysqlS> START SLAVE;