Продолжаем следить за новостями из мира PostgreSQL 18. Январский коммитфест принес много полезных изменений в области мониторинга и не только.

А самое интересное из предыдущих коммитфестов можно прочитать здесь: 2024-07, 2024-09, 2024-11.

pg_probackup 3 — не просто обновление, а полная перезагрузка системы резервного копирования PostgreSQL. Пока сообщество затаило дыхание в ожидании релиза, мы разберем по косточкам все ключевые изменения: от полностью переработанной архитектуры и нового репликационного протокола до революционной возможности восстановления отдельных баз данных и поддержки FUSE. Узнайте, как LibProbackup3 – полноценный SDK – открывает новые горизонты для интеграции в любую инфраструктуру, а улучшенная поддержка лент и S3, наконец, решает наболевшие проблемы. 

Недавно у Postgres Pro вышла новость о релизе Postgres Pro Enterprise Manager 2 (далее просто PPEM). Если коротко, то это админка для управления и мониторинга Postgres. Основная задача инструмента — помогать DBA в ежедневной работе и избавлять от рутины. Давайте в этой статье попробуем установить и запустить PPEM, посмотреть что это такое и какие возможности предоставляет система.

Настройка отказоустойчивого кластера PostgreSQL для «1С:Предприятие» — задача для опытных специалистов. Ручное или автоматическое переключение на резервный сервер? Сколько реплик действительно необходимо для надёжной отказоустойчивости? Сертифицированный эксперт по PostgreSQL Алексей Васильев делится практическими знаниями и пошаговыми инструкциями по развёртыванию отказоустойчивого решения на базе Postgres Pro Enterprise с использованием BiHA.

Всем привет, после публичного релиза pgpro-otel-collector, хочется продолжить рассказывать про инструмент и начать с серии постов про Коллектор. В этой серии постараюсь подробнее и на примерах познакомить читателя с коллектором и продемонстрировать сценарии использования. Рассказывать буду и про коллектор, и про разные вещи связанные с настройкой/мониторингом Postgres. Рассчитываю что посты будут полезны Linux администраторам, PostgreSQL DBA и тем кому интересен мониторинг Postgres.

Первый пост ознакомительный, в нем расскажу как установить, настроить и запустить коллектор. И конечно же, как посмотреть что-то что отдает коллектор и начнем мы с метрик Postgres.

Это продолжении серии статей о принятых изменениях в PostgreSQL 18. На этот раз речь пойдет о завершившемся в ноябре коммитфесте.

А самое интересное из предшествующих коммитфестов можно прочитать здесь: 2024-07, 2024-09.

Если вы когда-нибудь запускали несколько экземпляров PostgreSQL или другого ПО на одной машине (виртуальной или физической), то наверняка сталкивались с эффектом шумного соседа, когда инстансы мешали друг другу работать. Так как же примирить соседей? У нас есть ответ!

Защитите Postgres от квантов!

Why quantum-safe PostgreSQL is critical today

Только свыклись с мысльюо сосуществовании с LLM, и нате — новая напасть! Как сделать Postgres непробиваемым для квантов? Как, уже и об этом пора думать?

Автор — Тимоти Стюард (Timothy Steward) — считает, что да, пора. Статья в блоге Fujitsu Fastware, а Тимоти — главный архитектор данных по направлению энтерпрайз (Principal Enterprise Data Architect), там сейчас продвигают Fujitsu Enterprise Postgres 17.

Он говорит вот о чём: квантовые компьютеры пока мало что могут, но уже навострились ломать криптозащиту. Во всяком случае, надо к этому готовиться. Не то, чтобы заметка выдающаяся, но тема любопытная. Там есть ликбез, есть общеизвестные вещи, но есть и сведения, знакомые, наверное, только специалистам по шифрованию, есть красивые имена IBM‑овских птичек, оформленные в табличку (справа — число кубитов):

Всем привет, меня зовут Алексей, я люблю мониторинг, немного в нем разбираюсь, а в этом посте расскажу про pgpro-otel-collector который 31 января выпустили в публичное использование.

