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-источник и 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. Сравнивая значения этих переменных состояния до и после выполнения операторов, влияющих на реплицированные NDB таблицы, вы можете наблюдать соответствующие действия, выполняемые на уровне API NDB репликой, что может быть полезно при мониторинге или устранении неполадок в репликации NDB Cluster. Раздел 25.6.16 «Счетчики и переменные статистики API NDB» содержит дополнительную информацию.

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