Veritabanı Çöküşlerini Durdurun: Laravel’de Okuma Replikalarını Usta Seviyeye Taşıyın

Raporlama Bottleneck’i

Smart Tech Devs’teki B2B SaaS platformunuz olgunlaştıkça, veritabanı okuma ve yazma oranları ciddi şekilde dengesizleşir. Kullanıcılar verileri sadece ara sıra ekleyip güncellerken (yazma), sürekli olarak panelleri yükler, karmaşık analizler oluşturur ve devasa CSV raporları export ederler (okuma). Eğer tek bir birincil PostgreSQL veritabanına bağımlıysanız, ağır analitik sorgular tüm mevcut CPU ve RAM’i tüketir. Bu durumda, basit INSERT işlemleri (bir kullanıcının kaydolmaya çalışması gibi) bir kuyruğa zorlanır ve bu durum API zaman aşımına neden olarak uygulamanızı felç eder.

Büyük ölçek için mimarlık yapmak adına, trafiğimizi fiziksel olarak ayırmalıyız. Tüm ekleme, güncelleme ve silme işlemlerini Birincil (Yazma) Veritabanına yönlendirirken, karmaşık SELECT sorgularını bir veya daha fazla Okuma Kopyasına aktarıyoruz.

Laravel’de Okuma/Yazma Ayrımı Mimarisi

PostgreSQL ve bulut sağlayıcıları (AWS RDS veya DigitalOcean gibi), bir Okuma Kopyasını birkaç tıklamayla oluşturmanızı sağlar. Kopya, sürekli olarak birincil veritabanı ile senkronize edilir. Zorluk, uygulamanıza trafiği nasıl yönlendireceğini öğretmektir.

Neyse ki, Laravel bunu olağanüstü bir zarafetle yer native. Eloquent sorgularınızı yeniden yazmanıza gerek yok. Yapmanız gereken, config/database.php dosyanızı ayarlamak ve ayrımı tanımlamaktır.

Adım 1: Veritabanı Konfigürasyonu

// config/database.php

'pgsql' => [
    'driver' => 'pgsql',
    
    // 1. Birincil (Yazma) Bağlantıyı Tanımlayın
    'write' => [
        'host' => [env('DB_HOST_PRIMARY', '127.0.0.1')],
    ],

    // 2. Okuma Kopyalarını Tanımlayın (Yük dengeleme için birden fazla ekleyebilirsiniz)
    'read' => [
        'host' => [
            env('DB_HOST_REPLICA_1', '127.0.0.1'),
            env('DB_HOST_REPLICA_2', '127.0.0.1'),
        ],
    ],

    // 3. "Eski Veri" sorununu önleyin (KRİTİK)
    'sticky' => true,

    // Hem okuma hem de yazma veritabanları için paylaşılan kimlik bilgileri
    'port' => env('DB_PORT', '5432'),
    'database' => env('DB_DATABASE', 'forge'),
    'username' => env('DB_USERNAME', 'forge'),
    'password' => env('DB_PASSWORD', ''),
    'charset' => 'utf8',
    'prefix' => '',
    'schema' => 'public',
    'sslmode' => 'prefer',
],

Replikasyon Gecikmesini “Sticky” Bayrağıyla Çözmek

Okuma Kopyalarının fiziksel bir gerçeği vardır: Replikasyon Gecikmesi. Birincil veritabanında yapılan bir yazmanın Okuma Kopyasına kopyalanması birkaç milisaniye (veya ağır yük altında saniyeler) alır.

Bir kullanıcının şirket adını güncelleyip “Kaydet”e tıkladığını hayal edin. Laravel, birincil veritabanına yazar ve kullanıcıyı kontrol paneline geri yönlendirir. Kontrol paneli anında bir SELECT sorgusu gerçekleştirir ve bu sorgu Okuma Kopyasına yönlendirilir. 100ms’lik replikasyon gecikmesi nedeniyle Okuma Kopyası henüz güncellemeyi almamıştır. Kullanıcı eski şirket adını görür ve uygulamanızın bozulduğunu varsayar.

Laravel konfigürasyonunuzda 'sticky' => true ayarını yaparak, çerçeve harika bir güvenlik ağı sağlar. Eğer mevcut HTTP istek döngüsü içinde bir yazma işlemi gerçekleştirilirse, Laravel geçici olarak tüm sonraki okuma sorgularını aynı istek döngüsü içerisinde birincil veritabanına yönlendirir. Bu, eski veri ile ilgili kullanıcı deneyimi sorununu tamamen ortadan kaldırırken, yine de global okuma trafiğinizin %99’unu kopyalara yönlendirmiş olursunuz.

Sonuç

Bir veritabanını ölçeklendirmek, her zaman daha iyi SQL yazmakla ilgili değildir; çoğu zaman altyapı yönlendirmesi ile ilgilidir. Okuma Kopyaları uygulayarak ve Laravel’in yer native okuma/yazma ayrımı ile sticky oturumlarını kullanarak, birincil veritabanınızı analitik tükenmişlikten korur ve B2B SaaS’inizin büyük kurumsal yük altında hızla çalışmasını sağlarsınız.