Развертывание PgBouncer на Heroku и изучение того, как это работает

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

В этой статье давайте рассмотрим фактическое развертывание PgBouncer в существующем приложении, чтобы увидеть, как это работает. Для этой настройки я собираюсь использовать Heroku, чтобы мы могли быстро развернуть что-то и работать с минимальными хлопотами. Процесс будет простым, поскольку Heroku является поставщиком PaaS и выполняет за нас большинство шагов DevOps. Другие провайдеры IaaS и PaaS, вероятно, предлагают нечто подобное, и даже если вы предпочитаете работать на низком уровне, реализовать PgBouncer не так уж сложно.

Я собираюсь основывать свой пример на этом руководстве по PgBouncer и этом руководстве по Postgres пулу соединений от Heroku.

Архитектурные решения

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

Поскольку реализация на стороне сервера на Heroku все еще находится в стадии бета-тестирования, мы несколько ограничены другими вариантами конфигурации. Если вам нужны дополнительные параметры конфигурации, вам нужно будет использовать установку на стороне клиента. Но обычно, помимо развертывания сервера или клиента, вы также должны учитывать следующее.

Режим пула подключений

В PgBouncer доступны три различных режима пула соединений. Эти режимы точно определяют, когда соединение возвращается в пул соединений. Доступны следующие режимы:

  • Оператор - соединение возвращается в пул, как только оператор выполняется (автоматическая фиксация всегда включена).
  • Транзакция - соединение возвращается в пул, как только транзакция завершается (выполняется фиксация или откат).
  • Сеанс - соединение возвращается в пул, как только пользовательский сеанс закрывается.

Как правило, вы хотите использовать режим транзакции, поскольку большинству приложений требуется соединение с базой данных только тогда, когда транзакция происходит - между транзакциями большинство приложений ожидают пользователя, выполняют логику и т. Д. И не нуждаются в подключении к базе данных. . Однако стоит прочитать типичные варианты использования для каждого режима, чтобы убедиться, что вы используете лучший из них.

Настройки бассейна

Для PgBouncer существует довольно много настроек пула. Например, вот пять общих настроек:

  • pool_size - Прямо как звучит: размер пула. По умолчанию - 20. Для серверных планов Heroku значение по умолчанию составляет половину лимита подключений вашего плана.
  • reserve_pool_size - резервный пул, используемый во время всплесков использования.
  • max_db_connections - Максимальное количество подключений к базе данных. Для серверных планов Heroku по умолчанию установлено три четверти лимита подключений вашего плана.
  • max_user_connections - максимальное количество подключений, разрешенных для одного пользователя.
  • max_client_conn - максимальное разрешенное количество входящих клиентских подключений (среди всех пользователей). Для серверных планов Heroku значение по умолчанию - 1000.

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

В нашем примере мы будем использовать режим транзакции и настройки пула по умолчанию, настроенные Heroku при установке.

Развертывание нашего примера

Я хотел начать с развертывания, в котором уже используется Postgres, а затем преобразовать его в пул соединений. Я собираюсь использовать этот проект в качестве базового развертывания (и снова это руководство по Postgres пулу соединений). В этом проекте развертывается приложение Node.js, подключенное к базе данных Postgres (без объединения в пул). На его настройку и работу уходит около 10 минут, поэтому он идеально подходит для нашего быстрого примера.

Если вы раньше не использовали Heroku, но все же хотите продолжить, не волнуйтесь - руководство проведет вас через пошаговые инструкции. Единственное изменение, которое вам нужно сделать, - это подготовить базу данных ближе к концу настройки. Поскольку вы не можете использовать версию для хобби для пула подключений, вместо этого вам нужно использовать стандартный план (самый дешевый ежемесячный план). Используйте эту строку в интерфейсе командной строки Heroku для подготовки базы данных:

$ heroku addons:create heroku-postgresql:standard-0

Когда вы закончите настройку и ваше приложение будет запущено и запущено, вы можете открыть свое приложение (с /db в конце URL-адреса) и увидеть эту страницу:

Большой! Если вы следовали этому руководству, у вас все готово с приложением Node.js, подключенным к Postgres с тестовой таблицей. Теперь давайте посмотрим, насколько просто начать использовать пул соединений с PgBouncer. Всего несколько простых шагов с использованием интерфейса командной строки Heroku:

  • Включить пул. Приведенная ниже команда создает как пул, так и URL-адрес пула соединений (с использованием текущего URL-адреса базы данных).

$ heroku pg:connection-pooling:attach DATABASE_URL — as DATABASE_CONNECTION_POOL

  • Измените свою конфигурацию, чтобы использовать URL-адрес пула вместо URL-адреса базы данных:

  • Зафиксируйте изменения и перезапустите.

Вот и все! В качестве быстрого теста я внес бессмысленное изменение кода для клиента, чтобы посмотреть, что произойдет. Здесь я зацикливаю и открываю 999 операторов select для пула:

Развернув этот код, я дважды нажал URL-адрес /db. Давайте посмотрим на статистику после каждого забега, чтобы увидеть, что происходило. Чтобы просмотреть статистику, сначала используйте команду heroku config, чтобы найти URL-адрес пула соединений с базой данных. Затем введите следующую команду, используя URL-адрес пула соединений с базой данных и заменив последний компонент пути на pgbouncer:

$ psql postgres://username:password@ec2–192–168–1–1.compute-1.amazonaws.com:5433/pgbouncer

Теперь вы можете попробовать разные варианты, например show stats или show pools.

Вот что мы видим с show stats_totals после двух прогонов. На уровне db выполняется множество запросов:

А теперь show pools, пока выполняются запросы. Для всех этих запросов используется только одно активное соединение:

Успех! Мы запускаем PgBouncer пул подключений на Postgres.

Что дальше?

При использовании PgBouncer и других пулов подключений следует учитывать несколько вещей. Вот несколько вещей, о которых следует знать, и ресурсы, которые помогут вам копать дальше.

Мониторинг

Хотя вы можете использовать show stats, как в моем примере, это довольно простые показатели. Когда вы используете пул соединений, вам нужно будет использовать более надежное решение для мониторинга. Прочтите эту статью об использовании фреймворков USE и RED при мониторинге пулов соединений.

Клиент против сервера

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

Подготовленные заявления

Поскольку подготовленные операторы по своей природе создаются до открытия соединения с базой данных, они обычно вызывают проблемы с пулами соединений. Опять же, я рекомендую FAQ по PgBouncer как место для начала этой темы.

Заключение

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