Управление соединениями PostgreSQL
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
Интеграция 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 автоматически обеспечивает отказоустойчивость менеджера подключений в кластерах из нескольких хостов.