# Always On Availability Groups Ortamında Değişiklik Yönetimi

Always On AG yüksek erişilebilirlik sağlar. Ama aynı zamanda değişiklik yönetimini standart SQL Server ortamına göre çok daha karmaşık hale getirir.

Neden Daha Karmaşık? Tek bir SQL Server'da değişiklik yaparsınız, biter. AG ortamında şunları düşünmek zorundasınız: Primary'de yapılan değişiklik secondary'lere nasıl yansıyacak? Schema değişiklikleri otomatik replike edilir mi? Failover sırasında yarım kalan bir deployment ne olur? Her node'da aynı versiyon mu çalışıyor? Bu soruların her biri ayrı bir risk kalemi.

AG'de Schema Değişiklikleri Always On AG'de DDL değişiklikleri otomatik olarak secondary'lere replike edilir. Bu iyi haber. Ama bazı özel durumlar var. DBCC komutları replike edilmez. Primary'de çalıştırılan DBCC işlemlerini secondary'de ayrıca çalıştırmanız gerekebilir. Full-text catalog değişiklikleri bazı durumlarda replikasyonu geciktirir. Büyük DDL operasyonları log'u şişirir ve secondary'nin primary'ye yetişmesini yavaşlatır. Bu süreçte RPO hedefleri etkilenebilir.

Failover Sırasında Deployment AG ortamında en riskli senaryo deployment sırasında failover yaşanması. Deployment başladı, yarı tamamlandı. Primary çöktü. Secondary devreye girdi. Ama secondary'de deployment yarım kaldı. Sistem tutarsız bir durumda. Bu senaryoya karşı hazırlık şu anlama geliyor: deployment öncesinde AG sağlık durumu kontrol edilmeli, mümkünse AG ortamında deployment penceresi daha geniş tutulmalı ve her adım idempotent olmalı yani aynı scripti iki kez çalıştırmak sorun yaratmamalı. sql-- AG sağlık durumunu kontrol et SELECT ag.name AS AGAdi, ar.replica\_server\_name AS Sunucu, rs.role\_desc AS Rol, rs.synchronization\_health\_desc AS SenkronizasyonDurumu, rs.connected\_state\_desc AS BaglantıDurumu FROM sys.availability\_groups ag JOIN sys.availability\_replicas ar ON ag.group\_id = ar.group\_id JOIN sys.dm\_hadr\_availability\_replica\_states rs ON ar.replica\_id = rs.replica\_id ORDER BY ag.name, rs.role\_desc; Deployment öncesinde bu sorgu çalıştırılmalı ve tüm replica'ların SYNCHRONIZED ve CONNECTED durumda olduğu doğrulanmalı.

Read-Only Secondary'lerde Değişiklik Riski AG'de secondary'ler read-only olarak yapılandırılabilir. Raporlama sorguları secondary'ye yönlendirilir. Bir DDL değişikliği primary'de yapıldığında secondary'ye replike edilene kadar kısa bir süre fark oluşur. Bu süreçte secondary'ye bağlı raporlar hata verebilir. Bu pencereyi minimize etmek için büyük DDL değişikliklerini düşük trafik saatlerine planlamak önemli.

Sonuç Always On AG ortamında değişiklik yönetimi daha fazla koordinasyon gerektirir. AG sağlık kontrolü, idempotent script tasarımı ve doğru zamanlama bu ortamlarda temel gereksinimler. Detaylı bilgi için: sqlchangeguard.com