Greenplum 6.21.1: обзор свежего релиза

обучение Greenplum курсы примеры для разработчиков, Greenplum для инженеров данных, Greenplum дата-инженер курсы обучение, Greenplum Arenadata DB курсы примеры обучение, обучение большим данным, Школа Больших Данных Учебный Центр Коммерсант

Совсем недавно, в самом конце августа 2022 года вышел очередной минорный выпуск Greenplum. Специально для обучения дата-инженеров, ИТ-архитекторов и разработчиков распределенных OLAP-приложений мы подготовили краткий обзор самых важных обновлений и изменений версии 6.21.1.

15 исправлений на сервере Greenplum

В отличие от июньского релиза, новинок в этом выпуске немного: добавлено новое расширение сборщика метрик, совместимое с Greenplum Command Center 6.8. Но исправлено множество ошибок, связанных сервером, обработкой запросов и потоком данных. В части сервера устранены следующие проблемы:

  • исправлено ошибочное откатывание транзакции из-за группового удаления процессов;
  • прекращено прерывание запроса без вызова функции очистки при достижении предела памяти;
  • устранена причина вызова ошибки PANIC во время выполнения запроса;
  • внесены исправления для уязвимости CVE-2022-1552, позволяющей злоумышленнику с разрешениями на создание невременных объектов хотя в одной схеме PostgreSQL, выполнять произвольные функции SQL под учетной записью суперпользователя. Это случилось из-за того функции Autovacuum, REINDEX, CREATE INDEX, REFRESH MATERIALIZED VIEW, CLUSTER и pg_amcheck не использовали изолированную программную среду с ограничениями безопасности, когда привилегированный пользователь обслуживает объекты другого пользователя. Эти команды не активировали нужные защиты или делали это слишком поздно. Это устранено в свежем выпуске Greenplum. Подробнее об этой и других уязвимостях Greenplum и PostgreSQL читайте в нашей новой статье.
  • исправлен сбой обновлений устранен за счет ​​проверки pg_upgrade для родительских разделов с записями seg, а logicalEof добавлен в errdetail в OpenAOSegmentFile;
  • устранен сбой журнала упреждающей записи (WAL, Write Ahead Log) — primary теперь записывает специальный WAL туда, откуда зеркало должно продолжать потоковую передачу остальной части отказавшего WAL;
  • предотвращен CLOG во время обновления сегмента – теперь инфраструктура pg_resetxlog используется для установки самого старого xid вместо замораживания каталога;
  • исправлена непредвиденная внутренняя ошибка FATAL, которая могла возникнуть при создании плана коррелированного подзапроса к партиционированной таблице. Проблема возникала в некоторых запросах, когда не удавалось создать InitPlan, а планировщик создавал копии вложенных подпланов в неправильном порядке. В новой версии Greenplum это устранено: теперь в этой ситуации планы первого уровня и вложенные планы запросов создаются корректно.
  • удалено ненужное планирование отношений дерева подключений со сложными подзапросами, что повышает производительность планирования для DML-запросов;
  • внесено исправление логики метод а pg_lock_status(), которая не позволяет ему пропускать некоторые строки и дважды подсчитывать другие;
  • решена проблема ненужных проверок при фактическом отключении runaway_detector_activation_percent, т.е. его установки в значение 100;
  • устранена ошибка, когда запрос COPY FROM/INSERT приводил к тому, что вставленные данные становились невидимыми для пользовательских запросов, выдаваемых мастером;
  • исправлена непредвиденная внутренняя ошибка подтверждения ожидания процесса до завершения, которая могла произойти во время инициализации при схеме управления «группы ресурсов», о чем мы писали здесь.
  • изменен relfrozenxid для материализованных представлений, оптимизированных для добавления. В новой версии Greenplum он имеет значение invalid. Напомним, relfrozenxid – это «замороженный» идентификатор транзакции. Greenplum использует модель PostgreSQL Multiversion Concurrency Control (MVCC) для управления одновременными транзакциями для таблиц кучи. Как и в PostgreSQL, MVCC в Greenplum может сравнивать номера идентификаторов транзакций (XID) для управления несколькими версиями строк данных. В начале запроса модель использует XID, чтобы определить, какие строки ей видны. Для этого в каждой таблице есть системные столбцы, которые неявно определены для этого случая. Столбец xmin содержит XID транзакции вставки для строки, а столбец xmax содержит XID транзакции удаления для нее. Поэтому видимая строка будет иметь определенный xmin и нулевой xmax. Затем механизм MVCC сравнивает XID выполняемого запроса со строками в целевых таблицах и определяет, какую версию строки следует использовать. Чтобы предотвратить зацикливание XID, Greenplum, как PostgreSQL, имеет специальный XID, называемый FrozenXID, который всегда считается более старым, чем любой обычный XID, с которым он сравнивается. Xmin строки должен быть заменен на FrozenXID в течение двух миллиардов транзакций, и это одна из функций, которые выполняет команда VACUUM. Таблица pg_class содержит столбец relfrozenxid, который содержит XID отсечки замораживания, использованный при последней операции VACUUM для этой таблицы. Все строки с нормальными XID старше этого XID заменялись на FrozenXID и замораживались. Но для таблиц, оптимизированных только на добавление данных, сценарий с их обновлением не характерен. Поэтому в Greenplum21.1 relfrozenxid для материализованных представлений, оптимизированных для добавления, стал недействительным (invalid).
  • Решена проблема, из-за которой запрос CREATE EXTENSION WITH SCHEMA не удавалось выполнить, поскольку в Greenplum не установлен search_path как в диспетчере запросов, так и в исполнителе запросов перед выполнением сценария расширения.

