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

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

Рисунок 25.10 Макет репликации NDB Cluster-в-NDB Cluster

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

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

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

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