Этот раздел обсуждает известные проблемы или проблемы при использовании репликации с MySQL Cluster NDB 7.3.

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

Ведущее устройство репликации выпускает событие "разрыва", соединяясь или повторно соединяясь с основным кластером. (Событие разрыва является типом "инцидентного события,", который указывает на инцидентное, которое происходит, который влияет на содержание базы данных, но это не может легко быть представлено как ряд изменений. Примерами инцидентов являются катастрофические отказы сервера, пересинхронизация базы данных, (немного) обновления программного обеспечения, и (немного) аппаратные изменения.), Когда ведомое устройство встречается с разрывом в журнале репликации, оно останавливается с сообщением об ошибке. Это сообщение доступно в выводе SHOW SLAVE STATUS, и указывает, что поток SQL остановился из-за инцидентного, зарегистрированного в потоке репликации, и что ручное вмешательство требуется. См. Раздел 17.6.8, "Реализовывая Failover с MySQL Cluster Replication,", для получения дополнительной информации о том, что сделать при таких обстоятельствах.

Круговая репликация. MySQL Cluster Replication поддерживает круговую репликацию, как показано в следующем примере. Установка репликации включает три MySQL Clusters, пронумерованные 1, 2, и 3, в который Кластер 1 действие как ведущее устройство репликации для Кластера 2, Кластер 2 действия как ведущее устройство для Кластера 3, и Кластера 3 действия как ведущее устройство для Кластера 1, таким образом завершая круг. У каждого MySQL Cluster есть два узла SQL, с узлами SQL A и B, принадлежащий Кластеру 1, узлы SQL C и D, принадлежащий Кластеру 2, и узлы SQL E и F, принадлежащий Кластеру 3.

Круговая репликация, используя эти кластеры поддерживается, пока следующие условия встречаются:

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

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

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

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

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

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

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

Проблема встречалась, когда тиражирование без задержанной проверки обновлений уникального ключа может быть иллюстрировано, используя 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;

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

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

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

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

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

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

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

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

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

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

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

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

MySQL Cluster Replication и IPv6. В настоящий момент API NDB и API MGM не поддерживают IPv6. Однако, MySQL Servers — включая тех, которые действуют как узлы SQL в MySQL Cluster — может использовать IPv6, чтобы связаться с другим MySQL Servers. Это означает, что можно тиражироваться между MySQL Clusters, используя IPv6, чтобы соединить основные и ведомые узлы SQL как показано точечной стрелкой в следующей схеме:

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

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

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

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