E.30. Postgres Pro Enterprise 12.2.1
Дата выпуска: 2020-03-20
E.30.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-деревьях больше не поддерживается, о чём говорится в Подразделе 62.4.2. Влияние этих изменений на процедуру обновления освещается в Подразделе E.30.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.30.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.51.
При переходе с 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-деревьях, некоторые ранее сжатые индексы могут перестать поддерживать такое исключение, как описано в Подразделе 62.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 нового кластера с некорректным правилом сортировки. Вы можете попытаться решить эту проблему следующим образом:
Выгрузите базу данных, используя pg_dump; при этом необходимо указать параметры
--create
и--format=plain
.Смените в выгруженном файле провайдер основного правила сортировки с
'@icu'
на'@libc'
.Восстановите изменённое содержимое базы в 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
, соответственно. Для завершения обновления вам надо будет выполнить эти скрипты.