Always On Availability Groups Ortamında Değişiklik Yönetimi
I’m a passionate software engineer specializing in SQL change management, database security, and DevOps automation. With over 17 years of experience in the banking sector, I focus on building tools and processes that make database deployments safer, more auditable, and automated.
As the creator of SQL Change Guard, I develop solutions that use risk scoring and AI-powered code analysis to detect dangerous SQL scripts before they reach production. I’m dedicated to helping teams minimize downtime and data loss through smarter change governance.
When I’m not coding, I enjoy sharing insights about secure development practices, WPF desktop applications, and integrating modern CI/CD pipelines.
Feel free to connect or reach out at info@sqlchangeguard.com
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