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

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

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

Циклическая репликация. NDB Cluster Replication поддерживает циклическую репликацию, как показано в следующем примере. Настройка репликации включает три 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.

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

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

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

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

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

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

В этом случае в качестве источников и реплик используются разные узлы SQL в каждом кластере. Однако необходимо не запускать ни один из узлов SQL с включенной системной переменной log_replica_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.

Перезапуск с помощью --initial. Перезапуск кластера с опцией --initial приводит к тому, что последовательность номеров GCI и эпох начинается заново с 0. (Это обычно верно для NDB Cluster и не ограничивается сценариями репликации, включающими кластер.) В этом случае необходимо перезапустить серверы MySQL, участвующие в репликации. После этого следует использовать команды RESET BINARY LOGS AND GTIDS и RESET REPLICA для очистки недействительных таблиц 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 и шифрование файловой системы (TDE). Использование зашифрованной файловой системы не оказывает влияния на NDB Replication. Поддерживаются все следующие сценарии:

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

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

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

Репликация кластера NDB и IPv6. Все типы узлов кластера NDB поддерживают IPv6 в NDB 9.2; это включает узлы управления, узлы данных и узлы API или SQL.

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

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

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