Yandex Cloud
  • Сервисы
  • Решения
  • Почему Yandex Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Language / Region
© 2022 ООО «Яндекс.Облако»
Yandex Managed Service for PostgreSQL
  • Начало работы
  • Пошаговые инструкции
    • Все инструкции
    • Информация об имеющихся кластерах
    • Создание кластера
    • Подключение к базе данных
    • Остановка и запуск кластера
    • SQL-запросы в консоли управления
    • Обновление версии PostgreSQL
    • Изменение настроек кластера и базы данных
    • Подключение к DataLens
    • Управление хостами PostgreSQL
    • Управление базами данных
    • Управление PostgreSQL-расширениями
    • Управление пользователями БД
    • Назначение привилегий и ролей
    • Управление резервными копиями
    • Просмотр логов кластера
    • Удаление кластера
    • Диагностика производительности
    • Мониторинг состояния кластера и хостов
  • Практические руководства
    • Создание кластера PostgreSQL для 1С
    • Выгрузка базы данных в Yandex Data Proc
    • Анализ производительности и оптимизация
    • Репликация и миграция
      • Логическая репликация PostgreSQL
      • Миграция базы данных в Managed Service for PostgreSQL
      • Миграция базы данных из Managed Service for PostgreSQL
      • Создание логической реплики Amazon RDS для PostgreSQL в Managed Service for PostgreSQL
    • Поставка данных в Yandex Managed Service for Apache Kafka® с помощью Yandex Data Transfer
    • Поставка данных в Yandex Managed Service for Apache Kafka® с помощью Debezium
  • Концепции
    • Взаимосвязь ресурсов сервиса
    • Классы хостов
      • Действующие классы хостов
      • Архив
        • До 1 июня 2020 года
      • Использование устаревших классов хостов
    • Сеть в Managed Service for PostgreSQL
    • Квоты и лимиты
    • Хранилище в Managed Service for PostgreSQL
    • Резервные копии
    • Назначение ролей
    • Управление соединениями
    • Репликация
    • Техническое обслуживание
    • Поддерживаемые клиенты
    • Настройки PostgreSQL
  • Управление доступом
  • Правила тарификации
    • Действующие правила
    • Архив
      • До 1 января 2019 года
      • С 1 января до 1 марта 2019 года
      • С 1 марта 2019 года до 1 февраля 2020 года
  • Справочник API
    • Аутентификация в API
    • gRPC (англ.)
      • Overview
      • BackupService
      • ClusterService
      • DatabaseService
      • ResourcePresetService
      • UserService
      • OperationService
    • REST (англ.)
      • Overview
      • Backup
        • Overview
        • get
        • list
      • Cluster
        • Overview
        • addHosts
        • backup
        • create
        • delete
        • deleteHosts
        • get
        • list
        • listBackups
        • listHosts
        • listLogs
        • listOperations
        • move
        • rescheduleMaintenance
        • restore
        • start
        • startFailover
        • stop
        • streamLogs
        • update
        • updateHosts
      • Database
        • Overview
        • create
        • delete
        • get
        • list
        • update
      • ResourcePreset
        • Overview
        • get
        • list
      • User
        • Overview
        • create
        • delete
        • get
        • grantPermission
        • list
        • revokePermission
        • update
      • Operation
        • Overview
        • get
  • История изменений
  • Вопросы и ответы
    • Общие вопросы
    • Подключение
    • Изменение кластера
    • Настройки параметров кластера
    • Перемещение и восстановление кластера
    • Мониторинг и логи
    • Все вопросы на одной странице
  1. Концепции
  2. Управление соединениями

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

Статья создана
Yandex Cloud

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Менее подвержен проблеме исчерпания вычислительных ресурсов при большом количестве клиентских соединений за счет поддержки асинхронной многопоточности на уровне архитектуры Odyssey. Это особенно важно, если большинство клиентских соединений к СУБД осуществляются с помощью SSL/TLS.

      Например, PgBouncer использует однопоточную архитектуру, что при большой нагрузке может приводить к проблемам с потреблением ресурсов и маштабируемостью.

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

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

      Также Odyssey стремится как можно дольше поддерживать клиентское соединение установленным после завершения транзакции, чтобы переиспользовать его, если этот клиент вернется с новой транзакцией. Другой известный пулер, PgBouncer, напротив, стремится как можно быстрее вернуть такое соединение в пул.

    • Предоставляет улучшенные возможности логирования и обработки ошибок:

      • Ошибки на стороне PostgreSQL будут переданы клиентскому приложению без изменений.

        Например, PgBouncer скрывает сообщения об ошибках PostgreSQL: для клиента все ошибки выглядят как ошибка подключения к PgBouncer.

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

      Совет

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

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

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

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

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

    Language / Region
    © 2022 ООО «Яндекс.Облако»