Skip to main content

> okuma_kopyası_gecikmesi_ve_read-your-writes_tutarlılığı

Okuma Kopyası Gecikmesi ve Read-Your-Writes Tutarlılığı

Asenkron okuma replikalarıyla veritabanı okuma kapasitesi ölçeklenirken, kullanıcıların bir formu kaydettikten hemen sonra bayat verilerle karşılaşması (stale read) nasıl önlenir?

Stack: SOFTWARE ARCHITECTURE STACK →Staff (L6-L7)tradeoff

⚡ÖZET VE TEKNİK CEVAP

Son güncellenen kayıtlar için okumaları kısa bir süre ana sunucuya (Primary) yönlendiren 'Kendi-Yazdığını-Okuma' (Read-Your-Own-Writes) kuralı uygulayarak veya istemci oturum belirteçlerinde veritabanı LSN/GTID değerlerini takip ederek.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Tek sunucu sınırlarını aşmak için veritabanı mimarileri yazmaları tek bir Ana (Primary) sunucuya iletirken okuma sorgularını asenkron Okuma Replikalarına (Read Replicas) dağıtır. Ağ üzerinden replikasyon asenkron olduğundan, replikalar ana sunucunun milisaniyelerce (yoğun yük altında saniyelerce) gerisinden gelir. Kullanıcı profilini güncelleyip sayfayı yenilediğinde istek geciken bir replikaya giderse eski profil görünür. Çözüm; kullanıcıyı yazma işleminden sonra N saniye boyunca Ana sunucuya sabitlemek (Session Pinning) veya istemci çereziyle işlem LSN/GTID değerini taşıyıp replika o noktaya ulaşana kadar beklemektir.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Asenkron replikasyonlu çok sunuculu veritabanı kümeleri kullanan ve yüksek okuma/yazma oranına (örn. %90 okuma, %10 yazma) sahip tüm web uygulamaları ve API'ler.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk
  • ✓
    1. ▸Bayat Arayüz Anomalisi: Kullanıcının ürün ekledikten sonra listeye dönüp ürünü görememesi ve mükerrer kayıt oluşturması
  • ✓
    1. ▸Ana Sunucu İzdihamı: Bayat veri korkusuyla tüm okumaları Ana sunucuya yönlendirip yazma sunucusunu çökertmek
  • ✓
    1. ▸Ağır Analitik Kilitlenmesi: Replika üzerinde çalışan dev raporların replikasyon iş parçacığını kilitleyip gecikmeyi saatlere çıkarması

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

PostgreSQL replay_lag_bytes, MySQL Seconds_Behind_Master gecikme metrikleri, mükerrer kullanıcı işlem oranları ve Primary/Replica CPU ve disk kullanım dağılımı.

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler
  • ✓

    Çerez tabanlı oturum yönlendirmesi uygulayın (POST/PUT sonrası 5 saniye Primary'den oku)

  • ✓

    ProxySQL veya AWS Aurora gibi araçlarla nedensel tutarlılık proxy'leri kullanın ve ağır raporlama sorgularını özel analitik replikalara ayırın

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

Ödünleşim

Mükemmel yatay okuma ölçeklenebilirliği sağlar ve ana sunucuyu rahatlatır; buna karşılık yönlendirme mantığı karmaşıklığı ve veri yazmayan kullanıcılar için anlık bayatlık riski taşır.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

TinyCTO Vaka 064: Bir bankacılık portalında para transferi yapan kullanıcılar bakiye ekranına yönlendiriliyordu. Bakiye ekranı 400 ms geriden gelen asenkron replikadan okuduğu için eski bakiye göründü; kullanıcılar panikleyip transferi ikinci kez yaptı. Transfer sonrası 3 saniyelik Primary okuma sabitlemesi uygulanarak tüm mükerrer işlem şikayetleri sıfırlandı.

İnteraktif Konsept Alıştırmaları

3 Alıştırma
Q1

'Kendi-Yazdığını-Okuma' (Read-Your-Own-Writes) tutarlılığı nedir?

Bir kullanıcının kendi yaptığı güncellemeleri anında göreceğini garanti eden, diğer eşzamanlı kullanıcıların ise hafif bir replikasyon gecikmesi yaşayabileceği tutarlılık modelidir.
Q2

GTID / LSN takibi nedensel okuma tutarlılığını nasıl sağlar?

Yazma işlemi commit LSN numarasını istemciye döner. Sonraki okuma istekleri bu LSN'i iletir; yönlendirici isteği yalnızca o LSN seviyesine kadar güncellenmiş bir replikaya gönderir.
Q3

Yüksek yazma yükü altında replikasyon gecikmesinin aniden patlamasına ne sebep olur?

Ana sunucular yazmaları çoklu iş parçacığıyla paralel çalıştırırken, geleneksel replikalar WAL günlüklerini tek iş parçacıklı sırayla uygulayarak darboğaza girer.

Okuma Kopyası Gecikmesi ve Read-Your-Writes Tutarlılığı — Sıkça Sorulan Sorular

GET istekleri asla Ana (Primary) veritabanına yönlendirilmemeli midir?

Hayır. Kritik işlemler (ödeme onayı, şifre sıfırlama veya bir POST yazmasının hemen ardından gelen ilk okuma) yarış durumlarını önlemek için doğrudan Primary'den okunmalıdır.

Replikasyon gecikmesi veritabanı bağlantı havuzlarını nasıl etkiler?

Sorgular replikaların yetişmesini beklerse veya bayat veri nedeniyle tekrar denenirse bağlantı tutma süreleri uzar ve PgBouncer gibi havuzlar kilitlenir.

Veritabanı proxy'si olmadan Read-Your-Own-Writes uygulamanın en basit yolu nedir?

Yazma işlemi yapan HTTP yanıtlarına kısa ömürlü bir zaman damgası çerezi (`last_write_at`) koyun. Eğer `şimdi - last_write_at < 5sn` ise sonraki okumaları ana veritabanına yönlendirin.

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

Temel Gerçekler & İlkeler

  • ▸

    Asenkron replikasyon yüksek yazma performansı sunar çünkü Ana sunucu istemciye commit dönmeden önce replikaların onay vermesini beklemez.

  • ▸

    Senkron replikasyon sıfır gecikmeyi garanti eder; ancak yazma gecikmesini kümedeki en yavaş replikanın hızına düşürür.

Yaygın Yanılgılar

  • ✗

    Okuma replikalarının tüm veritabanı darboğazlarını çözeceğini sanmak; eğer yazma hacmi tek Ana sunucuyu kilitliyorsa okuma replikaları hiçbir fayda sağlamaz.

Karar Kılavuzu & Önceliklendirme

Kritik olmayan okuma trafiğinin %90'ını okuma replikalarına yönlendirin; ancak herhangi bir kullanıcı yazma işlemini takip eden 5 saniyelik pencerede okumaları mutlaka ana sunucuya sabitleyin.

Doğrulanmış Kaynaklar & Referanslar