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

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

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

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

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

Проверки перед обновлением (предварительная версия)

База данных Azure для PostgreSQL гибкий сервер предоставляет проверки перед обновлением (PVC) для оценки готовности к обновлению перед началом обновления основной версии.

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

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

После завершения проверки возвращается один из следующих результатов:

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

В зависимости от результатов можно продолжить обновление или устранить обнаруженные проблемы и повторно выполнить проверку.

Ограничения

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

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

Пошаговые инструкции см. в разделе "Запуск проверок перед обновлением".

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

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

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

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

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

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

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

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

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

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

Вопросы, связанные с PostGIS

Если вы используете 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 для отслеживания хода выполнения обновления и устранения неполадок.

Включение журналов обновления с помощью параметров журнала сервера

• Установите значение logfiles.download_enable ON.
• Настройте хранение с logfiles.retention_days.

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

Доступ к PG_Upgrade_Logs из пользовательского интерфейса журналов сервера

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

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

• Быстро диагностировать проблемы: используйте PG_Upgrade_Logs для просмотра каждого шага обновления и выявления ошибок или предупреждений.
• Устранение неполадок эффективно. Анализ журналов для выявления сбоев, уменьшения времени простоя и ускорения действий по исправлению.

PG_Upgrade_Logs помогает понять, что произошло во время обновления и устранить проблемы с уверенностью.

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

• Обновление основной версии.
• Проверки перед обновлением.