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

Потеря соединения между источником и репликой. Потеря соединения может произойти как между узлом SQL источника и узлом SQL реплики, так и между узлом SQL источника и узлами данных кластера источника. В последнем случае это может произойти не только из-за потери физического соединения (например, обрыва сетевого кабеля), но и из-за переполнения буферов событий узлов данных; если узел SQL слишком медленно отвечает, он может быть исключен из кластера (это в некоторой степени регулируется путем настройки параметров конфигурации MaxBufferedEpochs и TimeBetweenEpochs). Если это произойдет, весьма вероятно, что новые данные будут вставлены в кластер источника без записи в двоичный журнал узла SQL источника. По этой причине для обеспечения высокой доступности крайне важно поддерживать резервный канал репликации, отслеживать первичный канал и при необходимости переключаться на вторичный канал репликации, чтобы сохранить синхронизацию кластера реплики с источником. NDB Cluster не предназначен для выполнения такого мониторинга самостоятельно; для этого требуется внешнее приложение.

Узел SQL источника отправляет событие “пробел” при подключении или повторном подключении к кластеру источника. (Событие пробела — это тип “события инцидента”, которое указывает на инцидент, влияющий на содержимое базы данных, но который нельзя легко представить как набор изменений. Примеры инцидентов — сбои серверов, ресинхронизация базы данных, некоторые обновления программного обеспечения и некоторые изменения аппаратного обеспечения.) Когда реплика сталкивается с пробелом в журнале репликации, она останавливается с сообщением об ошибке. Это сообщение доступно в выводе SHOW SLAVE STATUS и указывает, что поток SQL остановился из-за инцидента, зарегистрированного в потоке репликации, и требуется ручное вмешательство. Более подробную информацию о том, что делать в таких ситуациях, см. в Разделе 21.7.8, «Реализация переключения на резервную копию с репликацией NDB Cluster».

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

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

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

Рисунок 21.13 Циклическая репликация NDB Cluster со всеми источниками как репликами

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

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

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

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

Репликация NDB Cluster и первичные ключи. В случае сбоя узла ошибки в репликации таблиц NDB без первичных ключей все еще могут возникнуть из-за возможности вставки дублирующих строк в таких случаях. По этой причине настоятельно рекомендуется, чтобы все таблицы NDB, которые реплицируются, имели явные первичные ключи.

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

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

Проблема, с которой можно столкнуться при репликации без отсрочки проверки уникальных обновлений ключей, может быть проиллюстрирована с помощью таблицы NDB, такой как t, которая создается и заполняется на источнике (и передается реплике, не поддерживающей отложенные обновления уникальных ключей), как показано здесь:

CREATE TABLE t (
    p INT PRIMARY KEY,
    c INT,
    UNIQUE KEY u (c)
)   ENGINE NDB;

INSERT INTO t
    VALUES (1,1), (2,2), (3,3), (4,4), (5,5);

Следующее оператор UPDATE в таблице t выполняется успешно на источнике, так как строки, на которые влияют изменения, обрабатываются в порядке, определяемом параметром ORDER BY, выполненном для всей таблицы:

UPDATE t SET c = c - 1 ORDER BY p;

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

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

Многопоточные реплики не поддерживаются. Кластер NDB не поддерживает многопоточные реплики. Это связано с тем, что реплика может не справиться с разделением транзакций, происходящих в одной базе данных от транзакций в другой, если они записаны в рамках одной эпохи. Кроме того, каждая транзакция, обрабатываемая хранилищем NDB, включает как минимум две базы данных — целевую базу данных и mysql системную базу данных — из-за необходимости обновления таблицы mysql.ndb_apply_status (см. Раздел 21.7.4, «Схема репликации и таблицы NDB Cluster»). Это, в свою очередь, нарушает требование о многопоточности, что транзакция специфична для данной базы данных.

До NDB 7.5.7 и NDB 7.6.3 установка любых системных переменных, относящихся к многопоточным рабам, таких как slave_parallel_workers и slave_checkpoint_group (или эквивалентные параметры запуска mysqld), полностью игнорировалась и не оказывала никакого влияния.

Начиная с NDB 7.5.7 и NDB 7.6.3, slave_parallel_workers всегда равно 0. Если при запуске оно устанавливается на любое другое значение, NDB изменяет его на 0 и записывает сообщение в файл журнала сервера mysqld.

