Veritabanı Felaket Kurtarma: Always On ve Replikasyon

Hızlı Özet (TL;DR)

Kurumsal ERP, MES (Üretim Yürütme Sistemi), WMS (Depo Yönetimi) ve finansal yazılım altyapılarının kalbi ilişkisel veritabanlarıdır. Yalnızca gece saat 02:00’de alınan geleneksel tam yedeklere (.bak veya pg_dump) güvenmek, öğleden sonra saat 16:00’da yaşanan bir donanım arızasında işletmeyi 14 saat öncesine fırlatarak o günkü tüm üretim, irsaliye ve stok kayıtlarının silinmesine yol açar. Microsoft SQL Server Always On Availability Groups (AG) ve PostgreSQL Streaming Replication (Patroni/WAL) mimarileri; birincil veritabanına gelen her bir işlemi (Transaction) milisaniyeler içinde ağ üzerinden ikincil sunuculara kopyalayarak Sıfır Veri Kaybı (RPO = 0) ve saniyeler mertebesinde Otomatik Yük Devretme (RTO < 30 sn Automatic Failover) güvencesi sağlar.

Geleneksel Gece Yedeklerinin RPO ve RTO Çıkmazı

Bir üretim tesisinde felaket kurtarma (Disaster Recovery - DR) ve iş sürekliliği mimarisi tasarlanırken iki temel mühendislik metriği baz alınır:

1. RPO (Recovery Point Objective - Kurtarma Noktası Hedefi): Felaket anında işletmenin kaybetmeyi göze alabileceği maksimum veri süresidir. Eğer sadece her gece 24 saatte bir tam yedek alınıyorsa RPO değeriniz 24 saattir. Saatte bir Transaction Log yedeği alınıyorsa RPO 1 saate düşer; ancak yoğun sevkiyat yapan bir fabrikada 1 saatlik barkod ve e-irsaliye verisinin kaybolması dahi kaosa neden olur. Sıfır veri kaybı (RPO = 0) yalnızca gerçek zamanlı senkron replikasyon ile mümkündür.
2. RTO (Recovery Time Objective - Kurtarma Süresi Hedefi): Ana sunucu çöktükten sonra sistemin tekrar çalışır hale gelip operatörlerin ekrana girebilmesi için geçen toplam kesinti süresidir. 1.5 Terabayt büyüklüğündeki bir ERP veritabanı yedeğini (.bak) yedekleme ünitesinden yeni bir sunucuya kopyalayıp geri yüklemek (Restore) en az 4 ila 8 saat sürer. Oysa aktif-pasif replikasyon kümesinde (Cluster) ikincil sunucu zaten canlı verinin birebir kopyasını üzerinde hazır tuttuğu için rol değişimi (Failover) 10 ila 30 saniye içinde tamamlanır.

Senkron ve Asenkron Veritabanı Replikasyonu Karşılaştırma Matrisi

Veritabanı replikasyonu kurgulanırken sunucular arasındaki fiziksel mesafe ve ağ gecikmesi (Network Latency) dikkate alınarak Senkron (Synchronous-Commit) veya Asenkron (Asynchronous-Commit) modlarından biri (ya da her ikisinin hibrit kombinasyonu) tercih edilir:

Değerlendirme Kriteri	Senkron Replikasyon (Synchronous Commit)	Asenkron Replikasyon (Asynchronous Commit)
Veri Kaybı Riski (RPO)	Tam Sıfır (RPO = 0 / Zero Data Loss)	Milisaniyeler veya birkaç saniye seviyesinde çok düşük
İşlem Onay (Commit) Akışı	İkincil sunucu logu diske yazdığını onaylayana kadar işlem bekler	Ana sunucu işlemi kendi diskine yazar yazmaz onay verir, arkadan gönderir
Yazma Gecikmesi (Latency)	Ağ gidiş-dönüş süresi (RTT) kadar yazma süresine ekleme yapar	Ana sunucunun yazma performansına sıfır gecikme etkisi vardır
İdeal Ağ ve Lokasyon	Aynı sistem odası, kampüs içi fiber hat veya < 2 ms gecikmeli yakın DC	Farklı şehirdeki felaket kurtarma merkezi (DRC) veya bulut bölgesi
Yük Devretme (Failover)	Tam Otomatik (Automatic Failover) güvenle uygulanır	Veri farkı olabileceği için yönetici onaylı Manuel (Forced) Failover
Kurumsal En İyi Uygulama	Yerel kümede 1. İkincil Sunucu (HA - Yüksek Erişilebilirlik)	Uzak şehirdeki 2. İkincil Sunucu (DR - Coğrafi Felaket Kurtarma)

Microsoft SQL Server Always On Availability Groups (AG) Mimarisi

Kurumsal ERP sistemlerinde (Logo, Mikro, Netsis, SAP ve Maysa özel imalat çözümleri) en yaygın kullanılan veritabanı motoru olan Microsoft SQL Server, Always On Availability Groups teknolojisiyle hem sunucu hem de veritabanı seviyesinde kurumsal yedeklilik sunar.