TLDR: pgpro-otel-collector - opentelemetry-коллектор (агент мониторинга) для сбора метрик и журналов Postgres от PostgresPro.

Согласно статистике, в сентябрьских коммитфестах меньше всего коммитов. Но похоже, что для релизного цикла 18-й версии это не так. Много принятых патчей и много интересных новых возможностей, информацией о которых хочется поделиться.

Напомню, что самое интересное из июльского коммитфеста можно прочитать здесь: 2024-07.

Вышел Postgres Pro Enterprise 17, и этот релиз принесёт улучшения в области производительности и масштабирования. Одно из ключевых нововведений — расширение Proxima, объединяющее функции пулера, прокси и балансировщика нагрузки, интегрированное непосредственно в ядро СУБД. Кроме того, разработчиков ждут новые возможности управления очередями сообщений, инструменты оптимизации запросов, средства обеспечения безопасности и функции интеллектуального хранения данных.

Администраторы баз данных часто ломают голову над тем, чтобы выявить самые «прожорливые» процессы, из-за которых страдает быстродействие систем. В далеком 2017-м DBA (а теперь инженер Postgres Professional) Андрей Зубков тоже задавался этим вопросом, а в результате придумал утилиту pg_profile для PostgreSQL, которая сейчас «проросла» в pgpro_pwr.

В этой статье мы расскажем о стратегическом мониторинге БД и научим выявлять узкие места в ваших БД с помощью наших утилит.

«Как ускорить выполнение запросов к базам данных?» — извечный вопрос админов и пользователей. Казалось бы, раньше всё работало неплохо, но стоило клиентской базе вырасти в пять раз, как всё замедлилось. Знакомая ситуация? В этой статье расскажем, как найти запросы, которые можно ускорить, и оптимизировать их.

Статья подготовлена по материалам выступления на конференции PGCONF.СПБ 2024.

Выбор SQL-запроса в реляционной СУБД в основном определяется пространством поиска возможных планов и техниками поиска плана в этом пространстве. У каждой СУБД оба этих фактора имеют свои особенности, что объясняет, почему иногда при миграции с одной СУБД на другую можно наблюдать как ускорения, так и провалы во времени выполнения отдельных запросов.

Здесь я привожу четыре случая, когда SQL Server позволяет строить планы запросов значительно более оптимальные, нежели это доступно PostgreSQL используя как более широкое пространство возможных планов, так и более совершенные методы оценок эффективности планов. Эти примеры: использование тредов, расширенная статистика, кэширование промежуточных результатов запроса и внутренняя параметризация. Примеры независимы и все кроме первого содержат скрипт воспроизведения - можно сразу листать на ту часть, которая выглядит интереснее.

Полагаю, знание о таких кейсах может быть полезным. Как минимум уменьшит количество стресса при миграции на PostgreSQL и возможно заинтересует кого-то настолько, чтобы начать свой проект в open-source сообществе разработчиков СУБД.

Badass Elephant

Из январского номера мы узнаём, что Тембо - имя лихого слоника из игры Tembo the Badass Elephant. Основатель и гендир Рай Уокер (Ry Walker) объявил о доступности Tembo Cloud, а в начале января взяли на работу Дэвида Уилера (David E. Wheeler) - основателя PGXN (PostgreSQL Extension Network). Компания | кампания настолько активная и шумная (в маркетинговом смысле), что кажется: они существуют уже ... годы во всяком случае, не год с небольшим.

PG-футурология

Thoughts on PostgreSQL in 2024

В своём блоге Джонатан Кац говорит, что хотел совсем чуть-чуть попредсказывать, но увлёкся - получилась немаленькая статья. Год назад это было интересно потому, что это было тогда. А сейчас это интересно потому, что это было ... тогда, то есть год назад. Начинал он с логической репликации - ну да, здесь всё успешно развивается. А вот тема HA (High Availability) актуальна в не меньшей степени, но напомним статейку из декабрьского, свежайшего Postgresso: PG Phriday: Kubernetes Killed the High Availability Star.

Aurora DSQL

