PostgreSQL Çökmelerini Önleme: Veritabanı Bağlantı Havuzu Yönetimi

“Çok Fazla İstemci” Krizi

<p>Smart Tech Devs'teki B2B SaaS platformunuz büyüdükçe, kaçınılmaz olarak daha fazla backend işleme gücü eklemeniz gerekecek. Üç yeni Laravel web sunucusu kurup arka plan kuyruk işçilerinizi iki katına çıkardığınızda, birden API'niz kritik bir 500 hatası vermeye başlar: <code>FATAL: sorry, too many clients already</code>.</p>

<p>Buradaki mimari hata, PostgreSQL'ün bellek yönetiminden kaynaklanıyor. Her seferinde bir Laravel işçisi veritabanına bağlandığında, PostgreSQL özel, ağır bir arka plan süreci başlatır. Varsayılan olarak, PostgreSQL genellikle <code>max_connections</code> değerini 100 ile sınırlıdır. Eğer altyapınızı 150 paralel kuyruk işçisine ölçeklendirirseniz, anında veritabanı bağlantı havuzunu tüketir ve uygulamanız tamamen çöker. Sadece <code>max_connections</code> değerini 5,000'e artırmak da mümkün değildir; aksi takdirde veritabanı RAM’i tükenecek ve çöküş yaşanacaktır. Yatay ölçeklenme için bir  Connection Pooler  kullanmalısınız.</p>

<h2>Çözüm: PgBouncer Multiplexleme</h2>

<p> PgBouncer  gibi bir bağlantı havuzlayıcı, Laravel uygulamanız ile PostgreSQL veritabanınızın arasında yer alır.</p>

<p>Laravel veritabanına doğrudan bağlanmak yerine, PgBouncer’a bağlanır. PgBouncer, Laravel işçilerinize binlerce hafif bağlantı sağlar, ancak bunları PostgreSQL'e gerçek bağlantılardan (örneğin, 50) oluşan küçük, yüksek optimize edilmiş bir havuzda çoklayarak yönetir. Bir işçi bir sorgu çalıştırması gerektiğinde, PgBouncer derhal 50 aktif veritabanı bağlantısından birini ödünç verir ve sorgu bitene kadar bu bağlantıyı geri alır.</p>

<h3>Adım 1: Laravel'i PgBouncer için Yapılandırma</h3>

<p>PgBouncer veritabanı sunucunuzda kurulduktan (veya AWS RDS Proxy veya DigitalOcean gibi bir yönetilen sunucuda sağlandığında), Laravel'in veritabanı yapılandırmasını güncellemeniz gerekir. PgBouncer "işlem modu"nda çalıştığı için, Laravel'in PDO sürücüsüne kalıcı bağlantılar veya oturum durumuna bağlı hazırlama durumu emülasyonunu kullanmaması gerektiğini belirtmelisiniz.</p>

<pre><code>

// config/database.php

‘pgsql’ => [
‘driver’ => ‘pgsql’,
// 1. Host’u PgBouncer portuna (genellikle 6432), standart 5432 değil
‘host’ => env(‘DB_HOST’, ‘127.0.0.1’),
‘port’ => env(‘DB_PORT’, ‘6432’),
‘database’ => env(‘DB_DATABASE’, ‘forge’),
‘username’ => env(‘DB_USERNAME’, ‘forge’),
‘password’ => env(‘DB_PASSWORD’, ”),
‘charset’ => ‘utf8’,
‘prefix’ => ”,
‘prefix_indexes’ => true,
‘search_path’ => ‘public’,
‘sslmode’ => ‘prefer’,

// 2. KRİTİK: İşlem-Modu Havuzlama için PDO seçeneklerini yapılandırın
'options' => [
    // PgBouncer'ın güvenli bir şekilde çoklamasını sağlamak için PDO'nun hazırlığı yerel olarak yapması gerektiğini onaylayın
    PDO::ATTR_EMULATE_PREPARES => true,
    // Bir havuzlayıcı aktif olduğunda asla kalıcı bağlantılar kullanmayın
    PDO::ATTR_PERSISTENT => false,
],

],

<h3>Adım 2: Kuyruk Bağlantılarını Ayırma</h3>

<p>Arka plan kuyrukları genellikle bağlantıları açık tutma konusunda kötü üne sahiptir. Nihai kararlılık için, birçok kurumsal mimari iki PgBouncer havuzu işletir: anlık HTTP web istekleri için yüksek öncelikli bir havuz ve arka plan kuyruk işçileri için sıkı bir şekilde sınırlı bir ikincil havuz, böylece arka plan işlerinin canlı web uygulamanızın veritabanı erişimini kıstırmasını engeller.</p>

<h2>Mühendislik ROI'si</h2>

<p>PgBouncer'ı uygulamak, uygulamanızın ölçeğini veritabanı bağlantı limitlerinden temelde ayırır. Trafik artışı sırasında 500 yeni Laravel kuyruk işçisini anında başlatabilirsiniz, hiçbir PostgreSQL yapılandırmasını değiştirmeden. Veritabanı RAM kullanımı önemli ölçüde düşer, sorgu gecikmesi iyileşir ve altyapınız bağlantı akınlarına karşı sağlam bir dayanıklılığa kavuşur.</p>