Asenkron Database Mirroring ve Asenkron Availability Group: DR Tasarımında Quorum Tuzağı

Asenkron database mirroring, yıllarca bir SQL Server veritabanının kopyasını felaket kurtarma (DR) lokasyonunda tutmanın en basit yoluydu. Mirroring artık deprecated olduğu için ekiplerin çoğu onu asenkron bir Always On availability group ile değiştiriyor. Kâğıt üzerinde ikisi neredeyse aynı görünür: bir primary, bir uzak kopya, commit sırasında DR lokasyonunu beklemeyen bir yapı ve felaket anında olası veri kaybıyla zorunlu (forced) failover.

Yine de ekipleri hazırlıksız yakalayan bir fark var: availability group cluster quorum’una bağımlıdır, database mirroring değildir. Bir mirroring tasarımını iki node’lu bir cluster’a birebir kopyalarsanız, DR sunucusunu bakım için kapatmak production veritabanlarınızı da offline’a düşürebilir.

Bu rehberde asenkron database mirroring ile asenkron availability group’u karşılaştırıyor, quorum tuzağını açıklıyor ve DR lokasyonu devre dışı kaldığında production’ı ayakta tutan bir yapının nasıl tasarlanıp geçirileceğini gösteriyoruz.

Database Mirroring ve Availability Group: Hızlı Karşılaştırma

DR Sunucusu Kapandığında Ne Olur?

İki teknoloji arasındaki gerçek fark, DR tarafı ortadan kalktığında ortaya çıkar: planlı bakım, bir çökme ya da lokasyonlar arasındaki bağlantının kopması fark etmez.

Asenkron Database Mirroring’de

Production çalışmaya devam eder. Principal, mirror’ı beklemediği için kullanıcılar hiçbir şey fark etmez. Tek yan etki transaction log’dadır: mirror’a ulaşmamış log kayıtları, log yedeği alınsa bile truncate edilemez. Mirror geri gelip yetişene kadar log büyümeye devam eder. Log diskinde yeterli boş alan olduğu sürece DR tarafındaki kesinti production’a görünmez.

Asenkron Availability Group’ta

Availability group bir cluster’ın içinde yaşar ve cluster yalnızca oylarının çoğunluğu mevcutken online kalır. Tipik mirroring ikamesini düşünün: her veri merkezinde bir tane olmak üzere iki node ve witness yok. Her node’un bir oyu var. DR node’u ya da lokasyonlar arası bağlantı koptuğunda primary node çoğunluğu kaybedebilir ve cluster offline’a düşebilir. Bu olduğunda availability group da offline olur. Primary SQL Server tamamen sağlıklıdır, ama uygulama veritabanlarına artık ulaşamaz ve birinin cluster’ı elle geri getirmesi gerekir.

Güncel Windows Server sürümlerindeki dynamic quorum, node’lar cluster’dan ayrıldıkça oyları yeniden düzenler ve özellikle planlı bir kapatmada bu riski azaltır. Ancak witness’ı olmayan iki node’lu bir cluster’da her plansız arızaya ya da lokasyonlar arası ağ bölünmesine karşı koruma sağlayamaz. Quorum tasarımınızı ona bırakmayın.

İki teknolojinin ortak bir davranışı daha var. Asenkron bir secondary’nin bağlantısı koptuğunda primary, henüz göndermediği log kayıtlarını truncate edemez. sys.databases‘ta veritabanının log_reuse_wait_desc değeri AVAILABILITY_REPLICA gösterir ve log, secondary yetişene ya da gruptan çıkarılana kadar büyür.

DR İçin Asenkron Availability Group Nasıl Tasarlanır?

Microsoft’un availability group’lar için quorum önerileri bu sorunu doğrudan ele alır. Üç değişiklik, kırılgan iki node’lu tasarımı DR lokasyonu kaybedildiğinde de production’ın ayakta kaldığı bir yapıya dönüştürür.

1. DR Node’una Oy Vermeyin

Microsoft’un önerisi, primary replikayı barındıran node’a ve otomatik failover hedeflerine oy vermek, DR lokasyonundaki node’lara ise genellikle vermemektir. Primary lokasyonda hiçbir sorun yokken DR lokasyonunun cluster’ı offline’a alma kararına katılmasını istemezsiniz. DR node’unun NodeWeight değerini 0 yaparak oyunu kaldırın.

2. Witness ile Oy Sayısını Tek Tutun

Kalan oy veren üyelerin sayısı çiftse, bir beraberliğin cluster’ı düşürmemesi için bir witness ekleyin. File share witness, cluster node’larının dışında durmalı ve hepsinden görülebilmelidir. Cloud witness bunun yerine bir Azure Storage hesabı kullanır ve güvenilir bir üçüncü lokasyon olmadığında iyi bir seçenektir.

