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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 25.17 Многоканальная репликация NDB Cluster с MySQL-серверами

MySQL-серверы, выполняющие роль реплик, должны запускаться с включенной системной переменной log_replica_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 REPLICATION SOURCE TO:

mysqlF> CHANGE REPLICATION SOURCE TO
     ->     SOURCE_HOST = 'serverC'
     ->     SOURCE_LOG_FILE='@file',
     ->     SOURCE_LOG_POS=@pos;

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

Оператор CHANGE REPLICATION SOURCE TO также поддерживает опцию IGNORE_SERVER_IDS, которая принимает список идентификаторов серверов, разделенных запятыми, и приводит к игнорированию событий, исходящих от соответствующих серверов. Дополнительная информация содержится в документации по этому оператору, а также в Раздел 15.7.7.35, «Оператор SHOW REPLICA STATUS». Информация о взаимодействии этой опции с переменной ndb_log_apply_status представлена в Раздел 25.7.8, «Реализация переключения на резервный источник с использованием NDB Cluster Replication».