PGConf.Russia 2025

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

Скорее всего, для решения этой задачи вы настраивали дополнительное ПО, которое отслеживало состояние вашего отказоустойчивого кластера и перенаправляло трафик на нужный узел. Чтобы это ПО не превратилось в единую точку отказа, вы разворачивали дополнительную логику по обработке сбоев уже на этом слое. Кроме того, возможно, вы сталкивались с ограничениями Postgres по одновременной обработке большого количества клиентских сессий и с необходимостью пулинга запросов. 

Мы разработали расширение Proxima, которое снимает необходимость в настройке и администрировании дополнительного программного обеспечения. Proxima — масштабируемый, отказоустойчивый прокси-сервер и пулер соединений, способный перенаправлять трафик на пишущий узел, а при работе с BiHA переключение на новый пишущий узел в случае аварии происходит автоматически. 

В докладе я расскажу, как мы делали Proxima, какие архитектурные решения заложены в расширение, почему мы выбрали именно такой подход. Разберем тонкости реализации, которые позволили нам обрабатывать более 10 тысяч одновременных клиентских сессий. Рассмотрим примеры использования и ответим на ваши вопросы

С СОБОЙ НЕОБХОДИМО ИМЕТЬ НОУТБУК! 1. Интеграция с Haproxy 1.1 Опрос с помощью скриптов валидации 1.2 Изменение конфигурации с помощью функций-обработчиков 2. Резервное копирование с помощью pg_probackup 2.1 Настройка копирования с выделенного узла 2.2 Восстановление лидера по резервной копии ведомого 2.3 Восстановление любого ведомого узла 2.4 Восстановление при сбое всего кластера

Доклад о наболевшем и немного об архитектуре приложений. Временные таблицы в приложениях БД используют, как правило, для нескольких целей. Во-первых, они нужны для хранения промежуточных результатов при реализации сложных алгоритмов обработки данных. Во-вторых, в случае использования хранимых процедур именно во временные таблицы сервер приложений помещает данные большого объёма, которые невозможно или неудобно передавать через параметры хранимых процедур. Работа с временными таблицами в различных СУБД организована по-разному, что зачастую затрудняет миграцию из этих СУБД в Postgres. Недостатки временных таблиц широко известны, поэтому возникает обоснованное желание заменить их, по возможности, какими-то другими средствами, позволяющими решать ту же задачу. Доклад посвящён альтернативным механизмам для решения этой проблемы, которые предлагает Postgres.

Доклад содержит рассмотрение двух случаев длительного выполнения create database в PostgreSQL 11, которые в кластерной конфигурации Corosync/Pacemaker приводили к переключению нод из-за таймаута мониторинга от кластерного ПО. Первый случай связан с большим размером shared buffers, а второй — с использованием опции WITH OWNER при создании БД и большим размером системной таблицы pg_shdepend (особенность использования ПО jBPM).