Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Yandex Managed Service for PostgreSQL
  • Начало работы
    • Взаимосвязь ресурсов сервиса
    • Планирование топологии кластера
    • Сеть в Managed Service for PostgreSQL
    • Квоты и лимиты
    • Хранилище в Managed Service for PostgreSQL
    • Резервные копии
    • Назначение ролей
    • Управление соединениями
    • Репликация
    • Техническое обслуживание
    • Поддерживаемые клиенты
    • Настройки PostgreSQL
    • Индексы
    • Ограничения для команд SQL
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • Публичные материалы
  • История изменений
  • Обучающие курсы
  1. Концепции
  2. Управление соединениями

Управление соединениями PostgreSQL

Статья создана
Yandex Cloud
Обновлена 11 марта 2025 г.

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

Чтобы решить проблему нехватки ресурсов, перед кластером PostgreSQL размещается менеджер подключений. Он управляет соединениями, позволяя подключиться к СУБД большому числу клиентов без деградации производительности. Между менеджером подключений и СУБД поддерживается относительно небольшое количество соединений, которые можно переиспользовать. После отключения клиента соединение возвращается в пул и может быть повторно использовано тем же самым или новым клиентом.

Такая схема развертывания усложняет администрирование, т. к. к инфраструктуре СУБД добавляются серверы, на которых расположен менеджер подключений.

В архитектуру сервиса Managed Service for PostgreSQL уже интегрирован менеджер подключений Odyssey, разработанный Яндексом.

Odyssey поддерживает три режима управления соединениями:

  • Сессионный (по умолчанию):

    В этом режиме клиентское соединение устанавливается при первом запросе к базе данных и поддерживается до тех пор, пока клиент не разорвет сессию. Затем это соединение может быть использовано другим или этим же клиентом. Такой подход позволяет хорошо переживать момент установления большого количества клиентских соединений к СУБД (например, при старте приложений, обращающихся к базам данных).

    Такой режим поддерживается всеми клиентами PostgreSQL, но является менее производительным, чем транзакционный режим.

  • Транзакционный:

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

    Транзакционный режим обеспечивает высокую производительность и позволяет максимально эффективно нагрузить СУБД. Однако такой режим поддерживается не всеми клиентами PostgreSQL, и в нем недоступно использование:

    • временных таблиц (temporary tables), курсоров (cursors) и рекомендательных блокировок (advisory locks), которые существуют дольше одной транзакции;

    • подготовленных операторов (prepared statements).

    Примечание

    Чтобы создать подготовленный оператор в Managed Service for PostgreSQL, используйте функциональность драйвера СУБД. Создание подготовленного оператора с помощью SQL-запроса PREPARE не поддерживается.

  • Режим запроса:

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

    Такой подход полезен при включенном режиме AUTOCOMMIT для клиентских сессий, когда каждая транзакция уже ограничена одним запросом. Однако режим запроса поддерживается не всеми клиентами PostgreSQL, а при одновременном включении режима AUTOCOMMIT и настройки synchronous_commit = remote_apply производительность такого кластера существенно снижается.

Режим работы менеджера подключений можно изменить после создания кластера.

Примечание

Время жизни самой длинной активной сессии/транзакции задается настройкой СУБД уровня кластера Session duration timeout.

Особенности OdysseyОсобенности Odyssey

Интеграция Managed Service for PostgreSQL с менеджером подключений Odyssey имеет ряд преимуществ, например по сравнению с менеджером подключений PgBouncer:

Сравнительный критерий Odyssey PgBouncer
Потребление ресурсов Кластер Managed Service for PostgreSQL менее подвержен проблеме исчерпания вычислительных ресурсов при большом количестве клиентских соединений за счет поддержки асинхронной многопоточности на уровне архитектуры Odyssey. Это особенно важно, если большинство клиентских соединений к СУБД осуществляются с помощью SSL/TLS. PgBouncer использует однопоточную архитектуру, что при большой нагрузке может приводить к проблемам с потреблением ресурсов и масштабируемостью.
Поддержка клиентских соединений Odyssey стремится как можно дольше поддерживать клиентское соединение установленным после завершения транзакции, чтобы переиспользовать его, если этот клиент вернется с новой транзакцией. PgBouncer стремится как можно быстрее вернуть такое соединение в пул.
Обработка ошибок Кластер Managed Service for PostgreSQL предоставляет улучшенные возможности обработки ошибок. Благодаря этому ошибки на стороне Greenplum® будут переданы клиентскому приложению без изменений. PgBouncer скрывает сообщения об ошибках Greenplum®. В результате для клиента все ошибки выглядят как ошибка подключения к PgBouncer.

Кроме того, благодаря интеграции с Odyssey кластер Managed Service for PostgreSQL:

  • Поддерживает большое число клиентских соединений без деградации производительности СУБД.

  • Не нуждается в дополнительном конфигурировании менеджера подключений и не требует дополнительной инфраструктуры для его работы.

  • Позволяет ограничивать количество соединений как глобально на уровне кластера, так и на уровне отдельных пользователей.

  • Поддерживает продвинутый транзакционный пулинг: автоматическую отмену операции (cancel) и откат транзакции (rollback) при разрыве клиентского соединения.

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

    Совет

    При возникновении проблем с подключением к кластеру Managed Service for PostgreSQL обратитесь в техническую поддержку. Для ускорения поиска решения проблемы сообщите полный текст сообщения об ошибке, включающий в себя идентификатор соединения.

  • Поддерживает прохождение потоков логической репликации через менеджер подключений.

    Примеры использования логической репликации приведены в разделе Логическая репликация.

Также Managed Service for PostgreSQL автоматически обеспечивает отказоустойчивость менеджера подключений в кластерах из нескольких хостов.

Была ли статья полезна?

Предыдущая
Назначение ролей
Следующая
Репликация
Проект Яндекса
© 2025 ООО «Яндекс.Облако»