Резервное копирование PostgreSQL с помощью pg_probackup: высокая производительность и острая форма паранойи

Как бэкапировать PostgreSQL? Как хранить сделанные бэкапы? Как валидировать бэкап? Как валидировать PostgreSQL и можно ли ему вообще доверять? Можно ли доверять твоему инструменту? Как сделать всю эту паранойю удобной и производительной, если СУБД не помогает в этом деле? На какие компромиссы можно идти и на какие ни в коем случае нельзя? Создавая свой инструмент бэкапирования, мы были вынуждены искать ответы на эти и многие другие вопросы, о чем и хотелось бы рассказать.

Басня про тестирование и postgres

Однажды вот Питон и Слон
Вести тестирование взялись.
И вместе все в него впряглись!

В нашей компании (Postges Professional) разрабатываются разные проекты: multimaster, pg_probackup, pg_pathman, pg_shardman, RUM, и другие. Совладать со всей этой оравой весьма непросто, поэтому нам необходим инструмент, который способен облегчить и ускорить написание всевозможных тестов.

В данном докладе мы расскажем о фреймворке testgres, написанном на Python, который уже позволил решить множество проблем и протестировать функциональность, которую нельзя так просто покрыть прямолинейными регрессионными тестами.

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

Мы стремимся сделать testgres фреймворком для проведения функциональных тестов пользовательских запросов, хранимых процедур и прочей серверной логики, привнося практику TDD на уровнь разработки БД.

PostgreSQL High Availability кластер для Enterprise

В последнее время PostgreSQL все чаще используется для Enterprise. Наша компания Ingram Micro Cloud была одной из первых, кто сделал это. Мы уже много лет используем PostgreSQL в качестве основной СУБД для наших продуктов. В докладе мы хотим рассказать об эволюции нашего High Availability (HA) кластера PostgreSQL: как мы в сжатые сроки внедряли решение на pgpool-II, писали failover сценарии, тестировали Postgres-XL и придумывали необычные конфигурации Stolon. Немного поговорим о проблемах балансировки нагрузки, пуллинга соединений и бекапировании.

Давайте отключим vacuum?!

Такой призыв часто возникает, когда в PostgreSQL возникают проблемы, и главным подозреваемым оказывается vacuum. По опыту, многие наступают на эти грабли, и мне с коллегам по Data Egret нередко приходится разгребать последствия, так как потом всё становится ещё хуже. Но если обратить внимание на сам vacuum, то, пожалуй, нет такого человека, который бы использовал Postgres, и при этом ничего не знал про вакуум. Ведь история вакуума начинается относительно давно, и в интернете можно найти массу как старых, так и новых постов про вакуум, объемные дискуссии в списках рассылки. Несмотря на то, что тема вакуума подробно описана в официальной документации к PostgreSQL, новые посты и новые дискуссии будут появляться и дальше. Возможно, поэтому с вакуумом связано очень много мифов, баек, страшилок и заблуждений. Между тем, вакуум является одним из важнейших компонентов PostgreSQL, и его работа напрямую сказывается на производительности. В одном докладе невозможно рассказать про вакуум абсолютно всё, но я бы хотел раскрыть ключевые моменты, связанные с вакуумом, такие как его внутреннее устройство, основные подходы к его настройке, наблюдение за производительностью, мониторинг, и что делать в случае, когда вакуум - главный подозреваемый во всех бедах. Ну и, конечно же, хочется развеять распространенные мифы и заблуждения, связанные с вакуумом.