MSSQL Server’da Resolving Modun’da Olan Availability Group’u Kurtarma Yöntemi

Bu makalede mssql server üzerinde Resolving modunda olan bir availability group üzerinde ne gibi işlemler yapılmasını ele almış olacağız.AlwaysOn Availability Group‘un “Resolving” moduna düşmesi, Availability Group’un bir veya daha fazla replikasının durumunu belirleyemediği/karar veremediği bir geçiş durumudur. Bu genellikle çökme, ağ kesintisi veya beklenmeyen servis durması sonrası oluşur.

Availability group’un Resolving moda girmesinin en önemli sebebi Windows Server Failover Cluster) çökmesi veya ağ bölünmesi, AlwaysOn endpoint’lerinin erişilemez olması, Firewall/Port engellemeleri (5022 varsayılan portu) DNS çözümleme sorunları başlıca sebeplerdendir.

Aşağıdaki komut ile AlwaysOn endpoint’lerinin erişilemez olup, olmadığı görülebilir.

SELECT name, state_desc FROM sys.database_mirroring_endpoints;

Cluster quorum kaybı sonucu çoğunluk sağlanamaması, Cluster servisinin (clussvc) durması veya hata vermesi, Cluster database bozulması, Node’lar arası heartbeat kaybı Availability group yapısının resolving moduna düşmesinin başka sebebidir.

SQL Server servisinin beklenmedik şekilde durması, cpu-memory anlamında kaynak sıkıntısı yaşanması ve alwayson kaynaklarının başlatılamaması resolving moduna girilmesinin başka sebebidir.

Aşağıdaki resimde Ag yapısının resolving modunda olduğu görülmektedir.

Yukarıda bahsedilen sebeplerden dolayı Resolving modunda olan Availability Group’umuzu aşağıdaki komutla Force edebiliriz. Veri kaybı yaşanmaması açısından resolving moda düşmeden önce hangi sunucu primary ise onun üzerinde çalıştırılması gerekmektedir. Veri kaybını kabul eder. Primary sunucusu üzerinde yaptığımız için veri kaybı yaşanmaz.

ALTER AVAILABILITY GROUP [AG_NAME] FORCE_FAILOVER_ALLOW_DATA_LOSS;

Resolving modundan önceki primary olan sunucumuzu tekrardan primary olarak belirliyoruz.

Secondary sunucular üzerinde Availability group altında bulunan veritabanlarına bakıldığında veritabanlarının Not Synchronizing modunda olduğu görülmektedir.

Yukarıdaki resimde görülen Not Synchronizing moduna neden girdiğine değinelim. Mevcut Availability group properties ekranında Availability Mode kısmının Asynchronous commit olmasından dolayı secondary sunucu üzerinde veritabanlarını resume yapmamız gerektiğini söylemektedir. Diyebiliriz biz sadece primary sunucusu üzerinde komutumuzu çalıştırdık. Evet doğru ilgili mode asynchronous olduğu için primary veya secondary olmasına bakmaz. Bu sebepten diğer secondary sunucularında bulunan veritabanlarının Resume komutuyla AG yapımıza katılması gerekmektedir.

Şunu da belirtmek gerekir ki Failover mode otomatik olsaydı sunucu failover olsaydı yeni primary sunucusunda veritabanlarının veri kaybı ile birlikte resume edilmesi gerektiğini söyleyecekti.

Aşağıdaki resimde görüldüğü gibi tüm veritabanlarımızın RESUME edilmesi gerekmektedir. Neden secondary DB’ler NOT SYNCHRONIZING oldu?

Çünkü FORCE_FAILOVER sonrası SQL Server şunu yapar:
• Split-brain riskini önlemek için
• Secondary’lerde data movement’ı otomatik resume etmez
• Manual intervention bekler

Bu yüzden is_suspended = 1 durumuna düşerler.

Veritabanı sayısı çok fazla olduğu için aşağıdaki komut ile secondary sunucusunda availability group’a katılmak için bekleyen tüm veritabanları Resume edilmektedir.

Tüm suspended DB’leri RESUME yapan script:

DECLARE @sql NVARCHAR(MAX) = '';

SELECT @sql +=
'ALTER DATABASE [' + db_name(database_id) + '] SET HADR RESUME;
'
FROM sys.dm_hadr_database_replica_states
WHERE is_suspended = 1
AND is_local = 1;

EXEC sp_executesql @sql;

Bu şunu yapar:
• Log receive + redo thread’i tekrar başlatır
• Primary’den log akışı yeniden başlar
• DB tekrar SYNCHRONIZING → SYNCHRONIZED olur

Eğer suspended olmasa bile hepsini resume etmek istersen:

DECLARE @sql NVARCHAR(MAX) = '';

SELECT @sql +=
'ALTER DATABASE [' + d.name + '] SET HADR RESUME;
'
FROM sys.databases d
JOIN sys.availability_databases_cluster adc
ON d.name = adc.database_name;

EXEC sp_executesql @sql;

Eğer FORCE_FAILOVER sonrası:
• RESUME düzeltemiyorsa
• LSN mismatch varsa
• DB “NOT JOINED” kalıyorsa

Çözüm: Secondary’i yeniden seed etmek gerekir.(backup-restore veya automatic seeding)

Bu makalede mssql serverda Always on yapısında REPLICA Resolving durumuna düştüğünde neler yapılması gerektiğini ele almış olduk. Başka makalede görüşmek dileğiyle..

“…Olur ki (bazen) hoşunuza gitmeyen bir şey sizin için hayırlı olur ve hoşunuza giden bir şey de sizin için şer olur. (Hayırlı ve doğru olanı) Allah bilir, siz bilemezsiniz.” Bakara Suresi; 216. Ayet

Author: Yunus YÜCEL

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir