En Kötü Senaryoya Hazırlık: Veritabanı Felaket Kurtarma (DR) (1 Görüntüleyici)

Yüksek Erişilebilirlik (HA), genellikle donanım arızaları, yazılım hataları veya yerel ağ sorunları gibi yerel veya bölgesel kesintilerde kesintisiz veya çok kısa kesintili çalışma sağlamayı hedefler (Bölüm 19). Ancak deprem, yangın, sel, geniş çaplı siber saldırılar veya tüm veri merkezini etkileyen büyük bir elektrik kesintisi gibi felaket düzeyindeki olaylar birincil sitenizin tamamını veya büyük bir kısmını devre dışı bırakabilir. İşte bu senaryoda devreye giren şey Felaket Kurtarma (Disaster Recovery - DR)'dır. DR, birincil sitenin tamamen kullanılamaz hale gelmesi durumunda, veritabanı sistemlerini ve iş süreçlerini başka bir konumda tekrar çalışır duruma getirme sürecidir.

Felaket Kurtarma, iki temel metrik ile tanımlanır (Bölüm 12'de kısaca bahsetmiştik):

• Kurtarma Süresi Hedefi (Recovery Time Objective - RTO): Felaket meydana geldikten sonra sistemin veya veritabanının kabul edilebilir maksimum kapalı kalma süresi. Örneğin, RTO'nuz 4 saat ise, felaketten sonra en geç 4 saat içinde veritabanının tekrar erişilebilir olması gerekir.
• Kurtarma Noktası Hedefi (Recovery Point Objective - RPO): Felaket durumunda kabul edilebilir maksimum veri kaybı miktarı. Bu genellikle zaman birimiyle ölçülür (örn: 15 dakikalık RPO, felaketten önceki son 15 dakikadaki veri kaybını tolere edebileceğiniz anlamına gelir). RPO'nuz 0 ise, hiçbir veri kaybı olmamalıdır.

Yaygın Veritabanı DR Stratejileri ve Mimarileri

Farklı RTO ve RPO hedeflerine ulaşmak için çeşitli DR stratejileri kullanılır. Strateji seçimi, verinin kritikliği, kabul edilebilir kesinti ve veri kaybı süresi ile bütçeye bağlıdır.

1. Yedek Kopyalama / Log Kopyalama (Backup Shipping / Log Shipping):
   
   • Nasıl Çalışır: Belirli aralıklarla alınan veritabanı yedekleri (tam, diferansiyel, işlem günlüğü - Bölüm 12) ağ üzerinden veya başka yollarla bir felaket kurtarma sitesine (ikincil bir konuma) gönderilir. İkincil sitede bu yedekler belirli bir noktaya kadar geri yüklenir ve hazır bekletilir.
   • RTO/RPO: RPO, işlem günlüğü yedeklerinin ne kadar sıklıkla gönderildiğine bağlıdır (genellikle dakikalar veya saatler). RTO, ikincil sitede veritabanını tamamen geri yükleyip çevrimiçi hale getirme süresine bağlıdır (genellikle saatler).
   • Avantajları: Genellikle kurulumu ve yönetimi daha basittir, daha düşük maliyetlidir.
   • Dezavantajları: RTO ve RPO genellikle daha yüksektir, yani daha fazla veri kaybı ve daha uzun kesinti süresi potansiyeli vardır.
2. Asenkron Çoğaltma (Asynchronous Replication) ile DR Sitesi:
   
   • Nasıl Çalışır: Birincil sitede yapılan veri değişiklikleri, hemen onaylanmadan, arka planda ağ üzerinden felaket kurtarma sitesindeki ikincil bir kopyaya çoğaltılır (Bölüm 19 - Çoğaltma).
   • RTO/RPO: RPO, çoğaltma gecikmesine (replication lag) bağlıdır (genellikle saniyeler veya dakikalar). Bu süre zarfında yapılan değişiklikler felaket durumunda kaybolabilir. RTO, ikincil kopyayı birincil olarak devreye alma süresine bağlıdır (genellikle dakikalar).
   • Avantajları: Yedek kopyalamaya göre daha düşük RPO sunar, birincil site performansı genellikle etkilenmez.
   • Dezavantajları: Senkron çoğaltmaya göre daha yüksek RPO (veri kaybı potansiyeli), çoğaltma gecikmesini izlemek gerekir.
3. Senkron Çoğaltma (Synchronous Replication) / Dağıtık Transactionlar:
   
   • Nasıl Çalışır: Birincil sitede yapılan bir veri değişikliği, ikincil (DR) sitede de eşzamanlı olarak onaylandıktan sonra birincil sitede commit edilir.
   • RTO/RPO: RPO çok düşüktür (sıfıra yakın). RTO, otomatik yük devretme yeteneğine bağlıdır (genellikle saniyeler veya dakikalar).
   • Avantajları: Veri kaybı riski minimumdur.
   • Dezavantajları: Yüksek ağ gecikmesi gereksinimi (siteler arası mesafe kritik), birincil site performansı çoğaltma tarafından etkilenebilir, kurulumu ve yönetimi çok karmaşıktır, genellikle özel donanım veya ağ altyapısı gerektirir. Çok kritik veriler için kullanılır.

Veritabanı Seviyesi vs. Depolama Seviyesi Çoğaltma: DR çoğaltması veritabanı yazılımı tarafından (işlem günlüğü çoğaltma gibi) veya temel depolama sistemi tarafından (tüm diskin veya bölümün kopyalanması) yapılabilir.

DR Sitesinin Hazırlık Durumu (Cold, Warm, Hot)

Felaket kurtarma sitesi, birincil siteye göre farklı hazırlık seviyelerinde olabilir:

• Cold Site (Soğuk Site): Temel bir altyapı vardır ancak donanım tam kurulu veya yapılandırılmış değildir. Felaket durumunda donanımın getirilmesi, kurulması ve yedeklerden geri yükleme yapılması gerekir. En yüksek RTO'ya sahiptir.
• Warm Site (Ilık Site): Temel donanım ve yazılım kuruludur, ancak sürekli aktif olmayabilir. DR durumunda güncel yedeklerin geri yüklenmesi veya çoğaltma akışının yakalanması gerekir. RTO, Cold site'tan daha düşüktür.
• Hot Site (Sıcak Site): Birincil sitenin tam kopyasıdır, veriler senkron veya asenkron olarak sürekli çoğaltılır. DR durumunda otomatik veya manuel olarak ikincil site birincil rolünü üstlenir. En düşük RTO'ya sahiptir.

DR Testinin Önemi

Bir felaket kurtarma planının çalıştığından emin olmanın tek yolu onu düzenli olarak test etmektir. DR testi, geri yükleme süreçlerinin doğrulanmasını, RTO ve RPO hedeflerine ulaşılıp ulaşılamadığının ölçülmesini ve planın güncelliğinin kontrol edilmesini sağlar. Test edilmemiş bir DR planı, planın olmamasından daha kötü olabilir.

Bulutun DR İçin Kullanımı

Bulut bilişim (Bölüm 24), felaket kurtarma için uygun maliyetli ve esnek seçenekler sunar. Farklı bölgelerdeki bulut altyapısı, ikincil DR sitesi olarak kullanılabilir. Bulut sağlayıcılarının yönetilen veritabanı hizmetleri (PaaS) genellikle yerleşik, kolay konfigüre edilebilir DR seçenekleri sunar.

Felaket kurtarma, bir veritabanı yönetiminin en ciddi senaryolarına hazırlık gerektiren, ancak iş sürekliliği için mutlak surette gerekli olan bir alandır. Doğru stratejiyi seçmek, uygulamalarınızın ve işletmenizin dayanıklılığını artırır.

Bu bölümde, veritabanı felaket kurtarmanın ne olduğunu, temel metriklerini (RTO/RPO), yaygın stratejilerini ve DR sitelerinin farklı hazırlık seviyelerini ele aldık.

Oldukça uzun ve detaylı bir seriyi geride bıraktık. Veritabanları ve SQL'in temel taşlarından başlayıp, veri yönetimi ekosisteminin birçok farklı yönüne derinlemesine baktık. Bu yolculuk, bir veritabanı sisteminin sadece veri saklayan bir yer olmadığını, aynı zamanda güvenliği, performansı, erişilebilirliği, ölçeklenebilirliği ve felaketlere karşı dayanıklılığı yönetilmesi gereken karmaşık bir sistem olduğunu göstermiştir.

Bu serinin, veritabanı ve SQL alanındaki bilginizi genişlettiğini ve bu alandaki kariyeriniz veya ilgi alanlarınız için sağlam bir temel oluşturduğunu umuyorum. Öğrenme ve keşfetme yolculuğunuz devam etsin!

Bu, serimizin bu aşamadaki ve kapsamdaki son bölümüdür.

Bu uzun soluklu seriyi takip ettiğiniz için hepinize içtenlikle teşekkür ederim! Veri dolu ve güvenli günler dilerim!

---