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

E.32. Postgres Pro Enterprise 11.2.1

E.32.1. Обзор
E.32.2. Миграция на версию 11

Дата выпуска: 2019-05-07

E.32.1. Обзор

Этот выпуск основан на Postgres Pro Enterprise 10.7.1 и PostgreSQL 11.2. Он включает все новшества, реализованные в PostgreSQL 11, а также исправления ошибок, вошедшие в PostgreSQL 11.1 и 11.2. Подробное их описание можно найти в Замечаниях к выпуску PostgreSQL 11, PostgreSQL 11.1 и PostgreSQL 11.2, соответственно. По сравнению с Postgres Pro Enterprise 10.7.1 эта версия содержит следующие изменения:

  • Реализован экспериментальный встроенный пул соединений, позволяющий ограничивать число обслуживающих процессов при подключении множества клиентов, не накладывая ограничения на использование параметров конфигурации сеансов, подготовленных операторов или временных таблиц. За подробностями обратитесь к Главе 34.

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

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

  • Появилась возможность замены индекса для ограничения без удаления самого ограничения, реализуемая предложением ALTER CONSTRAINT ... USING INDEX команды ALTER TABLE.

  • В конфигурации Postgres Pro Enterprise по умолчанию теперь применяется декларативный синтаксис секционирования, реализованный в ядре Postgres Pro, а не синтаксис pg_pathman, который применялся по умолчанию в Postgres Pro Enterprise версии 10. При необходимости вариант секционирования можно сменить с помощью параметра partition_backend.

  • Улучшено расширение multimaster:

    • Теперь multimaster использует только стандартное соединение Postgres Pro между узлами, без дополнительного канала взаимодействия через другой порт TCP. Вследствие этого в строках соединения больше не нужен параметр arbiter_port, а также был удалён параметр конфигурации multimaster.arbiter_port. Кроме того, был ликвидирован параметр multimaster.use_rdma, так как multimaster может использовать все типы подключения, которые поддерживает Postgres Pro, без дополнительной настройки.

    • Конфигурация кластера теперь хранится не в файлах конфигурации, а в базе данных. Вследствие этого, идентификаторы узлов назначаются автоматически, и при добавлении/удалении узлов не требуется редактировать файлы конфигурации вручную. Таким образом, параметры multimaster.conn_strings и multimaster.node_id оказались ненужными и были удалены. Для изменения конфигурации кластера на всех узлах вы можете воспользоваться функцией mtm.init_cluster().

    • Таблицы без первичного ключа теперь по умолчанию всегда реплицируются, поэтому параметр конфигурации multimaster.ignore_tables_without_pk был удалён. Тем не менее вы можете прекратить репликацию таблицы, воспользовавшись функцией mtm.make_table_local().

    • Автоматическое удаление отстающего слота репликации более не выполняется, так как оно создавало больше проблем, чем решало. Чтобы удалить слоты репликации для узла, нужно будет явно вызывать функцию mtm.drop_node().

    • Параметр конфигурации mtm.major_node был удалён за ненадобностью, так как то же поведение можно получить с использованием рефери.

    • Переменная multimaster.max_nodes теперь не требуется для изменения конфигурации кластера. Все необходимые действия производит функция mtm.add_node().

    • Несколько вариантов удаления/добавления узлов были сведены в один механизм, управляемый функциями mtm.add_node()/mtm.drop_node().

    • Представления, предназначенные для мониторинга, были пересмотрены; теперь информацию о кластере выдают функции mtm.status() и mtm.nodes(). Функции mtm.collect_cluster_info(), mtm.get_cluster_state() и mtm.get_nodes_state() были удалены.

    • Функции mtm.copy_table и mtm.broadcast_table удалены как избыточные.

  • Добавлена поддержка JIT-компиляции (Just-in-Time, Компиляция «точно в нужное время») в системах Debian и Ubuntu, Astra Linux 1.6, Альт Линукс 8 и CentOS 7. Для использования этой функциональности вы должны установить отдельный пакет JIT и настроить окружение, как описывается в Главе 17. Подробнее JIT описывается в Главе 32.

  • Добавлена поддержка ОС SUSE Linux Enterprise Server 15 и AlterOS 7.5.

  • Добавлены пакеты PL/Python для Python 3 в системах SUSE Linux Enterprise Server 12.1, CentOS 6/7, Red Hat Enterprise Linux 6/7 и Oracle Linux 6/7.

  • Изменён метод использования ICU: версия правила сортировки ICU теперь не хранится в кластере и, таким образом, не проверяется при подключении к базе данных. Как это отразилось на процедуре обновления, описано в Подразделе E.32.2.

  • Ускорено создание индексов и минимизировано нежелательное вытеснение страниц отношений из общих буферов при построении индексов.

  • Усовершенствован планировщик/оптимизатор, что позволило увеличить скорость и точность для нескольких типов запросов:

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

    • Для запросов с несколькими столбцами в предложении GROUP BY при сортировке данных теперь может выбираться другой порядок столбцов, если это не влияет на точность запроса. Чем более уникальны значения в первом сортируемом столбце, тем проще будет сортировать остальные столбцы. Если в одном из столбцов уникальны все значения, может быть достаточно отсортировать данные только по этому столбцу. Планировщик может также воспользоваться существующими результатами сортировки, полученными при сканировании индекса или выполнении ORDER BY.

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

    • Замкнутые соединения теперь исключаются из планов, если это не влияет на результаты запросов.

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

  • Улучшена оценка избирательности для индексов, построенных по логическим столбцам.

  • Улучшена стабильность автономных транзакций.

  • Добавлено представление pg_recovery_settings, отображающее текущие параметры восстановления из файла recovery.conf.

В новую версию была перенесена вся функциональность Postgres Pro, включённая в Postgres Pro Enterprise 10.7.1. Общее представление обо всех основных отличиях Postgres Pro от ванильной версии PostgreSQL вы можете получить в Разделе 2.

Примечание

Реализация покрывающих индексов вошла в ванильную версию PostgreSQL 11, но с некоторыми изменениями, так что и в Postgres Pro они теперь реализуются по-другому. Если вы использовали покрывающие индексы в предыдущей версии Postgres Pro Enterprise, вам потребуется перестроить их после обновления.

E.32.2. Миграция на версию 11

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

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

Примечание

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

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

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

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

  • При обновлении с Postgres Pro версии 10 кластеров, в которых нет информации о версии библиотеки ICU, состояние актуальности индексов и ограничений определяется по версиям правил сортировки. Однако для кластеров, в которых содержатся базы данных с основным правилом сортировки на базе ICU, но отсутствует информация о версии библиотеки ICU и/или версиях правил сортировки, нет никакой возможности удостовериться в том, что в текущей версии Postgres Pro используется та же версия библиотеки ICU.

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

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

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

Пред. Наверх След.
E.31. Postgres Pro Enterprise 11.4.1 Начало E.33. Выпуск 11.22