PgConf.Russia 2019

Вы только что установили PostgreSQL и запустили ваш первый кластер, создали несколько таблиц, загрузили данные, и даже немного подкрутили конфигурацию Постгреса для улучшения производительности. Теперь вы думаете о том, как сделать ваш кластер высокодоступным. К сожалению, Постгрес не умеет сам выполнять автоматическое переключение при недоступности мастера, но, к счастью для нас, этого можно достичь с помощью сторонних утилит. Задача ясна, и вы начинаете изучать преимущества и недостатки всех утилит, чтобы выбрать лучшую. И... вы уже на неправильном пути, потому что в первую очередь вы должны определиться со значениями SLA, RTO и RPO. В этом докладе я планирую рассказать о ряде ошибок, которые допускают администраторы баз данных при настройке и эксплуатации высокодоступного кластера Постгреса с автоматическим переключением.

Одной из наиболее приятных фич после выхода релиза Postgres v10 стала логическая репликация. В ходе доклада мы рассмотрим, что из себя представляет логическая репликация, как она соотносится с потоковой репликацией, как она работает, конфигурируется, какими ограничениями обладает, с какими подводными камнями можно столкнуться, как решаются вопросы безопасности и управления. Мы также обсудим возможные для развертывания архитектуры с логической и потоковой репликацией и некоторые черты базовой технологии.

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

Надежное резервное копирование и восстановление данных уровня предприятия для среды PostgreSQL. Больше никаких традиционных резервных копий. Технология CBT (Change Block Tracking) - это следующее поколение инкрементного резервного копирования. Быстрее, чем моментальные снимки, CBT создает резервные копии только блоков, которые изменяются, а не всех ваших данных, уменьшая нагрузку на сервер и сетевой трафик и устраняя необходимость в традиционных резервных копиях. Преимущества: • Защита данных в режиме близком к Real-Time • Обновление с легкостью

После перехода к микросервисной архитектуре для PostgreSQL наступили «темные времена». Каждая из десяти команд действовала самостоятельно — ставила свою базу данных, выбирала версию, писала деплои. Пришло время создать общий инструмент.

Мы собрали кластер на основе PostgreSQL, repmgr, PgBouncer, Barman. Несмотря на то, что система получилась достаточно сложной для неподготовленного специалиста, нам удалось создать повторяемый деплой, который позволяет быстро разворачивать рабочую систему. А также мы смогли консолидировать все базы в нескольких кластерах и снять с команд обязанности по администрированию.

Failover работает, мы проверяли :-)