Обновления основных версий в Базе данных Azure для PostgreSQL

Гибкий экземпляр сервера Базы данных Azure для PostgreSQL поддерживает PostgreSQL версии 18 (предварительная версия), 17, 16, 15, 14, 13, 12, 11. Сообщество Postgres выпускает новую основную версию, содержащую новые функции примерно один раз в год. Кроме того, каждая основная версия получает периодические исправления ошибок в виде минорных релизов. Мелкие обновления версий включают изменения, которые обратно совместимы с уже существующими приложениями. Гибкий экземпляр сервера Базы данных Azure для PostgreSQL периодически обновляет незначительные версии во время периода обслуживания клиента.

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

Гибкий экземпляр сервера Базы данных Azure для PostgreSQL имеет функцию, которая выполняет обновление основной версии сервера на месте с щелчком мыши. Эта функция упрощает процесс обновления, минимизируя нарушения работы пользователей и приложений, обращаюющихся к серверу.

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

Процесс обновления

Ниже приведены некоторые важные соображения по обновлению основных версий на месте:

• Перед началом обновления убедитесь, что на сервере доступно не менее 10–20% свободное хранилище. Во время обновления временные файлы журналов и операции метаданных могут увеличить использование диска. Недостаточно свободного места может привести к неудачам при обновлении или проблемам при откате.
• Во время обновления основной версии на месте гибкий экземпляр сервера Базы данных Azure для PostgreSQL выполняет предварительную проверку, чтобы определить возможные проблемы, которые могут привести к сбою обновления.
  • Если предварительная проверка обнаруживает любые несовместимости, создается запись журнала, указывающая на неудачу проверки обновления и содержащая сообщение об ошибке.
  • Если предварительная проверка выполнена успешно, гибкий экземпляр сервера Базы данных Azure для PostgreSQL останавливает службу и принимает неявную резервную копию перед началом обновления. Служба может использовать эту резервную копию для восстановления экземпляра базы данных до предыдущей версии, если возникла ошибка обновления.
• Гибкий экземпляр сервера Базы данных Azure для PostgreSQL использует средство pg_upgrade для выполнения обновлений основных версий на месте. Служба обеспечивает гибкость пропуска версий и обновления непосредственно до более поздних версий.
• Во время обновления основной версии сервера, включенного для обеспечения высокой доступности (HA), служба отключает высокий уровень доступности, выполняет обновление на первичном сервере, а затем повторно включает высокий уровень доступности после завершения обновления.
• Большинство расширений автоматически обновляются до более поздних версий во время обновления основной версии на месте с некоторыми исключениями.
• Процесс обновления основной версии на месте для гибкого экземпляра сервера Базы данных Azure для PostgreSQL автоматически развертывает последнюю поддерживаемую дополнительную версию.
• Обновление основной версии на месте — это автономная операция, т. е. сервер будет недоступен во время процесса. Хотя большинство обновлений выполняются в течение 15 минут, фактическая длительность зависит от размера и сложности базы данных. В частности, необходимое время напрямую пропорционально количеству объектов (таблиц, индексов, схем) в экземпляре PostgreSQL. Более крупные или более сложные схемы могут столкнуться с более длительным временем обновления.
• Длительные транзакции или высокая рабочая нагрузка перед обновлением могут увеличить время завершения работы базы данных и увеличить время обновления.
• После успешного обновления основной версии на месте нет автоматических способов вернуться к более ранней версии. Однако можно выполнить восстановление на определенный момент времени (PITR) до обновления, чтобы восстановить предыдущую версию экземпляра базы данных.
• Гибкий сервер Azure Database для PostgreSQL делает моментальный снимок вашей базы данных во время обновления. Моментальный снимок выполняется перед началом обновления. Если обновление завершается сбоем, система автоматически возвращает вашу базу данных в ее состояние по моментальному снимку.
• PostgreSQL 16 представляет меры безопасности на основе ролей. После обновления основной версии на гибком экземпляре сервера Базы данных Azure для PostgreSQL первый пользователь, созданный на сервере , которому предоставлен параметр ADMIN, теперь будет иметь права администратора над другими ролями для основных операций обслуживания.

Рекомендации по обновлению и ограничения

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

Неподдерживаемые конфигурации сервера

• Реплики чтения не поддерживаются во время локальных обновлений. Перед обновлением первичного сервера необходимо удалить реплику чтения (включая любую каскадную реплику чтения). После обновления реплику можно создать повторно.
• Правила сетевого трафика могут блокировать операции обновления.
  • Убедитесь, что гибкий экземпляр сервера может отправлять и получать трафик через порты 5432 и 6432 в виртуальной сети и в службу хранилища Azure (для архивации журналов).
  • Если группы безопасности сети (NSG) ограничивают этот трафик, высокая доступность не будет автоматически включена после обновления. Возможно, потребуется вручную обновить правила NSG и повторно включить высокий уровень доступности.
