17.6.2. Общие Требования для MySQL Cluster Replication

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

Репликация MySQL Cluster как описано в этом разделе и тех следующее зависит от построчной репликации. Это означает, что ведущий сервер MySQL репликации должен работать с --binlog-format=ROW или --binlog-format=MIXED, как описано в Разделе 17.6.6, "Репликация Кластера MySQL Starting (Единственный Канал Репликации)". Для получения общей информации о построчной репликации, см. Раздел 16.1.2, "Форматы Репликации".

Важный

Если Вы пытаетесь использовать MySQL Cluster Replication с --binlog-format=STATEMENT, репликация не в состоянии работать должным образом потому что ndb_binlog_index таблица на ведущем устройстве и epoch столбец ndb_apply_status таблица на ведомом устройстве не обновляется (см. Раздел 17.6.4, "MySQL Cluster Replication Schema и Tables"). Вместо этого только обновляет на сервере MySQL, действующем, поскольку ведущее устройство репликации распространяет к ведомому устройству, и никакие обновления от любых других узлов SQL на основном кластере не тиражируются.

Значение по умолчанию для --binlog-format опция в MySQL Cluster NDB 7.3 MIXED.

Каждый сервер MySQL, используемый для репликации в любом кластере, должен быть однозначно определен среди всех серверов репликации MySQL, участвующих в любом кластере (у Вас не может быть серверов репликации и на основных и на ведомых кластерах, совместно использующих тот же самый ID). Это может быть сделано, запуская каждый узел SQL, используя --server-id=id опция, где id уникальное целое число. Хотя это не строго необходимо, мы предположим в целях этого обсуждения, что все двоичные файлы MySQL Cluster имеют ту же самую версию выпуска.

Это - обычно истина в MySQL Replication, что оба сервера MySQL (mysqld процессы) включенный должны быть совместимыми друг с другом и относительно версии используемого протокола репликации и относительно наборов функций SQL, которые они поддерживают (см. Раздел 16.4.2, "Версии MySQL Replication Compatibility Between"). Это происходит из-за таких различий между двоичными файлами в MySQL Cluster и MySQL Server 5.6 дистрибутивов, что у MySQL Cluster Replication есть дополнительное требование что оба mysqld двоичные файлы, прибывшие от распределения MySQL Cluster. Самый простой и самый легкий способ гарантировать, что mysqld серверы являются совместимыми, состоит в том, чтобы использовать то же самое распределение MySQL Cluster для всего ведущего устройства и ведомого устройства mysqld двоичные файлы.

Мы предполагаем, что ведомый сервер или кластер выделяются репликации ведущего устройства, и что никакие другие данные не хранятся на этом.

Отметить

Возможно тиражировать MySQL Cluster, используя основанную на операторе репликацию. Однако, в этом случае, следующие ограничения применяются:

Все обновления к строкам данных на кластере, действующем как ведущее устройство, должны быть направлены к единственному серверу MySQL.
Не возможно тиражировать кластер, используя многократные одновременные процессы репликации MySQL.
Только изменения, произведенные на уровне SQL, тиражируются.

Они в дополнение к другим ограничениям основанной на операторе репликации в противоположность построчной репликации; см. Раздел 16.1.2.1, "Преимущества и Недостатки Основанной на операторе и Построчной репликации", для более определенной информации относительно различий между двумя форматами репликации.