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

Этот метод хорошо подходит для групп с одним первичным сервером. Если группа работает в режиме с одним первичным сервером, и вам нужно, чтобы первичный сервер оставался неизменным на протяжении всего процесса (кроме случаев, когда он сам обновляется), он должен быть последним членом, который будет обновлён. Первичный сервер не может оставаться первичным, если он не работает с самой низкой версией 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, Репликация. Для групп, работающих в режиме с одним первичным сервером, асинхронное соединение репликации со старой группой должно отправлять данные первичному серверу в новой группе; для группы с несколькими первичными серверами асинхронный канал репликации может подключаться к любому первичному серверу.

Процесс состоит из следующих этапов:

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