Bu makalede AlwaysOn yapısında Failover işlemine değineceğim. Failover, birincil (primary) sunucunun başarısız olması durumunda, yedek (secondary) sunucuya geçiş yapılmasını sağlar. Failover işlemi sırasında dikkat edilmesi gereken birçok faktör vardır. Bu faktörler, hem failover’ı doğru şekilde gerçekleştirmenizi sağlar hem de olası sorunların önüne geçer. Böyle bir durumda sağlıklı bir şekilde restart edeceğiniz sunucudaki Availability Group’ları diğer sunucuya failover etmeniz gerekir. Failover işlemi Database bazlı değil sunucu bazlı işlemlerde gerçekleşmektedir.
İlgili AG üzerine sağ tıklayıp properties ekranından availability Replicas ekranından bu işlemleri ayarlayabiliriz.
SQL Server AlwaysOn yapısında iki ana failover türü vardır:
- Automatic Failover: Eğer birincil sunucu başarısız olursa, SQL Server kendi kendine failover işlemini gerçekleştirir. Bu tür bir failover, genellikle iki sunucu arasında sağlanır (aynı veri kümesi ve ağ yapılandırması ile).
- Manual Failover: Bu durumda failover işlemi yöneticiler tarafından manuel olarak yapılır. Failover, genellikle bakım, güncelleme veya diğer yönetimsel işlemler için kullanılır.
Otomatik failover olabilmesi için availability mode’un synchronous commit olması gerekiyor yoksa otomatik failover olmuyor.
Planlı bir bakım yapmak istiyorsak primary makinemizden yükü almak için sağ üst köşede start failover Wizard diyorum. Bunu yapmadan önce Redo Queue Size ve Log Send Queue Size gibi kolun değerlerine bakmak gerekiyor. Eğer burada yüksek değerler varsa yeni primary makinanızın geç ayağa kalkmasına sebep olabilir.
Gelen ekranda Next deyip bir sonraki ekrana geçiyoruz.
Failover işlemi sırasında veritabanlarının güncel ve senkronize olması çok önemlidir. Eğer synchronous commit kullanıyorsanız, veritabanları arasında herhangi bir veri kaybı olmaz. Ancak asynchronous commit kullanıyorsanız, failover öncesi son yapılan değişiklikler hedef sunucuya aktarılmamış olabilir. Failover sonrası sonrasında veri kaybı yaşanabilir. Aşağıdaki resimde Senkron olduğu için No Data Loss ifadesi gözükmektedir. Data Loss ifadesi görünse bile kayıp olmaz ama olabilme ihtimali olduğu için böyle görünür. veriler ms cinsinden replica sunucusuna yazılmaktadır.
Not: Asenkron replikasyon kullanıyorsanız, veri kaybı yaşanabilir. Bu durumda, log shipping ya da backup and restore gibi yöntemlerle veri kaybını azaltmak için önceden hazırlık yapmanız gerekebilir.
Karşı sunucumuza bağlantı gerçekleştiriyoruz.
Gelen ekranda New olan kısımda yeni primary replikamızı gördükten sonra finish deyip failover işlemini yapıyoruz.
Başarılı bir şekilde failover işlemimiz gerçekleşiyor.
Failover işlemini aşağıdaki sonuç ekranında görmüş oluyoruz.
2. bir yöntem olarak Failover işlemini ilgili AG üzerine sağ tıklayıp aşağıdaki kısımdan da yapabiliriz.
Failover işlemini failover cluster üzerindende gözlemleyelim. İlk başta falover mod’a bakalım otomatik olması lazım.
S1 sunucusunda herhangi bir kapanma olduğunu failover modu otomatik olduğu için makine kendini otomatikmen S2 sunucusuna atmış olacak. MANUEL olsaydı failover mode resolving mode düşmüş olacaktı cluster manuel bir şekilde failover yapmamız gerekecekti.
S1 sunucumu kapatıyorum.
Kendini ikinci sunucuya atmış oldu.
Eğer sunucularımız otomatik failover modunda değilde manule modunda olsaydı resolving durumuna AlwaysOn düşecekti.
Bu durumda S2 sunucusunu kapatalım S2 sunucusu primary bakalım ne gibi bir durumla karşılaşılacak.
Büyük sistemlerde manuel durumda bırakılır çünkü bekleyen transaction fazla olabilir bu transactionlar primary sunucuya geçmeye çalışacağı için sistemin geç ayağa kalkmasına neden olur.
Şimdi S2 sunucusunu kapatıyorum ve S1 sunucusundan izliyorum.
Şimdi SSMS ekranında S1 sunucusunda always on high availability sekmesine bakalım.
Yapımızın resolving yapısında olduğu gözüküyor.
Not: Hangi instance üzerinde resolving modunda olan Ag failover yapılırsa yeni Ag yapımız ilgili sunucu ve instance olması gerekmektedir.
Yukarıdaki işlemi dashboard ekranındanda yapılabilir.
Aşağıdaki resimde yeni replicakanın S1\TEST olduğu görülmektedir.
Failover işleminin başarılı bir şekilde gerçekleştiğini görüyoruz.
S1 sunucusunun primary olduğunu görmüş oluyoruz.
Faiover cluster ekranında failover işlemi gerçekleştirilebilir. Roles üzerinden ilgili AG’ye sağ tıklayıp Move ve Select Node diyoruz.
Cluster içerisinde 2 sunucumuz olduğu için otomatikmen bir sunucuya failover yapacağımız tek bir sunucumuz gelmiş oldu. Failover yapmak istediğimiz sunucuyu seçip OK tuşuna basarsak failover işlemimiz gerçekleşmiş olur. Ama bu işlemden önce secondary ve primary sunucuların senkron durumlarının kontrol edilmesi gerekmektedir. Resolving modunda ise AG’miz bu şekilde kendi üzerine failover işlemi yapılabilir.
Tabi failover modumuz manuel ise aşağıdaki gibi bir bilgilendirme mesajı alırız. Bunun için failover işleminin otomatik olacak şekilde değiştirilmesi gerekmektedir.
Resolving modunda olan bir availability group’un resolving modunda kalması sıkıntı anından Resolving modunun ssms arayüzünde kendi üzerine failover yapılması gerekmektedir.
Failover işlemi yapmadan önce AG’lerin senkron durumunu öğrenmek için aşağıdaki komut işimize yarayacaktır.
SELECT
ag.name AS AvailabilityGroupName,
db.name AS DatabaseName,
drs.synchronization_state_desc AS SynchronizationState,
drs.synchronization_health_desc AS SynchronizationHealth,
r.replica_server_name AS ReplicaServerName
FROM
sys.dm_hadr_database_replica_states AS drs
JOIN
sys.availability_groups AS ag
ON drs.group_id = ag.group_id
JOIN
sys.databases AS db
ON drs.database_id = db.database_id
JOIN
sys.availability_replicas AS r
ON drs.replica_id = r.replica_id
ORDER BY
ag.name, db.name;
Açıklamalar:
- SynchronizationState: Veritabanasının senkronizasyon durumu. Bu, veritabanasının verileri ne kadar güncel olduğunu belirtir (örneğin, SYNCHRONIZED, SYNCHRONIZING, NOT SYNCHRONIZED vb.).
- SynchronizationHealth: Senkronizasyon sağlığı durumu. Bu, veritabanasının senkronizasyon işlemlerinin sağlıklı olup olmadığını gösterir (örneğin, HEALTHY, UNHEALTHY vb.).
- ReplicaServerName: Failover işlemi sonrasında veritabanının çalışacağı sunucuyu göstermektedir.
Senkronizasyon Durumları:
- SYNCHRONIZED: Veritabanı tamamen senkronize, herhangi bir senkronizasyon problemi yok.
- SYNCHRONIZING: Veritabanı senkronize ediliyor, yani henüz tamamlanmamış bir işlem var.
- NOT SYNCHRONIZED: Veritabanı senkronize olmamış, veri kaybı riski olabilir.
Eğer AG yapımız resolving moduna düşerse aşağıdaki komut ile tekrar aynı sunucuyu primary sunucusu olarak ayağa kaldırabiliriz. Primary olmasını istediğimiz sunucu üzerinde komut çalıştırılır.
ALTER AVAILABILITY GROUP AGLSQL FORCE_FAILOVER_ALLOW_DATA_LOSS;Tekrardan sunucumuz primary sunucusu olarak ayağa kalmış olur.
Yukarıdaki gibi yapmayıp failover cluster ekranından start stop yaptığımız zaman role’ü rastgele bir sunucuyu primary olarak seçmektedir. Tabi failover mode otomatik yapıda ise..
Görseldeki mevcut yapılandırmaya göre; Primary sunucu Synchronous, tüm Secondary sunucular ise Asynchronous moddadır. SQL Server mimarisinde bu durum şu sonuçları doğurur:
1. Mevcut Çalışma Mantığı ve Riskler
- Sistem şu an tamamen Asynchronous (Asenkron) gibi davranır. Çünkü verinin “Synchronous” işlenmesi için en az bir Secondary replikanın da bu modda olması ve onay (ACK) göndermesi gerekir.
- Sistem şu an yüksek performans önceliklidir ancak veri kaybı (Data Loss) riskine açıktır. Primary, ikincil sunuculardan onay beklemeden işlemi commit eder.
- İkincil sunucular asenkron olduğu için otomatik failover yapılamaz. Manuel failover durumunda ise veri kaybı ihtimali yüksektir.
2. Kesinti Sonrası Senkronizasyon (Log Gap Yönetimi)
Secondary sunucu kapandığında veya bağlantı koptuğunda süreç şöyle işler:
- Primary sunucu, Secondary’ye gönderilememiş log kayıtlarını .ldf dosyasında saklamaya devam eder. Log backup alınsa dahi, Always On mekanizması bu kayıtları “Secondary’ye gönderilene kadar” truncate etmez (saklar).
- Log Gap (Log Boşluğu): Eğer kesinti süresi çok uzarsa ve disk kapasitesi/log şişmesi gibi nedenlerle bu kayıtlar korunamazsa “Log Gap” oluşur. Bu durumda sunucu “Not Synchronizing” durumuna düşer.
- Tekrar Bağlanma:
- Kısa süreli kesinti: Sunucu açıldığında Redo Thread sayesinde eksik logları Primary’den çekerek otomatik senkron olur.
- Uzun süreli kesinti: Otomatik senkronizasyon başarısız olursa; Automatic Seeding (açıksa) devreye girer. Kapalıysa, veritabanını manuel olarak Copy-Only Full Backup + Log Restore yöntemiyle yeniden initialize etmek gerekir.
3. Kritik Öneriler
- Yüksek Kullanılabilirlik (HA): En az bir Secondary sunucuyu Synchronous Commit + Automatic Failover moduna çekmelisiniz. Bu, “Sıfır Veri Kaybı” garantisi sağlar.
- Log Yönetimi: Uzun süreli kesintilerde Primary sunucunun disk alanının (LDF) dolmamasına dikkat edilmelidir.
- İzleme: Senkronizasyon durumunu ve “Log Send Queue” değerlerini düzenli takip etmelisiniz.
Aşağıdaki script yardımıyla Secondary sunucunun primary sunucuya göre ne kadar geriden geldiğini bulabilirsiniz. 1 saat üzerinden fazla olan veritabanlarıyla ilgili kayıt dönmektedir. Aşağıdaki dönen ilgili veritabanları yukarıdaki komut ile kordineli çalıştırdığımızda mantık anlaşılıyor.
SELECT DB_NAME(drs.database_id) AS Database_Name
,drs.last_commit_time AS Primary_Commit
,drs2.last_commit_time AS Secondary_Commit
,CONCAT(DATEDIFF(second,drs2.last_commit_time,drs.last_commit_time)/3600 ,' Saat'
,(DATEDIFF(second,drs2.last_commit_time,drs.last_commit_time)%3600)/60 ,' Dakika'
,DATEDIFF(second,drs2.last_commit_time,drs.last_commit_time)%60 ,' Saniye') AS Senkronizasyon_Farki
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.dm_hadr_database_replica_states drs2 ON drs.database_id=drs2.database_id
WHERE drs.is_local=1 AND drs2.is_local=0 AND DATEDIFF(second,drs2.last_commit_time,drs.last_commit_time)>3600
ORDER BY DATEDIFF(second,drs2.last_commit_time,drs.last_commit_time) DESC
Not: Aşağıdaki komut ile alwayson yapımızda failover işlemi yapmadan önce görmemiz gereken ifadelerden birisi olarak karşımıza çıkar.
Select name,S.log_reuse_wait_desc from sys.databases s
--where log_reuse_wait_desc !='NOTHING'log_reuse_wait_desc sütunu, log dosyasının neden yeniden kullanılamadığını açıklayan değerleri döndürebilir. Sayfamızdan ilgili makale okunabilir.
Başka bir makalede görüşmek dileğiyle..
“Allah, melekler ve ilim sahipleri, ondan başka ilah olmadığına adaletle şâhitlik ettiler. Ondan başka ilah yoktur. O, mutlak güç sahibidir, hüküm ve hikmet sahibidir.”Âl-i İmrân-18
