Always On Ortamlarında SQL Server ve Windows Güncellemeleri: Rolling Update Rehberi

Always On kullanan bir ortamda SQL Server Cumulative Update’lerini ya da Windows güncellemelerini uygulamak, tek sunuculu bir ortama göre daha fazla planlama gerektirir. Doğru sırayla ilerlendiğinde bütün süreç boyunca kullanıcıların hissedeceği kesinti tek bir manuel failover süresiyle sınırlı kalır. Sıralama hatalı olduğunda ise senkronizasyonu duran replikalar, beklenmedik failover’lar ve uzayan kesintilerle karşılaşılabilir.

Bu rehberde, Microsoft’un rolling update yaklaşımını temel alarak Always On Availability Group (AG) ve Failover Cluster Instance (FCI) ortamlarında SQL Server ve Windows güncellemelerinin nasıl planlanıp uygulanacağını adım adım ele alıyoruz. Her aşamada kullanabileceğiniz kontrol sorgularını ve komutları da paylaşıyoruz.

Rolling Update Nedir?

Rolling update, cluster’daki node’ların aynı anda değil, sırayla güncellenmesi yaklaşımıdır. Önce aktif iş yükü taşımayan node’lar güncellenir, ardından iş yükü güncellenmiş bir node’a taşınır ve son olarak eski aktif node güncellenir. Microsoft’a göre bu yöntem, ister yeni bir SQL Server sürümü ister bir Cumulative Update ya da Windows güncellemesi olsun, primary tarafındaki kesintiyi tek bir manuel failover ile sınırlar. Orijinal primary’ye geri dönmek isterseniz bu sayı ikiye çıkar.

Bu yaklaşımın ön koşulu, uygulamaların sunucu adı yerine her zaman Availability Group listener (FCI’de ise sanal sunucu adı) üzerinden bağlanmasıdır. Bağlantı cümlesinde doğrudan node adı kullanan uygulamalar failover sonrasında eski sunucuya bağlanmaya çalışır ve DNS ya da bağlantı ayarları güncellenene kadar erişim sorunu yaşar. Birden fazla subnet’e yayılan ortamlarda bağlantı cümlesine MultiSubnetFailover=True eklenmesi de failover sonrası yeniden bağlanma süresini kısaltır. Güncelleme penceresinden önce bu bağlantıları gözden geçirmenizi öneriyoruz.

Güncellemeden Önce: Hazırlık Listesi

Güncelleme sırasında yaşanan sorunların büyük bölümü, hazırlık aşamasında tespit edilebilecek eksiklerden kaynaklanır. Microsoft’un önerileri ve sahadaki pratik doğrultusunda başlamadan önce şu adımların tamamlanmasını öneriyoruz:

• Güncellemeyi önce test ortamında doğrulayın. Üretime benzer bir ortamda uygulamaları, job’ları ve kritik raporları kontrol edin. Uygulayacağınız CU’nun bilinen sorunlar listesini okuyun; bu konuyu riskli SQL Server build’leri yazımızda ayrıntılı olarak ele alıyoruz.
• Tüm availability veritabanlarının tam yedeğini alın ve DBCC CHECKDB çalıştırın. Microsoft, rolling update öncesinde bu iki adımı açıkça öneriyor.
• En az bir senkron replikada deneme amaçlı manuel failover yapın. Failover’ın sorunsuz çalıştığını ve uygulamaların listener üzerinden yeniden bağlandığını güncelleme gününden önce görmüş olursunuz.
• Gerekli ön koşul yazılımlarını tüm node’lara önceden kurun. Böylece güncelleme sırasında beklenmedik yeniden başlatmalar ve uzayan bakım süreleri önlenir.
• Yedekleme tercihini geçici olarak primary’ye alın. Güncellenmekte olan bir veritabanının yedeği alınamaz. Yedekleme job’larınız secondary replikalarda çalışıyorsa, secondary’leri güncellemeden önce yedekleme tercihini primary olarak değiştirin.
• Windows Update’in node’ları kendi kendine yeniden başlatmadığından emin olun. Cluster node’larında otomatik yeniden başlatma, planlanmamış failover’lara yol açabilir. Ayrıntılar için Windows otomatik güncellemeleri yazımıza göz atabilirsiniz.

Replikaların sağlık durumunu aşağıdaki sorguyla kontrol edebilirsiniz. Güncellemeye başlamadan önce tüm senkron replikaların HEALTHY durumda olması gerekir:

-- Replika seviyesinde rol, mod ve sağlık durumu
SELECT ag.name                          AS ag_name,
       ar.replica_server_name,
       ars.role_desc,
       ar.availability_mode_desc,
       ar.failover_mode_desc,
       ars.connected_state_desc,
       ars.synchronization_health_desc
FROM sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
     ON ar.group_id = ag.group_id
JOIN sys.dm_hadr_availability_replica_states AS ars
     ON ars.replica_id = ar.replica_id
ORDER BY ag.name, ars.role_desc;