Her iki değişiklik de bir cluster node’unda birkaç satır PowerShell ile yapılır:

# DR lokasyonundaki node'un oyunu kaldır
(Get-ClusterNode -Name "SQLDR01").NodeWeight = 0

# Her iki cluster node'unun dışında bir file share witness ekle
Set-ClusterQuorum -FileShareWitness "\\witness-server\SQLCluster-Witness"

# Sonucu kontrol et
Get-ClusterNode | Format-Table Name, State, NodeWeight, DynamicWeight
Get-ClusterQuorum

Aynı kontrolü SQL Server’dan da yapabilirsiniz. number_of_current_votes, dynamic quorum’un yaptığı düzenlemelerden sonraki oyları gösterir:

SELECT cluster_name, quorum_type_desc, quorum_state_desc
FROM sys.dm_hadr_cluster;

SELECT member_name,
       member_type_desc,
       member_state_desc,
       number_of_quorum_votes,
       number_of_current_votes
FROM sys.dm_hadr_cluster_members;

3. Gerçek Felaket Prosedürünü Yazılı Hale Getirin

Oyu olmayan bir DR node’u tek başına quorum oluşturamaz. Günlük işleyişte istediğiniz budur; ama gerçek bir felaket, belgelenmiş manuel bir prosedür gerektirir demektir. Primary lokasyon kaybedildiğinde:

1. DR node’unda cluster’ı quorum olmadan başlamaya zorlayın (force quorum).
2. DR replikasında ALTER AVAILABILITY GROUP [AG_Adi] FORCE_FAILOVER_ALLOW_DATA_LOSS; ile forced failover yapın.
3. Eski primary geri geldiğinde askıya alınmış (suspended) secondary veritabanlarını resume edin ve DR lokasyonuna hiç ulaşmamış transaction’lar için ne yapılacağına karar verin.
4. Cluster’ın yeni haliyle sağlıklı bir quorum’u olması için oy dağılımını yeniden kontrol edin.

Bu prosedürü kesinti runbook’unuzun yanında tutun ve prova edin. Bir felaket anında kimse cluster dokümantasyonunu ilk kez okuyor olmamalı.

Mirroring’den Availability Group’a Geçiş

• Doğru sürüm yolunu seçin. Enterprise’da normal bir availability group kullanın. Standard’da her veritabanı için bir basic availability group kullanın; basic AG’ler asenkron commit’i destekler.
• Önce cluster’ı ve quorum’u kurun. Herhangi bir veritabanı gruba katılmadan önce yukarıdaki oy ve witness tasarımını uygulayın.
• Geçişi planlayın. Bir veritabanı aynı anda hem mirroring session’ında hem availability group’ta olamaz. Mirroring’i kaldırın, ardından secondary kopyayı hazırlayın (WITH NORECOVERY ile restore ya da automatic seeding) ve gruba katın.
• Veritabanının dışında yaşayanları kopyalayın. Login’ler, SQL Server Agent job’ları, linked server’lar ve credential’lar grubun parçası değildir. Bunları DR replikasında da oluşturun.
• Connection string’leri değiştirin. Uygulamalar Failover Partner yerine listener’a bağlanmalı. Microsoft, yalnızca iki replika varsa ve secondary okunabilir değilse mirroring connection string’inin geçici olarak çalışmaya devam ettiğini belirtir; bu da geçişi yumuşatabilir.
• Kuyrukları izleyin. Deneyimimize göre izlenmeyen availability group gecikmesi, devraldığımız ortamlarda en sık karşılaştığımız sorunlardan biridir. Log send queue’ya ve primary’deki log kullanımına alarm kurun; SQL Server high availability rehberimizdeki sorgu iyi bir başlangıç noktasıdır.
• İki yönlü failover’ı test edin. Tasarıma güvenmeden önce DR’a forced failover’ı ve primary lokasyona geri dönüşü test edin.

Availability Group’un Doğru Cevap Olmadığı Durumlar

Yalnızca bir DR kopyasına ihtiyacınız varsa ve hiçbir cluster bağımlılığı istemiyorsanız log shipping hâlâ sağlam bir seçenektir. Cluster olmadan çalışır, birden fazla secondary’yi destekler ve hatalı değişikliklere karşı tampon olarak restore’ları bilerek geciktirebilir. Failover, asenkron mirroring’de olduğu gibi manueldir. Read-scale availability group’lar da cluster olmadan çalışır, ancak Microsoft onları yüksek erişilebilirlik için değil okuma ölçeklendirmesi için konumlandırır. Seçeneklerin tam karşılaştırması için SQL Server high availability rehberimize, availability group temelleri için SQL Server Always On rehberimize göz atın.