Перезапуск с помощью --initial. Перезапуск кластера с параметром --initial приводит к тому, что последовательность номеров GCI и эпох начинается заново с 0. (Это, как правило, верно для NDB Cluster и не ограничивается сценариями репликации, включающими Cluster.) В этом случае необходимо перезапустить вовлеченные в репликацию серверы MySQL. После этого необходимо использовать операторы RESET MASTER и RESET SLAVE, чтобы очистить недействительные таблицы ndb_binlog_index и ndb_apply_status соответственно.

Репликация из NDB в другие хранилища данных. Можно скопировать таблицу NDB на источнике в таблицу с использованием другого хранилища данных на реплике, учитывая ограничения, указанные здесь:

Следующие несколько абзацев содержат дополнительную информацию о каждом из описанных выше вопросов.

Несколько источников не поддерживаются при репликации NDB в другие хранилища данных. Для репликации из NDB в другое хранилище данных отношение между двумя базами данных должно быть одно-к-одному. Это означает, что двунаправленная или циклическая репликация между NDB Cluster и другими хранилищами данных не поддерживается.

Кроме того, при репликации между NDB и другим хранилищем данных нельзя настроить более одного канала репликации. (База данных NDB Cluster может одновременно реплицировать данные в несколько баз данных NDB Cluster.) Если источник использует таблицы NDB, можно иметь более одного сервера MySQL, поддерживающего двоичный журнал всех изменений, но для изменения источников репликой (переключения на новый источник) новое отношение источник-реплика должно быть явно определено на реплике.

Репликация таблиц NDB в хранилище данных, которое не выполняет двоичное протоколирование. Если вы пытаетесь реплицировать данные из NDB Cluster на реплику, которая использует хранилище данных, которое не обрабатывает собственное двоичное протоколирование, процесс репликации прерывается с ошибкой Двоичное протоколирование невозможно... Операция не может быть записана атомарно, так как задействовано более одного движка, и по крайней мере один из движков выполняет самопротоколирование (ошибка 1595). Можно обойти эту проблему одним из следующих способов:

Репликация из NDB в нетранзакционное хранилище данных. При репликации из NDB в нетранзакционное хранилище данных, такое как MyISAM, могут возникнуть ненужные ошибки дублирования ключей при репликации операторов INSERT ... ON DUPLICATE KEY UPDATE. Их можно подавить, используя --ndb-log-update-as-write=0, что заставляет регистрировать обновления как записи, а не как обновления.

Правила фильтрации репликации и двоичного журнала при репликации между NDB Clusters. Если вы используете любые параметры --replicate-do-*, --replicate-ignore-*, --binlog-do-db или --binlog-ignore-db для фильтрации реплицируемых баз данных или таблиц, необходимо следить, чтобы не блокировать репликацию или двоичное протоколирование таблицы mysql.ndb_apply_status, что необходимо для правильной работы репликации между NDB Clusters. В частности, необходимо учитывать следующее:

Также следует помнить, что каждое правило репликации требует следующего:

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

Репликация NDB Cluster и IPv6. Хотя API NDB и MGM API (и, следовательно, узлы данных и управляющие узлы) не поддерживают IPv6 в NDB 7.5 и 7.6, MySQL серверы, в том числе действующие как узлы SQL в NDB Cluster, могут использовать IPv6 для связи с другими MySQL серверами. Это означает, что вы можете выполнять репликацию между NDB Clusters с использованием IPv6 для подключения исходного и реплики SQL-узлов, как показано пунктирной стрелкой на следующей диаграмме:

Рисунок 21.15 Репликация между SQL-узлами с использованием IPv6

Все соединения, исходящие изнутри NDB Cluster — представленные на предшествующей диаграмме сплошными стрелками — должны использовать IPv4. Другими словами, все узлы данных NDB Cluster, управляющие серверы и управляющие клиенты должны быть доступны друг другу через IPv4. Кроме того, узлы SQL должны использовать IPv4 для связи с кластером.

Поскольку в настоящее время нет поддержки IPv6 в API NDB и MGM, любые приложения, написанные с использованием этих API, также должны выполнять все соединения с использованием IPv4.

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

Дополнительную информацию о продвижении и понижении атрибутов в NDB Cluster см. в Репликация на основе строк: продвижение и понижение атрибутов.

NDB, в отличие от InnoDB или MyISAM, не записывает изменения виртуальных столбцов в двоичный журнал; однако, это не оказывает негативного влияния на репликацию NDB Cluster или репликацию между NDB и другими движками хранения. Изменения в хранимых сгенерированных столбцах регистрируются.