#Обновление

MySQL-PXC устарел и удален начиная с Alauda Database Service for MySQL v4.3.0. Существующие экземпляры PXC продолжат работать, но больше не будут управляться оператором MySQL. Если у вас есть экземпляры PXC, вы должны выполнить их миграцию в MySQL-MGR до обновления до MySQL Operator v4.3.0 или более поздней версии.

• Руководство по миграции: см. Migrate MySQL-PXC to MySQL-MGR для получения подробных пошаговых инструкций, охватывающих совместимость схемы, наборы символов, пользователей и привилегии. :::

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

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

#Контрольный список перед обновлением MySQL-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.

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

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

Шаги:

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

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

Если вы должны сначала обновить оператор:

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

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

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

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

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

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

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

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>  # Подождите, пока pod перейдет в состояние Running
4. Если pod не восстанавливается, проверьте состояние PVC и логи. При сохранении проблемы обратитесь в техническую поддержку.

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

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

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

#Миграция PXC-to-MGR не выполняется в окно обновления

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

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

:::warning Важно: не удаляйте PXC CR до завершения и проверки миграции Удаление custom resource PXC приведет к удалению всех связанных pod и данных. Всегда проверяйте целостность данных на целевом экземпляре MGR перед выводом исходного экземпляра PXC из эксплуатации.