В MySQL Group Replication набор серверов образует группу репликации. У группы есть имя, которое имеет вид UUID. Группа динамична, и серверы могут в любое время покидать (добровольно или нет) и присоединяться к ней. Группа корректирует себя при присоединении или уходе серверов.

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

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

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

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

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

Для предотвращения такой возможности MySQL Group Replication проверяет ситуацию, когда новая инкарнация того же сервера пытается присоединиться к группе, в то время как его старая инкарнация (с тем же адресом и номером порта) все еще указана как член. Новая инкарнация блокируется от присоединения к группе до тех пор, пока старая инкарнация не будет удалена посредством переконфигурации. Обратите внимание, что если переменная системы group_replication_member_expel_timeout добавила период ожидания, чтобы предоставить дополнительное время членам для повторного подключения к группе до их исключения, член, находящийся под подозрением, может снова стать активным в группе в качестве своей текущей инкарнации, если он подключится к группе до истечения срока подозрения. Если член превышает тайм-аут исключения и будет исключен из группы, или если Group Replication будет остановлена на сервере с помощью оператора STOP GROUP_REPLICATION или произойдёт сбой сервера, он должен присоединиться как новая инкарнация.