Многие разговоры про бэкапы начинаются с присказки что люди делятся на две категории… так вот я отношусь к тем людям которые делают бэкапы. Правильно настроенное резервное копирование и проверка резервных копий укрепляет сон. А наличие заранее написаных и проигранных инструкций по восстановлению вообще укрепляет пищеварение и иммунитет. Так вот, за время работы с PostgreSQL мне довелось часто настраивать резервное копирование, при этом условия и требования были самые разные. Однако при этом набор инструментов за редким исключением оставался неизменным. В этой статье поделюсь своим опытом в деле, как можно брать резервные копии PostgreSQL.

Zabbix + Iostat: мониторинг дисковой подсистемы.

Зачем?
Дисковая подсистема одна из важных подсистем сервера и от уровня нагрузки на дисковую подсистему зачастую зависит очень многое, например скорость отдачи контента или то как быстро будет отвечать база данных. Это в большей степени относится к почтовым или файловым серверам, серверам БД. Вобщем, показатели дисковой производительности отслеживать нужно. На основании графиков производительности дисковой подсистемы мы можем принять решение о необходимости наращивания мощностей задолго до того как петух клюнет. Да и вобще полезно поглядывать от релиза к релизу как работа разработчиков сказывается на уровне нагрузки.

Под катом, о мониторинге и о том как настроить.

Всем кому приходилось сталкиваться с процедурой failover при работе с потоковой репликацией в PostgreSQL, наверняка озадачивались вопросом: «А как бы мне ничего заново не копировать, а по-быстрому завести старый мастер в качестве stand-by». Так вот к сожалению, встроенной такой функциональности в PostgreSQL, увы нет. Да, нельзя так просто взять и подключить старый мастер к новому и чтобы все заработало. Для этого нужно повторить процесс настройки потоковой репликации заново, т.е. скопировать весь кластер и запустить postgres в режиме hot-standby.
К счастью работы в этом направлении ведутся, причем результаты довольно не плохие. Называется же проект pg_rewind.
Сразу предупреждаю это еще не production-ready и пост носит характер how-to + technology preview.

В течение минуты думал над заголовком, так ничего и не придумал…
Strace. Наверное нет того человека, который бы не слышал про strace. Если кто не слышал, то strace — это утилита, отслеживающая системные вызовы, которые представляют собой механизм трансляции, обеспечивающий интерфейс между процессом и операционной системой (ядром). Эти вызовы могут быть перехвачены и прочитаны. Это позволяет лучше понять, что процесс пытается сделать в заданное время. Перехватывая эти вызовы, мы можем добиться лучшего понимания поведения процессов, особенно если что-то идет не так. Функциональность операционной системы, позволяющая отслеживать системные вызовы, называется ptrace. Strace вызывает ptrace и читает данные о поведении процесса, возвращая отчет. Детали можно прочитать в вики или официальном man. Собственно вот, ну и речь конечно же о Linux. В других ОС свои аналоги.
Так вот, лично для меня strace это как последняя инстанция. Когда уже все логи просмотрены, все debug и verbose ключи включены, а причина проблем так и не обнаружена, я достаю из широких штанин запускаю strace. Есть одно но, strace это такой инструмент который вовсе не является серебряной пулей, которая тут же все покажет и расскажет. Для работы с strace требуется наличие определенных знаний и чем шире и глубже эти знания тем больше вероятность обнаружения проблемы.
В интернетах полно вводных статей, где описываются примеры запуска strace. Я же в этой статье покажу частные проблемы и их решение с помощью strace.

Предположим что у нас есть postgresql в режиме потоковой репликации. master-сервер и hot-standby готовый заменить погибшего товарища. При плохом развитии событий, нам остается только создать trigger-файл и переключить наши приложения на работу с новым мастером. Однако, возможны ситуации когда вполне законные изменения были сделаны криво написанной миграцией и попали как на мастер, так и на подчиненный сервер. Например, были удалены/изменены данные в части таблиц или же таблицы были вовсе удалены. С точки зрения базы данных все нормально, а с точки зрения бизнеса — катастрофа. В таком случае провозглашение горячего hot-standby в мастера, процедура явно бесполезная…
Для предостережения такой ситуации есть, как минимум, два варианта…

Думаю многим известна особенность PostgreSQL, которая приводит к эффекту раздувания таблиц, или table bloat. Известно что она проявляет себя в случаях интенсивного обновления данных, как при частых UPDATE так и при INSERT/DELETE операциях. В результате такого раздувания снижается производительность. Рассмотрим почему это происходит и как с этим можно бороться.

Статья — заметка, выросшая из вопроса, заданного в Q&A. Вкратце дело было так… Был предложен вариант тестирования PostgreSQL на определенной файловой системе и стоял вопрос, нормальный ли это подход и можно ли хоть как-то доверять результатам этого теста. В ходе обсуждения вопроса альтернативных вариантов не нашлось и я решил тестировать как и задумал изначально.

Всем доброго времени суток!
Как известно, недавно вышел PostgreSQL 9.2 с массой интересных и полезных вещей. Недолго думая мы решили обновить наш кластер потоковой репликации с 9.0 на 9.2. Все бы ничего, если бы не несколько обстоятельств:

• это продакшен с большой суточной посещаемостью.
• даунтайм исключен.

Чтож, так даже интересней… Как мы это делали и что из этого вышло читайте дальше.