NDB Cluster поддерживает асинхронную репликацию, чаще всего называемую просто “репликацией”. В данном разделе объясняется, как настроить и управлять конфигурацией, в которой одна группа компьютеров, работающих как NDB Cluster, выполняет репликацию на другой компьютер или группу компьютеров. Предполагается, что читатель знаком со стандартной репликацией MySQL, описанной в других разделах данного руководства. (См. Главу 16, Репликация).

Нормальная (некластеризованная) репликация включает сервер-источник (ранее называемый “мастером”) и сервер-реплику (ранее называемый “следом”), источник так называется, потому что операции и данные, подлежащие репликации, исходят от него, а реплика — получатель этих данных. В NDB Cluster репликация концептуально очень похожа, но на практике может быть сложнее, поскольку она может быть расширена для покрытия ряда различных конфигураций, включая репликацию между двумя полными кластерами. Хотя сам NDB Cluster зависит от хранилища NDB для функциональности кластеризации, использование NDB в качестве хранилища для копий реплицируемых таблиц реплики необязательно (см. Репликация из NDB в другие хранилища). Однако для максимальной доступности можно (и желательно) осуществлять репликацию из одного NDB Cluster в другой, и именно этот сценарий мы рассматриваем, как показано на следующей схеме:

Рисунок 21.12 Схема репликации NDB Cluster-в-NDB Cluster

В этом сценарии процесс репликации заключается в записи и сохранении последовательных состояний исходного кластера в кластере реплики. Этот процесс выполняется специальной нитью, известной как нить инжектора двоичного журнала NDB, которая выполняется на каждом сервере MySQL и генерирует двоичный журнал (binlog). Эта нить гарантирует, что все изменения в кластере, генерирующем двоичный журнал, а не только те изменения, которые выполняются через сервер MySQL, вставляются в двоичный журнал с правильной последовательностью. Мы называем серверы MySQL источника и реплики серверами репликации или узлами репликации, а поток данных или линию связи между ними — каналом репликации.

Дополнительную информацию о выполнении восстановления состояния на определённый момент времени с использованием NDB Cluster и NDB Cluster Replication см. в Разделе 21.7.9.2, «Восстановление состояния на определённый момент времени с использованием NDB Cluster Replication».

Переменные состояния реплики API NDB. Счётчики API NDB могут обеспечить расширенные возможности мониторинга кластеров реплик. Эти счётчики реализованы как статистические данные NDB _slave, как показано в выводе SHOW STATUS, или в результатах запросов к SESSION_STATUS или GLOBAL_STATUS таблице в сеансе клиента mysql, подключенном к серверу MySQL, выполняющему роль реплики в NDB Cluster Replication. Сравнивая значения этих переменных состояния до и после выполнения инструкций, влияющих на реплицируемые NDB таблицы, вы можете наблюдать соответствующие действия, выполняемые на уровне API NDB репликой, что может быть полезно при мониторинге или устранении неполадок в NDB Cluster Replication. Дополнительную информацию см. в Разделе 21.6.14, «Счётчики и переменные статистики API NDB».

Репликация из NDB в таблицы, отличные от NDB. Возможна репликация NDB таблиц из NDB Cluster, действующего в качестве источника репликации, в таблицы, использующие другие хранилища MySQL, такие как InnoDB или MyISAM на сервере реплики mysqld. Это ограничено рядом условий; см. Репликация из NDB в другие хранилища и Репликация из NDB в хранилище без транзакций для получения дополнительной информации.