Veritabanı Çökmesini Önleyin: Laravel’de Okuma/Yazma Ayrımı

Veri Raporlama Sıkışıklığı

Smart Tech Devs’in B2B SaaS platformu büyüdükçe, standart kullanıcılar ile yönetim ekibi arasında tehlikeli bir veritabanı darboğazı ortaya çıkar. Bir kullanıcı hızlı bir INSERT sorgusu ile ödeme formu gönderirken, CFO aynı anda yıl sonu finansal raporunu çalıştırıyor olabilir ( milyonlarca satırı birleştiren büyük bir SUM() ve GROUP BY sorgusu).

Her iki sorgu da tam olarak aynı PostgreSQL veritabanına ulaşırsa, ağır analitik sorgu büyük miktarda CPU ve RAM tüketecek ve sıklıkla tabloları kilitleyecektir. Kullanıcının hızlı ödeme sorgusu, ağır raporun arkasında sırada sıkışır. Kullanıcı 10 saniye yüklendiği spinner ile karşılaşır, ödeme zaman aşımına uğrar ve ödeme işlemi başarısız olur. Ana uygulama akışlarınızı korumak için, Veritabanı Okuma/Yazma Ayrımı uygulamanız gerekmektedir (CQRS’in pratik bir uygulaması).

Çözüm: Okuma Replica Mimarisi

Tek bir veritabanına güvenmek yerine, kurumsal bulut mimarileri Birincil/Replica kümesini kullanır. Birincil veritabanı, INSERT, UPDATE ve DELETE işlemlerinin %100’ünü yönetir. AWS veya Laravel Forge, bu verileri bir veya daha fazla “Okuma Replica”ya neredeyse gerçek zamanlı olarak otomatik olarak çoğaltır.

Ağır SELECT sorgularınızı Okuma Replica’ya yönlendirerek, yazma veritabanınızı tamamen izole edersiniz. CFO’nun ağır raporu, Replica’nın CPU’sunun %100’ünü tüketebilir ve standart kullanıcının ödeme süreci etkilenmez çünkü tamamen sağlıklı farklı bir sunucuya yazılıyor.

Laravel’de Ayrım Mimarisi Kurmak

Laravel, kutudan çıktığı gibi Okuma/Yazma ayrımını destekler. Bunu database.php dosyanızda yapılandırmanız yeterlidir. Laravel’in sorgu oluşturucusu, sorguları otomatik olarak yönlendirmek için yeterince akıllıdır.

// config/database.php

'mysql' => [
    'driver' => 'mysql',
    
    // 1. ✅ KURUMSAL DÜZEN: Okuma Replicalarını Tanımlayın
    // Laravel, bu ana makinelere SELECT sorgularını rastgele dengeler
    'read' => [
        'host' => [
            '192.168.1.2', // Okuma Replica 1 (Analytics)
            '192.168.1.3', // Okuma Replica 2 (Dashboards)
        ],
    ],

    // 2. Birincil Yazma Veritabanını Tanımlayın
    // Tüm Ekleme, Güncelleme ve Silme işlemleri buraya otomatik olarak yönlendirilir
    'write' => [
        'host' => [
            '192.168.1.1', // Birincil Veritabanı
        ],
    ],

    'sticky' => true, // Kritik ayar! (Aşağıda açıklandı)
    
    'database' => env('DB_DATABASE'),
    'username' => env('DB_USERNAME'),
    'password' => env('DB_PASSWORD'),
    // ...
],

“Sticky” Okuma-Sonrası-Yazma Problemi

Çoğaltma birkaç milisaniye sürdüğü için tehlikeli bir yarış durumu vardır. Bir kullanıcı profilini güncellerse (Birincil’e Yazma) ve hemen ardından profil sayfasına yönlendirilirse (Replica’dan Okuma), Replica henüz güncellenmiş veriye sahip olmayabilir. Kullanıcı, kaydetmenin başarısız olduğunu düşünecektir.

Bunu düzeltmek için, Laravel’in 'sticky' => true yapılandırmasını etkinleştiriyoruz. sticky etkinleştirildiğinde, bir kullanıcı veritabanına veri yazdığında, Laravel tüm sonraki okuma sorgularını o belirli kullanıcının mevcut isteği için direkt olarak Birincil veritabanına yönlendirir, böylece kullanıcı kendi değişikliklerini anında görebilir.

İş Mühendisliği ROI’si

Veritabanı trafiğinizi ayırarak, “gürültücü komşu” veritabanı çöküşlerini tamamen ortadan kaldırırsınız. Ağır iç analitik artık hızlı müşteri ödeme işlemleri için gereken CPU’yu zorlayamaz, bu da Eloquent sorgularınızı yeniden yazmadan büyük dikey ölçeklendirme yetenekleri açar.