Merhaba
Daha önceki yazılarımız da Windows Server 2019 Üzerinde SQL Server 2017 Always ON Kurulumu, Windows Server 2019 Üzerinde SQL Server 2017 Always ON Yapısına Database Eklemek ve Microsoft SQL Server 2017 Always ON Yapısına Sunucu Eklemek sizlerle paylaşmıştık.
Bu yazımızda da Microsoft SQL Server 2017 Always ON yapısınına Database ( Veritabanı ) Restore ( Geri Yükleme ) etmeyi ve sonrasında Microsoft SQL Server 2017 Always ON yapısınına eklemeyi anlatacağız.
Peki Nedir SQL Server Always ON :
Microsoft SQL Server Always On yapısı High Availability ( Yüksek Erişebilirlik ) ve Disaster Recovery ( Felaket Kurtarma ) çözümüdür.
High Availability ( Yüksek Erişebilirlik ) şirket ortamlarınızda bulunan Datacenter ( Veri Merkezi ) üzerinde birden fazla sunucu ile yapılır. Sunuculardan birinin Donanımsal ya da Yazılımsal bir sorun nedeniyle arızalanması durumunda diğer sunucunuzun devreye girmesini sağlayan teknolojidir.
Disaster Recovery ( Felaket Kurtarma ) şirket ortamlarınızda bulunan Datacenter ( Veri Merkezi ) üzerinde oluşabilecek herhangi beklenmedik bir felaket sonucu ( Deprem, Sel, Yangın ) Datacenter ( Veri Merkezi ) tamamen hizmet veremez duruma gelme ihtimaline karşı farklı bir uzak lokasyonda Datacenter ( Veri Merkezi ) kurularak sağlanır. Örneğin Datacenter ( Veri Merkezi ) Istanbul’da ise Disaster Recovery ( Felaket Kurtarma ) olarak İstanbul’da farklı bir lokasyonu ya da Ankara,İzmir gibi uzak ve daha az riskli bir lokasyonu Disaster Recovery ( Felaket Kurtarma ) için tercih edebilirsiniz. Microsoft Azure Cloud ve Amazon Cloud gibi Cloud ( Bulut ) hizmetlerinde Disaster Recovery ( Felaket Kurtarma ) Datacenter ( Veri Merkezi ) olarak yapılandırabilirsiniz.
Microsoft SQL Server Always On yapısı kurulum ve yapılandırması için ortamınızda Windows Server Failover Cluster yapısı içinde en az iki sunucuya ihtiyac duymakdır.
Availability Group yapısını Synchronous ( Senkron ) olarak yapılandırırsanız Availability Group yapısı içindeki tüm Database ( Veritabanı ) Synchronous ( Senkron ) bir şekilde çalışacaktır. Yani ortamdaki Primary Database ( Veritabanı ) gelen bir istek Secondary Database ( Veritabanı ) işlenmeden kullanıcıya işlem tamamlandı bilgisi iletilmeyecektir. Bu çok yoğun Transaction ( İşlem ) alan Database ( Veritabanı ) biraz performans kaybına neden olabilir. Ama Automatic ( Otomatik ) Failover Synchronous ( Senkron ) Availability Group yapısı yapılabildiği için herhangi bir sorun yaşamazsınız. Sunucularda herhangi bir Donanımsal ya da Yazılımsal bir sorun olması durumunda herhangi bir kesinti yaşanmadan Availability Group yapısı diğer sunucudan Automatic ( Otomatik ) bir şekilde hizmet vermeye devam edecektir.
Availability Group yapısını Asynchronous ( Asenkron ) olarak yapılandırısanız eğer. Primary Database ( Veritabanı ) veritabanına gelen bir istek Secondary Database ( Veritabanı ) işlenmeyi beklemeden direk kullanıcıya işlem tamamlandı bilgisi iletilecektir ve arka tarafta Synchronous ( Senkron ) yapılacaktır. Asynchronous ( Asenkron ) olarak yapılandırılan Availability Group yapısında Secondary Database ( Veritabanı ) yazma işlemi için belli bir süresi yoktur. Buradaki yazma işlemi ortamınızda mevcut Donanım ve Network yapınızın Performansına bağlı olarak değişkenlik gösterebilir.
Availability Group yapısını Automatic ( Otomatik ) ya da Manual ( Manuel ) olarak Failover yapabilirsiniz. Automatic ( Otomatik ) Failover yapabilmek için Availability Group yapısını Synchronous ( Senkron ) olarak yapılandırmanız gerekmektedir. Çok yoğun Transaction ( İşlem ) içeren sistemlerde Availability Group yapısını Synchronous ( Senkron ) ve Automatic ( Otomatik ) olarak yapılandırabiliriz. Index Rebuild ( Dizin Yeniden Oluşturma ) işlemlerinde Performans kaybı daha fazla olduğu için sıkıntı yaşayan yapılarda Index Rebuild ( Dizin Yeniden Oluşturma ) öncesinde Availability Group yapısını Asynchronous ( Asenkron ) olarak yapılandırabilirsiniz.
Automatic ( Otomatik ) Failover işlemi Availability Group yapısını dahil bir Database ( Veritabanı ) oluşan bir hata sonucu gerçekleşmez. Availability Replica seviyesinde gerçekleşir. Availability Group yapısında Database ( Veritabanı ) biri Corrupt ( Bozulma ) olması Transaction Log ( İşlem Logu ) dolmuş, Database ( Veritabanı ) bulunduğu Data dizini dolmuş gibi sebeplerde Automatic ( Otomatik ) Failover işlemi gerçekleşmez.
High Availability ( Yüksek Erişebilirlik ) ve Disaster Recovery ( Felaket Kurtarma ) SQL ServerAlways ON’da nasıl kullanıldığını için örnek vermemiz gerekirse.
Datacenter ( Veri Merkezi ) iki Adet sunucumuz var. Bu iki sunucumuzu Windows Server Failover olarak yapılandırdınız. Bu iki sunucumuz üzerinde SQL Server Always ON yapılandırdınız ve Synchronous ( Senkron ) olarak yapılandırdınız. Bu yapılandırmaya High Availability ( Yüksek Erişebilirlik ) yapılandırması deriz.
Datacenter ( Veri Merkezi ) iki Adet sunucumuz var. Bu iki sunucumuzu Windows Server Failover olarak yapılandırdınız Datacenter ( Veri Merkezi ) bir sıkıntı olma ihtimaline karşı başka bir lokasyonda Datacenter ( Veri Merkezi ) üzerinde bir sunucuz var. Bu sunucuyuda mevcut Windows Server Failover yapınıza dahil ettiniz ve mevcut SQL Server Always ON yapınıza Replica ( Kopya ) olarak yapılandırdınız ve Asynchronous ( Asenkron ) olarak yapılandırdınız. Bu yapılandırmaya Disaster Recovery ( Felaket Kurtarma ) yapılandırması deriz. SQL Server Always ON yapısında aynı Availability Group yapısı içinde birden fazla Secondary yapılandırması yapabilirsiniz.
W19SQL17NOD1 isimli sunucumuz üzerinde sağ tuş Restore Database… diyerek daha önce Backup ( Yedek ) aldığımız bir Database ( Veritabanı ) dosyasını Microsoft SQL Server sunucumuz üzerine Restore ( Geri Yükleme ) ediyoruz.
Restore Database ekranı geliyor karşımıza.
Restore Database ekranın da Device bölümünde Restore ( Geri Yükleme ) edeceğimiz Database ( Veritabanı ) seçeceğiz.
Select backup devices ekranın da Add diyoruz.
Locate Database File – W19SQL17NOD1 ekranın da NIHATCUBUK.bak isimli BAK uzantılı Backup Database ( Veritabanı ) seçerek OK diyoruz.
Select backup devices ekranın da OK diyoruz.
Restore Database ekranın da Database bölümüne NIHATCUBUK isimli Database ( Veritabanı ) geldiğini görüyoruz. Restore plan bölümü altında bulunan Backup sets to restore bölümünde NIHATCUBUK isimli Database ( Veritabanı ) bilgilerini görüyoruz.
Restore Database ekranın da Files menüsüne tıklıyoruz. NIHATCUBUK isimli Database ( Veritabanı ) hangi dizin altına Restore ( Geri Yükleme ) edileceğini yapılandıracağız.
Restore Database ekranın da Files menüsüne geldiğimiz Original File Name bölümünde NIHATCUBUK isimli Database ( Veritabanı ) hangi dizin altına Restore ( Geri Yükleme ) yapacağını görüyoruz. SQL Server Always ON yapısı üzerinde Restore ( Geri Yükleme ) işlemi gerçekleştireceğimiz için bu dizini değiştirmemiz gerekiyor.
Restore Database ekranın da Files menüsünde Relocate all file to folder seçeneğini seçerek NIHATCUBUK isimli Database ( Veritabanı ) SQL Server Always ON yapısı üzerinde Data file folder bölümünde hangi dizinde tutulacağını, Log file folder bölümünde hangi dizinde tutulacağını yapılandırıyoruz. Restore Database ekranın da Files menüsünde gerekli yapılandırmayı tamamladıktan sonra OK diyoruz.
Restore Database ekranın da NIHATCUBUK isimli Database ( Veritabanı ) başarılı bir şekilde Restore ( Geri Yükleme ) işleminin başarılı bir şekilde tamamlandığını görüyoruz.
NIHATCUBUK isimli Database ( Veritabanı ) Restore ( Geri Yükleme ) edildiğini görüyoruz.
Microsoft SQL Server Management Studio ( SSMS ) konsolunu üzerinde Always On High Availability altında bulunan Availability Groups altında bulunan BAKICUBUKSQLAO ismi ile yapılandırmış olduğumuz Availability Group yapılandırmasında Availability Database sekmesi altında BAKICUBUK ve MUGECUBUK isimli Database ( Veritabanı ) görüyoruz.
NIHATCUBUK isimli Database ( Veritabanı ) SQL Server Always ON yapısına dahil etmek için Availability Database sekmesinde sağ tuş Add Database diyoruz.
Introduction ekranın da Always On High Availability yapısı için gerekli yapılandırma için bilgileri görüyoruz. Next diyerek devam ediyoruz.
Select Databases ekranın da Availability Group dahil edeceğimiz Database ( Veritabanı ) seçmemiz gerekiyor. Daha önce Availability Group yapısına dahil ettiğimiz BAKICUBUK ve MUGECUBUK isimli Database ( Veritabanı ) Status bölümünde Already part of this availability group olarak görüyoruz. Availability Group yapısına dahil edeceğimiz NIHATCUBUK isimli Database ( Veritabanı ) Status bölümünde Meets prerequisities olarak görünüyor. Eğer Database ( Veritabanı ) üzerinde Full Backup almazsanız Status bölümü Full backup is required olarak görünecektir ve Database ( Veritabanı ) üzerinde Full Backup almadığınız için Availability Group yapısına ekleyemezsiniz.
Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUK isimli Database ( Veritabanı ) Status bölümünde Meets prerequisities olarak görüyoruz. NIHATCUBUK isimli Database ( Veritabanı ) seçiyoruz ve Next diyerek devam ediyoruz.
Connect to Existing Secondary Replicas ekranın da W19SQL17NOD2 ve W19SQL17NOD3 isimli sunucularımızı Secondary olarak yapılandıracağımız için bu sunucularımız üzerine bağlanmamız gerekiyor.
Connect to Existing Secondary Replicas ekranın da W19SQL17NOD2 isimli sunucumuzu Secondary olarak yapılandıracağımız için Connect diyoruz.
Connect to Server ekranın da Server name bölümüne W19SQL17NOD2 olarak geliyor ve Connect diyoruz.
Connect to Existing Secondary Replicas ekranın da W19SQL17NOD3 isimli sunucumuzu Secondary olarak yapılandıracağımız için Connect diyoruz.
Connect to Server ekranın da Server name bölümüne W19SQL17NOD3 olarak geliyor ve Connect diyoruz.
Connect to Existing Secondary Replicas ekranın da W19SQL17NOD2 ve W19SQL17NOD3 isimli sunucularımızı Secondary olarak yapılandırdıktan sonra Next diyoruz.
Select Initial Data Synchronization ekranın da Secondary sunucusu üzerine Database ( Veritabanı ) senkronizasyonun ilk yapılandırmasını nasıl yapacağımızı seçtiğimiz ekrandır.
Automatic seeding : Bu seçenek ile devam edersek eğer Secondary sunucusu üzerine Database ( Veritabanı ) senkronizasyonu için gerekli olan bütün işlemler Automatic ( Otomatik ) olarak gerçekleştirilecektir.
Full database and log backup : Bu seçenek ile devam edersek eğer her Database ( Veritabanı ) Full Backup ve Log Backup dosyalarını yapılandırmış olduğumuz Share ( Paylaşım ) üzerinden alarak Secondary sunucumuz üzerine kendisi aktarır ve bu işlem için sunucularımız üzerindeki Instance’ın SQL Server Servis hesaplarının Write ( Yazma ) ve Read ( Okuma ) yetkisi olan bir Share ( Paylaşım ) istemektedir. Yapılandırdığınız Share ( Paylaşım ) diskinde bulunan Database ( Veritabanı ) Full Backup ve Log Backup sığacağı kadar yer olmalıdır.
Join only : Bu seçenek ile seçtiğimiz her Database ( Veritabanı ) Full Backup ve Log Backup Manuel ( Manuel ) olarak alıp Manuel ( Manuel ) olarak Secondary sunucusuna bu adımı geçmeden önce kopyalamamız gerekir.
Skip initial data synchronization : Bu seçenek ile yine her Database ( Veritabanı ) Full Backup ve Log Backup Manual ( Manuel ) olarak alıp Manual ( Manuel ) olarak Secondary sunucumuz üzerine kopyalamamız gerekir. Ancak Join only seçeneğinden farklı olarak bu işlemi sonra yapabiliriz.
Select Initial Data Synchronization ekranın da Secondary sunucusu üzerine senkronizasyonun Full database and log backup seçeneğini seçiyoruz.
Select Initial Data Synchronization ekranın da Secondary sunucusu üzerine senkronizasyonun Full database and log backup seçtikten sonra Specify the file share patch in Windows format bölümünde W19SQL17NOD1 isimli sunucumuz üzerinde Share ( Paylaşım ) dizinin gösteriyoruz ve Next diyerek devam ediyoruz.
Validation ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için gerekli kontroller yapılıyor. NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için bütün adımları Success olarak görüyoruz. Eğer bir sorun varsa Error olarak görürdük ve Back diyerek geri gidebilirsiniz ve yanlış yaptığınız bir yapılandırma varsa yapılandırmayı düzelttikten sonra Re-run validation diyebilirsiniz.
Validation ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için herhangi bir sorun olmadığı için Next diyerek devam ediyoruz.
Summary ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için gerekli olan yapılandırmanın bir özetini görüyoruz. Finish diyerek NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için işlemi başlatıyoruz. Script bölümünde Database ( Veritabanı ) Availability Group yapısına dahil etmek için yapılandırmış olduğunuz yapılandırmayı Script ( Senaryo ) olarak alabilirsiniz.
Results ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına başarılı bir dahil edildiğini görüyoruz. Close diyerek Add Database to Availability Group Wizard ekranını kapatıyoruz.
Microsoft SQL Server Management Studio ( SSMS ) konsolunu üzerinde Always On High Availability altında bulunan Availability Groups altında bulunan BAKICUBUKSQLAO ismi ile yapılandırmış olduğumuz Availability Group yapılandırmasında Availability Database sekmesi altında NIHATCUBUK isimli Database ( Veritabanı ) görüyoruz.
Microsoft SQL Server Management Studio ( SSMS ) konsolunu W19SQL17NOD2 isimli sunucumuz üzerinde Always On High Availability altında bulunan Availability Groups altında bulunan BAKICUBUKSQLAO ismi ile yapılandırmış olduğumuz Availability Group yapılandırmasında Availability Database sekmesi altında NIHATCUBUK isimli Database ( Veritabanı ) geldiğini ve Synchronized olarak görüyoruz.
Microsoft SQL Server Management Studio ( SSMS ) konsolunu W19SQL17NOD2 isimli sunucumuz üzerinde Always On High Availability altında bulunan Availability Groups altında bulunan BAKICUBUKSQLAO ismi ile yapılandırmış olduğumuz Availability Group yapılandırmasında Availability Database sekmesi altında NIHATCUBUK isimli Database ( Veritabanı ) geldiğini ve Synchronized olarak görüyoruz.
Başka bir yazımızda görüşmek dileğiyle…
