Возможно использование NDB Cluster для двунаправленной репликации между двумя кластерами, а также для циклической репликации между любым количеством кластеров.

Пример циклической репликации. В следующих абзацах мы рассмотрим пример конфигурации репликации, включающей три кластера NDB, обозначенных как 1, 2 и 3, в котором кластер 1 выступает в роли источника репликации для кластера 2, кластер 2 — для кластера 3, а кластер 3 — для кластера 1. Каждый кластер имеет два узла SQL, при этом узлы SQL A и B принадлежат кластеру 1, узлы SQL C и D — кластеру 2, а узлы SQL E и F — кластеру 3.

Циклическая репликация с использованием этих кластеров поддерживается при соблюдении следующих условий:

Данная конфигурация циклической репликации показана на следующей диаграмме:

Рисунок 21.17 Циклическая репликация NDB Cluster, где все источники являются репликами

В этом сценарии узел SQL A в кластере 1 реплицирует данные на узел SQL C в кластере 2; узел SQL C реплицирует данные на узел SQL E в кластере 3; узел SQL E реплицирует данные на узел SQL A. Другими словами, линия репликации (показанная изогнутыми стрелками на диаграмме) напрямую соединяет все узлы SQL, используемые в качестве источников и реплик репликации.

Также возможно настроить циклическую репликацию таким образом, что не все узлы SQL-источники являются также репликами, как показано здесь:

Рисунок 21.18 Циклическая репликация NDB Cluster, где не все источники являются репликами

В этом случае разные узлы SQL в каждом кластере используются в качестве источников и реплик репликации. Необходимо не запускать ни один из узлов SQL с включенной системной переменной log_slave_updates. Такая схема циклической репликации для NDB Cluster, в которой линия репликации (снова обозначенная изогнутыми стрелками на диаграмме) является прерывистой, должна быть возможна, но следует отметить, что она еще не была полностью протестирована и поэтому по-прежнему рассматривается как экспериментальная.

Использование резервного копирования и восстановления NDB для инициализации кластера реплик. При настройке циклической репликации можно инициализировать кластер реплик, используя команду управления клиентом START BACKUP в одном кластере NDB для создания резервной копии, а затем применение этой резервной копии в другом кластере NDB с помощью команды ndb_restore. Это не автоматически создаёт бинарные журналы на узле SQL второго кластера NDB, выступающего в качестве реплики; для создания бинарных журналов необходимо выполнить операцию SHOW TABLES на этом узле SQL; это следует сделать до запуска команды START SLAVE. Это известная проблема.

Пример масштабируемого аварийного переключения. В этом разделе обсуждается аварийное переключение в настройке репликации NDB Cluster с несколькими источниками с тремя кластерами NDB, имеющими идентификаторы серверов 1, 2 и 3. В этом сценарии кластер 1 реплицирует данные в кластеры 2 и 3; кластер 2 также реплицирует данные в кластер 3. Это отношение показано здесь:

Рисунок 21.19 Репликация NDB Cluster с несколькими мастерами с 3 источниками

Другими словами, данные реплицируются из кластера 1 в кластер 3 по двум различным путям: напрямую и через кластер 2.

Не все серверы MySQL, участвующие в репликации с несколькими источниками, должны выступать в роли и источника, и реплики, и определённый кластер NDB может использовать разные узлы SQL для различных каналов репликации. Такой случай показан здесь:

Рисунок 21.20 Репликация NDB Cluster с несколькими источниками, с серверами MySQL

Серверы MySQL, выступающие в роли реплик, должны быть запущены с включённой системной переменной log_slave_updates. Процессы mysqld, которые требуют этого параметра, также показаны на предыдущей диаграмме.

Необходимость в аварийном переключении возникает, когда один из реплицируемых кластеров выходит из строя. В этом примере мы рассмотрим случай, когда кластер 1 теряет доступность, и кластер 3 теряет два источника обновлений из кластера 1. Поскольку репликация между кластерами NDB асинхронна, нет гарантии, что обновления кластера 3, полученные напрямую из кластера 1, будут более свежими, чем те, которые получены через кластер 2. Это можно решить, обеспечив, чтобы кластер 3 догнал кластер 2 по обновлениям из кластера 1. С точки зрения серверов MySQL это означает, что необходимо реплицировать любые ожидающие обновления с сервера MySQL C на сервер F.

На сервере C выполните следующие запросы:

mysqlC> SELECT @latest:=MAX(epoch)
     ->     FROM mysql.ndb_apply_status
     ->     WHERE server_id=1;

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

Перепишите значения @file и @pos вручную с сервера C на сервер F (или выполните эквивалентную операцию через ваше приложение). Затем на сервере F выполните следующий запрос CHANGE MASTER TO:

mysqlF> CHANGE MASTER TO
     ->     MASTER_HOST = 'serverC'
     ->     MASTER_LOG_FILE='@file',
     ->     MASTER_LOG_POS=@pos;

После этого можно выполнить запрос START SLAVE на сервере MySQL F; это заставит все отсутствующие обновления, исходящие от сервера B, быть реплицированы на сервер F.

Запрос CHANGE MASTER TO также поддерживает опцию IGNORE_SERVER_IDS, которая принимает список идентификаторов серверов, разделённых запятыми, и игнорирует события, исходящие с этих серверов. Дополнительная информация приведена в Разделе 13.4.2.1, «Запрос CHANGE MASTER TO» и Разделе 13.7.5.34, «Запрос SHOW SLAVE STATUS». Сведения о взаимодействии данной опции с переменной ndb_log_apply_status смотрите в Разделе 21.7.8, «Реализация аварийного переключения с помощью репликации NDB Cluster».