Администрирование и поддержка PostgreSQL
Сопровождение, отказоустойчивые кластеры, оптимизация запросов, резервное копирование и мониторинг. В том числе на Astra Linux и российских сборках.
Что делаем
Постоянное администрирование PostgreSQL вместо штатного DBA: кто-то должен смотреть на сервер до того, как он ляжет.
- Контроль роста базы, распухания таблиц и индексов
- Настройка autovacuum под реальную нагрузку, а не по умолчанию
- Обновление версий в согласованное окно
- Разбор инцидентов и разбор того, почему они повторяются
Кластер PostgreSQL на Patroni: автоматическое переключение на реплику вместо ручного восстановления посреди ночи.
- Настройка кластера Patroni с etcd, кворум и защита от split-brain
- Синхронная и асинхронная репликация, реплики под отчётность
- Точка входа для приложений: HAProxy или pgbouncer
- Учения по переключению - до того, как оно понадобится всерьёз
Оптимизация запросов PostgreSQL начинается с измерения, а не с покупки железа.
- Поиск тяжёлых запросов по pg_stat_statements и статистике ожиданий
- Разбор планов выполнения, индексы: отсутствующие и лишние
- Блокировки, долгие транзакции, пулинг соединений
- Настройка памяти, контрольных точек и параллелизма под нагрузку
Резервное копирование PostgreSQL, из которого действительно можно восстановиться.
- pgBackRest или WAL-G, полные и инкрементальные копии
- Непрерывное архивирование WAL и восстановление на точку во времени
- Хранение копий вне сервера базы, контроль сроков хранения
- Регулярная проверка восстановлением, а не отметкой «задание выполнено»
Мониторинг PostgreSQL в Zabbix или в связке с Grafana: доступность и репликация, распухание таблиц, длинные транзакции, блокировки, использование соединений, успешность бэкапов. Настраиваем не «чтобы графики были», а чтобы алерт приходил до того, как проблему заметят пользователи. Работает и как отдельная задача, и как часть абонентского обслуживания.
Работаем с PostgreSQL на Astra Linux, РЕД ОС и российских сборках Postgres Pro, включая замкнутую программную среду и требования к защите информации. Разворачиваем и сопровождаем в закрытом контуре без доступа в интернет, с учётом того, что часть привычных инструментов и репозиториев там недоступна.
Если задача - уйти с MS SQL или Oracle, начинать нужно не с установки, а с оценки объёма переноса: см. консультации по архитектуре.
Как начать
Диагностика одного инстанса - 30 000 ₽, три рабочих дня. Отчёт со списком проблем по приоритетам и оценкой работ.
Настройка кластера, бэкапов, мониторинга, оптимизация запросов - по часам, 4 200 или 6 500 ₽/час.
Абонентское обслуживание - 150 000 ₽/мес до 5 инстансов, реакция на критический инцидент за 1 час.
Частые вопросы
Работаете с российскими сборками PostgreSQL?
Да. Postgres Pro, Postgres Pro Enterprise, сборки в составе Astra Linux и РЕД ОС - всё это тот же PostgreSQL с надстройками, приёмы администрирования те же. Особенности сборки учитываем: свои пакеты, свои пути, свои ограничения на версии расширений.
Что такое autovacuum и почему он всегда виноват?
Autovacuum убирает мёртвые версии строк, которые PostgreSQL оставляет после каждого UPDATE и DELETE. При настройках по умолчанию на нагруженной базе он не успевает: таблицы распухают, планы запросов портятся, а на пике autovacuum запускается сам и съедает ресурсы в худший момент. Лечится настройкой порогов и стоимости под конкретные таблицы, а не глобально.
Нужен ли нам отказоустойчивый кластер?
Зависит от того, сколько стоит час простоя. Одиночный сервер с бэкапами восстанавливается часами. Кластер на Patroni переключается за десятки секунд, но требует дисциплины в эксплуатации: кворум, свидетель, разнесение по площадкам. Если час простоя стоит дешевле, чем сопровождение кластера, - кластер не нужен, и мы так и скажем.
У нас нет собственного DBA. Кто будет сопровождать то, что вы настроите?
Либо вы, по переданному runbook, либо мы в рамках абонентского обслуживания. Настроить кластер и уйти - плохая идея: отказоустойчивость держится не на конфигурации, а на том, что кто-то следит за состоянием репликации и регулярно проверяет восстановление из бэкапов.
Как понять, что база тормозит из-за запросов, а не из-за железа?
По статистике ожиданий: видно, чего именно ждут сессии - диска, блокировок, процессора или сети. Запускается это за один рабочий день. Чаще всего причина в паре тяжёлых запросов и отсутствующих индексах, а не в нехватке ресурсов, и покупка железа проблему только откладывает.
Проверяете ли вы, что бэкапы восстанавливаются?
Да, и это отдельный пункт работ. Бэкап, который никогда не разворачивали, - это не бэкап, а надежда. Настраиваем непрерывное архивирование WAL и восстановление на точку во времени, а затем регулярно проверяем разворачиванием на отдельном сервере.
Расскажите о задаче - мы предложим подходящий формат.