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

Вы можете выбрать область, для которой применяется уровень согласованности, задав 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, не все чтения блокируются, чтобы вы могли продолжать проверять сервер, пока он применяет отставание после продвижения. Это полезно для отладки, мониторинга, наблюдаемости и устранения неполадок.

Разрешены некоторые запросы, которые не изменяют данные, например: