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

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

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

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

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