Klasik bir Always On kurulumunda, kullanıcı veritabanları ikincil sunuculara taşınsa da; Loginler (oturum açma bilgileri), Linked Serverlar ve SQL Agent Jobları gibi master ve msdb veritabanlarında tutulan nesneler otomatik olarak taşınmaz. Bu durum, failover sonrası uygulamanın “Login failed” hatası almasına neden olur.
Bu özellik ilk olarak SQL Server 2022 (16.x) sürümü ile hayatımıza girdi. Daha önceki sürümlerde (2019, 2017 vb.) bu yapı mevcut değildir.
Contained AG, SQL Server’ın her sürümünde çalışmaz. Always On teknolojisinin bir parçası olduğu için aşağıdaki sürümlere ihtiyaç duyar:
- Enterprise Edition: Tam destek sunar. Sınırsız sayıda veritabanını kapsanmış (contained) bir AG içine alabilir ve çok sayıda ikincil (secondary) replica kullanabilirsiniz.
- Standard Edition: Basic Availability Group kapsamında çok kısıtlı bir şekilde kullanılabilir. Ancak Standard Edition’da AG başına sadece 1 veritabanı sınırı ve tek replica desteği olduğu için Contained AG’nin “yönetimsel kolaylık” avantajı bu sürümde oldukça sınırlı kalmaktadır.
Contained AG, bu bağımlılığı ortadan kaldırır. AG oluşturulduğunda, AG’nin kendi içinde özel master ve msdb veritabanları oluşturulur.
- Loginler ve Joblar artık fiziksel SQL Instance’ına değil, AG’nin kendisine kaydedilir.
- AG içine eklediğiniz bir login, otomatik olarak tüm replikalara (secondary düğümlere) taşınır.
- AG seviyesindeki nesneler, fiziksel instance’ın nesnelerinden izole edilir.
Kurulum süreci standart Always On kurulumuna çok benzerdir ancak T-SQL veya Wizard üzerinde küçük bir farkla ayrılır.
Yeni bir AG oluştururken CONTAINED anahtar kelimesini eklemeniz yeterlidir:
CREATE AVAILABILITY GROUP [CAG_Sistem]
WITH (CONTAINED) -- Bu parametre özelliği aktif eder
FOR DATABASE [SatisDB]
REPLICA ON
'SQL-NODE1' WITH (...),
'SQL-NODE2' WITH (...);New Availability Group Wizard‘ı seçeneği ile yeni bir AG yapımız oluşturulur. Specify Options sayfasında “Contained” seçeneğini işaretlenir.
Yukarıdaki “Contained” seçeneğinin hemen altında pasif duran “Reuse System Databases” kutucuğuna ne işe yarar:
- İşaretlemezsen (Varsayılan): SQL Server, bu AG için sıfır, tertemiz bir master ve msdb veritabanı oluşturur. Mevcut loginleriniz veya joblarınız bu yeni AG içine otomatik taşınmaz, AG’ye bağlandıktan sonra onları baştan yaratmanız gerekir.
- İşaretlersen: Eğer daha önceden oluşturulmuş ve silinmiş bir Contained AG’den kalan sistem veritabanı dosyalarınız varsa, onları tekrar kullanmanıza olanak tanır. Genellikle yeni kurulumlarda boş bırakılır.
Reuse System Databases seçeneği ile sistem veritabanlarını mevcut bir yapıdan mı alacağınızı yoksa sıfırdan mı oluşturacağınızı belirlenir.
İkinci sunucum üzerinde de sql server 2022 kuruludur. Relicayı ekleyip Availability group’umuzu oluşturuyoruz.
Contained AG oluşturulduğunda, sistem otomatik olarak AGİsmi_master ve AGİsmi_msdb adında veritabanları oluşturur. Bunlar AG’nin iç mekanizmasını yönetir.
Contained AG içine login veya job eklemek istediğinizde, fiziksel instance yerine AG’ye bağlanmanız gerekir.
- Uygulamanız AG Listener ismine bağlandığında, otomatik olarak “contained” kapsamına girer.
- Bağlanırken Options -> Connection Properties kısmında Connect to database alanına AG ismini yazarsanız, o AG’nin özel master veritabanına ulaşırsınız.
Contained AG yapısına bağlanmak Sunucu\InstanceName ile bağlanılabildiği gibi Listener üzerinden de bağlantı gerçekleştirilir.
Mevcut SSMS ekranında yeni bir bağlantı penceresi açılır. (Connect > Database Engine):
Yukarıdaki ekranda listener ismi yazılırsa otomatik olarak Contained AG yapısına bağlanılmış olunur. Listener oluşturmadığım için Contained AG yapısına girmek için Connection ekranından Options kısmına tıklanır. Burada Connection Properties sekmesine gelinir. Connect to database kısmına elinle AG ismini, yani SQLAG yazılır.
Bu şekilde bağlandığında SQL Server seni doğrudan o AG’nin özel master veritabanına sokar.
Bağlantı sağladıktan sonra oluşturulan her bir login, job ve instance seviyesinde msdb ve master veritabanlarının kaydettiği her işlem otomatik olarak secondary sunucusuna geçmektedir. Dikkat ederseniz gerçek instance üzerinde bulunan msdb ve master veritabanına kaydedilmez. AG altında oluşan özel veritabanlarında olmaktadır.
Login Testi
Yukarıdaki yöntemle (yani SQLAG veritabanına odaklanarak) bağlandıktan sonra: Yeni bir Login oluştur: CREATE LOGIN [TestKullanici] WITH PASSWORD = ‘Sifre123!’, Şimdi ikincil (secondary) sunucuna (S2\INST2022) git ve Security > Logins altına bak. Login’i orada göreceksin! Fiziksel instance’lar arasında manuel bir taşıma yapmana gerek kalmadan SQL Server bunu arka planda senin için senkronize etti.
Job Testi
Aynı bağlantı penceresinde (AG kapsamında bağlıyken): SQL Server Agent altına git ve yeni bir Job oluştur. Job’u oluşturduktan sonra diğer sunucuya geç. Job’un diğer sunucuda da otomatik olarak belirdiğini göreceksin. Normal Always On yapısında Joblar asla kendiliğinden karşıya geçmezdi, bu Contained AG’nin en büyük farkıdır.
Birinci sunucu üzerinde oluşturulan jobın ikinci sunucuya eklendiği görülmektedir.
İkinci sunucu:
Bu özellik her senaryo için zorunlu değildir ancak şu durumlarda hayat kurtarır:
- Kullanıcıların sürekli eklendiği ortamlarda, her login’i manuel olarak secondary sunucuda “SID” çakışması olmadan oluşturma zahmetinden kurtulmak için.
- Veritabanı ile ilişkili SQL Agent Joblarının, failover sonrası secondary sunucuda da hazır olmasını istediğinizde.
- Veritabanını bir instance’tan başka bir instance’a taşırken, tüm login ve jobları paket halinde taşımak istediğinizde.
- Farklı projelerin aynı instance üzerinde ama birbirlerinin loginlerini görmeden çalışması gereken “Multi-tenant” yapılarda.
Özetle
| Özellik | Standart Availability Group | Contained Availability Group |
| Login Yönetimi | Manuel veya script ile eşitleme gerekir | Otomatik senkronize edilir |
| SQL Agent Jobları | Her node’da manuel oluşturulmalı | AG içinde bir kez oluşturulur |
| SID Çakışması | Yaygın bir sorun (Orphaned Users) | Söz konusu değil |
| Linked Server | Instance bazlıdır | AG bazlı tanımlanabilir |
Contained AG içindeki bir veritabanı özünde hala standart bir SQL Server veritabanıdır; sadece metadata seviyesinde (login/job) AG’ye bağımlıdır. Bu sebepten bu yapı içerisinde olan veritabanı ilgili AG yapısından çıkartılıp normal bir AG yapısına rahatlıkla alınabilir.
Başka makalede görüşmek dileğiyle..
Emanetlerinizi ve sözlerinizi tutun. Müminun-8
