25.7.2 Общие требования к репликации NDB Cluster
Для канала репликации требуются два сервера MySQL, действующие как серверы репликации (по одному для источника и реплики). Например, в случае настройки репликации с двумя каналами репликации (для предоставления дополнительного канала резервирования) должно быть всего четыре узла репликации, по два на кластер.
Репликация NDB Cluster, как описано в этом разделе и последующих, зависит от репликации на основе строк. Это означает, что исходный сервер MySQL репликации должен работать с --binlog-format=ROW или --binlog-format=MIXED, как описано в разделе 25.7.6 «Запуск репликации NDB Cluster (один канал репликации)». Дополнительную информацию о репликации на основе строк см. в разделе 19.2.1 «Форматы репликации».
Если вы попытаетесь использовать репликацию NDB Cluster с --binlog-format=STATEMENT, репликация не будет работать должным образом, потому что таблица ndb_binlog_index на исходном кластере и столбец epoch таблицы ndb_apply_status на кластере реплики не обновляются (см. раздел 25.7.4 «Схема и таблицы репликации NDB Cluster»). Вместо этого обновления на сервере MySQL, выступающем в роли источника репликации, распространяются на реплику, и обновления от других узлов SQL в исходном кластере не реплицируются.
Значение по умолчанию для параметра --binlog-format равно MIXED.
Каждый сервер MySQL, используемый для репликации в любом из кластеров, должен быть уникально идентифицирован среди всех серверов MySQL репликации, участвующих в любом из кластеров (у вас не может быть серверов репликации как в исходном, так и в реплицированном кластере с одинаковым идентификатором). Это можно сделать, запустив каждый узел SQL с параметром --server-id=, где idid — уникальное целое число. Хотя это не строго необходимо, мы предположим для целей этого обсуждения, что все двоичные файлы NDB Cluster имеют одинаковую версию выпуска.
В MySQL Replication в целом оба сервера MySQL (mysqld процессы), участвующие в процессе, должны быть совместимы друг с другом по версии используемого протокола репликации и поддерживаемым наборам функций SQL (см. раздел 19.5.2 «Совместимость репликации между версиями MySQL»). Именно из-за таких различий между двоичными файлами в распределениях NDB Cluster и MySQL Server 9.2 репликация NDB Cluster имеет дополнительное требование о том, что оба mysqld двоичных файла должны быть из дистрибутива NDB Cluster. Самый простой и легкий способ гарантировать совместимость серверов mysqld — использовать один и тот же дистрибутив NDB Cluster для всех исходных и реплицируемых mysqld двоичных файлов.
Мы предполагаем, что сервер или кластер реплики предназначен только для репликации исходного кластера и что на нем не хранится другая информация.
Все NDB таблицы, подлежащие репликации, должны быть созданы с помощью сервера и клиента MySQL. Таблицы и другие объекты базы данных, созданные с использованием API NDB (например, ), не видны серверу MySQL и поэтому не реплицируются. Обновления приложений API NDB в существующих таблицах, созданных с помощью сервера MySQL, могут быть реплицированы.
Возможна репликация NDB Cluster с использованием репликации на основе инструкций. Однако в этом случае действуют следующие ограничения:
Все обновления строк данных в кластере в качестве источника должны направляться на один сервер MySQL.
Невозможно реплицировать кластер с использованием нескольких одновременных процессов репликации MySQL.
Реплицируются только изменения, сделанные на уровне SQL.
Кроме того, существуют другие ограничения, связанные с репликацией на основе инструкций по сравнению с репликацией на основе строк; см. раздел 19.2.1.1 «Преимущества и недостатки репликации на основе инструкций и строк» для получения более подробной информации о различиях между двумя форматами репликации.
© 2025 Oracle
Licensed under the GPLv2 License.