20.1.3.2 Multi-Primary Mode — MySQL 8.4

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 8.4 поддерживает атомарные операторы языка определения данных (DDL), где весь оператор DDL либо фиксируется, либо отменяется как одна атомарная транзакция. Операторы DDL, атомарные или нет, неявно завершают любую активную транзакцию в текущей сессии, как если бы вы выполнили COMMIT перед выполнением оператора. Это означает, что операторы DDL не могут выполняться в рамках другой транзакции, в операторах управления транзакциями, таких как START TRANSACTION ... COMMIT, или комбинироваться с другими операторами в рамках одной транзакции.

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

Более подробную информацию о поддержке атомарных операторов DDL см. в разделе 15.1.1, «Поддержка атомарных операторов DDL».

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

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

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

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

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