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

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

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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

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

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

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

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

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

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

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

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

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

Обновления основной версии на месте не поддерживают все расширения PostgreSQL. Обновление завершается ошибкой на этапе предварительной проверки, если в затронутом сценарии обновления обнаружено заблокированное расширение. Большинство блоков привязано к определённым целевым (а иногда и исходным) версиям, а не к каждому обновлению, как указано в следующих списках.

• Следующие расширения блокируют обновление основной версии на месте во всех путях обновления. Удалите их перед обновлением и повторно включите их после, если они поддерживаются в целевой версии: session_variable, anon, age. pg_duckdb

• Следующие расширения являются непостоянными служебными расширениями и должны быть удалены перед обновлением и повторно созданы после него согласно архитектуре (для всех путей обновления): pg_repack, hypopg, pg_partman.

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

  Extension	Заблокировано, когда
  pg_hint_plan	Целевая версия — PostgreSQL 14
  semver	Целевая версия — PostgreSQL 16 или 17
  azure_local_ai	Целевая версия — PostgreSQL 17 или 18
  pg_failover_slots	Целевая версия — PostgreSQL 17 или 18 (общая библиотека предварительной загрузки)
  azure_ai	Целевая версия — PostgreSQL 18
  azure_storage	Целевая версия — PostgreSQL 18
  pg_diskann	Целевая версия — PostgreSQL 18
  pgrouting	Целевая версия — PostgreSQL 15; или исходная версия ниже PostgreSQL 16, а целевая версия — PostgreSQL 16 или более поздняя; или целевая версия — PostgreSQL 18
  orafce	Исходная версия : PostgreSQL 11, 12 или 13

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

  • pg_stat_statements: блокируется, если другие объекты зависят от его представления или функции, что приведет к сбою ALTER EXTENSION pg_stat_statements UPDATE . Сначала удалите зависимые объекты.
  • pgcrypto: при установке в схему pg_catalog и обновлении с PostgreSQL 11 или 12 до PostgreSQL 13 или более поздних версий возникает блокировка, если от него зависят пользовательские объекты (конфликт со встроенной функцией gen_random_uuid()). Сначала переместите расширение в другую схему или удалите зависимые объекты.

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

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

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

Особенности TimescaleDB

Если вы используете TimescaleDB, обновления основных версий на месте поддерживаются только для определенных сочетаний исходных и целевых версий PostgreSQL:

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

Перед началом обновления убедитесь, что исходные и целевые версии включены в поддерживаемую матрицу.

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

• Триггеры событий: предварительная проверка обновления блокирует триггеры событий, поскольку они привязаны к командам DDL и могут ссылаться на системные каталоги, которые изменяются между мажорными версиями. Удалите все EVENT TRIGGERфайлы перед обновлением и повторно создайте их после обновления, чтобы обеспечить плавное обновление.
• Крупные объекты (LOS): способ обновления обрабатывает базы данных, содержащие миллионы больших объектов (хранящихся в pg_largeobject) зависит от целевой основной версии:
  • Целевой объект PostgreSQL 15 или более поздней версии: обновление использует оптимизированный массовый метод для передачи метаданных больших объектов, поэтому память и временное использование дисков больше не масштабируются с количеством больших объектов. Базы данных с десятками или сотнями миллионов крупных объектов надежно обновляются без дополнительной подготовки. Чтобы справиться с большим количеством крупных объектов, не требуется заранее запускать vacuumlo или масштабировать сервер, хотя вы по-прежнему можете запустить vacuumlo для удаления неиспользуемых крупных объектов по другим причинам.
  • Целевая версия — PostgreSQL 14 или более ранняя: базы данных с миллионами крупных объектов могут приводить к сбоям при обновлении из-за высокого потребления памяти или большого объёма журналов. Используйте утилиту vacuumlo для очистки неиспользуемых больших объектов и рассмотрите возможность увеличения ресурсов сервера перед обновлением, если многие большие объекты все еще используются.

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

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

postgres=> analyze;
ANALYZE

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

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

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

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

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

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

• Обновление основной версии
• Запуск проверок проверки обновления (предварительная версия)