PGConf.Russia 2025

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

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

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

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

При нагрузочном тестировании PostgreSQL бенчмарки замеряют время исполнения запроса (latency). Для более объективного результата запрос выполняется большое количество раз — из этого получается некоторый набор latency. Для оценки производительности PostgreSQL на данном запросе можно использовать стандартные методы, такие как медиана или среднее, но мы предлагаем использовать более комплексный подход. Как показала практика, такие выборки часто бывают мультимодальными и состоят из различных распределений с некоторыми параметрами. 

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

Работа DBA бывает очень многогранной: бэкапы, обновления версий, проблемы с производительностью, — перечислять можно долго. Но иногда из-за занятости мы не обращаем должного внимания на нововведения, которые не относятся напрямую к тому, что мы делаем каждый день. Так получилось и с логической репликацией.

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

На этом и будет основан мой доклад: мы начнём с теории (как всегда, подход — меньше теории, больше практики) и простых примеров, затем перейдём к более сложным примерам работы. Обратим особое внимание на то, что изменилось в современных версиях PostgreSQL.

Доклад будет полезен тем, кто хочет познакомиться с логической репликацией или обновить свои знания по этому инструменту.

Что необходимо дать современному прикладному разработчику, чтобы он перешёл из привычных облачных решений к использованию SQL-БД? Практический отчёт о том, как превратить базу данных на SQL в NoSQL-решение с привычным для прикладных разработчиков интерфейсом. Речь идёт о том, что ожидает прикладной разработчик от фреймворка для работы с данными, и как это реализовать поверх интерфейса SQL, в частности, декларативный DDL, контроль доступа, автоматизацию при записи и получении данных, упрощённый DML, пагинацию и другие функции, необходимые в прикладной разработке.