Veritabanı replikasyonu nasıl çalışır? Read replica kullanırken replication lag ve read-your-writes sorununu nasıl çözersiniz?

Replikasyon, bir veritabanındaki (primary) değişikliklerin bir veya daha fazla kopyaya (replica) aktarılmasıdır. Amaçlar: okuma yükünü dağıtmak, yüksek erişilebilirlik (failover) ve yedekleme.

Türler

• Asenkron: primary commit eder, değişikliği sonra gönderir. Hızlıdır ama primary çökerse son commit'ler kaybolabilir ve replica'lar geriden gelir (lag).
• Senkron: commit en az bir replica onaylayınca tamamlanır. Veri kaybı olmaz ama yazma gecikmesi artar.
• Semi-sync (MySQL) ve PostgreSQL'deki synchronous_commit seviyeleri arada bir denge sunar.

PostgreSQL WAL (write-ahead log) kayıtlarını streaming replication ile gönderir; MySQL binlog kullanır.

Replication lag sorunu

1. Kullanıcı profilini günceller   -> primary
2. Sayfa yenilenir, profil okunur   -> replica (henüz güncel değil)
3. Kullanıcı eski veriyi görür: "kaydetmedi mi?"

Read-your-writes çözümleri

1. Yazmadan sonra primary'den oku: kullanıcı son N saniye içinde yazdıysa (cookie veya session'da timestamp) onun okumalarını primary'ye yönlendirin.
2. Kritik okumaları her zaman primary'ye yönlendirin: ödeme durumu, bakiye, stok gibi.
3. LSN/GTID takibi: yazma sonrası primary'nin log pozisyonunu saklayın, replica bu pozisyona ulaşana kadar bekleyin veya primary'ye düşün.
4. Uygulama tarafında yanıtı kullanın: güncelleme endpoint'i yeni kaydı döndürsün, istemci tekrar okumasın.

Ayrıca bilinmesi gerekenler

• Lag'i izleyin: PostgreSQL'de pg_stat_replication içindeki replay_lag, MySQL'de Seconds_Behind_Source.
• Replica'ya giden uzun analitik sorgular lag'i artırabilir veya PostgreSQL'de sorgu iptallerine yol açabilir.
• Failover sırasında asenkron replikasyonda veri kaybı ve split-brain riski vardır; yönetilen servisler (RDS, Cloud SQL) veya Patroni gibi araçlar bunu yönetir.
• Spring'de @Transactional(readOnly = true) ile routing datasource kurularak okumalar replica'ya yönlendirilebilir.