Про асинхронный ввод-вывод в PostgreSQL за последний год написали многие:

Механизм появился в 18-й версии, в 19-й его докрутили и в релиз-нотах он числится среди главных улучшений производительности.

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

Утечка данных почти никогда не выглядит как взлом — чаще это тихий SELECT без LIMIT от роли, у которой и так есть доступ. Заметить такое штатными средствами PostgreSQL почти невозможно: аудита как отдельной подсистемы там нет, а есть лишь разрозненные логи, из которых расследование превращается в quest с grep. В этой статье — как с помощью pg_proaudit и pgpro-otel-collector превратить эту головную боль в один запрос на LogsQL.

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

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

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

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

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

Это вольный перевод поста одного из сильных разработчиков Postgres - Andres Freund. Кроме того что разработчик сильный, так еще и статья довольно интересная и раскрывает детали того как работает ОС Linux.

Довольно часто можно слышать заявления что постгресовые соединения используют слишком много памяти. Об этом часто упоминают сравнивая процессную модель обработки клиентских соединений с другой моделью, где каждое соединение обслуживается в отдельном потоке (thread).

Как по мне, здесь есть что обсудить...

Неделю назад я делал анонс про pgSCV новом экспортере метрик для PostgreSQL. После анонса мне ожидаемо стали писать читатели с намеком что неплохо бы и дашборды сделать. Эта задача есть у меня в списке и этот запрос не оказался для меня сюрпризом. Оно и понятно, метрик ого-го сколько и даже продвинутому DBA понадобится довольно много времени чтобы разобраться в них и соорудить более-менее вменяемый дашборд.

Я занялся вопросом и сделал базовые дашборды которые покрывают некий (но не весь) объем метрик которые есть в pgSCV. А в этом посте я сделаю быстрый обзор и расскажу что там есть.

Всем привет. В этом посте я расскажу про pgSCV - новый экспортер метрик для PostgreSQL (и не только), чем он так хорош и какие проблемы решает.

Пост представляет собой небольшой контрольный список (checklist) при публикации Go приложения на Github'е.

TLDR:

- Makefile как входная точка для выполнения основных действий

- Линтеры и тесты как инструменты повышающие качество кода

- Dockerfile как способ распространения приложения

- Github Actions как возможность автоматической сборки и выкладки приложения при новых изменениях

- Goreleaser как инструмент для публикации релизов и пакетов

Результатом должно быть опубликованное приложение с настроенными инструментами которые позволяют легко сопровождать приложение в процессе его существования. В качестве реализации я буду рассматривать примеры на основе утилиты pgcenter.

Методы наблюдения Golden Signals и RED являются шаблонами при построении мониторинга сервисов и определяют ключевые метрики которые нужны при наблюдении. Раньше об этих методах знали исключительно администраторы мониторинга или SRE. Сейчас тема инструментирования приложений уже не является чем-то новым и об этих методах знают более-менее все.

В этом посте я порассуждаю о том как в мониторинге покрыть PostgreSQL используя методы RED и Golden Signals. Подсистема мониторинга в Postgres реализована в те времена когда RED и Golden Signals еще не было и на мой скромный взгляд в ней есть некоторые недостатки и с ходу натянуть RED или Golden Signals на Postgres может показаться непростой задачей. В этом посте я постараюсь коротко рассмотреть возможности которые предоставляет Postgres для реализации наблюдения по методам RED/Golden Signals и дам конкретные направления к тому чтобы реализовать это. К тому же это на так сложно как можно подумать.

Это цитата одного из моих знакомых который когда-то давно обращался ко мне с вопросом про Postgres. Тогда мы за пару дней порешали его проблему и поблагодарив меня он добавил: "Хорошо, когда есть знакомый DBA".

Но что делать если нет знакомого DBA? Вариантов ответа может быть довольно много, начиная от поискать среди друзей друзей и заканчивая до изучить вопрос самостоятельно. Но какой бы ответ не пришел к вам в голову, у меня для вас хорошая новость. В тестовом режиме мы запустили сервис рекомендаций для Postgres'ов и всего что вокруг них.

Введение в PostgreSQL BDR