Bu makalede AlwaysOn yapısında oluşturulan bir database’in secondary sunucusuna otomatik olarak oluşturulmasını ele alacağız. Bu işlem genelde küçük databaselerde yapılmaktadır. Gerçek sistemde tercih edilmeyen bir yöntemdir.
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ı otomatik olarak kopyalar ve güncel tutar. Bu süreç tamamen otomatik olduğu için manuel müdahale gerektirmez.
SQL Server AlwaysOn yapısında Automatic Seeding (Otomatik Tohumlama), yeni bir veritabanını secondary (ikincil) sunucuya eklerken yedek alıp (backup) o yedeği diğer sunucuya taşıyıp geri yükleme (restore) zahmetini ortadan kaldıran bir özelliktir.
Kısacası; SQL Server, veritabanı dosyalarını VDI üzerinden doğrudan ağ kanalıyla secondary sunucuya kopyalar.
Avantajları:
- Manuel yedekleme, dosya kopyalama ve geri yükleme adımlarını atlar.
- Küçük ve orta ölçekli veritabanları için kurulumu saniyeler içinde tamamlar.
- Manuel işlem sırasında oluşabilecek dosya yolu hataları veya izin problemlerini minimize eder.
Dezavantajları:
- Veriyi ağ üzerinden bastığı için bant genişliğini yoğun kullanır.
- İşlem bitene kadar primary taraftaki loglar truncate edilemez.
- Manuel yöntem kadar şeffaf değildir; bir hata oluştuğunda DMV’ler üzerinden takip etmek gerekir.
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. |
Automatic Seeding, primary sunucudaki dosya yollarının aynısını secondary sunucuda arar.
Automatic Seeding mekanizmasında, SQL Server eğer Secondary sunucuda Primary ile birebir aynı klasör yapısını (örneğin P:\Data\mydb.mdf) bulamazsa normal şartlarda hata verir. Farklı yollara restore etme durumu şu iki senaryodan biriyle gerçekleşir:
- Default Instance Klasörleri: Eğer veritabanı dosyalarınız Primary üzerinde SQL Server’ın Default Data/Log klasörleri içindeyse ve Secondary sunucunun Default klasör yolları farklıysa (Örn: Biri C:\… diğeri D:\…), SQL Server akıllı davranarak dosyaları Secondary’nin kendi default yollarına yazar.
- Aynı Drive Harfi, Farklı Alt Klasör Yokluğu: Eğer hedefte drive harfi tutuyor ama alt klasör yoksa, SQL Server bu klasörleri seeding sırasında otomatik oluşturabilir.
Ancak, Primary’de P:\CustomData\ gibi özel bir yoldaysanız ve Secondary’de P: sürücüsü hiç yoksa, Automatic Seeding başarısız olur.
Seeding işleminin durumunu şu SQL sorgusu ile takip edebilirsiniz:
SELECT start_time, completion_time, is_source,
current_state, failure_reason
FROM sys.dm_hadr_automatic_seeding;Tüm makalelerde yaptığım gibi bir örnek üzerinden konuya değinelim.
Primary sunucumda TEST adından bir database ve bu database altında ISIMLER adında bir tablo oluşturuyorum. Bu tablo içerisine bir isim insert ediyorum ve AlwaysOn yapısına alıyorum ve ikinci sunucumda gözlemliyorum. Amaç bu database ekleme yöntemiyle database secondary sunucusuna ekleniyor mu ve primary sunucuya eklenen kayıt ikinci sunucuda gözlemleye biliyormuyuz.
Şimdi TEST veritabanımı primary sunucusunda AlwaysOn’a dahil edelim.
Full backup almam gerektiğini söylüyor. Backup’ını alıp tekrar Refresh yaptıktan sonra hazır olduğuna dair mesajla karşılaşacağız.
Next deyip bir sonraki aşamaya geçeceğiz. Gelen ekranda connect deyip secondary sunucuya bağlanma işlemini gerçekleştireceğiz.
Gelen ekranda veritabanı boyutu küçük olduğu için Automatic seeding kısmını işaretliyorum ve next deyip bir sonraki aşamaya geçiyorum.
Next next dedikten sonra en sonda create scriptini alıp adım adım çalıştırıyorum.
USE [master]
GO
ALTER AVAILABILITY GROUP [SQLAlways]
MODIFY REPLICA ON N'S2\TEST' WITH (SEEDING_MODE = AUTOMATIC)
GO
--------------------------
USE [master]
GO
ALTER AVAILABILITY GROUP [SQLAlways]
ADD DATABASE [TEST];
GO
ALTER AVAILABILITY GROUP [SQLAlways] GRANT CREATE ANY DATABASE;
GO
GO
--Aşağıdaki script yardımıyla tekrardan manuel’e çekebiliriz.
USE [master]
GO
ALTER AVAILABILITY GROUP [SQLAlways]
MODIFY REPLICA ON N'S2\TEST' WITH (SEEDING_MODE = MANUAL)Secondary sunucumuzda veritabanımızın AlwaysOn yapısında oluştuğunu görmüş oluyoruz. Select sorgusu çektiğimizde primary sunucusundaki kaydın geldiğini görmüş oluyoruz.
Başarılı bir şekilde AlwaysOn yapımızda verilerimiz çekmiş olduk. Ayrıca AG üzerine sağ tıklayıp properties dedikten sonra alt tarafta bulunan kısımda seeding mode kısmını ayarlayabiliriz. Bu modu otomatik yaptığımızda availability group’a eklenen her veritabanının secondary’si SQL Server tarafından otomatik olarak oluşturuluyor. Bu işlemin yapılabilmesi için primary ve secondary sunucularda data ve log dosyaları için aynı isimde path’lerin olması gerekiyor. İkinci bir secondary sunucu eklendiğinde seeding mode otomatikse primary sunucularındaki database’ler otomatik olarak secondary sunucuya gider. Büyük veritabanlarında sıkıntıya sebep olmaktadır.
Primary sunucusunda olan dosya dizinleri secondary sunucusunda yoksa SQL Server otomatik olarak default data ve log yollarına veritabanını restore işlemi için kullanmaktadır.
Bu makalede Sql Server AlwaysOn yapısında Automatic Seeding yöntemiyle database eklenmesini ele almış olduk. Bir sonraki makalede görüşmek dileğiyle.
“Böyle birine âyetlerimiz okunduğunda sanki kulaklarında ağırlık varmış da onu işitemiyormuş gibi büyüklük taslayarak sırt çevirir. Ona acıklı bir azabı müjdele!”Lokman-7
1 thought on “MSSQL Server AlwaysOn’a Automatic Seeding Database Ekleme”