Bu rehber neyi çözer?
HA, replication, backup ve DR aynı şey değildir. Yüksek erişilebilirlik servis kesintisini azaltır; backup veri geçmişini korur; DR ise ayrı failure domain’de geri dönüş planıdır.
PostgreSQL
Streaming replication ve WAL tabanlı standby mimarisi HA/DR için kullanılabilir; point-in-time recovery için base backup + WAL archive gerekir.
Failover orchestration ayrı araçlarla veya managed platformla tasarlanmalıdır.
MySQL / MariaDB
Asenkron veya semi-sync replication, Group Replication/InnoDB Cluster ve MariaDB Galera gibi farklı modeller vardır.
Senkronluk arttıkça latency etkisi ve operasyon karmaşıklığı değişir; workload’a göre seçilmelidir.
SQL Server
Always On Availability Groups, Failover Cluster Instances ve log shipping farklı availability/DR problemlerini çözer.
Transaction log backup zinciri RPO ve point-in-time restore için kritiktir.
Oracle
Data Guard DR ve standby, RAC ise belirli local HA/scale senaryoları için kullanılır. İki teknoloji aynı probleme birebir çözüm değildir.
RMAN backup ve restore testi, Data Guard/RAC olsa bile gereklidir.
MongoDB
Replica set otomatik failover ve redundancy için temel yapıdır; sharding scale-out içindir ve tek başına backup değildir.
Oplog window, backup consistency ve restore prosedürü DR hedefleriyle ölçülmelidir.
RPO / RTO ve test
RPO kabul edilebilir veri kaybını, RTO kabul edilebilir servis kesinti süresini tanımlar. Teknoloji seçimi bu iki hedefe göre yapılmalıdır.
Planlı failover, node kaybı, storage corruption, yanlış DELETE ve tam site kaybı ayrı test senaryolarıdır.
Sık Sorulan Sorular
HA varsa backup gerekli mi?
Evet. HA yanlış DELETE, logical corruption veya ransomware’a karşı geçmiş veri kopyası sağlamaz.
Replication sıfır veri kaybı garanti eder mi?
Hayır. Replication modu, network ve commit davranışına göre veri kaybı penceresi değişebilir.
DR testi ne sıklıkla yapılmalı?
İş kritikliği ve değişim hızına göre periyodik yapılmalı; yalnız doküman değil gerçek restore/failover testi gerçekleştirilmelidir.
Resmî teknik kaynaklar
- https://www.postgresql.org/docs/current/high-availability.html
- https://dev.mysql.com/doc/refman/8.4/en/replication.html
- https://learn.microsoft.com/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server
- https://docs.oracle.com/en/database/oracle/oracle-database/23/sbydb/
- https://www.mongodb.com/docs/manual/replication/
- https://mariadb.com/docs/server/ha-and-performance/
Veritabanı Altyapınızı Birlikte Değerlendirelim
Workload, güvenlik, donanım, HA ve yedekleme gereksinimlerinize göre altyapıyı birlikte planlayabiliriz.
Mimari ve çalışma modeli
HA servis sürekliliği, replication başka kopyaya değişim aktarımı, backup geçmiş noktaya dönüş ve DR geniş arızadan iş kurtarma sağlar. Aynı yanlış silme replikaya taşınabilir. Senkron/asenkron davranış, quorum, fencing ve uygulama bağlantı hedefi birlikte tasarlanmalıdır. Eski primary geri geldiğinde kontrolsüz yazması önlenir.
- 1Commit ve replication
- 2Quorum/fencing
- 3Yeni yazıcı
- 4Backup/PITR ve iş testi
Tasarım parametreleri
- Quorum ve fencing
- Failoverda tek yetkili yazıcıyı sağlayın; eski primarynin ağ dönüşünde yeniden yazmasını engelleyin.
- Lag ve kurtarma noktası
- Replica bağlantısı güncellik değildir; gönderilen ve uygulanmış son transactionı ölçün.
- İş yükü ve sorgu dağılımı
- Okuma/yazma oranı, bağlantı sayısı, transaction süresi ve yoğun sorguları ölçün. Veritabanı boyutu tek başına donanım gereksinimini açıklamaz.
- Bellek ve depolama
- Çalışma kümesi, günlük yazması, geçici alan ve checkpoint davranışını ayrı inceleyin. Güvenilir yazma garantisi performans kadar önemlidir.
- Kurtarma zinciri
- Başlangıç yedeği, gerekli günlükler, yapılandırma ve anahtarların birlikte geri getirilebildiğini sınayın.
- Erişim ve değişiklik
- Uygulama rolü, yönetici rolü ve schema değişiklik yetkisini ayırın. Üretimde indeks veya parametre değişimini kontrollü yapın.
Hesap ve uygulama örneği
Örnek primary kaybında replica yaşı ve en son commit edilmiş işlem karşılaştırılır. Uygulamanın yeni yazıcıya yönlenmesi ve retry davranışı ölçülür. Ayrı tatbikatta yanlış silinen kayıt backup/PITR ile temiz hedefe döndürülür; failoverı silme kurtarması yerine kullanmayın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| İki taraf yazabiliyor | Fencing veya failover kararı hatalı olabilir. | Onaylı testte eski primaryyi izole edip bağlantı dönüşünde yazma yetkisini kontrol edin. |
| CPU düşük, sorgu yavaş | Kilit, I/O veya istemci beklemesi baskın olabilir. | Yürütme planını ve bekleme türünü aynı sorgu için inceleyin. |
| Replica bağlı ama verisi eski | Gönderme, uygulama veya transaction beklemesi gerilik yaratabilir. | Son uygulanmış işlem ve kaynağın commit zamanını karşılaştırın. |
| Disk sürekli büyüyor | Günlük tutma, açık transaction, replication slot veya bakım ihtiyacı etkili olabilir. | Ürünün desteklediği istatistikleri inceleyin; günlükleri elle silmeyin. |
Kabul ve doğrulama kontrolleri
- Düğüm arızası ile veri bozulmasını iki farklı kurtarma senaryosu olarak test edin.
- Temsilî transactionları ve sorguları gerçek veri dağılımıyla test edin.
- Ayrı hedefe restore yapıp uygulama kayıtlarını doğrulayın.
- Yetkisiz okuma ve schema değişikliği denemelerini test kimliğiyle reddedin.
- Failover sonrasında tek yetkili yazıcı ve doğru bağlantı hedefini doğrulayın.
- Bakım sırasında kilit, günlük hacmi ve gecikme değişimini ölçün.
İlgili kavramlar
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Replikasyonun kapsamı
Replikasyon veri veya durum değişikliklerini başka bir kopyaya aktarır. Senkron aktarım gecikme ve bağlantı bağımlılığı yaratabilir; asenkron aktarım ise geride kalabilir. Kopyanın güncel olması, yanlış değişikliklerden korunması anlamına gelmez: silme veya bozulma da taşınabilir. Gecikmeyi yalnız bağlantı durumu üzerinden değil, uygulamanın tamamlanan son işlemiyle karşılaştırın. Kaynak düğüm kaybedildiğinde yazma yetkisinin hangi kopyaya geçeceğini ve eski düğüm geri gelince nasıl uzlaştırılacağını tanımlayın. Replikasyon gecikmesi ile gerçek kurtarma noktasını ayrı raporlayın.
Quorum ve split-brain
Quorum, hangi düğüm grubunun hizmeti sürdürme yetkisine sahip olduğuna karar verilmesine yardımcı olur. Amaç, bağlantısı kopan grupların aynı kaynağa bağımsız şekilde yazmasını önlemektir. Oy sayısı, dinamik oy yönetimi ve witness davranışı ürüne göre değişir; yalnız düğüm sayısıyla sonuç çıkarılmaz. Witness aynı arızada kaybedilecek yerdeyse beklenen fayda azalır. Ağ bölünmesi ve witness kaybını ayrı test edin. Geçişten sonra tek bir yetkili yazıcı bulunduğunu ve eski düğümün kontrolsüz biçimde hizmete dönmediğini doğrulayın.
Failover ve failback
Failover, hizmetin başka bir bileşene geçmesidir; failback, tercih edilen konuma geri alınmasıdır. İkisi aynı risk ve işlem sırasına sahip olmayabilir. DNS güncellemesi, yönlendirme, oturumlar, veri geriliği ve uygulama bağımlılıkları kullanıcı kesintisini belirler. Otomatik geçişin hangi koşulda tetiklendiğini, yanlış alarmda ne olacağını ve geri dönüş onayını tanımlayın. Arızayı yalnız sanal makineyi kapatarak test etmek tüm hata türlerini kapsamaz. Ağ, depolama ve yönetim katmanı arızalarının ayrı etkilerini ölçün.
RPO ve gerçek veri kaybı penceresi
RPO, olay sonrasında kabul edilebilecek veri kaybı süresidir. Yedek zamanlaması tek başına RPO kanıtı değildir; işin başarısız olması veya kopyanın karşı merkeze geç ulaşması pencereyi büyütebilir. Olay anı ile kullanılabilir son tutarlı kurtarma noktasının zamanını karşılaştırın. Örneğin olay 14.00'te, doğrulanmış kopya 13.20'deyse o testteki veri kaybı penceresi 40 dakikadır. Hedefi uygulama bazında belirleyin: dosya arşivi ile sürekli sipariş alan veritabanının gereksinimleri aynı olmayabilir.
RTO ve uçtan uca kurtarma süresi
RTO, bir hizmetin olaydan sonra ne kadar sürede kullanılabilir hale gelmesi gerektiğini ifade eder. Yedek dosyasının indirilmesi veya sanal makinenin açılması bu sürenin yalnız bir bölümüdür. Olayı tanıma, onay, altyapı hazırlığı, veri aktarımı, uygulama açılışı ve iş biriminin doğrulaması ayrı zaman kalemleri olarak kaydedilmelidir. Test süresinin hangi olayla başlayıp hangi olayla sona erdiğini açıkça belirtin. Aynı teknik geri dönüş süresi, bağımlılık veya erişim beklenmesi nedeniyle farklı iş süreçlerinde farklı kesinti süresine dönüşebilir.