Bu makalede AlwaysOn yapımızda primary sunucusuna eklenen database’in otomatik olarak secondary sunucusuna ekleme yöntemini ele alacağız. İlk olarak Automatic Seeding kavramının ne olduğuna değinelim.
SQL Server’da, bir AlwaysOn Availability Group’a yeni bir replica (yeni bir düğüm) eklediğinizde, yeni replica’nın veritabanlarını almak ve senkronize etmek için Automatic Seeding devreye girer. Bu özellik, yeni replica’ya veritabanlarının fiziksel kopyalarını VDI (Virtual Device Interface) üzerinden otomatik olarak aktarır ve güncel tutar. Bu süreç tamamen otomatik olduğu için manuel yedekleme ve geri yükleme (backup/restore) adımları gerektirmez.
Faydaları: Automatic Seeding, yöneticilerin manuel müdahale yükünü ortadan kaldırır. Veritabanlarının hızla senkronize edilmesini sağlayarak yüksek erişilebilirlik kurulumunu hızlandırır. Manuel kopyalama sırasında oluşabilecek “Transaction Log Chain” bozulma riskini yok eder ve LSN takibini SQL Server bizzat yapar. Bu da hem zaman kazandırır hem de veri kaybı riskini minimize eder.
Zararları ve Riskleri: Ağ üzerinde büyük veri transferlerine yol açarak ağ trafiğini ciddi oranda artırabilir. Ağ altyapısının yetersiz olduğu durumlarda replica’lar arası performans sorunlarına neden olabilir. En kritik risklerden biri; seeding işlemi tamamlanana kadar Primary node üzerindeki Transaction Log dosyasının temizlenememesidir. Büyük veritabanlarında bu durum Primary diskinde yer bitmesine yol açabilir. Ayrıca süreç otomatik ilerlediği için anlık bir bant genişliği kısıtlaması yapmak manuel yöntemlere göre daha zordur.
Dosya Yolu ve Yapılandırma Yanılgısı: “Automatic Seeding sadece her iki sunucuda da dosya yolları aynıysa çalışır” ifadesi yanlıştır. Eğer hedef sunucuda aynı path mevcut değilse, Automatic Seeding işlemi veritabanını hedef sunucudaki “Default Instance Path” üzerine oluşturur. Ancak operasyonel standartların korunması adına disk yapılarının eşlenik olması yine de tavsiye edilen yöntemdir.
Log Dosyası dolma riski vardır. Automatic Seeding işlemi başladığında, primary sunucu veritabanının bir “snapshot”ını alır. Seeding işlemi tamamlanana kadar primary sunucudaki Transaction Log dosyası temizlenemez (truncate edilemez).
- Eğer veritabanı çok büyükse ve ağ hızı yavaşsa, seeding süreci uzar.
- Bu süre zarfında veritabanında yoğun yazma işlemi (Insert/Update/Delete) oluyorsa, log dosyası disk dolana kadar şişebilir.
Bu süreçte log dosyasının dolma riski “seeding süresine” ve “aktiviteye” bağlıdır:
- Log Kilitlenmesi: Seeding başladığı andan itibaren, Primary sunucu üzerinde bir VDI (Virtual Device Interface) oturumu açılır. Bu oturum bitene kadar SQL Server, log dosyasındaki o anki checkpoint’i ileri taşıyamaz.
- Truncate Engelleyici: Siz log yedeği (Log Backup) alsanız dahi, “Active Transaction” gibi görünen seeding işlemi bitmeden log dosyası fiziksel olarak boşaltılamaz (truncate edilemez).
- Kritik Eşik: Eğer 2 TB’lık bir veritabanını 100 Mbps gibi yavaş bir hatla taşımaya kalkarsanız, işlem 20-30 saat sürebilir. Bu 30 saat boyunca gelen tüm INSERT/UPDATE işlemleri log dosyasını şişirir ve disk dolarsa sistem “Standby” veya “Read-only” moda düşebilir.
Hangi veritabanları için geçerli olduğuyla ilgili teknik olarak bir boyut sınırı yoktur ancak pratik kullanımda şunlar önerilir:
- Küçük ve Orta Ölçekli (<500 GB – 1 TB): Hızlı ağ bağlantısı (10Gbps+) varsa sorunsuz çalışır.
- Büyük Ölçekli (>1 TB): Çok büyük veritabanlarında ağ kesintisi riski ve log şişmesi nedeniyle hala geleneksel “Backup-Restore” yöntemi daha güvenli kabul edilir.
| Veritabanı Boyutu | Önerilen Yöntem | Risk Faktörü |
| 0 – 200 GB | Automatic Seeding | Çok düşük. Modern ağlarda dakikalar içinde biter. |
| 200 GB – 1 TB | Automatic Seeding | Orta. Ağ hızınız 1Gbps ve altındaysa log takibi yapılmalı. |
| 1 TB ve Üstü | Manual (Backup/Restore) | Yüksek. Uzun süren seeding, Primary diski patlatabilir. |
Makalenin sonunda basit bir scriptle SSMS arayüzüne gerek kalmadan primary AG altına database ekleme işlemini ele alacağız. Şuan database üzerinde Seeding Mode olarak manuel olarak işaretlenmiş durumda.
Bu işlemi uygulamalı bir şekilde yapmak için sıfırdan bir database oluşturalım. Bu database’i primary sunucusunda Automatic seeding yapısıyla AlwaysOn yapısına ekleyelim.
Primary sunucusunda AlwaysOn yapısına otomatik seeding modda eklemiş olduğumuz veritabanı secondary sunucusuna replica olmuş durumda .
Seeding mode yukarıdaki veritabanımızı eklerken başlangıçta manuel olmasına rağmen SSMS arayüzünden auto seeding yapısıyla primary sunucusunda veritabanı eklediğimizde secondary sunucusunda senkron olmuş olur. AG properties ekranından secondary sunucunun seeding mode otomatik bir yapıya dönüşmüş olduğunu görmüş oluyoruz.
Not: Seeding mode her sunucuya özgü çalışmaktadır. Genel bir ayarı bulunmamaktadır.
Eğer veritabanımızı ilk AG altına alınırken Skip initial data synchronization mode seçilerek sadece primary altına replica olmuş olabilir. Veritabanımızı primary AG üzerine eklemeden önce AG properties ekranından seeding mode’u otomatiğe çekip secondary sunucusunda olmayan databaselerin otomatikmen replica olmasını sağlayabiliriz. Büyük veritabanları restoring moduna girip daha sonra dahil olmaktadır.
Şunu da belirtmek gerekir ki Başlangıçta seeding mode manuel olup Skip initial data synchronization ile veritabanımızı ekleseydik secondary sunucusuna veritabanımız gelmezdi sadece ilgili AG altında veritabanımız ünlem işareti olmuş olurdu. Primary sunucusunda AG properties ekranında seeding mode otomatik yapıya çekilirse secondary sunucularındaki veritabanı replica olur.
Veritabanları skip initial data synchronization yöntemiyle eklenip seeding mode Automatic olması durumlarında büyük küçük tüm dblerin otomatik olarak secondary sunucusuna geçmesi sağlanır. Bu yöntem yerine primary sunucusunda skip initial data synchronization yöntemiyle primary sunucusuna eklenen db, secondary sunucunda full,diff ve log backup’ı restoring modda secondary sunucusunda restore edilerek daha sonra AG’ye senkron edilmesi gerekmektedir. Bu yöntem denenmek istendiğinde Seeding Mode Automatic yapıya çekilmesi gerekmektedir.
Aşağıdaki bulunan bir başka örnek veritabanı skip initial data synchronization eklenmeden önce Seeding Mode primary ve secondary sunucularında otomatik değilse Secondary sunucusunda aşağıdaki resimde görüldüğü gibi veritabanı dahil edilmez. Seeding Mode otomatik olarak manuel yapısına dönüştürülmektedir.
Not: Veritabanı ekleme işlemi skip initial data synchronization ile yapılırsa secondary sunucularında auto seeding mode manual’e çevrilir. Tüm sunucularda auto seeding mod sunucu bazlıdır.
Aşağıdaki yapı üzerinden AG altına bir veritabanı eklersek Secondary sunucusuna database dahil olmaz. Yukarıdaki örneğin aynısı diyebiliriz.
Aşağıdaki komut ile ilgili sunucunun Seeding Mode’u manuel veya otomatik yapılabilir.
USE [master]
GO
ALTER AVAILABILITY GROUP [AG2]
MODIFY REPLICA ON N'S1\TEST' WITH (SEEDING_MODE = MANUAL)
GO
----------------------
USE [master]
GO
ALTER AVAILABILITY GROUP [AG2]
MODIFY REPLICA ON N'S2\TEST' WITH (SEEDING_MODE = AUTOMATIC)
GO
Kısacası yukarıdaki komut ile seeding mode’u otomatik yapısına alarak database’in kendiliğinden secondary sunucusunda senkron olmasını sağlayabiliriz.
Elimizde bulunan bir database’i primary sunucusunda uzun uzadıya SSMS arayüzünde yapmayıp aşağıdaki komut ile hemen primary sunucusunda AG altına alınabilir. Aşağıdaki komut auto seeding yapısı ile veritabanını secondary sunucuya geçirmektedir. Disk yolları aynı değilse bile default disk yollarında oluşmaktadır.
ALTER AVAILABILITY GROUP [AG2] ADD DATABASE DB10;Not: Sql server availability group altına database eklenmesi sırasında spn, tde veya başka bir sebepten veritabanımızı ekleyemezsek Yukarıdaki komut sayesinde rahatlıkla primary sunucusuna eklenir. Secondary sunucusunda veritabanı tam eşir bir şekil restoring modunda duruyorsa ilgili veritabanıda bağlanmaktadır. Neden çünkü yukarıdaki komut availability group üzerinde bulunan auto seeding özelliğini otomatik yapıya çekmektedir.
Yukarıdaki komut ile DB10 database’i primary sunucusuna dahil edilir. Aşağıdaki resimde ise secondary sunucusunda senkron olduğunu gözlemlemiş oluruz. Bunun sebebi AG properties ekranından iki replicamızın seeding modunun otomatik olmasından dolayıdır.
Seeding mode manuel durumda olsa bile YENIDB database’i AG23 altına eklenmiş olduğu görülmektedir. Zaten AG altındaki tüm dbler secondary sunucusunda görünür. Manuel bir şekilde primary sunucusundaki AG altına alınırken database’imiz hata mesajı ile karşılaşırsak AG’mize database oluşturma yetkisi verilmesi gerekmektedir. Bunun için aşağıdaki komut kullanılmaktadır.
ALTER AVAILABILITY GROUP [AG23]
GRANT CREATE ANY DATABASE;
GO
Secondary sunucusunda AG altına dahil etme işlemini makalenin başında bahsettiğim gibi seeding mode’u ya otomatiğe çekeriz yada elle manuel bir şekilde restoring modda bırakıp dahil etme işlemlerimizi yapabiliriz.
Başka bir makalede görüşmek dileğiyle…
“Allah’tan kulları içinde ancak ilim sahibi olanlar korkar.” Fâtır sûresi – 28
