E.19. Postgres Pro Enterprise 13.2.1

Дата выпуска: 2021-04-21

E.19.1. Обзор

Этот выпуск основан на PostgreSQL 13.2 и включает все новые возможности, появившиеся в PostgreSQL 13, а также исправления ошибок, вошедшие в корректирующие выпуски PostgreSQL 13.1 и 13.2. Подробное описание этих новшеств вы можете найти в замечаниях к выпускам PostgreSQL 13, PostgreSQL 13.1 и PostgreSQL 13.2, соответственно.

Список дополнительных модулей и утилит, добавленных в Postgres Pro Enterprise, а также перечень ключевых видимых пользователям изменений в ядре сервера по сравнению с ванильным PostgreSQL вы можете найти в Разделе 2. Ниже перечислены значимые отличия этой версии от Postgres Pro Enterprise 12.6.1:

  • Реализована инфраструктура для обновления «на ходу» до следующих корректирующих выпусков. Она предназначена для обновления установленного кластера до очередной младшей версии без перезапуска сервера, то есть не прерывая существующие клиентские подключения. На данный момент эта инфраструктура предоставляется для платформ Linux, за исключением Astra Linux «Смоленск» 1.5 и Альт Линукс СПТ 7.0. Чтобы обновление «на ходу» впоследствии было возможно, создайте кластер БД, выполнив команду pg-setup initdb с ключом --enable-online-upgrade.

  • Расширение multimaster стало стабильнее и обрело статус проекта с открытом кодом. Теперь результат транзакции определяется по алгоритму консенсуса Паксос и протоколу двухфазной фиксации с поколениями. Благодаря этому обеспечивается полноценная поддержка не только конфигурации кластера «2+1», которая раньше была единственной рекомендуемой и надёжно работающей конфигурацией multimaster.

  • В CFS добавлена поддержка библиотеки сжатия lz4.

  • Добавлено представление pgpro_stat_wal_activity, показывающее объём WAL, который генерирует каждый серверный процесс.

Важно

Начиная с Postgres Pro 12, использовать pg_pathman не рекомендуется. Применяйте вместо него реализованное в ванильной версии декларативное секционирование, описанное в Разделе 5.11.

E.19.2. Миграция на версию 13

Вы можете перейти на Postgres Pro Enterprise/ 13 с той же или предыдущей версии PostgreSQL (которая поддерживается выбранным способом обновления) или Postgres Pro Standard/Postgres Pro Standard Certified, а также с предыдущей версии Postgres Pro Enterprise/Postgres Pro Enterprise Certified. То же самое справедливо для перехода на Postgres Pro Enterprise Certified 13. Способы обновления кластера базы данных описаны в Разделе 18.6. Если у вас возникнут проблемы при переходе на новую версию, обратитесь в службу поддержки Postgres Pro Enterprise. Обратный переход не поддерживается. Обратите внимание, что переход с Postgres Pro Enterprise на Postgres Pro Enterprise Certified той же основной версии (или наоборот) — это обновление на совместимую версию Postgres Pro (за подробным описанием обратитесь к Разделу 18.6).

Для перехода с PostgreSQL, Postgres Pro Standard или выпуска Postgres Pro Enterprise, основанного на предыдущей основной версии PostgreSQL, сначала установите его последний корректирующий выпуск, а затем выполните выгрузку/восстановление данных, применив pg_dumpall, или воспользуйтесь pg_upgrade:

  • Если вы решите использовать pg_upgrade, важно инициализировать новый кластер баз данных с совместимыми параметрами. В частности, обратите внимание на характеристику контрольных сумм и выбор провайдера основного правила сортировки в кластере, который вы будете обновлять. Если pg_upgrade создаст какие-либо скрипты SQL в текущем каталоге, выполните их для завершения обновления.

  • Если вы выбираете вариант с выгрузкой/восстановлением данных, не забудьте при выгрузке добавить ключ --add-collprovider, чтобы для обновляемой базы данных был установлен правильный провайдер основного правила сортировки.

Понять, какое правило сортировки является основным в старом кластере и какой провайдер оно использует, можно по значению datcollate для базы данных template0 в каталоге pg_database. Если вы производите обновление с версии, в которой провайдер основного правила сортировки не задан, опустите указание провайдера при переходе с предыдущих версий Postgres Pro или выберите провайдер libc при переходе с ванильного PostgreSQL.

Помимо этого, учтите описанные ниже особенности обновления, связанные с изменениями в использовании правил сортировки.

В Windows инсталляции Postgres Pro могли содержать базы данных с основным правилом сортировки на базе ICU, имя которого имело синтаксически правильный формат языка BCP 47, но неправильный код языка или другие параметры, в результате чего это правило сортировки оказывалось недействительным для ICU.

Если эта проблема затрагивает вашу базу данных template0, при попытке инициализировать новый кластер с тем же правилом сортировки вы получите следующее сообщение об ошибке: failed to get the canonical name for collation locale (не удалось получить каноническое имя для локали правила сортировки). В этом случае выполнить обновление можно только путём выгрузки/восстановления данных, задав для нового кластера подходящую локаль для выбранного провайдера правил сортировки.

Если эта проблема затрагивает другие базы данных, вы получите то же сообщение об ошибке, что и при попытке создания в Postgres Pro нового кластера с некорректным правилом сортировки. Вы можете попытаться решить эту проблему следующим образом:

  1. Выгрузите базу данных, используя pg_dump; при этом необходимо указать параметры --create и --format=plain.

  2. Смените в выгруженном файле провайдер основного правила сортировки с '@icu' на '@libc'.

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

В некоторых особых случаях при выгрузке/восстановлении данных вы можете столкнуться с нарушением ограничений в восстанавливаемых базах данных, так что вместо этого метода лучше использовать pg_upgrade. В частности:

  • Если в инсталляции Postgres Pro версии 9.6 или ниже содержались индексы или ограничения, зависящие от правил сортировки, отличных от основного правила сортировки БД, а также от C или POSIX в базах данных с многобайтными кодировками, индексы и ограничения в таких базах могли оказаться несогласованными при обновлении до Postgres Pro версии 10 или выше. В Windows эта ситуация также могла иметь место, если база данных с многобайтной кодировкой содержала индексы или ограничения, зависящие от основного правила сортировки с полным именем "Russian_Russia[.кодировка]" или "English_United States[.кодировка]".

  • В Windows у кластеров Postgres Pro 10 с основным правилом сортировки на базе ICU локаль правила сортировки может не совпадать с локалью соответствующего правила сортировки libc.

Когда вы используете программу pg_upgrade, она объявляет такие индексы и ограничения нерабочими и создаёт для их исправления файлы reindex_text_indexes.sql и validate_text_constraints.sql, соответственно. Для завершения обновления вам надо будет выполнить эти скрипты.

При переходе с PostgreSQL или Postgres Pro Standard обязательно уделите внимание особенностям реализации, связанным с 64-битными идентификаторами транзакций. Если вы ранее использовали явные приведения идентификаторов транзакций к 32-битным целым, вы должны заменить их на приведения к типу bigint, так как 64-битные идентификаторы транзакций имеют такой тип.

Примечание

Во избежание конфликтов в системах Linux не используйте пакет postgrespro-ent-13 для установки исполняемых файлов Postgres Pro, а установите вместо него отдельные пакеты компонентов продукта. В этом случае режим автозапуска сервера, если он требуется, нужно будет включить вручную. Подробнее о предоставляемых пакетах и вариантах установки вы можете узнать в Главе 17.

Другие особенности обновления, присущие и ванильной версии PostgreSQL, описаны в Разделе E.34.