Из-за того, что у меня недостаточно информации об используемой архитектуре и она основана только на очень описательном примере, я загружаю информацию, полученную в результате исследования, позволяющую членам сообщества завершить/дополнить этот ответ.
На основе эта документация PgBouncer не имеет внутренней многоузловой конфигурации. Для балансировки нагрузки запросов между несколькими серверами можно использовать внешние инструменты, такие как:
DNS циклический перебор. Используйте несколько IP-адресов за одним DNS-именем. PgBouncer не ищет DNS каждый раз, когда запускается новое соединение. Вместо этого он кэширует все IP-адреса и выполняет внутренний циклический перебор. Примечание: если за одним именем более 8 IP-адресов, серверная часть DNS должна поддерживать протокол EDNS0. Подробности смотрите в README.
Использовать Балансировщик нагрузки TCP-соединения. Либо ЛВС или же HAProxy кажутся хорошими вариантами. Со стороны PgBouncer может быть хорошей идеей сделать server_lifetime меньше, а также поворот server_round_robin on: по умолчанию простаивающие соединения повторно используются алгоритмом LIFO, который может работать не так хорошо, когда нужна балансировка нагрузки.
Этот блог объясняет, зачем использовать другой механизм балансировки нагрузки с pgBouncer.
В соответствии с этим вы не должны использовать pgBouncer вместо HAProxy или другого балансировщика нагрузки.Очевидно, что pgBouncer имеет несколько настраиваемых функций, определяющих, к чему обращается балансировщик нагрузки, но чаще всего в средах prod используется HAProxy или какой-либо другой балансировщик нагрузки для высокой доступности. Причина этого в том, что HAProxy лучше распределяет рабочие нагрузки между действующими серверами, чем pgbouncer.
Хотя pgbouncer лучше подходит для пула соединений postgres, может быть лучше использовать один небольшой демон, который отлично выполняет одну задачу, вместо более крупного демона, который выполняет две задачи, но хуже.
Также неплохо использовать PgPool. Смотрите также этот ответ.
Здесь также статья, в которой сравниваются PgBouncer и PgPool. Небольшая часть этого:
| | PGBUNCER | PGPOOL-II |
|--|--|--|
| Высокая доступность |Не поддерживается. |Высокая доступность PostgreSQL поддерживается встроенными процессами-наблюдателями Pgpool-II. Победитель! |
|Балансировки нагрузки|Не поддерживается — PgBouncer рекомендует использовать HAProxy для обеспечения высокой доступности и балансировки нагрузки.| Поддерживает автоматическую балансировку нагрузки — достаточно интеллектуален, чтобы перенаправлять запросы на чтение на резервные серверы и на запись на ведущие. Победитель! |