1. Transaction Log Hardening (Kütük Sertleştirme) Nasıl Çalışır?

Bir kullanıcı ERP ekranında “Siparişi Kaydet” dediğinde SQL Server Always On senkron modda şu 4 adımı milisaniyeler içinde yürütür:

1. İstemci INSERT / UPDATE işlemini Primary (Birincil) sunucuya gönderir.
2. Primary sunucu bu işlemi kendi Transaction Log (.ldf) önbelleğine yazar ve aynı anda ağ üzerinden şifreli TCP (varsayılan 5022 portu) paketiyle Secondary (İkincil) sunucuya iletir.
3. Secondary sunucu gelen log kaydını kendi diskindeki Transaction Log dosyasına kalıcı olarak yazar (Log Hardening) ve Primary sunucuya "Yazdım (ACK)" onayı döner.
4. Primary sunucu istemciye "İşlem Tamamlandı (Commit)" bilgisini iletir; Secondary sunucu ise arka planda (Redo Thread) bu logları veri sayfalarına (.mdf) uygular.

2. WSFC Kümesi, Quorum Tanığı (Witness) ve Split-Brain Koruması

Always On mimarisinin altında WSFC (Windows Server Failover Clustering) altyapısı çalışır. İki sunuculu bir kümede sunucular arasındaki ağ kablosu koparsa, her iki sunucu da diğerinin öldüğünü sanıp kendisini “Primary” ilan etmeye çalışabilir. Veri bütünlüğünü yok eden bu duruma Split-Brain (Bölünmüş Beyin) Sendromu denir.

Split-Brain felaketini önlemek için kümeye üçüncü bir oy hakkı olarak Quorum Witness (Dosya Paylaşımı Tanığı, Disk Tanığı veya Bulut Tanığı) eklenir. Ana sunucu çöktüğünde; ikincil sunucu ve Quorum Tanığı birlikte çoğunluk oyunu (2/3 oy) sağlayarak ikincil sunucuyu güvenle Primary rolüne yükseltir.

3. Availability Group Listener ve MultiSubnetFailover Bağlantısı

Uygulama yazılımlarının veya ERP istemcilerinin bağlantı dizesine (Connection String) birinci veya ikinci sunucunun gerçek IP adresi yazılmaz; bunun yerine kümenin sanal IP ve DNS adı olan AG Listener adresi tanımlanır:

Server=tcp:ag-erp-listener.maysa.local,1433;Database=MaysaERP;MultiSubnetFailover=True;ApplicationIntent=ReadWrite;

Ana sunucu donanımsal bir arıza verdiğinde Listener sanal IP adresi saniyeler içinde ikinci sunucuya geçer. Bağlantı dizesindeki MultiSubnetFailover=True parametresi sayesinde uygulama sunucuları hiçbir ayar değişikliği veya yeniden başlatma gerektirmeden çalışmaya devam eder.

4. Read-Scale (Salt Okunur Yönlendirme) ile Raporlama Yükünü Ayırma

Always On mimarisi yalnızca felaket anını bekleyen atıl bir yatırım değildir. İkincil sunucu Readable Secondary (Okunabilir İkincil Kopya) olarak yapılandırıldığında:

• Bağlantı dizesinde ApplicationIntent=ReadOnly parametresi kullanan İş Zekası (BI), PowerBI, yönetim panelleri ve ağır maliyet/muhasebe raporları Listener tarafından otomatik olarak İkincil Sunucuya yönlendirilir.
• Böylece Birincil (Primary) sunucunun işlemcisi (CPU) ve disk IOPS kapasitesi ağır rapor sorgularıyla hiç yorulmaz; %100 oranında üretim sahasındaki barkod terminallerine ve canlı veri girişine tahsis edilir.

PostgreSQL Streaming Replication, WAL ve Patroni Küme Mimarisi

Açık kaynaklı kurumsal veritabanı dünyasının lideri olan PostgreSQL, modern Özel Yazılım Geliştirme projelerinde ve yüksek hacimli endüstriyel telemetri sistemlerinde WAL (Write-Ahead Log) Streaming Replication mimarisiyle üstün bir felaket kurtarma yeteneği sunar:

Mimari Bileşen	Microsoft SQL Server Always On	PostgreSQL Yüksek Erişilebilirlik Kümesi
Log Aktarım Mekanizması	Transaction Log (.ldf) Block Streaming	WAL (Write-Ahead Log) Byte-by-Byte Streaming (walreceiver)
Küme ve Orkestrasyon	Windows Server Failover Clustering (WSFC)	Patroni + Dağıtık Konsensüs (etcd veya Consul)
Sanal IP ve Yük Dengeleme	Availability Group Listener (VNN / VIP)	HAProxy + Keepalived (VRRP) ve PgBouncer Bağlantı Havuzu
Sıfır Veri Kaybı Ayarı	AVAILABILITY_MODE = SYNCHRONOUS_COMMIT	synchronous_commit = on veya remote_apply + synchronous_standby_names
Otomatik Yeniden Katılım	Onarılan sunucu kümeye otomatik senkronize olur	pg_rewind ile eski ana sunucu sıfırdan kopyalanmadan farkları alarak katılır