Availability Group Ortamlarında Güncelleme Sırası

Microsoft’un önerdiği sıra, en az kritik replikadan başlayıp primary’ye doğru ilerler. İki node’lu basit bir senkron AG’de bu süreç, secondary’nin güncellenmesi, failover ve eski primary’nin güncellenmesinden ibarettir. Daha geniş topolojilerde ise şu sırayı izlemenizi öneriyoruz:

1. Automatic failover’ı kaldırın. Güncelleme sırasında yeniden başlatılan bir node’un beklenmedik bir failover tetiklemesini önlemek için tüm senkron replikaları geçici olarak manuel failover moduna alın.
2. Asenkron secondary replikaları güncelleyin.
3. Uzak lokasyondaki senkron secondary replikaları güncelleyin.
4. Yerel senkron secondary replikaları güncelleyin.
5. Güncellenmiş bir yerel senkron secondary’ye manuel failover yapın. Failover’dan önce hedef replikanın SYNCHRONIZED durumda olduğunu doğrulayın.
6. Eski primary’yi güncelleyin.
7. Automatic failover ayarlarını eski haline getirin ve isterseniz ikinci bir manuel failover ile orijinal primary’ye geri dönün.

Automatic failover ayarı primary replika üzerinden değiştirilir. Aşağıdaki örnekte AG1 grubundaki iki senkron replika manuel moda alınıyor ve güncelleme tamamlandıktan sonra eski haline getiriliyor:

-- Primary'de çalıştırın: güncelleme öncesi automatic failover'ı kaldırın
ALTER AVAILABILITY GROUP [AG1]
    MODIFY REPLICA ON N'NODE1' WITH (FAILOVER_MODE = MANUAL);
ALTER AVAILABILITY GROUP [AG1]
    MODIFY REPLICA ON N'NODE2' WITH (FAILOVER_MODE = MANUAL);

-- Secondary'ler güncellenmeden önce yedekleri primary'de tutun
ALTER AVAILABILITY GROUP [AG1]
    SET (AUTOMATED_BACKUP_PREFERENCE = PRIMARY);

-- Güncelleme tamamlandıktan sonra eski ayarlara dönün
ALTER AVAILABILITY GROUP [AG1]
    MODIFY REPLICA ON N'NODE1' WITH (FAILOVER_MODE = AUTOMATIC);
ALTER AVAILABILITY GROUP [AG1]
    MODIFY REPLICA ON N'NODE2' WITH (FAILOVER_MODE = AUTOMATIC);

AUTOMATED_BACKUP_PREFERENCE ayarı yalnızca yedekleme job’larınız sys.fn_hadr_backup_is_preferred_replica kontrolünü kullanıyorsa etkilidir. Kendi yedekleme script’lerinizi kullanıyorsanız, hangi replikada çalıştıklarını ayrıca kontrol etmeniz gerekir.

Failover’dan Önce Senkronizasyonu Doğrulayın

Manuel failover, hedef replikadaki tüm veritabanları SYNCHRONIZED durumdayken yapılmalıdır. Aşağıdaki sorgu her veritabanının senkronizasyon durumunu, gönderilmeyi ve uygulanmayı bekleyen log miktarını ve failover’a hazır olup olmadığını gösterir:

SELECT ag.name                        AS ag_name,
       ar.replica_server_name,
       drcs.database_name,
       drs.synchronization_state_desc,
       drs.is_suspended,
       drs.log_send_queue_size        AS log_send_queue_kb,
       drs.redo_queue_size            AS redo_queue_kb,
       drcs.is_failover_ready
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar
     ON ar.replica_id = drs.replica_id
JOIN sys.availability_groups AS ag
     ON ag.group_id = drs.group_id
JOIN sys.dm_hadr_database_replica_cluster_states AS drcs
     ON drcs.replica_id = drs.replica_id
    AND drcs.group_database_id = drs.group_database_id
ORDER BY ag.name, ar.replica_server_name, drcs.database_name;

Hedef replikadaki tüm veritabanlarında is_failover_ready değeri 1 ve kuyruklar boş ya da çok düşük seviyedeyse, failover komutunu hedef secondary replika üzerinde çalıştırabilirsiniz:

-- Güncellenmiş hedef secondary'de çalıştırın
ALTER AVAILABILITY GROUP [AG1] FAILOVER;

-- Eski primary güncellendikten sonra veri akışı askıda kaldıysa
-- (secondary'ye dönüşen eski primary'de, her veritabanı için)
ALTER DATABASE [SalesDB] SET HADR RESUME;

Bu komut, veri kaybı olmadan yapılan planlı bir failover’dır. FORCE_FAILOVER_ALLOW_DATA_LOSS seçeneği yalnızca felaket senaryoları içindir ve planlı bir güncelleme sürecinde kullanılmamalıdır.

