PostgreSQL Висока доступність / масштабованість за допомогою HAProxy та PGBouncer

У мене є кілька серверів PostgreSQL для веб-програми. Зазвичай один ведучий і кілька підлеглих в режимі гарячого очікування (асинхронна потокова реплікація).

Я використовую PGBouncer для об'єднання з'єднань: один екземпляр, встановлений на кожному PG-сервері (порт 6432), що підключається до бази даних на localhost. Я використовую режим пулу транзакцій.

Для того щоб завантажити баланс моїх з’єднань лише для читання на рабах, я використовую HAProxy (v1.5) з конфіденційності більш-менш, як це:

listen pgsql_pool 0.0.0.0:10001
        mode tcp
        option pgsql-check user ha
        balance roundrobin
        server master 10.0.0.1:6432 check backup
        server slave1 10.0.0.2:6432 check
        server slave2 10.0.0.3:6432 check
        server slave3 10.0.0.4:6432 check

Отже, мій веб-додаток підключається до haproxy (порт 10001), який підключає баланс навантаження на декількох pgbouncer, налаштованих на кожному PG-підлеглому.

Ось графік представлення моєї поточної архітектури:

Це працює досить добре, як це, але я розумію, що деякі реалізують це зовсім інакше: веб-додаток підключається до одного екземпляра PGBouncer, який підключається до HAproxy, який балансує навантаження на декількох серверах PG:

Який найкращий підхід? Перший (мій поточний) чи другий? Чи є переваги одного рішення над іншим?

Спасибі

Ваша існуюча конфігурація програми HAProxy -> PGBouncer -> PGServer краще. І це тільки працює. Ось причина: HAProxy перенаправляє з'єднання на різні сервери. це призводить до зміни MAC-адреси підключення до бази даних. Отже, якщо PGBouncer вище HAProxy, щоразу, коли з'єднання в пулі стають недійсними через зміну MAC-адреси.

pgbouncer підтримує з'єднання в пулі з сервером postgres. Часи встановлення з'єднання TCP є важливими у середовищі з великим обсягом.

Клієнтам, які роблять велику кількість запитів БД, доведеться встановити з'єднання з віддаленим PGBouncer для кожного запиту. Це дорожче, ніж запуск PgBouncer локально (тому додаток підключається до pgbouncer локально) і pgBouncer підтримує пул зв’язків із віддаленим сервером PG.

Отже, IMO, PGBouncer -> HAProxy -> PGServer, здається, краще, ніж HAProxy -> PGBouncer -> PGServer, особливо коли PGBouncer є локальним для клієнтської програми.

Я повинен не погодитися з відповіддю, наданим donatello.

Ви бачите, якщо ваша програма не керує з'єднаннями DB з використанням локального пулу, вона створюватиме нове з'єднання щоразу, коли потрібно запитувати БД; це відбувається точно так само при використанні PgBouncer, тому ви будете мати дуже гарне покращення, використовуючи його.

Коли PgBouncer керує з'єднаннями PostgreSQL, об'єднуючи їх, час, який ваша програма витрачає на відкриття з'єднання, значно падає порівняно з тим, коли з'єднання відкривається безпосередньо в БД. Це тому, що PG досить повільно перевіряє та перевіряє облікові дані та все щоразу, коли запит на з'єднання.

Отже, підхід App -> HAProxy -> [PgBouncer -> PostgreSQL] є кращим, оскільки PgBouncer економить час підключення до PG. Важливо враховувати і режим об'єднання. Ви повинні знати про те, як поводиться ваш додаток. Це переважно трансакційні? Або це більше виконати купу маленьких речень SQL з високою сумісністю? Усі ці параметри впливають на продуктивність.