Эта Аврора наделала шуму. Откликов на анонс много. Люди говорят о сомнительной (но громко заявленной) совместимости с Postgres. Официальный анонс был такой:

AWS Announces New Database Capabilities Including Amazon Aurora DSQL- the Fastest Distributed SQL Database

Мэт Гарман (Matt Garman), гендир AWS, объявил на сборище re:Invent в Лос-Анджелесе в присутствии 60 тыс. очных и 400 тыс (это ж почти полмиллиона!) онлайновых гостей о принципиально новой, геораспределённый СУБД Aurora DSQL. Более того: это была его инаугурационная гендирская речь. Так что ставки высоки. Видео есть на сайте re:Invent. Документация Aurora DSQL здесь.

Это гео‑распределённая SQL‑база с доступностью 99.999%, практически неограниченной масштабируемостью, строгой согласованностью и нулевыми заботами об управлении инфраструктрой.

Главная целевая аудитория — те, у кого приложения, обслуживающие миллионы клиентов по всему Земному Шару.

У СУБД архитектура active‑active (т. е. примерно мультимастер), и все транзакции, записанные в одном регионе, согласованно отображаются на другие регионы. И вообще утверждается, что удалось избавиться от компромиссов «или‑или» (trade‑offs): она И быстрая, И надёжная. Для этого пришлось «переизобрести» архитектуру — отвязать обработку транзакций от хранения. Обещано, что чтение и запись будут в 4 раза быстрее, чем у конкурентов.

Aurora DSQL при синхронизации узлов использует Amazon Time Sync Service на каждом экземпляре Amazon Elastic Compute Cloud (EC2), а там всё привязано к атомным часам, связь с которыми через спутники. Этот же механизм используется для работы глобальных таблиц DynamoDB.

DSQL Vignette: Aurora DSQL, and A Personal Story

Много лет в комьюнити PostgreSQL никто не верил что эта СУБД в принципе может использоваться в системах с большой транзакционной нагрузкой. То есть, какие-то тестовые лаборатории, бэкенд веб-приложений средней руки и так далее — вот его типичные задачи. А когда нужна серьёзная нагрузка, это уже надо брать СУБД за много денег и не сомневаться. Ну и раз никто не верил, то и не развивал особенно его в эту сторону, оставляя всё больше повисших в воздухе вопросов.

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

В то время, как пользователи видят позитивные стороны технологий, мы, разработчики, обычно сталкиваемся с ограничениями/недоработками/багами и видим наш продукт с совсем другой стороны. Вот и в этот раз: после публикации результатов сравнительного тестирования где я прогонял запросы теста Join-Order-Benchmark на базе с партициями и без, меня не отпускало ощущение, что всё-таки что-то я не досмотрел и при наличии партиций постгрес должен строить план хуже, чем без них. И это должен быть не просто баг, а технологическое ограничение. И вот, методом разглядывания потолка удалось-таки найти тонкое место - запросы с лимитами.

Оптимизация Asymmetric Join (AJ) — это новый подход к объединению партицированных связей (partitioned relation, PR) и непартицированных связей (non-partitioned relation, NR). Она заключается в том, что каждая партиция присоединяется с помощью NR, а результаты объединяются путём APPEND. Всё это выглядит как эволюция техники partitionwise join (PWJ).

Работа над ошибками

PostgreSQL: Out-of-cycle release scheduled for November 21, 2024

Дело прошлое - уже вышла 17.2 со свитой из более почтенных версий, где всё поправили. Но история поучительная.

Итак: вышла новость, с восклицательным знаком, как обычно: PostgreSQL: PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 Released!

Ура! Прикрыли дыру CVE-2024-10976: в таблицах с безопасностью на уровне строк можно было подсмотреть или изменить те строки, в которые лезть не положено. После CVE-2023-2455 и CVE-2016-2193 многое поправили, но пропустили случаи подзапросов, запросов с WITH и другие. И всё это в версиях с 12 по 17. Ещё и закрыли уязвимость CVE-2024-10979. Но:

A change to ResultRelInfo - A Near Miss with with Postgres 17.1