Spec-Zone.ru › MySQL 8.4

25.7.9 Резервное копирование NDB Cluster с репликацией NDB Cluster

  • 25.7.9.1 Репликация NDB Cluster: Автоматизация синхронизации реплики с исходным бинарным журналом
  • 25.7.9.2 Восстановление в заданный момент времени с использованием репликации NDB Cluster

В этом разделе рассматривается создание резервных копий и восстановление из них с использованием репликации NDB Cluster. Предполагается, что серверы репликации уже настроены, как описано ранее (см. раздел 25.7.5 «Подготовка NDB Cluster для репликации» и последующие разделы). После этого процедура создания резервной копии и восстановления из неё следующая:

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

    • Метод A. Этот метод требует, чтобы процесс резервного копирования кластера был ранее включен на исходном сервере до запуска процесса репликации. Это можно сделать, включив следующую строку в раздел [mysql_cluster] в my.cnf file, где management_host — IP-адрес или имя хоста NDB сервера управления для исходного кластера, а port — номер порта сервера управления:

      ndb-connectstring=management_host[:port]
      
      Примечание

      Номер порта необходимо указывать только в том случае, если используется не стандартный порт (1186). Подробнее о портах и распределении портов в NDB Cluster см. в разделе 25.3.3 «Начальная настройка NDB Cluster».

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

      shellS> ndb_mgm -e "START BACKUP"
      
    • Метод B. Если файл my.cnf не указывает, где найти хост управления, вы можете запустить процесс резервного копирования, передав эту информацию клиенту управления NDB как часть команды START BACKUP. Это можно сделать, как показано здесь, где management_host и port — имя хоста и номер порта сервера управления:

      shellS> ndb_mgm management_host:port -e "START BACKUP"
      

      В нашем сценарии, как описано ранее (см. раздел 25.7.5 «Подготовка NDB Cluster для репликации»), это будет выполнено следующим образом:

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

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

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

    Важно

    Оператор CREATE DATABASE (или CREATE SCHEMA) соответствующий каждой базе данных, подлежащей репликации, должен быть выполнен на каждом узле SQL в кластере реплики.

  4. Сбросьте кластер реплики с помощью этого оператора в клиенте mysql:

    mysqlR> RESET REPLICA;
    
  5. Теперь вы можете начать процесс восстановления кластера на реплике, используя команду 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
    
    Важно

    Опция -e (или --restore-epoch) в последнем вызове ndb_restore в этом примере необходима, чтобы убедиться, что эпоха записывается в таблицу mysql.ndb_apply_status реплики. Без этой информации реплика не может должным образом синхронизироваться с источником. (См. раздел 25.5.23 «ndb_restore — Восстановление резервной копии NDB Cluster».)

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

    mysqlR> SELECT @latest:=MAX(epoch)
            FROM mysql.ndb_apply_status;
    
  7. Используя @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. В этом случае вы должны определить, какой это файл, и вручную указать имя на следующем шаге или обработать вывод с помощью скрипта.

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

    mysqlR> CHANGE REPLICATION SOURCE TO
         ->     SOURCE_LOG_FILE='@file',
         ->     SOURCE_LOG_POS=@pos;
    
  9. Теперь, когда реплика знает, с какой точки какого файла бинарного журнала начинать чтение данных с источника, вы можете заставить реплику начать репликацию с помощью этого оператора:

    mysqlR> START REPLICA;

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

Дополнительную информацию о выполнении резервного копирования кластера и восстановлении кластера из резервных копий см. в разделе 25.6.8 «Online Backup of NDB Cluster».

© 2025 Oracle
Licensed under the GPLv2 License.
https://docs.oracle.com/cd/E17952_01/mysql-8.4-en/mysql-cluster-replication-backups.html

Spec-Zone.ru

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