Обработка запросов, поток данных и развертывание на VMWare

В части обработки SQL-запросов в новой версии Greenplum предотвращен сбой оптимизатора во время оптимизации из-за отсутствия статистики, о чем мы писали здесь. Также добавлен GUC, который предотвращает зависание запросов к распределенным реплицированным таблицам при использовании оптимизатора ORCA, контролируя откат для реплицированных таблиц. Оптимизатор ORCA теперь требует, чтобы тип индекса правильно оценивал bitmap-сканирование перед выполнением полного сканирования таблицы. Также устранена разница в производительности запросов между оптимизаторами GPORCA и PostgreSQL.

Еще исправлен процесс главного регистратора, создававший высокую нагрузку на главный сервер и приводивший к отключению сегментов через обработку строки с двумя видами модификации. ORCA теперь предотвращает создание spill-файлов, помещая в план SQL-запроса операции приведения ниже операций соединения, когда это безопасно. Про проблему spiil-файлов в Greenplum мы рассказывали в этой статье. Если целевой список в CTE-провайдере пуст, вместо оптимизатора ORCA используется оптимизатор Postgres. Наконец, исправлены неправильные адреса, которые вызывали утечку памяти.

В части потока данных в Greenplum 6.21.1 устранена проблема в коде форматирования с фиксированной шириной, которая могла вызвать ошибку из-за того, что код не обрабатывал ситуацию, когда конец буфера совпадал с концом данных, а потому не включал ожидаемый символ новой строки. Еще исправлена ошибка утилиты файлового сервера gpfdist, которая использует протокол HTTP, чтобы загружать данные параллельно в каждый сегмент напрямую без мастера, параллельно обслуживая внешние файлы данных для сегментов Greenplum. Ошибка могла возникнуть во время очистки сеанса, если его время истекло из-за переполнения диска. Вместо сбоя утилита gpfdist теперь регистрирует ошибку для этого условия. Подробнее про эту и другие ETL-утилиты Greenplum смотрите в нашем прошлом материале.

В заключение, специально для администраторов кластера, отметим несколько решенных проблем Tanzu Greenplum на vSphere, платформе виртуализации облачных вычислений VMware. В частности, раньше пользователи видели предупреждения в журналах gpinitsystem, когда имелось несоответствие между тем, что сообщала утилита имени хоста, и фактическим именем хоста сегмента. Теперь это исправлено. Также решена проблема, из-за которой во время развертывания Greenplum появлялись предупреждения «команда не найдена» (command not found) и проблема, из-за которой развертывание завершалось сбоем, если количество сегментов было равно 1 или нечетным числам для зеркалированных развертываний. Наконец, исправлено некорректное отображение состояния сбой для виртуальной службы Greenplum при ручном завершении работы гостевой операционной системы.

Узнайте больше про администрирование и эксплуатацию Greenplum и Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://docs.vmware.com/en/VMware-Tanzu-Greenplum/6/greenplum-database/GUID-relnotes-release-notes.html
  2. https://www.postgresql.org/support/security/CVE-2022-1552/
  3. https://community.pivotal.io/s/article/About-XIDs-and-XID-Wraparound-in-Greenplum

Поиск по сайту