Kurulum · Veritabanları
PgBouncer Transaction Pooling Kurulumu ve Uyumluluk Testi
PgBouncer istemci bağlantılarını PostgreSQL server bağlantılarından ayırır. Transaction pooling, transaction bitince server bağlantısını havuza bırakır; sonraki işlem farklı backend…
Teknik gözden geçirme:
Mimari ve çalışma modeli
PgBouncer istemci bağlantılarını PostgreSQL server bağlantılarından ayırır. Transaction pooling, transaction bitince server bağlantısını havuza bırakır; sonraki işlem farklı backend kullanabilir. Session seviyesinde state tutan uygulama bu kipte ayrıca test edilmelidir.
Önce lab database ve dar erişimli kimlik hazırlayın. PgBouncer listen adresini yönetim/ağ kapsamıyla sınırlayın, authentication ve iki bacağın TLS ayarını tanımlayın. Uygulamayı ayrı pilot portuna yönlendirin; doğrudan DB ile p95 ve hata oranını karşılaştırın.
SET, temp table, advisory lock ve prepared statement ihtiyaçlarını uygulama sürücüsüyle test edin. PgBouncer sürüm ve max_prepared_statements desteği nedeniyle eski “prepared statements hiç çalışmaz” genellemesi doğru değildir; davranışı güncel feature belgesine göre doğrulayın.
- 1Uygulama client
- 2PgBouncer auth/kuyruk
- 3Transaction server havuzu
- 4PostgreSQL commit
Tasarım parametreleri
- Pool büyüklüğü
- default_pool_size database/user havuzlarına göre çoğalabilir; PostgreSQL toplam bağlantı bütçesini koruyun.
- Kuyruk süresi
- Waiting client ve server kullanımını birlikte izleyin; havuz artırımı CPU sınırını aşabilir.
- Kimlik/TLS
- İstemci→pool ve pool→DB güven zincirlerini ayrı doğrulayın.
Hesap ve uygulama örneği
200 client bağlantısı ve iki user/database havuzunda 20’şer server sınırı yaklaşık 40 server bağlantısı üretebilir; reserve pool ve diğer uygulamalar buna eklenir. Kabulde yalnız bağlantı sayısı azalmamalı, uygulama transaction’ları ve prepared statement akışı doğru kalmalıdır.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
[databases]
lab = host=127.0.0.1 port=5432 dbname=lab
[pgbouncer]
listen_addr = 127.0.0.1
listen_port = 6432
pool_mode = transaction
default_pool_size = 20
max_client_conn = 200
; Add version-appropriate authentication and TLS; this is not a complete production configuration.Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Waiting client artıyor | Havuz dar veya uzun transaction. | SHOW POOLS ve DB aktif transaction süresini karşılaştırın. |
| Doğrudan çalışıyor, pool’da bozuk | Session state veya sürücü uyumsuzluğu. | Başarısız sorguyu feature matrisiyle eşleştirin. |
Kabul ve doğrulama kontrolleri
- PostgreSQL bağlantı bütçesini hesaplayın.
- İki TLS bacağını doğrulayın.
- Uygulama transaction’ını test edin.
- Prepared statement uyumunu sınayın.
- Waiting süresini ölçün.
- Doğrudan DB geri dönüşünü planlayın.
İlgili kavramlar
Kuyruk ve eşzamanlılık
Kuyruk, bir kaynağın işleyebildiğinden daha hızlı gelen işleri tutar. Eşzamanlılığı artırmak belirli bir noktaya kadar kapasite kullanımını yükseltir; sonra bekleme süresini büyütür. Durağan durumda Little yasası L = λ × W ilişkisidir: ortalama sistemdeki iş sayısı, tamamlanan iş hızı ile ortalama toplam sürenin çarpımıdır. Birimler tutarlı olmalıdır. 2.000 işlem/s ve 5 ms toplam süre yaklaşık 10 eşzamanlı iş demektir. Bu ilişki tasarım tahminidir; kuyruk sınırları, ani yük ve çok değişken servis süreleri ayrıca ölçülmelidir.
Transaction sınırı
Transaction, uygulamanın belirli işlemleri birlikte başarılı veya başarısız kabul ettiği mantıksal birimdir. Veritabanı içindeki atomiklik, e-posta gönderimi veya farklı servislerdeki değişikliklerin otomatik olarak aynı atomik kapsamda olduğu anlamına gelmez. Commit noktası ve hata sonrasında tekrar denemenin davranışı açık olmalıdır. Aynı isteğin iki kez işlenmesini önlemek için idempotency gereksinimini değerlendirin. Testte ağ kesintisi ve bağlantı kopmasını commit öncesi ve sonrasında ayrı uygulayın; istemcinin hata alması işlemin kesinlikle başarısız olduğu anlamına gelmeyebilir.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
TLS ve sertifika doğrulaması
TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.
Bağımlılık ve geri açılış sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.