#Обновление MySQL 8.0 до 8.4

Начиная с v4.4.0, вы можете выполнить обновление на месте существующего кластера MGR MySQL 8.0 до MySQL 8.4 без пересоздания кластера и без миграции данных. Оператор выполняет поочередное, поузловое обновление: данные и членство Group Replication сохраняются, схема метаданных InnoDB Cluster автоматически обновляется, а кластер продолжает обслуживать трафик через MySQL Router во время поэтапного перезапуска.

Это обновление major-version. В отличие от patch-обновления, оно необратимо — запланируйте окно обслуживания и убедитесь, что перед началом у вас есть актуальная резервная копия.

#Предварительные требования

Перед началом обновления убедитесь, что выполнены все следующие условия:

1. Оператор обновлен до v4.4.0 или более поздней версии. Возможность обновления с 8.0 до 8.4 предоставляется оператором v4.4.0. Сначала обновите оператор Alauda Database Service for MySQL-MGR; существующие экземпляры 8.0 продолжат работать без изменений после обновления оператора.
2. Есть недавняя резервная копия. Поскольку major-обновление нельзя откатить, перед продолжением выполните полное резервное копирование экземпляра (или проверьте наличие недавней автоматической резервной копии). Если что-то пойдет не так, вы восстановите новый экземпляр из этой резервной копии.
3. Кластер находится в исправном состоянии. Все участники должны иметь статус ONLINE, а экземпляр должен находиться в состоянии Ready. Не начинайте обновление на деградировавшем кластере.
4. Каждый участник имеет не менее 2Gi памяти. Сервер 8.4 требует больше памяти при запуске, чем 8.0. Убедитесь, что лимит памяти каждого участника составляет ≥ 2Gi; при необходимости сначала увеличьте спецификацию экземпляра.
5. Рекомендуется топология single-primary. Обновление на месте проверено для кластеров single-primary.

#Процедура обновления

#Что происходит во время обновления

После запуска обновления оператор:

1. Выполняет предварительные проверки. Каждый участник проверяется на готовность к обновлению (аналог утилиты MySQL checkForServerUpgrade). Если участник находится в небезопасном состоянии согласованности репликации, оператор сначала приводит его в порядок, поэтому обновление безопасно даже при смешанном исходном состоянии. Обновление не продолжается, пока все предварительные проверки не будут успешно пройдены.

2. Обновляет участников по одному. Сначала обновляются вторичные участники; перед обновлением текущего primary его роль передается другому узлу (abdicated), поэтому active primary всегда остается доступным. MySQL Router продолжает направлять трафик на доступный primary для операций чтения и записи на протяжении всего процесса.

3. Обновляет метаданные InnoDB Cluster. Схема метаданных кластера автоматически обновляется до версии, требуемой 8.4.

4. Завершает работу. После того как каждый участник будет работать на 8.4, экземпляр отобразит новую версию и вернется в состояние Ready, а Group Replication полностью придет к согласованному состоянию.

#Проверка обновления

После завершения обновления убедитесь, что:

• состояние экземпляра — Ready, а отображаемая версия — 8.4.x;
• все участники Group Replication имеют статус ONLINE (3/3 для кластера из трех участников);
• подключения на чтение и запись через MySQL Router работают;
• данные приложения не повреждены.

#Устранение неполадок

• Кластер не возвращается в состояние Ready. Проверьте, что каждый участник соответствует требованию по памяти (≥ 2Gi) и что до обновления кластер находился в исправном состоянии. Проверьте события экземпляра и состояния участников.
• Нужно выполнить откат. Major-обновление нельзя отменить на месте. Восстановите резервную копию, созданную на этапе предварительных требований, в новый экземпляр, а затем перенаправьте на него ваше приложение.