E.31. Postgres Pro Enterprise 12.2.1
Пред. НаверхПриложение E. Замечания к выпускамНачало След.

E.31. Postgres Pro Enterprise 12.2.1

E.31.1. Обзор
E.31.2. Миграция на версию 12

Дата выпуска: 2020-03-20

E.31.1. Обзор

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

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

  • Представление pg_recovery_settings стало ненужным, так как содержимое recovery.conf было включено в postgresql.conf и теперь его можно просмотреть через системное представление pg_settings; параметры primary_conninfo, restore_command и primary_slot_name можно изменять, не перезапуская сервер.

  • Модификация, сокращающая объём записей в WAL, генерируемых при создании индексов GiST, GIN и SP-GiST, вошла в PostgreSQL 12, поэтому продукты Postgres Pro теперь включают её в несколько изменённом виде. Формат индексов не поменялся, поэтому все индексы должны остаться в рабочем состоянии.

  • Механизм исключения дубликатов в индексах-B-деревьях претерпел важные изменения. Теперь вы можете отключить исключение дубликатов для создаваемых индексов, воспользовавшись параметром deduplicate_items команды CREATE INDEX. Кроме того, для некоторых классов операторов и типов данных исключение дубликатов в индексах-B-деревьях больше не поддерживается, о чём говорится в Подразделе 63.4.2. Влияние этих изменений на процедуру обновления освещается в Подразделе E.31.2.

  • Механизм PTRACK был основательно переработан и получил новый внешний API. Если ранее вы создавали резервные копии с использованием PTRACK в pg_probackup, вам нужно будет обновить pg_probackup до версии 2.2.6 или выше и настроить копирование PTRACK заново.

  • Встроенный пул соединений был существенно переработан и теперь не считается экспериментальным. Чтобы узнать больше о существующих особенностях использования этого механизма, обратитесь к Разделу 33.1.

  • Усовершенствовано расширение multimaster:

    • Расширение multimaster рекомендуется использовать в конфигурации с тремя узлами, один из которых является рефери. Подробнее о настройке кластера с рефери рассказывается в Подразделе F.30.3.3.

    • Теперь можно проверить согласованность данных на узлах кластера, используя функцию mtm.check_query().

  • В CFS улучшена функциональность управления сжатием:

    • Теперь вы можете выбирать алгоритмы сжатия. В выпускаемом Postgres Pro поддерживаются алгоритмы zstd (по умолчанию), zlib и pglz. Дополнительно могут быть добавлены и другие алгоритмы.

  • В представление pg_stat_activity добавлено поле wait_state_id для целей мониторинга.

  • Добавлен параметр plan_cache_lru_memsize, ограничивающий объём памяти, выделяемый для подготовленных операторов. По умолчанию это ограничение теперь равно 8 МБ, а параметр plan_cache_lru_size отключён.

  • Добавлено расширение pgpro_stats, которое не только собирает статистику выполнения SQL-операторов, но и подсчитывает статистику событий ожидания.

  • Расширение mchar обновлено до версии 2.1.

  • Расширение dump_stat обновлено до версии 1.2.

Важно

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

E.31.2. Миграция на версию 12

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

Для перехода с PostgreSQL, Postgres Pro Standard или выпуска Postgres Pro Enterprise, основанного на предыдущей основной версии PostgreSQL, обязательно установите последний корректирующий выпуск вашего продукта. Выполните выгрузку/восстановление данных, используя pg_dumpall, или воспользуйтесь утилитой pg_upgrade. Помимо нижеперечисленных требований, примите во внимание все особенности обновления, присущие ванильному PostgreSQL, о которых рассказывается в Разделе E.54.

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

Примечание

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

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

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

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

Вследствие изменений в реализации исключения дубликатов в индексах-B-деревьях, некоторые ранее сжатые индексы могут перестать поддерживать такое исключение, как описано в Подразделе 63.4.2. Если вы воспользуетесь утилитой pg_upgrade, она объявит такие индексы нерабочими и создаст скрипт reindex_non_equalimage_btree.sql, который надо будет запустить для завершения обновления.

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

В 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 для завершения обновления. Эта операция может прерваться ошибкой, если окажутся нарушенными какие-либо ограничения, зависящие от правил сортировки в базе данных. В этом случае вы можете попытаться разрешить эти проблемы вручную или обратиться к службе поддержки.

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

  • Если в инсталляции 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, соответственно. Для завершения обновления вам надо будет выполнить эти скрипты.

Пред. Наверх След.
E.30. Postgres Pro Enterprise 12.3.1 Начало E.32. Выпуск 12.22