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

Этот метод хорошо подходит для групп с одним первичным сервером. Когда группа работает в режиме с одним первичным сервером, если вам необходимо, чтобы первичный сервер оставался тем же самым на протяжении всего процесса (кроме случаев, когда он сам обновляется), он должен быть последним членом, который будет обновлён. Первичный сервер не может оставаться первичным, если он не работает с самой низкой версией MySQL Server в группе. После обновления первичного сервера вы можете использовать функцию group_replication_set_as_primary(), чтобы снова назначить его первичным. Если вам всё равно, какой член является первичным, члены могут быть обновлены в любом порядке. Группа выбирает новый первичный сервер при необходимости из членов, работающих с самой низкой версией MySQL Server, следуя принципам выбора, описанным в разделе 20.1.3.1 «Режим с одним первичным сервером».

Для групп, работающих в режиме с несколькими первичными серверами, во время поэтапного обновления внутри группы количество первичных серверов уменьшается, что приводит к снижению доступности для записи. Это связано с тем, что если член присоединяется к группе, когда он работает с более новой версией MySQL Server, чем самая низкая версия, на которой работают существующие члены группы, он автоматически переходит в режим только чтения (super_read_only=ON).

Для получения полной информации о совместимости версий в группе и о том, как это влияет на поведение группы во время процесса обновления, см. раздел 20.8.1 «Комбинирование различных версий членов в группе».

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

Так как группа со старой версией остаётся онлайн во время обновления членов, группе с новой версией необходимо «догнать» любые транзакции, выполненные во время обновления членов. Поэтому один из серверов в новой группе настроен как реплика первичного сервера из старой группы. Это гарантирует, что новая группа «догонит» старую группу. Поскольку этот метод полагается на асинхронный канал репликации, который используется для репликации данных из одной группы в другую, он поддерживается при тех же предположениях и требованиях, что и асинхронная репликация источник-реплика, см. главу 19 «Репликация». Для групп, работающих в режиме с одним первичным сервером, асинхронное соединение репликации со старой группой должно отправлять данные на первичный сервер в новой группе; для групп с несколькими первичными серверами асинхронный канал репликации может подключиться к любому первичному серверу.

Процесс следующий:

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

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

Поскольку группа со старой версией находится в режиме онлайн во время развертывания членов в новой группе, группе с новой версией необходимо «догнать» любые транзакции, выполненные во время развертывания членов. Поэтому один из серверов в новой группе настроен как реплика первичного сервера из старой группы. Это гарантирует, что новая группа «догонит» старую группу. Поскольку этот метод полагается на асинхронный канал репликации, который используется для репликации данных из одной группы в другую, он поддерживается при тех же предположениях и требованиях, что и асинхронная репликация источник-реплика, см. главу 19 «Репликация». Для групп, работающих в режиме с одним первичным сервером, асинхронное соединение репликации со старой группой должно отправлять данные на первичный сервер в новой группе; для групп с несколькими первичными серверами асинхронный канал репликации может подключиться к любому первичному серверу.

Процесс следующий:

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