Postgresql

Вертикальное масштабирование PostgreSQL упирается в потолок рано или поздно. Диск перестаёт тянуть IOPS, либо рабочий набор строк уже не влезает в память целиком, как ни добавляй RAM. Citus — расширение, которое раскладывает таблицы по нескольким узлам вместо одного, но снаружи остаётся обычным PostgreSQL: тот же psql, те же типы, тот же SQL. Таблица создаётся как обычно, а дальше — одна функция: CREATE TABLE github_events (event_id bigint, repo_id bigint, payload jsonb); SELECT create_distributed_table('github_events', 'repo_id'); Citus хэширует значения repo_id и раскладывает строки по шардам. Каждый шард физически — обычная таблица PostgreSQL на одном из worker-узлов, а координатор хранит только схему распределения и маршрутизирует запросы к нужным шардам. Количество шардов задаётся заранее через citus.shard_count, и если две таблицы логически связаны (например, события и репозитории одного repo_id), их стоит объединить через colocate_with — иначе джойн между ними полетит по сети между узлами вместо локального выполнения на одной машине. ...

По умолчанию checkpoint_timeout — 5 минут, а max_wal_size — 1 GB: PostgreSQL запускает checkpoint каждые 5 минут или раньше, если накопилось больше гигабайта WAL. На нагруженной базе второе условие срабатывает первым, и checkpoint случается заметно чаще, чем каждые 5 минут — сервер постоянно сбрасывает грязные буферы на диск, и это видно по скачкам latency в самые непредсказуемые моменты. Проверить, насколько часто это происходит, можно по логу: если включить checkpoint_warning (по умолчанию 30 секунд) и checkpoint’ы начинают случаться чаще этого порога, PostgreSQL сам пишет в лог предупреждение, что max_wal_size стоит увеличить. Частое появление такого сообщения — не повод для паники с первого раза, но если оно встречается регулярно, значит параметры checkpoint пора пересматривать. ...

Декларативное партиционирование в PostgreSQL требует, чтобы кто-то заранее создавал секции под будущие даты — вручную или крон-скриптом, иначе вставка в несуществующий диапазон просто упадёт с ошибкой. TimescaleDB — это расширение поверх PostgreSQL, которое берёт ровно эту рутину на себя: таблица превращается в hypertable, а партиции («чанки») создаются автоматически по мере поступления данных. CREATE TABLE metrics ( time TIMESTAMPTZ NOT NULL, host TEXT NOT NULL, cpu_percent DOUBLE PRECISION ); SELECT create_hypertable('metrics', 'time'); Снаружи metrics выглядит как обычная таблица — тот же INSERT, тот же SELECT — но физически строки лежат по чанкам фиксированного временного интервала (по умолчанию 7 дней, меняется через chunk_time_interval в create_hypertable или глобально через timescaledb.default_chunk_time_interval). Новый чанк создаётся сам, как только приходит строка с временем за пределами существующих — никакого аналога CREATE TABLE ... PARTITION OF под будущий месяц заранее. ...

pgBackRest и barman одинаково умеют складывать WAL-архив и бэкапы в S3, но оба выросли из эпохи, когда основным хранилищем была локальная файловая система, а объектное хранилище — опциональный репозиторий поверх. WAL-G спроектирован наоборот: он написан на Go и с первого дня целится именно в object storage как основной репозиторий, без промежуточного слоя абстракций под POSIX-пути. ...

Barman и pgBackRest оба бэкапят PostgreSQL, но по-разному устроены внутри. Исторически Barman строился вокруг rsync поверх SSH: backup_method = rsync копирует файлы кластера по ssh-соединению, а archiver = on принимает WAL-сегменты через archive_command, которая переносит их на сервер бэкапов. Со стороны PostgreSQL это полностью агентless-модель — отдельный процесс не нужен, достаточно ssh-доступа. ...

Patroni сам не хранит состояние кластера — кто сейчас лидер, список реплик, таймстемп последнего обновления лежат в etcd, отдельном распределённом key-value хранилище. На каждом цикле HA-проверки Patroni ходит в etcd, читает и продлевает lease лидера; без доступного DCS Patroni не может быть уверен, кто сейчас главный, и не имеет права безопасно переизбирать лидера. ...

До десятой версии PostgreSQL партиционирование собирали вручную через наследование таблиц и триггеры на INSERT — рабочая, но хрупкая конструкция, которую легко сломать неосторожным DDL. Декларативное партиционирование сделало то же самое штатным синтаксисом: секции объявляются прямо при создании таблицы, а планировщик сам знает о структуре и использует её при построении плана запроса. Синтаксис для диапазонов по дате — обычное дело для таблиц с логами или метриками: CREATE TABLE measurement ( city_id int NOT NULL, logdate date NOT NULL, peaktemp int, unitsales int ) PARTITION BY RANGE (logdate); CREATE TABLE measurement_y2026m10 PARTITION OF measurement FOR VALUES FROM ('2026-10-01') TO ('2026-11-01'); Для PARTITION BY LIST значения перечисляются явно, что удобно для партиционирования по региону или арендатору (tenant) в мультитенантной схеме: ...

Обычная streaming-репликация в PostgreSQL копирует кластер байт-в-байт — WAL одинаковый на всех репликах, и реплика обязана быть той же мажорной версии, что и мастер. Логическая репликация работает иначе: она декодирует WAL в поток изменений строк (insert/update/delete) и применяет их через обычный SQL. Из-за этого можно реплицировать не весь кластер, а отдельные таблицы, и версии publisher/subscriber могут отличаться — это штатный способ мигрировать между мажорными релизами без pg_upgrade и почти без простоя. ...

pg_basebackup делает ровно одну вещь — снимает физическую копию кластера, а всё остальное (расписание, ретеншн, инкременты, сжатие в несколько потоков) приходится дописывать самому в обвязке на bash. pgBackRest с самого начала проектировался как отдельный инструмент именно под эти задачи, а не как обёртка вокруг pg_basebackup. ...

Разбирать log_min_duration_statement через pgBadger — рабочий, но окольный путь узнать, какие запросы реально тормозят продакшен. pg_stat_statements считает эту статистику сам, в реальном времени, без парсинга логов. ...