Yüksek Erişilebilirlik / Felaket Kurtarma · SQL Server

Güvenilir Bir Always On Mimarisi Tasarlamak

Availability Group tek başına eksiksiz bir iş sürekliliği stratejisi değildir. Güvenilir mimari, iş biriminin kurtarma hedefleriyle başlar; tüm uygulama bağımlılıklarını kapsar ve tekrarlanabilir hata senaryolarıyla kanıtlanır.

[company_article_image src=”articles/always-on-architecture.svg” alt=”Uygulamaların listener üzerinden primary ve secondary SQL Server replikalarına bağlanması” caption=”Kullanılabilir bir HA tasarımı listener, replikalar, quorum ve operasyonel bağımlılıkları birlikte ele alır.”]

RPO ve RTO’yu tasarım kararlarına dönüştürün

RPO kabul edilebilir veri kaybını, RTO ise kabul edilebilir kesinti süresini tanımlar. Synchronous commit sağlıklı replikalar arasında veri kaybı riskini azaltabilir; fakat network latency ve commit throughput ölçülmelidir. Uzak lokasyonda asynchronous commit kullanılıyorsa olası veri kaybı penceresi açıkça kabul edilmelidir.

Veritabanının ötesini tasarlayın

Listener, DNS, portlar, sertifikalar, loginler, SQL Agent jobları, linked serverlar, encryption keyleri ve connection string davranışı kurtarma sürecini etkiler. Database erişilebilir olsa bile onu kullanan servis erişilebilir olmayabilir.

Failover politikasını bilinçli seçin

  • Hangi replikaların otomatik failover yapabileceğini belirleyin.
  • Quorum ve witness davranışını dokümante edin.
  • Yanlış failover riskini azaltacak health detection değerleri kullanın.
  • Planlı ve acil failover runbooklarını ayırın.
  • Veri kaybı ihtimali olan failover için yetki şartlarını yazılı hale getirin.

Client davranışını doğrulayın

Connection string node adına değil listener’a gitmelidir. Uygulamada sınırlı timeout, retry storm oluşturmayan tekrar politikası ve güvenli transaction tekrarı bulunmalıdır. Multi-subnet ortamda DNS ve bağlantı davranışı her uygulama ağından test edilmelidir.

Data movement sağlığını izleyin

Synchronization state, log send queue, redo queue, last hardened time ve replica bağlantıları takip edilmelidir. Alert eşikleri tek bir evrensel sayıya değil gerçek iş yükü ile RPO’ya dayanmalıdır.

Backup hâlâ gereklidir

Availability servis sürekliliğini destekler; mantıksal hata, kötü niyetli değişiklik veya uzun süreli retention ihtiyacını tek başına çözmez. Bağımsız backup zinciri korunmalı ve restore işlemleri düzenli olarak kanıtlanmalıdır.

En iyi mimari, operasyon ekibinin baskı altında anlayabildiği, çalıştırabildiği ve ölçebildiği mimaridir.