PostgreSQL'de Asenkron (Asynchronous) Replikasyon: Nedir, Nasıl Çalışır ve Avantajları Nelerdir?

PostgreSQL'de Asenkron (Asynchronous) Replikasyon

Veri tabanı yönetiminde yüksek kullanılabilirlik (High Availability), felaket kurtarma (Disaster Recovery) ve yük dengeleme (Load Balancing) süreçlerinin merkezinde replikasyon (kopyalama) yer alır. PostgreSQL, verileri bir ana sunucudan (Primary/Master) bir veya birden fazla yedek sunucuya (Standby/Replica) aktarmak için çeşitli yöntemler sunar.

Bu yöntemlerin en yaygını ve PostgreSQL’in varsayılan (default) olarak kullandığı mekanizma Asenkron (Asynchronous) Replikasyondur. Bu makalede, asenkron replikasyonun ne olduğunu, çalışma mantığını, avantajlarını, dezavantajlarını ve hangi senaryolarda tercih edilmesi gerektiğini detaylıca ele alacağız.

1. Asenkron Replikasyon Nedir?

Asenkron replikasyon; ana sunucunun (Primary), üzerine yazılan verileri yedek sunucuya (Standby) gönderirken onların diske yazılmasını veya ulaşıp ulaşmadığını beklemeden istemciye (istemci uygulamasına) “İşlem Başarılı (Commit)” yanıtını dönmesi esasına dayanır.

Buradaki anahtar kelime “beklememektir”. Ana sunucu kendi üzerine düşen yazma ve loglama işlemini bitirir bitirmez yoluna devam eder. Yedek sunucuya veri aktarımı ise arka planda, ana sunucunun performansını doğrudan etkilemeyecek şekilde (asenkron olarak) yürütülür.

2. Çalışma Mantığı ve WAL Mekanizması

PostgreSQL’de asenkron replikasyonun arkasındaki en önemli güç WAL (Write-Ahead Logging) mekanizmasıdır. PostgreSQL’de yapılan her değişiklik (Insert, Update, Delete) önce RAM’de yapılır ve ardından diske yazılmadan önce WAL adı verilen log dosyalarına ardışık olarak kaydedilir.

Asenkron replikasyon sürecinin adımları sırasıyla şu şekildedir:

1. İstemci İsteği: İstemci (Client) ana sunucuya bir yazma isteği gönderir ve işlemi sonlandırmak için COMMIT komutunu tetikler.

2. Yerel Yazma (Local Commit): Ana sunucu, bu değişikliği kendi belleğinde (Shared Buffers) işler ve hemen ardından WAL dosyasına yazar.

3. Anında Onay: Ana sunucu, WAL kaydını diske güvenli bir şekilde yazdığı anda istemciye “İşlem başarıyla tamamlandı” mesajını döner. İstemci sonraki işlemlerine gecikmeksizin devam edebilir.

4. WAL Gönderimi (Arka Plan): Ana sunucudaki wal_sender adı verilen özel bir arka plan süreci, bu yeni WAL kayıtlarını ağ üzerinden yedek sunucudaki wal_receiver sürecine gönderir.

5. Yedekte Uygulama (Redo/Apply): Yedek sunucu (Standby), aldığı WAL kayıtlarını kendi veri dosyalarına uygular (replay eder). Böylece yedek sunucu, ana sunucunun durumuna arkadan gelerek eşitlenmiş olur.

3. Asenkron Replikasyonun Avantajları

Asenkron replikasyonun veri tabanı mimarilerinde bu kadar popüler olmasının çok geçerli sebepleri vardır:

• Maksimum Yazma Performansı: Ana sunucu, ağ üzerinden başka bir makinenin onayını beklemek zorunda kalmaz. Bu sayede uygulamanızın yazma (write) gecikme süreleri (latency) minimumda kalır.

• Ağ Gecikmelerinden Bağımsızlık: Ana sunucu ile yedek sunucu arasında yüksek ağ gecikmesi (örneğin farklı kıtalardaki veri merkezleri) olsa bile bu durum ana sunucunun transaction hızını yavaşlatmaz.

• Yüksek Erişilebilirlik (Sistem Ayakta Kalır): Yedek sunucu kapansa, çökse veya aradaki ağ bağlantısı tamamen kopsa dahi ana sunucu bundan etkilenmez. İstemcilerden gelen yazma isteklerini kabul etmeye ve çalışmaya kesintisiz devam eder.

