HAProxy ve PGBouncer kullanarak PostgreSQL Yüksek Kullanılabilirlik / Ölçeklenebilirlik


18

Bir web uygulaması için birden fazla PostgreSQL sunucum var. Genellikle, bekleme modunda bir ana ve birden fazla slave (eşzamansız akış çoğaltma).

Bağlantı havuzu oluşturmak için PGBouncer kullanıyorum: localhost üzerindeki veritabanına bağlanan her PG sunucusunda (port 6432) yüklü bir örnek. İşlem havuzu modunu kullanıyorum.

Slave'lerdeki salt okunur bağlantılarımı yük dengelemek için HAProxy (v1.5) 'i az ya da çok bir conf ile kullanıyorum:

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

Bu nedenle, web uygulamam, her PG bağımlı biriminde yapılandırılmış birden çok pgbouncer üzerindeki yük dengesi bağlantılarını haproxy'ye (bağlantı noktası 10001) bağlar.

İşte mevcut mimarimin temsil grafiği:

haproxy> pgbouncer> postgresql

Bu oldukça iyi çalışıyor, ancak bazılarının bunu oldukça farklı şekilde gerçekleştirdiğinin farkındayım: web uygulaması, birden çok PG sunucusu üzerinde yük dengesini sağlayan HAproxy'ye bağlanan tek bir PGBouncer örneğine bağlanır:

pgbouncer> haproksi> postgresql

En iyi yaklaşım nedir? Birincisi (benim şu anki) veya ikincisi mi? Bir çözümün diğerine göre avantajları var mı?

Teşekkürler

Yanıtlar:


10

Mevcut HAProxy -> PGBouncer -> PGServer yaklaşımınız daha iyi. Ve bu sadece işe yarıyor. Nedeni: HAProxy, bağlantıyı farklı sunuculara yönlendirir. bu veritabanı bağlantısında MAC adresi değişikliği ile sonuçlanır. Dolayısıyla, PGBouncer HAProxy'nin üzerindeyse, MAC adres değişikliği nedeniyle havuzdaki bağlantılar her seferinde geçersiz kılınır.


7

pgbouncer, postgres sunuculu bir havuzdaki bağlantıları korur. TCP bağlantısı oluşturma süreleri yüksek hacimli bir ortamda önemlidir.

Çok sayıda DB isteği yapan müşterilerin, her istek için uzak bir PGBouncer ile bağlantı kurmaları gerekecektir. Bu, PgBouncer'ı yerel olarak çalıştırmaktan daha pahalıdır (bu nedenle uygulama yerel olarak pgbouncer'a bağlanır) ve pgBouncer uzak PG sunucusuyla bir bağlantı havuzu tutar.

Bu nedenle, IMO, PGBouncer -> HAProxy -> PGServer, HAProxy -> PGBouncer -> PGServer'dan, özellikle PGBouncer istemci uygulamasında yerel olduğunda daha iyi görünüyor.


2

Donatello'nun verdiği cevaba katılmıyorum.

Uygulamanız yerel bir havuz kullanarak DB bağlantılarını yönetmezse, DB'yi her sorgulaması gerektiğinde yeni bir bağlantı oluşturur; PgBouncer kullanırken aynı şekilde olur, böylece onu kullanarak çok iyi bir gelişme elde edersiniz.

PgBouncer PostgreSQL bağlantılarını birleştirerek yönetirken, uygulamanızın bir bağlantı açmaya harcadığı zaman, bağlantının doğrudan DB'ye açılmasına kıyasla önemli ölçüde düşer. Bunun nedeni PG'nin her bağlantıda kimlik bilgilerini ve her şeyi kontrol etmek ve doğrulamak için oldukça yavaş olmasıdır.

PgBouncer bağlantı zamanını PG'ye kaydettiği için App -> HAProxy -> [PgBouncer -> PostgreSQL] yaklaşımı daha iyidir. Havuzlama modu da dikkate alınması önemlidir. Uygulamanızın davranış biçiminin farkında olmalısınız. Çoğunlukla işlemsel mi? Yoksa, yüksek bir eşzamanlılık ile bir grup küçük SQL cümlesi yürütmek mi? Tüm bu parametrelerin performans üzerinde etkisi vardır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.