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

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

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

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

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

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

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

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