Microsoft ayrıca failover’ın her zaman senkron bir replikaya yapılmasını öneriyor. Asenkron bir replikaya failover yapıldığında veritabanları veri kaybına açık hale gelir ve veri akışı, manuel olarak devam ettirilene kadar otomatik olarak askıya alınır. Yalnızca felaket kurtarma amacıyla kurulmuş, uzak lokasyonda tek bir asenkron replikanın bulunduğu ortamlarda ise failover öncesinde commit modunun geçici olarak senkron yapılması ve replikanın SYNCHRONIZED durumuna gelmesinin beklenmesi gerekir. Senkron modun uzak lokasyonda gecikmeyi artıracağını göz önünde bulundurarak bu işlemi düşük trafikli bir zamanda yapmanızı öneriyoruz.

Failover Cluster Instance (FCI) Ortamlarında Güncelleme

FCI’lerde de aynı rolling yaklaşım geçerlidir: SQL Server Setup her node’da tek tek çalıştırılır ve işe pasif node’lardan başlanır. Microsoft’un dokümantasyonuna göre güncellenen her node, güncelleme sırasında FCI’nin olası sahipleri (possible owners) listesinden çıkarılır; böylece beklenmedik bir failover durumunda güncellenmemiş bir node’a geçiş yapılmaz. Node’ların yarısı veya daha fazlası güncellendiğinde Setup, bir sonraki node’un güncellenmesi sırasında FCI’yi otomatik olarak güncellenmiş bir node’a taşır. Bu davranışı kontrol etmek isterseniz güncellemeyi komut satırından /FAILOVERCLUSTERROLLOWNERSHIP parametresiyle çalıştırabilirsiniz.

Bu süreçte kullanıcıların yaşadığı kesinti, tek bir failover süresi ile veritabanı yükseltme script’lerinin çalışma süresinden oluşur. FCI’ler aynı zamanda bir AG’nin replikası olarak kullanılıyorsa, her FCI içinde önce pasif node’lar güncellenir ve AG için yukarıda anlatılan sıra korunur.

Windows Güncellemeleri

Windows güncellemeleri de aynı mantıkla, node node uygulanmalıdır. Ancak burada AG ve FCI ortamları arasında önemli bir fark vardır:

• FCI ortamlarında SQL Server bir cluster rolü olarak çalıştığı için, güncellenecek node’u Suspend-ClusterNode -Drain ile duraklatmak rolleri diğer node’lara güvenli şekilde taşır.
• AG ortamlarında ise primary rolün cluster üzerinden taşınması önerilmez. Bunun yerine önce AG’yi T-SQL ile başka bir replikaya failover edin, ardından artık primary rolü taşımayan node’u duraklatın.

# FCI node'u: rolleri boşaltarak duraklat
Suspend-ClusterNode -Name "NODE2" -Drain

# AG node'u: önce AG'yi T-SQL ile failover edin, sonra rolleri taşımadan duraklatın
Suspend-ClusterNode -Name "NODE2"

# Windows güncellemelerini ve gerekiyorsa SQL Server CU'sunu uygulayın, sunucuyu yeniden başlatın

# Node'u tekrar cluster'a dahil edin (rolleri otomatik geri almadan)
Resume-ClusterNode -Name "NODE2" -Failback NoFailback

Aynı bakım penceresinde hem Windows hem SQL Server güncellemesi yapılacaksa, her ikisini aynı node üzerinde tek seferde uygulamak ve tek bir yeniden başlatmayla tamamlamak, ikinci bir failover turuna gerek bırakmaz.

Güncelleme Sonrası Doğrulama

Tüm node’lar güncellendikten sonra süreci tamamlanmış saymadan önce şu kontrollerin yapılmasını öneriyoruz:

• Tüm node’larda build numarasının beklenen değerde olduğunu SELECT SERVERPROPERTY('ProductVersion') ile doğrulayın. Microsoft, aynı AG içinde farklı sürümlerdeki instance’ların yalnızca rolling güncelleme süresince bir arada bulunmasını destekliyor; farklı CU seviyelerinin de uzun süre bir arada kalmaması gerekir.
• Replika ve veritabanı sağlık sorgularını yeniden çalıştırın; askıda kalan veritabanı olmadığından ve kuyrukların boşaldığından emin olun.
• Automatic failover ve yedekleme tercihi ayarlarının eski haline getirildiğini kontrol edin.
• Error log’u ve Agent job geçmişini inceleyin; özellikle yedekleme, CHECKDB ve index bakım job’larının bir sonraki çalışmalarını takip edin.
• Change Data Capture veya replikasyon kullanılan veritabanlarında, güncellemenin release notlarında ek adım gerekip gerekmediğini kontrol edin.

Güncellenmiş bir secondary replika, bakım süresince biriken log’u primary’den alıp uygulayana kadar bir süre geride kalabilir. Bu süre primary üzerindeki işlem yoğunluğuna bağlıdır ve ağ trafiğinde geçici bir artış beklenmelidir. Bir sonraki node’a geçmeden önce bu senkronizasyonun tamamlanmasını beklemenizi öneriyoruz.