17.5.3 Network Partitioning — MySQL 5.7

17.5.3 Разбиение сети

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

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

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

Примечание

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

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

Подсказка

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

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

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

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

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.

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

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 и должна рассматриваться как крайняя мера. Она должна использоваться с особой осторожностью и только для устранения потери кворума. При неправильном использовании она может создать искусственную ситуацию «разделенного мозга» или заблокировать всю систему.

Вспомните, что система заблокирована, и текущая конфигурация следующая (как воспринимается локальным детектором отказов на 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       |
+--------------------------------------+--------------+

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

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