• Kolay Ölçeklenebilirlik: Tek bir ana sunucuya bağlı onlarca asenkron yedek sunucu (Read Replica) oluşturabilir, okuma yükünü (Read-heavy query) bu yedeklere dağıtarak ana sunucunun yükünü hafifletebilirsiniz.

4. Dezavantajları ve Riskleri

Her mimari kararda olduğu gibi, asenkron replikasyonun sunduğu yüksek performansın da bir bedeli vardır:

• Veri Kaybı Riski (Data Loss): Ana sunucu üzerinde COMMIT edilen ancak henüz ağ üzerinden yedek sunucuya ulaştırılamamış WAL kayıtları bulunabilir. Eğer tam bu milisaniyede ana sunucunun donanımı fiziksel olarak çökerse (veya elektrik kesilirse), yedek sunucuya aktarılamayan o son veriler kaybolur.

• RPO (Recovery Point Objective) $> 0$: Felaket kurtarma senaryolarında kurtarma noktası hedefi (RPO) sıfır değildir. Yani sistem çöktüğünde son birkaç milisaniyelik veya saniyelik veriyi kaybetmeyi göze almanız gerekir.

• Veri Gecikmesi (Replication Lag): Ana sunucudaki yoğun yazma işlemlerinde veya ağ darboğazlarında yedek sunucu ana sunucunun biraz gerisinde kalabilir. Bu süre zarfında yedek sunucudan okuma yapan kullanıcılar, verilerin birkaç saniye önceki eski halini görebilirler (Eventual Consistency).

5. PostgreSQL’de Asenkron Replikasyon Nasıl Yapılandırılır?

PostgreSQL’de asenkron replikasyon kurmak oldukça basittir çünkü bu yöntem varsayılan yapılandırmadır.

1. Ana Sunucu (Primary) Yapılandırması:

postgresql.conf dosyasında asenkron çalışmayı garanti altına almak ve replikasyona izin vermek için şu temel parametreler ayarlanır:

# Replikasyon için WAL seviyesini replica veya logical yapınwal_level = replica

# Maksimum yedek sunucu bağlantı sayısımax_wal_senders = 10

# Senkron replikasyonun kapalı (boş) olduğundan emin olunsynchronous_standby_names = ''

# İşlemlerin yerel disk onayından sonra hemen dönmesini sağlarsynchronous_commit = on # veya local

2. Yedek Sunucu (Standby) Yapılandırması:

Yedek sunucunun ana sunucuya bağlanıp WAL kayıtlarını çekebilmesi için pg_basebackup aracı kullanılarak ana sunucunun bir kopyası çekilir ve yedek sunucuda standby.signal dosyası oluşturulur. Yedek sunucunun postgresql.conf veya connection ayarlarında ana sunucunun bilgileri belirtilir:

primary_conninfo = 'host=192.168.1.50 port=5432 user=replicator password=guvenli_sifre'

Ne Zaman Asenkron Replikasyon Tercih Edilmelidir?

Asenkron replikasyon, aşağıdaki gereksinimlere sahip projeler için biçilmiş kaftandır:

1. Yüksek Performans ve Düşük Gecikme Süresi: Milisaniyelerin kritik olduğu e-ticaret sepet işlemleri, sosyal medya platformları, oyun sunucuları veya IoT veri akışları.

2. Coğrafi Dağıtık Yapılar: Ana sunucunun Avrupa’da, yedek sunucunun (Afet kurtarma merkezi) ise Amerika’da olduğu senaryolar.

3. Okuma Yükünün Dağıtılması: Veri tabanına gelen SELECT sorgularının (raporlama, analiz) ana sunucuyu yormaması için birden fazla “Read Replica” üzerinden karşılandığı durumlar.

4. Kabul Edilebilir Küçük Veri Kayıpları: Sistem çöktüğünde son 1–2 saniyelik verinin (örneğin log kayıtları veya kullanıcı beğenileri) kaybolmasının iş süreçlerini hayati derecede etkilemeyeceği senaryolar.

Eğer sisteminizde kesinlikle tek bir satır dahi veri kaybına tahammülünüz yoksa (örneğin bankacılık transferleri, bakiye güncellemeleri), performans kaybını göze alarak Senkron (Synchronous) Replikasyon modeline geçiş yapmayı değerlendirmelisiniz.