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

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

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

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

В архитектуру сервиса 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 производительность такого кластера существенно снижается.

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

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

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

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

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

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

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

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

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

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

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

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

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

  Совет

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

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

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

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