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

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

Чтобы применить уровень согласованности для текущего сеанса, используйте область сеанса, например:

> SET @@SESSION.group_replication_consistency= 'BEFORE';

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

> SET @@GLOBAL.group_replication_consistency= 'BEFORE';

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

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

Следует помнить, что все транзакции чтения/записи всегда упорядочены в Group Replication, поэтому даже когда вы устанавливаете уровень согласованности на AFTER для текущего сеанса, эта транзакция ожидает, пока ее изменения не будут применены ко всем членам, что означает ожидание этой и всех предыдущих транзакций, которые могут быть в очередях вторичных узлов. Другими словами, уровень согласованности AFTER ожидает всех транзакций до и включая эту.

Другой способ классификации уровней согласованности — с точки зрения влияния на группу, то есть последствий, которые уровни согласованности оказывают на других участников.

Уровень согласованности BEFORE, помимо упорядочения в потоке транзакций, влияет только на локального участника. То есть, он не требует координации с другими участниками и не оказывает последствий на их транзакции. Другими словами, BEFORE влияет только на транзакции, для которых он используется.

Уровни согласованности AFTER и BEFORE_AND_AFTER оказывают побочные эффекты на параллельные транзакции, выполняемые на других участниках. Эти уровни согласованности заставляют транзакции других участников ожидать, если транзакции с уровнем согласованности EVENTUAL начинаются, в то время как транзакция с уровнем AFTER или BEFORE_AND_AFTER уже выполняется. Другие участники ожидают, пока транзакция AFTER не будет подтверждена на этом участнике, даже если транзакции других участников имеют уровень согласованности EVENTUAL. Другими словами, AFTER и BEFORE_AND_AFTER влияют на все ONLINE участники группы.

Для дальнейшей иллюстрации представьте группу из 3 участников, M1, M2 и M3. На участнике M1 клиент выполняет:

> SET @@SESSION.group_replication_consistency= AFTER;
> BEGIN;
> INSERT INTO t1 VALUES (1);
> COMMIT;

Затем, пока вышеупомянутая транзакция применяется, на участнике M2 клиент выполняет:

> SET SESSION group_replication_consistency= EVENTUAL;

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

Вы можете использовать уровни согласованности BEFORE, AFTER и BEFORE_AND_AFTER только на ONLINE участниках. Попытка использовать их на участниках в других состояниях приводит к ошибке сеанса.

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

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

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

При включении и правильной настройке управления потоком в группе существует лишь небольшая вероятность временного чтения устаревших данных с недавно избранного первичного сервера сразу после продвижения, поскольку задержка не должна быть существенной, или если она есть, то она должна быть небольшой. Кроме того, у вас могут быть прокси-серверы или промежуточные слои, которые управляют доступом приложения к первичному серверу после продвижения и обеспечивают соблюдение критериев согласованности на этом уровне. Вы можете указать поведение нового первичного сервера после его продвижения, используя переменную group_replication_consistency, которая управляет тем, блокирует ли недавно избранный первичный сервер чтение и запись до тех пор, пока задержка не будет полностью применена. Если переменная group_replication_consistency была установлена в значение BEFORE_ON_PRIMARY_FAILOVER на недавно избранном первичном сервере, у которого есть задержка для применения, и транзакции направляются на новый первичный сервер, в то время как он все еще применяет задержку, входящие транзакции блокируются до тех пор, пока задержка не будет полностью применена. Это предотвращает следующие аномалии:

Подводя итог, когда group_replication_consistency установлено в значение BEFORE_ON_PRIMARY_FAILOVER, вы выбираете приоритет согласованности над доступностью, так как чтение и запись удерживаются всякий раз, когда выбирается новый первичный сервер. Это компромисс, который необходимо учитывать при настройке вашей группы. Также следует помнить, что если управление потоком работает правильно, задержка должна быть минимальной. Обратите внимание, что более высокие уровни согласованности BEFORE, AFTER и BEFORE_AND_AFTER также включают гарантии согласованности, предоставляемые BEFORE_ON_PRIMARY_FAILOVER.

Чтобы гарантировать, что группа обеспечивает один и тот же уровень согласованности независимо от того, какой участник продвинут до первичного, все участники группы должны иметь значение BEFORE_ON_PRIMARY_FAILOVER (или более высокий уровень согласованности), сохраненное в их конфигурации. Например, на каждом участнике выполните:

> SET PERSIST group_replication_consistency='BEFORE_ON_PRIMARY_FAILOVER';

Это гарантирует, что участники будут вести себя одинаково и что конфигурация сохранится после перезапуска участника.

Транзакция не может находиться в ожидании вечно, и если время ожидания превышает значение wait_timeout, возвращается ошибка ER_GR_HOLD_WAIT_TIMEOUT.

Хотя все записи удерживаются при использовании уровня согласованности BEFORE_ON_PRIMARY_FAILOVER, не все чтения блокируются, чтобы вы могли просмотреть сервер, в то время как он применяет задержку после продвижения. Это полезно для отладки, мониторинга, наблюдаемости и устранения неполадок. Некоторые запросы, не изменяющие данные, разрешены, такие как следующие: