20.1.3.2 Multi-Primary Mode — MySQL 9.2

20.1.3.2 Режим с несколькими первичными узлами

В режиме с несколькими первичными узлами (group_replication_single_primary_mode=OFF) ни один узел не имеет специальной роли. Любой совместимый с другими узлами группы узел устанавливается в режим чтения/записи при присоединении к группе и может обрабатывать транзакции записи, даже если они выполняются одновременно.

Если узел перестаёт принимать транзакции записи, например, в случае неожиданного выхода из строя сервера, клиенты, подключенные к нему, могут быть перенаправлены или переключены на любой другой узел, находящийся в режиме чтения/записи. Group Replication сам по себе не обрабатывает переключение клиентов, поэтому вам необходимо организовать это с помощью фреймворка middleware, такого как, прокси, коннектора или самого приложения. Рисунок 20.5, «Переключение клиента» демонстрирует, как клиенты могут повторно подключиться к альтернативному узлу группы, если узел покидает группу.

Рисунок 20.5 Переключение клиента

Five server instances, S1, S2, S3, S4, and S5, are deployed as an interconnected group. All of the servers are primaries. Write clients are communicating with servers S1 and S2, and a read client is communicating with server S4. Server S1 then fails, breaking communication with its write client. This client reconnects to server S3.

Group Replication — это система с конечной согласованностью. Это означает, что как только входящий трафик замедлится или прекратится, все узлы группы будут иметь одинаковое содержимое данных. Пока трафик течёт, транзакции могут быть завершены на некоторых узлах раньше, чем на других, особенно если у некоторых узлов пропускная способность записи ниже, чем у других, что создаёт возможность получения устаревших данных. В режиме с несколькими первичными узлами более медленные узлы также могут накапливать избыточный задел транзакций для сертификации и применения, что приводит к большему риску конфликтов и сбоев сертификации. Чтобы ограничить эти проблемы, вы можете активировать и настроить механизм управления потоком Group Replication, чтобы свести к минимуму разницу между быстрыми и медленными узлами. Дополнительную информацию о управлении потоком см. в разделе 20.7.2, «Управление потоком».

Если вы хотите гарантировать согласованность транзакций для каждой транзакции в группе, вы можете сделать это, используя системную переменную group_replication_consistency. Вы можете выбрать настройку, соответствующую рабочей нагрузке вашей группы и вашим приоритетам чтения и записи данных, учитывая влияние на производительность синхронизации, необходимой для повышения согласованности. Вы также можете установить системную переменную для отдельных сеансов, чтобы защитить особенно чувствительные к одновременным операциям транзакции. Дополнительную информацию о согласованности транзакций см. в разделе 20.5.3, «Гарантии согласованности транзакций».

20.1.3.2.1 Проверка транзакций

При развертывании группы в режиме с несколькими первичными узлами транзакции проверяются на совместимость с режимом. При развертывании Group Replication в режиме с несколькими первичными узлами выполняются следующие строгие проверки согласованности:

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

Проверки управляются системной переменной group_replication_enforce_update_everywhere_checks. В режиме с несколькими первичными узлами системная переменная должна быть обычно установлена в ON, но проверки могут быть необязательно отключены, установив системную переменную в OFF. При развертывании в режиме с одним первичным узлом системная переменная должна быть установлена в OFF.

20.1.3.2.2 Определения данных

В топологии Group Replication в режиме с несколькими первичными узлами следует соблюдать осторожность при выполнении операторов определения данных, также известных как операторы языка определения данных (DDL).

MySQL 9.2 поддерживает атомарные операторы языка определения данных (DDL), в которых весь оператор DDL либо подтверждается, либо отменяется как единая атомарная транзакция. Операторы DDL, атомарные или нет, неявным образом завершают любую активную транзакцию в текущей сессии, как если бы вы выполнили COMMIT перед выполнением оператора. Это означает, что операторы DDL не могут выполняться в рамках другой транзакции, в операторах управления транзакциями, таких как START TRANSACTION ... COMMIT, или объединяться с другими операторами в рамках одной транзакции.

Group Replication основана на оптимистичной парадигме репликации, где операторы оптимистически выполняются, а затем отменяются при необходимости. Каждый сервер выполняется без предварительного обеспечения согласия группы. Поэтому при репликации операторов DDL в режиме с несколькими первичными узлами требуется больше осторожности. Если вы вносите изменения в схему (с помощью DDL) и изменения в данные, которые содержит объект (с помощью DML), для одного объекта, эти изменения должны обрабатываться через один и тот же сервер, пока операция со схемой ещё не завершена и не реплицирована на все узлы. Отсутствие этого может привести к несогласованности данных при прерывании или неполном завершении операций. Если группа развернута в режиме с одним первичным узлом, эта проблема не возникает, так как все изменения выполняются через один сервер, первичный.

Дополнительную информацию об атомарной поддержке DDL см. в разделе 15.1.1, «Atomic Data Definition Statement Support».

20.1.3.2.3 Совместимость версий

Для оптимальной совместимости и производительности все узлы группы должны работать с одной версией MySQL Server и, следовательно, Group Replication. В режиме с несколькими первичными узлами это ещё более важно, поскольку все узлы обычно присоединяются к группе в режиме чтения/записи. Если группа включает узлы, работающие с более чем одной версией MySQL Server, существует возможность несовместимости некоторых узлов с другими, поскольку они поддерживают функции, которые другие не поддерживают, или отсутствуют функции, которые есть у других. Для защиты от этого, когда новый узел присоединяется (включая бывший узел, который был обновлён и перезапущен), узел выполняет проверки совместимости с остальной частью группы.

Один из результатов этих проверок совместимости особенно важен в режиме с несколькими первичными узлами. Если присоединяющийся узел работает с более новой версией MySQL Server, чем самая старая версия, на которой работают существующие узлы группы, он присоединяется к группе, но остаётся в режиме только чтения. (В группе, работающей в режиме с одним первичным узлом, новые узлы по умолчанию остаются в режиме только чтения.) Узлы учитывают версию MySQL (и, следовательно, плагина Group Replication) в формате major.minor.release при проверке совместимости.

В группе, работающей в режиме с несколькими первичными узлами с узлами, использующими разные версии MySQL Server, Group Replication автоматически управляет их статусом чтения/записи и только чтения. Если узел покидает группу, узлы, работающие с версией, которая теперь является самой старой, автоматически переключаются в режим чтения/записи. При изменении группы, работавшей в режиме с одним первичным узлом, на работу в режиме с несколькими первичными узлами с помощью функции group_replication_switch_to_multi_primary_mode(), Group Replication автоматически устанавливает узлы в правильный режим. Узлы автоматически переходят в режим только чтения, если они работают с более новой версией MySQL Server, чем самая старая версия в группе, и узлы, работающие с самой старой версией, переходят в режим чтения/записи.

Для получения полной информации о совместимости версий в группе и о том, как это влияет на поведение группы во время процесса обновления, см. раздел 20.8.1, «Объединение разных версий узлов в группе».