Bu makalede join only yöntemiyle AlwaysOn ortamında database ekleme işlemine değineceğim. Eğer database’imiz büyükse veya secondary makinemiz uzak bir lokasyondaysa bu yöntemi kullanmakta fayda var. Çok büyük transactionlarımız varsa secondary sunucusuna database eklemede ilk iki seçenek log dosyamızın şişmesine sebep oluyor.
Auto Seeding sırasında, primary replikadaki VLF’ler (Virtual Log Files) tüm veri taşıma işlemini transaction log olarak kaydeder. 100GB’lık bir veritabanı için Auto Seeding başlatıldı. İşlem sırasında ~100GB’lık log kaydı oluşur. Log backup’ı alınmazsa log dosyası dolana kadar büyümeye devam eder.
Full database and log backup yönteminde secondary database NORECOVERY modunda olduğu sürece, gelen tüm log kayıtları işlenir ama serbest bırakılmaz. Secondary sunucusunda veritabanı restoring modunda olduğu sürece primary sunucusunda log backup alınsa bile truncate işlemi gerçekleşmez.
Önceden AlwaysOn’a eklemiş olduğum databaseleri AlwaysOn’dan çıkarıp tekrardan belirtilen AlwaysOn’a alma adımını yapmaya çalışacağım. Bu adımlada bir veritabanı AlwaysOn’dan nasıl çıkarılı ele almış olacağız.
Önceki database’i AlwaysOn’dan çıkaracağım zaman secondary sunucusundan kendisi otomatikmen çıkarmış oluyor. Secondary sunucusundan AlwaysOn’dan çıktıktan sonra veritabanı databases sekmesi altında restoring modda oluyor.
Primary sunucusunda Remove database.. dediğimizde secondary sunucusunda ilgili veritabanı restoring moduna düşüyor.
İkinci node’da restoring moda düşen database artık silinebilir.
Bu makalede join only işlemi yapacağımız için primary sunucumuzda Availability Groups’un altında Availability Databases sekmesine sağ tıklanır.
Gelen ekran next denilip bir sonraki adıma geçilir.
Gelen ekranda AdvantureWorks2012 veritabanımızın AlwaysOn için gerekli özellikleri karşıladığını söylüyor. Önceki makalelerde gerekli şartları karşılamadığında ne gibi senaryolar yapıldığından bahsetmiştik. Next deyip bir sonraki adıma geçiyoruz.
Gelen ekranda primary sunucumuzdan S2\TEST sunucumuza bağlanıyoruz.
Bağlantıyı sağladıktan sonra Next deyip bir sonraki aşamaya geçiyoruz.
Makalemizinde konu başlığı olan Join only kısmını seçip Next deyiyoruz. Database’imiz büyükse ve secondary makinemiz uzak bir lokasyondasa bu sekmeyi kullanabiliriz.
Automatic seeding moda ve full database and log backup modu ile işlemlerimizi yaptığımız zaman transaction’larımız aşırı derecede büyüyor ldf’imizin bu şekilde dolmasına sebep olacaktır.
Join only işleminden önce secondary sunucusuna ekleyeceğimiz veritabanı için bir full backup’ını alıyorum. Bu işlem, yaptıktan sonra log backup alıyorum. Veritabanımıza aktif transaction geldiğini varsayarsak bu yöntem hızlı bir şekilde secondary makinesinin primary makinesiyle sekronizasyonu sağlıyor.
Şimdi Adventureworks2012 veritabanının backup’ını alıyorum.
Yukarıdaki işlemi yaptıktan sonra ilgili veritabanımın log backup’ını alıyorum.
Şimdi almış olduğum bu full ve log backup’ı secondary sunucuna restore işlemine alıyorum.
Bu backup’ları secondary sunucuma fiziksel olarak kopyalıyorum. Kopyalamayıp bu klasörü paylaşıma açsamda olur.(Sharing) Ama bu işlem network hızında gerçekleştiği için yavaş olacaktır.
Secondary sunucuma kopyaladıktan sonra şimdi ise SSMS arayüzünden restore işlemlerine geçelim.
Database’i seçtikten sonra option kısmından norecovery modu seçip veritabanını restoring modunda bırakıyorum. Veritabanını kullanıma açmıyorum.
Aşağıdaki resimde görüldüğü gibi ilgili bölümden norecovery mod seçilir.
Veritabanımız görüldüğü gibi restoring modunda üzerine diff veya log backup dönülebilir hale getirdik.
Restoring modda üzerine bir diff veya log backup bekliyor durumda. Şimdi secondary sunucusunda restoring modda olan database üzerine log backup’ı restore ediyorum. Buraya dikkat edilmesi gereken log backup restore edilirse primary sunucusunda log backup alınmaması lazım lsn değeri değişir buda backup’ımızı restore edemediğimize sebep olur. Log shipping yöntemiylede bu yapılabilir ama log’la ilgili job’ımız varsa kapatılması gerekmektedir. Yoksa ilgili log backup dosyamızında restore edilmesi gerekmektedir.
Restore edeceğimiz log dosyasını seçtikten sonra tekrar options bölümünden norecovery modunda log backup’ımızı restore ettiğmiz full backup’ın üzerine dönüyoruz.
Veritabanımızı yine restoring modda bırakıyoruz.
Benim elimde canlı veri olmadığı için gerçek sistemlerde durum aynen yukarıdaki gibi olmaktadır. Tek fark ben secondary sunucusunda restore işlemleri yaparken primary sunucusunda veriler birikmiş olabilir. Yukarıdaki gibi restore işlemini tamamlamadan önce primary sunucusunda son log backup alınır. Yukarıdaki gibi log backup no recovery modda restore edilir ve daha sonra aşağıdaki yöntemlerdeki gibi always ona dahil edilir.
Kısacası secondary sunucu ile primary sunucusu arasımdaki farkı minimize etmek için kullanılır.
Tekrardan primary sunucusuna geliriz always on database senkronizayon ekranına kaldığımız yerden devam ederiz. İkinci node’a restore işlemi yapıldıktan sonra AG üzerinde database aşağıdaki şekilde eklenebilir.
Next deyip bir sonraki aşamaya geçeriz. Kurulumuzun başarılı bir şekilde yapıldığını görmüş oluyoruz.
Not: Alwayson yapısında bir secondary replica üzerinde bir veritabanı join aşamasına geliyorsa bu durum history kısmında görünür. Alwayson a dahil etmezsek bile, bunun temel nedeni veritabanının synchronize sürecinde geçici olarak bu durumda olmasıdır. Diff backup restore edildikten sonra veritabanı lsn zinciri kopmadığı için alwayson mekanizması otomatik olarak devreye girer ve secondary sunucusunda veritabanı join olarak görünür. Log backup’ı restore etmeden senkron olabileceğini alwayson içerisideki log mekanizmasıyla öğrenmiş oldu. Bu durumu genellikle Skip initial data synchronization bölümünü seçip veritabanı manuel ekleyeceğimiz zaman görülmektedir.
History dediğimiz kavram aşağıdan veya Show dasboard ekranından gözleyebiliriz.
SELECT
ag.name AS AvailabilityGroupName,
db.name AS DatabaseName,
drs.synchronization_state_desc AS SynchronizationState,
drs.synchronization_health_desc AS SynchronizationHealth,
r.replica_server_name AS ReplicaServerName
FROM
sys.dm_hadr_database_replica_states AS drs
JOIN
sys.availability_groups AS ag
ON drs.group_id = ag.group_id
JOIN
sys.databases AS db
ON drs.database_id = db.database_id
JOIN
sys.availability_replicas AS r
ON drs.replica_id = r.replica_id
ORDER BY
ag.name, db.name;Kurulum işlemlerinden sonra secondary sunucumuzda database’imiz AG’ye dahil olmuş mu kontrol ediyoruz.
Secondary sunucusunda synchronized durumunda olduğunu görmüş oluyoruz. Join only yöntemiyle secondary sunucusunda veritabanımız hemen AG altına dahil olmaktadır.
Başka bir makalede görüşmek dileğiyle..
“Şüphesiz, inkar edenlere, ne malları, ne de evlatları Allah’a karşı hiçbir fayda sağlamaz. Onlar ateşin yakıtıdırlar.”Âl-i İmrân-10
