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.
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..
Yukarıdaki resimde yalnızca Primary sunucu “Synchronous Commit” olarak işaretli. İki secondary’nin de ikisi Asynchronous Commit modda. Bu yapıda Primary’ye bir istek geldiğinde yapı sync modda mı çalışır, async modda mı? Şu an sistemde hiçbir secondary synchronous commit modda çalışmadığı için, Primary aslında Asynchronous Commit gibi davranır.
Transaction:
• Primary’ye gelen işlem hemen commit edilir.
• Secondary’lerin log’u alması beklenmez.
• Bu da daha hızlı ama veri kaybı riskine açık bir çalışma anlamına gelir.
Gerçek Senaryo:
1. Failover olur ve bir secondary Primary olmaya çalışırsa:
• Sadece Synchronous Commit + Automatic Failover yapıdaysa veri kaybı olmadan geçiş yapılabilir.
• Ama ikinciller Asynchronous olduğu için bu yapı veri kaybı riskiyle failover yapar.
Ne Yapmalısın?
• Eğer yüksek veri güvenliği istiyorsan:
• En az 1 secondary replikayı Synchronous Commit + Automatic Failover yap.
• Bu durumda sistem gerçekten sync çalışır.
• Şu an yapı performans öncelikli, veri güvenliği düşük yapıdadır.
Primary sunucu, kendi üzerinde “Synchronous Commit” olarak ayarlanmış gözüküyor. Ama hiçbir Secondary replika “Synchronous Commit” modunda değil. SQL Server’da gerçek Synchronous çalışma, en az bir aktif ve sağlıklı Secondary’nin de Synchronous Commit modda olmasıyla mümkündür.
Dolayısıyla:
• Primary, veriyi kendi üzerinde commit ederken Secondary replika cevap vermesini beklemiyor.
• Bu da Asynchronous davranıştır → veri kaybı riski olabilir.
• Yani loglar gönderiliyor ama beklenmeden işlem tamamlanıyor.
Not: Herhangi bir failover anından secondary sunucusu kapanıp primary sunucusu tek olarak hayatına devam eder aradan belirli bir zaman dilimi geçti secondary sunucusu halen aktif değil aynı zaman primary sunucusunda log backup alındığını zaman sistem açıldığı zaman secondary sunucusu bir süreden sonra senkron olur. Sebebi ise bir transaction log dosyası backup alındığı zaman log dosyasındaki loglar temizlenir. Ancak alwayson mekanizması secondary sunucusu için gerekli olan logları saklar.(secondary sunucuya gönderilene kadar bellek veya disk üzerinde bir yerde saklanır.) Bu nedenle log backup alınmış olsa bile secondary sunucusunun senkronize olmasını engellemez. loglar secondary sunucusuna yüklenir. Bu işlem auto seeding olmasada gerçekleşir. Eğer synchronous commit modu kullanılıyorsa: Secondary sunucu kapandığında işlemler gecikebilir, çünkü işlemlerin onaylanması için secondary sunucunun aktif olması gerekir. Ancak kapalı olduğu durumda, işlemler asynchronous olarak devam eder. Eğer asynchronous commit modu kullanılıyorsa: Primary sunucu kesintisiz işlem yapar. Secondary sunucu açıldığında, log’lar otomatik olarak gönderilir ve senkronizasyon tamamlanır. Secondary Sunucu Kendini Nasıl Günceller: Eğer Log’lar Hâlâ Mevcutsa: Redo Thread mekanizması ile Primary’den eksik log’ları alıp işler ve otomatik senkronize olur. Eğer Log’lar Temizlendiyse (Log Gap Oluştuysa): Secondary sunucu Primary sunucudan eksik log’ları alamaz ve “Not Synchronizing” olur. Bu durumda ise ne yapılır. Eğer automatic seeding açıksa, Primary sunucu eksik verileri otomatik olarak Secondary sunucuya tekrar gönderir. Ancak veritabanı büyükse bu işlem uzun sürebilir Bir başka yöntem ise Manuel Full Backup + Log Restore yöntemidir. Full backup’ı copy only yöntemiyle alınması gerekmektedir. Hiyerarşi bozulması diyedir.
Not: Eğer automatic seeding açık değilse, Secondary sunucu kapanıp açıldığında manuel full backup ve restore gerekecektir.
Not: Log Gap, SQL Server Always On ortamında Primary ve Secondary sunucular arasındaki transaction log farkıdır. Yani Secondary sunucu, Primary sunucudan belirli bir zaman dilimindeki transaction log’ları alamamışsa, bu eksiklik Log Gap olarak adlandırılır. Secondary sunucu “Not Synchronizing” durumuna düşer. Primary’den eksik log’ları alamadığı için otomatik olarak senkron olamaz. Manuel müdahale gerektirir. Kısacası primary ve secondary sunucular arasında ldf dosya farkı diyebiliriz.
Not: Yukarıdaki ilk notumuzda secondary sunucuya gönderilene kadar bellek veya disk üzerinde bir yerde saklanır demiştik. Log’lar Bellekte Ne Zamana Kadar Tutulur?
SQL Server Always On mekanizması, Secondary sunuculara gönderilmemiş log’ları bellekte (memory) ve disk üzerindeki transaction log dosyasında (.ldf) tutar. Ama bu veriler sonsuza kadar bellekte kalmaz! İşte ne zaman silindiği: Transaction log’lar, Secondary sunucuya başarıyla gönderildikten sonra bellekte temizlenebilir. Eğer Secondary sunucu kapalıysa veya gecikme varsa, SQL Server bu log’ları bellek ve disk üzerinde saklamaya devam eder. Ancak log backup alınıp, log’lar truncate edildiğinde ve Secondary sunucu hala güncellenmediyse, bu log’lar artık bellekte tutulmaz ve Log Gap oluşabilir. Yani bellek, yalnızca kısa süreli bir buffer görevi görür. Uzun süreli kesintilerde disk üzerindeki .ldf dosyası kullanılır.
Not: Peki Log’ların Saklanma Süresi Ne Kadardır?
Bu tamamen konfigurasyona ve sistemin çalışma şekline bağlıdır: Eğer log backup sık sık alınıyorsa (örneğin her 5-10 dakikada bir) ve Secondary sunucu uzun süre kapalı kalıyorsa, log’lar hızlıca temizlenir ve Secondary sunucu güncellenemez hale gelebilir (Log Gap oluşur). Eğer log backup retention süresi uzun tutuluyorsa, Primary sunucu eski log’ları daha uzun süre tutar ve Secondary açıldığında eksik log’ları alıp senkron olabilir. Secondary sunucunun replikasyon gecikme süresi (HADRSYNCCOMMIT süresi) uzun olduğunda, SQL Server log’ları daha uzun süre saklamaya çalışır. Genel olarak, log backup retention süresi 1-2 saatten uzun değilse, Secondary sunucu uzun süre kapalı kalırsa otomatik senkron olamayabilir.
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 aşağıdaki değerlerden birini döndürebilir:
- NOTHING:
- Log dosyası yeniden kullanılabilir durumda. Herhangi bir engel yok.
- Bir işlem yapmanıza gerek yok.
- CHECKPOINT:
- Log dosyasının bufferdan diske yazılması için bir checkpoint bekleniyor.
- Checkpoint işlemi otomatik olarak gerçekleşecektir. Ancak, manuel olarak CHECKPOINT komutunu çalıştırabilirsiniz.
- LOG_BACKUP:
- Log dosyasının temizlenmesi için bir log yedeği (log backup) bekleniyor.
- Log yedeği alın (BACKUP LOG komutu).
- ACTIVE_BACKUP_OR_RESTORE:
- Aktif bir yedekleme veya geri yükleme işlemi devam ediyor.
- İşlem tamamlandıktan sonra log dosyası temizlenebilir.
- ACTIVE_TRANSACTION:
- Aktif bir işlem (transaction) devam ediyor ve log dosyası temizlenemiyor.
- İşlemi tamamlayın veya işlemi sonlandırın.
- DATABASE_MIRRORING:
- Veritabanı yansıtma (mirroring) işlemi devam ediyor.
- Mirroring işlemi tamamlandıktan sonra log dosyası temizlenebilir.
- REPLICATION:
- Replikasyon işlemi devam ediyor.
- Replikasyon işlemi tamamlandıktan sonra log dosyası temizlenebilir.
- DATABASE_SNAPSHOT_CREATION:
- Veritabanı anlık görüntüsü (snapshot) oluşturuluyor.
- Snapshot işlemi tamamlandıktan sonra log dosyası temizlenebilir.
- LOG_SCAN:
- Log taraması (log scan) devam ediyor.
- arama işlemi tamamlandıktan sonra log dosyası temizlenebilir.
- AVAILABILITY_REPLICA:
- AlwaysOn Availability Group replikası log kayıtlarını işliyor.
- İşlem tamamlandıktan sonra log dosyası temizlenebilir.
- OLDEST_PAGE:
- En eski sayfa (oldest page) işlemi devam ediyor.
- İşlem tamamlandıktan sonra log dosyası temizlenebilir.
- OTHER_TRANSIENT:
- Geçici bir durum söz konusu.
- Genellikle kendiliğinden çözülür.
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