• Слоты логической репликации не поддерживаются во время обновления основной версии на месте.
• Серверы, использующие хранилище SSDv2, не имеют права на обновление основных версий.
• Представления, зависящие от pg_stat_activity, не поддерживаются во время обновления основных версий.
• Если вы выполняете обновление с PG11 до более поздней версии, необходимо сначала настроить гибкий сервер для использования проверки подлинности SCRAM , включив SCRAM и сбросив все пароли роли входа.

Ограничения расширения

Обновления основной версии на месте не поддерживают все расширения PostgreSQL. Обновление завершится ошибкой во время предварительной проверки, если обнаружены неподдерживаемые расширения.

• Следующие расширения поддерживаются для регулярного использования, но если они присутствуют, будут блокировать обновление основной версии непосредственно. Удалите их перед обновлением и повторно включите их после, если они поддерживаются в целевой версии: timescaledb, dblink, orafce. postgres_fdw
• Следующие расширения — это неизстойчивые расширения служебной программы, которые необходимо удалить и повторно создать после обновления с помощью конструктора: pg_repack, . hypopg
• При обновлении до PostgreSQL 17 следующие расширения не поддерживаются и должны быть удалены перед обновлением. Их можно повторно включить, только если поддерживается в целевой версии: age, , azure_ai, hllpg_diskann. pgrouting

Заметка: Если любой из этих расширений отображается в параметре azure.extensions сервера, обновление будет заблокировано. Удалите их из параметра перед началом обновления.

Соображения PostGIS-Specific

Если вы используете PostGIS или любые зависимые расширения, необходимо настроить параметр сервера search_path для включения:

• Схемы, связанные с PostGIS
• Зависимые расширения, включая: postgis, postgis_rasterpostgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizeraddress_standardizer_data_usfuzzystrmatch
• Ошибка правильной настройки search_path может привести к сбоям обновления или сбою объектов после обновления.

Другие рекомендации по обновлению

• Триггеры событий: Проверка перед обновлением блокирует триггеры событий, поскольку они связаны с командами DDL и могут ссылаться на системные каталоги, которые изменяются между основными версиями — удалите все EVENT TRIGGER перед обновлением и затем воссоздайте их после завершения обновления, чтобы обеспечить его плавное выполнение.
• Крупные объекты (LOs): базы данных с миллионами больших объектов (хранящиеся в pg_largeobject) могут привести к сбоям обновления из-за высокой нагрузки на память или тома журнала. Используйте служебную программу vacuumlo для очистки неиспользуемых LOS и рассмотрите возможность масштабирования сервера перед обновлением, если многие LOS по-прежнему используются.

После обновления

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

postgres=> analyze;
ANALYZE

Просмотр журналов обновления

Журналы обновления основных версий (PG_Upgrade_Logs) предоставляют прямой доступ к подробным журналам сервера. Интеграция PG_Upgrade_Logs в процесс обновления может помочь обеспечить более плавный и более прозрачный переход на новые версии PostgreSQL.

Журналы обновления основной версии можно настроить так же, как журналы сервера, используя следующие параметры сервера:

• Чтобы включить функцию, установите logfiles.download_enable в ON.
• Чтобы определить хранение файлов журнала в днях, используйте logfiles.retention_days.

Настройка журналов обновления

Чтобы начать работу с PG_Upgrade_Logs, можно настроить запись журналов сервера PostgreSQL и журналов обновления основных версий.

Журналы обновления можно получить через пользовательский интерфейс для журналов сервера. Там вы можете отслеживать ход выполнения и подробные сведения об обновлениях основных версий PostgreSQL в режиме реального времени. Этот пользовательский интерфейс предоставляет централизованное расположение для просмотра журналов, чтобы упростить отслеживание и устранение неполадок процесса обновления.

Преимущества использования журналов обновления

• Аналитическая диагностика: PG_Upgrade_Logs предоставляет ценную информацию о процессе обновления. Он записывает подробные сведения о выполненных операциях и выделяет все ошибки или предупреждения, возникающие. Этот уровень детализации играет важную роль в диагностике и устранении проблем, которые могут возникнуть во время обновления, для более плавного перехода.
• Упрощенное устранение неполадок. С прямым доступом к этим журналам можно быстро определить и устранить потенциальные препятствия на обновление, сократить время простоя и свести к минимуму влияние на операции. Журналы служат важным средством устранения неполадок, обеспечивая более эффективное и эффективное решение проблем.

Связанный контент

• Обновление основной версии.
• Высокий уровень доступности в Базе данных Azure для PostgreSQL.
• Резервное копирование и восстановление в Базе данных Azure для PostgreSQL.