#Обновление

Alauda Database Service for MySQL-MGR будет выполнять обновления на основе настроенной стратегии обновления:

• Automatic: автоматические обновления запускаются немедленно при обнаружении новых версий компонентов.
• Manual: требуется ручное подтверждение перед запуском процесса обновления.

Существует три вида обновления для MySQL-MGR:

• Обновление версии patch — в пределах той же major-версии MySQL (например, 8.0.x или 8.4.x), чтобы получить исправления и улучшения. См. Patch Version Upgrade.
• Обновление major-версии MySQL (8.0 → 8.4) — обновление существующего кластера 8.0 до 8.4 на месте. См. ниже.
• Миграция MySQL-PXC в MySQL-MGR — требуется перед обновлением operator до v4.3.0 или более поздней версии, если вы все еще используете экземпляры PXC. См. контрольный список ниже и Migrate MySQL-PXC to MySQL-MGR.

#Обновление major-версии MySQL (8.0 → 8.4)

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

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

Требования и полную пошаговую процедуру см. в Upgrade MySQL 8.0 to 8.4.

#Контрольный список перед обновлением PXC

Если на вашей платформе есть экземпляры MySQL-PXC, выполните следующие действия до обновления до MySQL Operator v4.3.0 или более поздней версии:

kubectl get perconaxtradbcluster -A

kubectl delete perconaxtradbcluster <pxc-instance-name> -n <namespace>

kubectl delete pvc -l app.kubernetes.io/instance=<pxc-instance-name> -n <namespace>

#Сценарии обновления PXC

Следующие сценарии применяются при обновлении до MySQL Operator v4.3.0 или более поздней версии:

#Сценарий 1: экземпляры PXC отсутствуют

Дополнительные действия не требуются. Продолжайте стандартное обновление MySQL operator.

#Сценарий 2: экземпляры PXC присутствуют — выполните миграцию до обновления

Если в кластере есть экземпляры PXC, вы должны мигрировать их в MySQL-MGR до обновления MySQL operator. После завершения и проверки миграции можно продолжить стандартное обновление.

Шаги:

1. Определите все экземпляры PXC: kubectl get perconaxtradbcluster -A
2. Для каждого экземпляра следуйте руководству Migrate MySQL-PXC to MySQL-MGR.
3. Убедитесь, что приложения подключаются к новым endpoints MGR.
4. Выведите экземпляры PXC из эксплуатации.
5. Продолжите обновление MySQL operator.

#Сценарий 3: экземпляры PXC присутствуют — сначала обновите operator, мигрируйте позже

Если вам необходимо сначала обновить operator:

1. Обновите MySQL operator, следуя стандартной процедуре.
2. После обновления экземпляры PXC остаются запущенными, но не управляются.
3. Спланируйте и выполните миграцию PXC в MGR как можно скорее после обновления.
4. Внимательно отслеживайте экземпляры PXC на предмет любых проблем в период, когда они не управляются.

#Сценарий 4: смешанный кластер (часть PXC, часть MGR)

Кластеры, содержащие как PXC, так и MGR экземпляры, можно обновлять, но после обновления operator управляемыми останутся только экземпляры MGR. Для каждого экземпляра PXC выберите либо сценарий 2 (сначала миграция), либо сценарий 3 (сначала обновление, миграция позже).

#План аварийного реагирования для PXC

Если во время или после обновления operator у экземпляров PXC в неуправляемом состоянии возникают проблемы, используйте следующие процедуры:

#Pod PXC не запущен после обновления

Экземпляры PXC больше не управляются operator, поэтому автоматическое восстановление не произойдет.

1. Проверьте состояние pod:

   kubectl get pod -n <namespace> | grep <pxc-instance-name>
   kubectl describe pod <pxc-pod-name> -n <namespace>
2. Вручную перезапустите pod PXC:

   kubectl delete pod <pxc-pod-name> -n <namespace>
3. Проверьте восстановление:

   kubectl get pod -n <namespace>  # Wait for pod to reach Running state
4. Если pod не восстанавливается, проверьте состояние PVC и журналы. При устойчивых проблемах обратитесь в техническую поддержку.

#Обнаружена несогласованность данных PXC

Если есть подозрение на несогласованность данных:

1. Немедленно остановите запись в затронутый экземпляр PXC, чтобы предотвратить дальнейшее расхождение.
2. Определите последнюю известную рабочую резервную копию до обновления.
3. Оцените варианты восстановления:
   • Если доступна недавняя резервная копия и окно потери данных допустимо, восстановите данные из резервной копии.
   • Если потеря данных недопустима, обратитесь в техническую поддержку за помощью.
4. После восстановления в приоритетном порядке завершите миграцию PXC в MGR, чтобы вернуть управляемое состояние.

#Миграция PXC в MGR не удалась в течение окна обновления

Если миграцию невозможно завершить в пределах окна обслуживания:

1. Верните подключения приложений к исходным endpoints PXC, если приложения уже были переключены.
2. Убедитесь, что PXC по-прежнему работает: kubectl get perconaxtradbcluster -n <namespace>
3. Отложите дальнейшую миграцию до запланированного окна обслуживания.
4. Задокументируйте сбой для последующего анализа.

#Соображения по откату

MySQL operator нельзя откатить до предыдущей версии после обновления. Если возникает критическая проблема:

• Экземпляры PXC остаются запущенными (на само обновление operator они не влияют, затрагивается только потеря управления со стороны operator).
• Экземпляры MySQL-MGR продолжают нормально работать.
• Обратитесь в техническую поддержку, чтобы оценить проблему и определить дальнейшие действия.