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

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

Тем временем, сервер, присоединяющийся к группе, выбирает донора из списка активных серверов, как указано службой членства через абстракцию представления. Участник присоединяется к представлению 4, и активные участники записывают событие изменения представления в двоичный журнал.

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

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

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

Когда сервер, присоединяющийся к группе, распознаёт событие журнала изменения представления с ожидаемым идентификатором представления, соединение с донором закрывается, и он начинает применять кешированные транзакции. Важно понять процедуру окончательного восстановления. Несмотря на то, что он действует как маркер в двоичном журнале, разделяя изменения представлений, событие журнала изменения представления также играет другую роль. Оно передаёт информацию о сертификации, как она воспринимается всеми серверами при вступлении присоединяющегося сервера в группу, другими словами, последнее изменение представления. Без него присоединяющийся сервер не имел бы необходимой информации для сертификации (обнаружения конфликтов) последующих транзакций.

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

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