Bu makalede Always on yapısında olan büyük veritabanlarının farklı bir sunucuya nasıl taşınır. Bunu görmüş olacağız. Bu taşıma yöntemini log shipping yöntemi ile 3. ve 4. node’a alwayson altındaki veritabanını alma yöntemini ile yapmış olacağız.
Öncelikle log shipping yapısına değinmek gerekirse bu yapı veritabanı bazlı yapılmaktadır. Primary sunucusu üzerinde log backupların bir paylaşım klasörüne alınarak secondary sunucusuna restore işlemine denilmektedir. Veritabanı recovery model’in full olması gerekmektedir.
Oluşturacağımız bu sistemde 3. ve 4. node farklı bir clusterda bu cluster’da bulunan node’lara veritabanlarımızı log shipping ile restore işlemi yapmış olacağız. Daha sonra 3. ve 4. node bulunan log shipping ile alınmış veritabanlarını birbirlerine aynı AG altında bağlamış olacağız.
Aşağıdaki resimde Alwayson yapısında olan 2 sunucumuz görülmektedir. S1 ve S2 sunucumuz birbirleriyle senkron durumdadır. Log shipping yapacağımız sunucu S1 sunucusu
Aşağıdaki resimde iki farklı clusterda sunucularımız görülmektedir.
Primary olan sunucu üzerinde log backuplar düzenli bir şekilde alınmaktadır. Backup job’ı durdurulur çünkü log shipping kendi log job’ını almış olacaktır. Karmaşıklığı önlemek amacıyla default olan log backup job’ı durdurulur.
Bu database’in transaction log’ları BAŞKA BİR YEDEKLEME Job’ı ile alınırsa:
- Log shipping BOZULUR
- Secondary sunucular restore edemez.
- Data kaybı riski oluşur
Şimdi primary olan S1 sunucusu üzerinden S3 ve s4 sunucumuz için Log Shipping yapılandırmasını açalım.
Log shipping kurulumuna başlamadan önce Transaction log dosyalarını tutacağımız bir paylaşım klasörü yapacağız.
Veritabanı üzerine sağ tıklanır properties kısmına gelinir. Gelen ekranda Transaction Log Shipping sekmesine gelinir. İlgili Enable this as a primary database in a log shipping configuration checkbox’ı aktif edilir.
Transaction Log Shipping sekmesini aktif ettikten sonra Transactions log backups bölümünde bulunan Backup Settings.. kısmına tıklanır. Bu işlem S1 sunucusundaki yapılandırma içindir.
Gelen ekranda Backup job bölümünde Job Name kısmında job’a bir isim verdikten sonra Schedule kısmına tıklayarak backup için gerekli olan zaman konfigürasyonunu yapmam gerekiyor. Default olarak 15 dakika ayarlanmış onun düzenlenmesini yapalım. Bu işlem primary sunucusunda backup alıncak job’ın ne kadar sürede bir çalışacağını belirleyen yapı.
Gelen ekranda kaç dakikada bir Log Backup almak istiyorsak onu seçeriz. 30 sn’de bir transaction log backup alacak şekilde ayarlamaları yaparız.
Backuplarımı alacağım bir paylaşım klasörü oluşturmam gerekiyor. Çünkü primary sunucuda oluşturacağımız klasöre yukarıda tanımladığımız job’ımız backup alacak ikinci sunucuda bu klasörden kendi üzerindeki klasöre kopyalayıp restore job ile restore işlemi tabi tutacak. Makelenin sonunda şunuda görmüş olacağız. Secondary sunucular bu klasörü olduğu gibi kopyalamaktadır. Yani içerisinde bulunan önceki loglar otomatik olarak secondary sunucusunda belirtilen klasöre alınmaktadır.
Bunun için ABC diye bir klasör oluşturuyorum ve buna paylaşım yetkisi veriyorum. Çünkü farklı bir sunucunun bu klasöre ulaşması gerekiyor.
Transaction log backup’larının kaydedileceği ağ paylaşımı yolu. Bu paylaşım hem primary hem secondary sunucular tarafından erişilebilir olmalıdır.
Bu işlemi yaptıktan sonra istenilen yere yapıştırıyorum. Aynı zamanda backuplarımı sıkıştırarak alıyorum. Eğer kendi bulunduğu sunucu üzerinde ikinci bir instance altında log shipping yapılacaksa local bir disk belirlenebilir.
Yukarıdaki ayarlamaları yaptıktan sonra alt kısımda hangi zamandan önceki dosyaları silmemiz gerektiğini söylüyor.
Delete files older than kısmından kaç saat sonra eski backup’ların silineceğini, Alert if no backup occurs within kısmından da backup alınmamışsa kaç saat sonra alert üreteğini ayarlayabilirsiniz.
Yukarıda belirtilen not bölümünde “If you backup the transaction logs of this database with any other job or maintenance plan, Management Studio will not be able to restore the backups on the secondary server instances.”
Bu database’in transaction log’ları BAŞKA BİR YEDEKLEME Job’ı ile alınırsa:
- Log shipping BOZULUR
- Secondary sunucular restore edemez
- Data kaybı riski oluşur
Bu yüzden log backup’ı kapatıyoruz. Başlatmadan başlatmadan önce kapatmamız gerekiyor.
Default değerlerle bırakıp OK deyip primary makinamda işlemlerimi tamamlıyorum.
Yukarıdaki resimde Add ikonuna tıkladıktan sonra aşağıdaki ekran resminde connect ikonuna tıklayıp S3 sunucuma bağlantı işlemlerimi yapıyorum. Benim şuan S3 sunucum log shipping yapacağım sunucu , S1 sunucusu Alwayson yapısındaki primary sunucusu, S3 sunucusu ayarlarını yaptıktan sonra yukarıda resimdeki Add butonuna tıklayıp S4 sunucusu ile de bağlantı yapmış olacağız.
İşaretlemiş olan Yes, generate a full backup of the primary database and restore it into the secondary database (and create the secondary database if it doesn’t exist) seçeneğinde primary veritabanının tam yedeğini alır ve secondary sunucuya geri yükler. Eğer secondary sunucuda ilgili veritabanı yoksa, otomatik olarak oluşturulur. Yeni bir Log Shipping yapılandırması oluştururken bu seçeneği kullanabilirsin. Küçük veritabanları için bu yöntem tercih edilebilir. Büyük veritabanlarında bu yöntem aktif edilirse veritabanı için log job’ı kapatılacağı için full backup alınana kadar log dosyamız şişebilir.
Restore options kısmında ikinci sunuda oluşturulacak veritabanın mdf ve ldf uzantıların hangi uzantıda oluşturacağını seçiyoruz.
Yes, restore an existing backup of the primary database into the secondary database (and create the secondary database if it doesn’t exist) ile başlayan kısmı seçersek primary veritabanının daha önce alınmış bir yedeği varsa, onu kullanarak secondary sunucuda aynı veritabanını oluşturur. Bu işlem için bir ağ yolunda (network path) bulunan bir yedek dosyasını (backup file) belirtmek gerekir. Mevcut bir yedeği manuel olarak yükleyerek Log Shipping başlatmak için kullanılır.
No, the secondary database is initilalize kısmını seçerseniz, Secondary sunucusuna backup manuel bir şekilde restoring modun da restore edilir. Yani primary sunucudan bir backup alınmasına veya restore edilmesine gerek yoktur. Eğer zaten bir secondary database oluşturduysan ve sadece Log Shipping işlemlerini başlatmak istiyorsan bu seçeneği kullanabilirsin. Burada dikkat edilmesi gereken Restore edilecek nodedaki veritabanı önceki log shipping alınmış veritabanı full backup olmalıdır. Farklı log backup olan veritabanları AG altında senkron olmazlar. Çünkü her full backup kendine göre bir lsn yapısı oluşturur kendinden sonraki log backuplar ile zincir oluşturmaktadır.
Hangi Seçeneği Kullanmalısın?
Yeni bir Log Shipping yapılandırması yapıyorsan ve secondary veritabanın yoksa: 1. Seçenek (Yes, generate a full backup…)
Zaten bir backup aldıysan ve manuel restore etmek istiyorsan: 2. Seçenek (Yes, restore an existing backup…)
Secondary veritabanı zaten hazırsa ve sadece Log Shipping’i devam ettirmek istiyorsan: 3. Seçenek (No, the secondary database is initialized)
Burada 2. seçenek ile veritabanımızı restore işlemine tabi tutacağız. Primary sunucusu üzerinden tekrardan bir full backup almamak içindir.
Primary sunucusu üzerinde Full backup alınan klasörü paylaşıma açıp uzantısını gösteriyorum.
Daha sonra Copy Files sekmesine geçilir. İkinci sunucuda kopyalar hangi klasör içerisinde dursun oluşturduğumuz 3. sunucusundaki klasörü yazıyoruz. Bu klasörün paylaşım klasörü olmasına gerek yok. Destination folder for… ile başlayan kısma secondary sunucudaki lokal bir path’i yazmalısınız. Secondary sunucusunda oluşturulan klasörde sql server servis hesaplarının yetkisi olması gerekmektedir. Log shipping başlangıcında belirtilen full ve log backupların olduğu klasörü olduğu gibi aşağıdaki belirtilen C:\Backup klasörüne kopyalamaktadır.
Delete copied files after yazan kısım kopyalanan backup’ın 72 saat sonra silineceğini gösterir.
Bu işlemleri yaptıktan sonra alt tarafta bulunan Copy Job kısmında kopyalama işlemlerinin ne kadar süreyle olacağını belirtiyoruz. Kısacası aşağıdaki copy job ile paylaşım klasöründen tüm dosyaları alır. Belirtmiş olduğumuz disk uzantısına kaydetmektedir.
Bu ayarlamaları yaptıktan sonra Restore Transaction Log bölümüne geçilir.
S3 sunucusu için işlemleri yaptıktan sonra S4 sunucusu için restore işlemlerini yapalım. S3 sunucumuz başarılı bir şekilde çalışmış oldu.
S3 sunucusunda data ve log dosyalarının belirlenen dizin altında oluştuğu görülmektedir.
S3 sunucusunda belirtilen dizin altında kopyalama işleminin gerçekleştiği görülmektedir.
4. sunucumuzu kurmuş olduğumuz log shipping yapısına dahil edelim. Burada dikkat edilmesi gereken en önemli konu farklı sunucuya eklenecek veritabanının full backup’ı aynı olmak zorunludur. Yoksa S3 ve S4 sunucuları aynı AG altında olmazlar. Çünkü her Full backup kendi lsn değerini oluşturmaktadır.
Aşağıdaki resimde add denilip S4 sunucusuna connect oluyoruz.
İlk seçenek seçilirse yeni bir backup alınır S3 ve S4 sunucuları arasında AG yapısı kurulamaz çünkü farklı backup setleri ben 3 seçenek üzerinden işlem yapmak istedim bu manuel bir şekilde Önceden alınmış olan log shipping backup’ını alıp S4 sunucusuna restore işlemine tabi tutulması gerekmektedir. Aşağıdaki resimde connection’a bağlanmadıktan önce yapılması gerekmektedir.
Aşağıdaki resimlerde dikkat edilirse S1 sunucusu üzerinde log shipping yapısı çok önceden başlatılmıştı. S4 sunucusu log shipping’e dahil edildiğinde diğer log backuplar hemen S4 sunucusunda belirtilen klasöre gelmiş oldu.
Tekrar belirtmek gerekirse aynı full backupların restore edilmesi gerekmektedir.
S1 sunucusunda son kullanıcıların gelmemesi için bağlantı kesilir. Bu sayede S3 ve S4 sunucusunda son değerleri alıp kendi AG yapılarını eklemiş olacağız. Yeni kullanıcılar yeni connection string ile yeni ortama gelmiş olacak. Always on yapısında iki sunucu için son kullanıcıların gelmeyeceği şekilde bağlantı kestikten sonra S3 ve S4 sunucuları için işlemlerime koyuluyorum.
Primary olan S1 sunucusundaki veritabanı kayıtları:
Alwayson yapısındaki S2 sunucusundaki veritabanı kayıtları:
S3 sunucusundaki veritabanı kendi sunucu üzerinde oluşturulan AG yapısına katılması için Restoring modundan çıkarılması gerekmektedir. Restoring modundan çıkarıldıktan sonra veri kayıtlarını baktığımızda S1 ve S2 sunucularıyla aynı olduğu görülmektedir.
Restore database TEST with Recovery
S3 ve S4 sunucularında herhangi bir sıkıntı olmaması için log shipping yapısı kapatıldı. Farklı log backuplar restore edilip lsn değerleri uyuşmaya bilir.
S3 sunucusunda Veritabanı AG_S3_S4 availability group altında join only yöntemi ile eklenmektedir.
Auto seeding yapısı aktif olduğu için S4 sunucusunda veritabanı hemen senkron olmaktadır.
S3 ve S4 sunucularında bulunan Failover cluster yapısı incelendiğinde AG yapımızın eklendiği görülmektedir.
Son kullanıcı artık yeni listener ile S3 ve S4 sunucularına gelmektedir. Bu makalede gerçek sistem üzerinde bulunan senaryo benzeri bir işlem en kısa kesinti ve Normal backup restore yöntemiyle bir nebze olsa farklı bir yol görmüş olduk. Başka makalede görüşmek dileğiyle..
“Gurura kapılarak insanlara burun kıvırma, ortalıkta çalım satarak yürüme; unutma ki Allah gurura kapılıp kendini beğenen hiç kimseyi sevmez.”Lokman-18
