Версия сайта для слабовидящих
Совсем недавно, в самом конце августа 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 при ручном завершении работы гостевой операционной системы. А какие обновления вышли в осенних релизах этой MPP-СУБД, мы рассказываем в новой статье.
Узнайте больше про администрирование и эксплуатацию Greenplum и Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
