Skip to main content

> pgbouncer_ve_ölçekte_bağlantı_havuzu_tıkanması

PgBouncer ve Ölçekte Bağlantı Havuzu Tıkanması

Yüksek verimli canlı mimarilerde PgBouncer ve Ölçekte Bağlantı Havuzu Tıkanması yapısını nasıl doğru kurar ve yönetirsiniz?

Stack: SOFTWARE ARCHITECTURE STACK →Senior (L5)antipattern

ÖZET VE TEKNİK CEVAP

PgBouncer bağlantı tıkanması, veritabanı bağlantı havuzlarının yetersiz boyutlandırılması, uzun süren işlemlerle kilitlenmesi veya oturum ile işlem havuzlama modlarının yanlış yapılandırılması sonucu isteklerin kuyruğa girip zaman aşımına uğramasıdır.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

PostgreSQL her istemci bağlantısı için ayrı bir işletim sistemi süreci açar ve yüzlerce bağlantıda ciddi CPU/RAM maliyeti yaratır. PgBouncer binlerce istemci bağlantısını küçük bir sunucu havuzuna bağlayan hafif bir proxydir. Ancak yanlış havuz modu veya açık unutulan işlemler bağlantıları rehin alarak tüm servisi kilitler.

2. Doğru Kullanım Senaryosu

PgBouncer bağlantı tıkanması, havuzdaki tüm veritabanı sunucu bağlantılarının meşgul olması veya kilit beklemesi sebebiyle yeni sorguların kuyrukta birikip zaman aşımına uğradığı sistem arızasıdır.

3. Prodüksiyon Arıza Modları

Veritabanı işlemi açıp işlem içinde yavaş harici HTTP çağrıları veya dosya yüklemeleri yaptıktan sonra commit etmek. 200 podluk Kubernetes kümesinde `max_connections=100` olan veritabanı için Oturum Havuzlama (Session) kullanmak. 4 çekirdekli veritabanında `default_pool_size=1000` yaparak işletim sistemini CPU bağlam değiştirme (context switch) krizine sokmak.

4. Teşhis ve Telemetri Sinyalleri

sunucu süreçlerinin PostgreSQL max_connections sınırını aşması, uzun süren işlemlerin havuzdaki bağlantıları tüketmesi, işlem havuzlama modunda prepared statement hataları

5. Önleme ve Mimari Bariyerler

PgBouncer 1.21+ sürümünün protokol düzeyinde prepared statement desteğiyle İşlem Havuzlama (Transaction Pooling) kullanın. Veritabanı işlemlerini son derece kısa tutun (<50 ms) ve işlem bloğu içinde asla harici ağ çağrısı yapmayın. PostgreSQL sunucu bağlantı sınırı için temel altın kuralı uygulayın: `Havuz Boyutu = (2 * CPU Çekirdeği) + Disk Sayısı`.

6. Mimari Ödünleşimler (Trade-offs)

Bağlantı havuzu tükenmesi uçurum etkisi yaratan bir arızadır: havuz kuyruğu dolmaya başladığı an veritabanı yanıt süresi katlanarak artar, üst HTTP sunucularının iş parçacıkları tükenir ve tüm platform çöker.

Vaka İncelemesi (TinyCTO Örneği)

Yüksek eşzamanlı mimarilerde PgBouncer havuzlama modlarını anlamak hayatidir: 1. **İşlem Havuzlaması (Transaction Pooling - Önerilen):** Sunucu bağlantısı istemciye yalnızca tek bir işlem (`BEGIN` ... `COMMIT`) süresince atanır. İşlem bittiğinde bağlantı anında havuza döner. *Dikkat:* İsimlendirilmiş prepared statement'lar, `LISTEN/NOTIFY` ve geçici tablolar bu modda varsayılan olarak çalışmaz. 2. **Oturum Havuzlaması (Session Pooling):** Sunucu bağlantısı istemcinin TCP bağlantısı boyunca istemciye rehin kalır. Tüm özelliklerle uyumludur ancak aktif istemci sayısını veritabanının `max_connections` sınırına hapseder. 3. **İfade Havuzlaması (Statement Pooling):** Her bir SQL sorgusundan sonra bağlantı havuza döner (çoklu sorgulu işlemler yasaktır). Bağlantı tıkanmasını önlemek için `query_wait_timeout` ile hızlı hata verin, `statement_timeout = '5s'` uygulayın ve havuzu pod sayısına göre değil veritabanı CPU çekirdeğine göre boyutlandırın.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

PgBouncer'da Oturum Havuzlama ile İşlem Havuzlama arasındaki temel fark nedir?

Oturum havuzlama istemcinin tüm TCP süresince bağlantıyı tutar; işlem havuzlama ise COMMIT/ROLLBACK yapıldığı an bağlantıyı havuza iade eder.
Q2

Veritabanı işlemi içinde harici bir Stripe HTTP API çağrısı yapmak neden bağlantı havuzunu tıkar?

Çünkü veritabanı bağlantısı ağ çağrısını beklerken yüzlerce milisaniye boyunca meşgul tutulur ve diğer sorgular için bağlantı kalmaz.

PgBouncer ve Ölçekte Bağlantı Havuzu Tıkanması — Sıkça Sorulan Sorular

Uygulamanız kampanya sırasında 20'den 200 poda çıkıyor. Doğrudan PostgreSQL bağlantısında veritabanı 'FATAL: sorry, too many clients already' ile çöküyor. Doğru mimari nedir?

İşlem Havuzlama (Transaction Pooling) modunda PgBouncer kurarak 2000 istemci bağlantısını 30 sunucu bağlantısı üzerinde çoğullamak. İşlem Havuzlama modundaki PgBouncer, binlerce kısa ömürlü istemci sorgusunu CPU için en uygun küçük bir sunucu havuzunda çoğullayarak süreci kurtarır.

Modern geçici çözümler olmadan PgBouncer İşlem Havuzlama moduna alındığında hangi PostgreSQL özelliği tarihsel olarak hataya yol açıyordu?

İsimlendirilmiş Sunucu Taraflı Prepared Statement'lar ve Oturum düzeyindeki değişkenler (`SET timezone`). İşlem havuzlama modunda aynı istemcinin sonraki sorguları farklı sunucu bağlantılarına gidebileceği için oturuma bağlı prepared statement tanımları kaybolur.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸PgBouncer bağlantı tıkanması, veritabanı bağlantı havuzlarının yetersiz boyutlandırılması, uzun süren işlemlerle kilitlenmesi veya oturum ile işlem havuzlama modlarının yanlış yapılandırılması sonucu isteklerin kuyruğa girip zaman aşımına uğramasıdır.
  • ▸PgBouncer bağlantı tıkanması, havuzdaki tüm veritabanı sunucu bağlantılarının meşgul olması veya kilit beklemesi sebebiyle yeni sorguların kuyrukta birikip zaman aşımına uğradığı sistem arızasıdır.

Yaygın Yanılgılar

  • ✗Veritabanı işlemi açıp işlem içinde yavaş harici HTTP çağrıları veya dosya yüklemeleri yaptıktan sonra commit etmek.

Karar Kılavuzu & Önceliklendirme

Bağlantı havuzu tükenmesi uçurum etkisi yaratan bir arızadır: havuz kuyruğu dolmaya başladığı an veritabanı yanıt süresi katlanarak artar, üst HTTP sunucularının iş parçacıkları tükenir ve tüm platform çöker.

Doğrulanmış Kaynaklar & Referanslar

İlgili Kavramlar

https://tinycto.tv/topics/software-architecturehttps://tinycto.tv/incidentpedia