PostgreSQL kümelerinde etcd (3 düğümlü Raft konsensüs deposu) ve Patroni birlikte kullanıldığında; birincil PostgreSQL düğümü yanıt vermezse Patroni liderlik anahtarını (Leader Lock) düşürür, en güncel WAL pozisyonuna (LSN - Log Sequence Number) sahip ikincil düğümü yeni lider seçer ve HAProxy üzerinden yazma trafiğini (port 5000) yeni lidere, okuma trafiğini (port 5001) ise diğer kopyalara kesintisiz yönlendirir.

Replikasyon Neden Tek Başına Yedekleme Değildir? (Hibrit DR Topolojisi)

Tıpkı RAID mimarisinde olduğu gibi, canlı veritabanı replikasyonu da tek başına soğuk yedeklemenin (Backup) yerini tutmaz:

• Bir yazılımcı veya yönetici birincil veritabanında yanlışlıkla DROP TABLE veya DELETE FROM Siparisler komutunu çalıştırdığında, senkron replikasyon bu silme işlemini 5 milisaniye içinde ikincil sunucuya da uygular ve tablo her iki sunucuda aynı anda silinir.
• Bu tür mantıksal hatalara ve siber saldırılara karşı; canlı Always On / Streaming Replication kümesinin yanında mutlaka Zaman Noktasına Geri Dönüş (PITR - Point-in-Time Recovery) sağlayan Transaction Log/WAL arşivlemesi, Güvenlik Duvarı Firewall ile izole edilmiş yedekleme VLAN’ı ve değiştirilemez (Immutable) Ortak Dosya Sunucusu ve Yedekleme katmanı birlikte çalıştırılmalıdır.

Sıfır veri kayıplı kurumsal veritabanı kümeleri, yüksek erişilebilirlikli Özel ERP & CRM ve İmalat Çözümleri ve uçtan uca felaket kurtarma danışmanlığı için Ortak Dosya Sunucusu ve Yedekleme sayfalarımızı inceleyebilir, sistem mühendislerimizle iletişime geçebilirsiniz.

Sıkça Sorulan Sorular

SQL Server Always On için mutlaka Enterprise lisans mı gerekir, Standard sürümde çalışır mı?

Microsoft SQL Server Standard sürümünde Basic Availability Groups (Temel Erişilebilirlik Grupları) özelliği mevcuttur ve 2 sunucu arasında senkron veya asenkron otomatik yük devretme (Failover) yapabilir. Ancak Standard sürümdeki Basic AG; grup başına yalnızca 1 veritabanı tanımlanmasına izin verir ve ikincil sunucunun raporlama için salt okunur (Read-Only) açılmasını desteklemez. Birden fazla veritabanını tek grupta yönetmek, 2’den fazla kopya oluşturmak ve ikincil sunucudan canlı rapor çekmek için SQL Server Enterprise sürümü veya açık kaynaklı PostgreSQL Streaming Replication mimarisi tercih edilmelidir.

Farklı şehirlerdeki iki veri merkezi arasında senkron replikasyon yapılırsa ERP yavaşlar mı?

Evet, fiziksel mesafe arttıkça fiber optik kablodaki ışık hızı gecikmesi (Round-Trip Time - RTT) artar. Örneğin Kocaeli ile Ankara arasındaki 8–12 milisaniyelik ağ gecikmesi, senkron modda yapılan her bir tekil INSERT/COMMIT işlemine doğrudan eklenir ve yoğun toplu işlemlerde yavaşlama hissedilebilir. Bu nedenle en doğru kurumsal topoloji; aynı sistem odasında (veya aynı OSB içinde < 1 ms fiber hatta) Senkron HA ikincil sunucu, farklı şehirdeki felaket kurtarma merkezinde ise Asenkron DR üçüncül sunucu çalıştırmaktır.

Birincil veritabanı sunucusu çöktüğünde (Failover anında) o sırada açık olan ERP ekranları kapanır mı?

Ana sunucu çöktüğü anda henüz tamamlanmamış (Uncommitted / In-flight) olan yarım saniyelik işlemler güvenlik gereği geri alınır (Rollback) ve istemci uygulaması kısa bir bağlantı yenileme (Reconnect) yaşar. Modern ERP ve özel yazılım mimarilerinde kullanılan Connection Resiliency (Bağlantı Esnekliği / Retry Logic) ve MultiSubnetFailover=True özelliği sayesinde, uygulama 10–15 saniye içinde yeni birincil sunucuya otomatik bağlanır ve kullanıcılar programı kapatıp açmaya gerek kalmadan işlemlerine kaldıkları yerden devam eder.