20.7.8 Handling a Network Partition and Loss of Quorum — MySQL 8.4

20.7.8 Обработка сетевого разбиения и потери кворума

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

Кворум может быть потерян, когда происходит несколько непреднамеренных сбоев, что приводит к внезапному удалению большинства серверов из группы. Например, в группе из 5 серверов, если 3 из них одновременно станут неактивными, большинство окажется под угрозой, и поэтому кворум не может быть достигнут. Фактически, оставшиеся два сервера не могут определить, аварийно ли завершили работу остальные 3 сервера, или сетевое разбиение изолировало только этих двух, и поэтому группа не может быть автоматически переконфигурирована.

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

Примечание

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

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

В следующих разделах объясняется, что делать, если система разделена таким образом, что серверы в группе не могут автоматически достичь кворума.

Обнаружение разбиений

Таблица схемы производительности replication_group_members отображает состояние каждого сервера в текущем представлении с точки зрения этого сервера. Большинство времени система не сталкивается с разбиением, и поэтому таблица показывает информацию, которая согласована на всех серверах группы. Другими словами, состояние каждого сервера в этой таблице согласовано всеми в текущем представлении. Однако, если происходит сетевое разбиение и кворум теряется, то таблица показывает состояние UNREACHABLE для тех серверов, с которыми она не может связаться. Эта информация экспортируется локальным детектором сбоев, встроенным в Group Replication.

Рисунок 20.14 Потеря кворума

Five server instances, S1, S2, S3, S4, and S5, are deployed as an interconnected group, which is a stable group. When three of the servers, S3, S4, and S5, fail, the majority is lost and the group can no longer proceed without intervention.

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

Итак, предположим, что в группе есть эти 5 серверов:

Сервер s1 с идентификатором члена 199b2df7-4aaf-11e6-bb16-28b2bd168d07
Сервер s2 с идентификатором члена 199bb88e-4aaf-11e6-babe-28b2bd168d07
Сервер s3 с идентификатором члена 1999b9fb-4aaf-11e6-bb54-28b2bd168d07
Сервер s4 с идентификатором члена 19ab72fc-4aaf-11e6-bb51-28b2bd168d07
Сервер s5 с идентификатором члена 19b33846-4aaf-11e6-ba81-28b2bd168d07

Изначально группа работает нормально, и серверы успешно общаются друг с другом. Вы можете проверить это, войдя в s1 и просмотрев таблицу схемы производительности replication_group_members. Например:

mysql> SELECT MEMBER_ID,MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+-------------+
| MEMBER_ID                            | MEMBER_STATE | MEMBER_ROLE |
+--------------------------------------+--------------+-------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | ONLINE       | SECONDARY   |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       | PRIMARY     |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       | SECONDARY   |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | ONLINE       | SECONDARY   |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | ONLINE       | SECONDARY   |
+--------------------------------------+--------------+-------------+

Однако через некоторое время происходит катастрофический сбой, и серверы s3, s4 и s5 неожиданно останавливаются. Через несколько секунд, снова посмотрев на таблицу replication_group_members на s1, мы видим, что он все еще активен, но несколько других членов нет. Фактически, как видно ниже, они помечены как UNREACHABLE. Кроме того, система не смогла переконфигурировать себя для изменения членства, потому что большинство было потеряно.

mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE  |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE  |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE  |
+--------------------------------------+--------------+

Таблица показывает, что s1 теперь находится в группе, которая не может развиваться без внешнего вмешательства, потому что большинство серверов недоступны. В этом конкретном случае список членства группы необходимо сбросить, чтобы система могла продолжить работу, что описано в этом разделе. Кроме того, вы также можете остановить Group Replication на s1 и s2 (или полностью остановить s1 и s2), выяснить, что случилось с s3, s4 и s5, а затем перезапустить Group Replication (или серверы).

Разблокировка разбиения

Group replication позволяет сбросить список членства в группе, принудительно задав определенную конфигурацию. Например, в приведенном выше случае, когда s1 и s2 являются единственными активными серверами, вы можете выбрать принудительную конфигурацию членства, содержащую только s1 и s2. Это требует проверки некоторой информации о s1 и s2, а затем использования переменной group_replication_force_members.

Рисунок 20.15 Принудительное изменение членства

Three of the servers in a group, S3, S4, and S5, have failed, so the majority is lost and the group can no longer proceed without intervention. With the intervention described in the following text, S1 and S2 are able to form a stable group by themselves.

Предположим, что вы снова в ситуации, когда s1 и s2 — единственные оставшиеся серверы в группе. Серверы s3, s4 и s5 неожиданно покинули группу. Чтобы серверы s1 и s2 продолжили работу, вы хотите принудительно задать конфигурацию членства, содержащую только s1 и s2.

Предупреждение

Эта процедура использует group_replication_force_members и должна рассматриваться как крайняя мера. Она должна использоваться с большой осторожностью и только для перекрытия потери кворума. Неправильное использование может создать искусственную ситуацию «разделенного мозга» или полностью заблокировать систему.

При принудительном изменении конфигурации членства убедитесь, что все серверы, которые должны быть исключены из группы, действительно остановлены. В описанном выше сценарии, если s3, s4 и s5 не действительно недоступны, а вместо этого активны, они могут сформировать свою собственную функциональную группу (их 3 из 5, следовательно, они имеют большинство). В этом случае принудительная конфигурация списка членства с s1 и s2 может создать искусственную ситуацию «разделенного мозга». Поэтому перед принудительной переконфигурацией списка членства необходимо убедиться, что исключаемые серверы действительно выключены, а если нет, выключить их перед продолжением.

Предупреждение

Напомним, что система заблокирована, и текущая конфигурация следующая (как воспринимается локальным детектором сбоев на s1):

mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE  |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE  |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE  |
+--------------------------------------+--------------+

Первым делом необходимо проверить локальный адрес (идентификатор групповой связи) для s1 и s2. Войдите в s1 и s2 и получите эту информацию следующим образом.

mysql> SELECT @@group_replication_local_address;

После того как вы узнаете адреса групповой связи для s1 (127.0.0.1:10000) и s2 (127.0.0.1:10001), вы можете использовать их на одном из двух серверов для вставки новой конфигурации членства, тем самым перекрыв существующую конфигурацию, которая потеряла кворум. Для этого на s1:

mysql> SET GLOBAL group_replication_force_members="127.0.0.1:10000,127.0.0.1:10001";

Это разблокирует группу, принудительно задав другую конфигурацию. Проверьте таблицу replication_group_members на s1 и s2, чтобы проверить членство в группе после этого изменения. Сначала на s1.

mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE       |
| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE       |
+--------------------------------------+--------------+

Затем на s2.

mysql> SELECT * FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE       |
| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE       |
+--------------------------------------+--------------+

После того, как вы успешно применили системную переменную group_replication_force_members для принудительного изменения членства в группе и разблокировки группы, убедитесь, что вы очистили системную переменную. group_replication_force_members должна быть пустой, чтобы можно было выполнить оператор START GROUP_REPLICATION.