Site icon Baki CUBUK

Microsoft SQL Server 2019 Always ON Otomatik Failover

Merhaba

Daha önceki yazılarımız da Microsoft SQL Server yazılarımız sizlerle paylaşmıştık.

Microsoft SQL Server 2016

Microsoft SQL Server 2016 Failover Cluster Kurulumu

Microsoft SQL Server 2017

Microsoft SQL Server 2017 Failover Cluster Kurulumu

Microsoft SQL Server 2017 Always ON Kurulumu

Microsoft SQL Server 2017 Always ON Yapısına Database Eklemek

Microsoft SQL Server 2017 Always ON Yapısına Sunucu Eklemek

Microsoft SQL Server 2017 Always ON Full Recovery Mode is Required

Microsoft SQL Server 2017 Always ON Manuel Failover

Microsoft SQL Server 2017 Always ON Otomatik Failover

Microsoft SQL Server 2017 Always ON Upgrade Microsoft SQL Server 2019

Microsoft SQL Server 2017 Always ON Listener Yapılandırması

Microsoft SQL Server 2017 Always ON Listener Name Değiştirme

Microsoft SQL Server 2019

Microsoft SQL Server 2019 Kurulumu

Microsoft SQL Server Management Studio 18.4 Kurulumu

Microsoft SQL Server 2019 Failover Cluster Kurulumu

Microsoft SQL Server 2019 Failover Cluster Yapısına Sunucu Eklemek

Microsoft SQL Server 2019 Failover Cluster Yapısına Database Oluşturmak

Microsoft SQL Server 2019 Failover Cluster Yapısına Database Eklemek

Microsoft SQL Server 2019 Always ON Kurulumu

Microsoft SQL Server 2019 Always ON Yapısına Sunucu Eklemek

Microsoft SQL Server 2019 Always ON Yapısına Database Eklemek 

Microsoft SQL Server 2019 Always ON Full Recovery Mode is Required

Microsoft SQL Server 2019 Always ON Manuel Failover

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.

Daha önceki Microsoft SQL Server 2019 Always ON Kurulumu sizlerle paylaşmıştık. Bu yazımız da Microsoft SQL Server 2019 Always ON yapısı üzerinde Failover işlemini Automatic  ( Otomatik ) olarak nasıl çalıştığını anlatıyor olacağız.

Microsoft SQL Server Management Studio konsolu üzerinde BAKICUBUKSQLAO isimli Availability Group yapısı üzerine Connect diyerek bağlanıyoruz.

Always On High Availability Group altında bulunan yapısı Availability Groups sekmesi altında bulunan BAKICUBUKSQLAO üzerinde sağ tuş Properties diyoruz.

Availability Group Properties – BAKICUBUKSQLAO isimli Availability Group yapısının yapılandırılmış ayarlarını görüyoruz.

Availability Replicas bölümünde

Server Instance sekmesinde SQL Server Always ON yapısı içindeki W19SQLNOD1 ve W19NOD2 isimli sunucularımızı görüyoruz.

Role sekmesinde SQL Server Always ON yapısı içindeki W19SQLNOD1 isimli sunucumuz Primary olarak yani birinci sunucu olarak görünmektedir. W19SQLNOD2 isimli sunucumuz Secondary olarak yani ikinci sunucu olarak görünmektedir.

Availability Mode sekmesinde Asynchronous commit ve Synchronous commit olarak yapılandırabilirsiniz.

Failover sekmesinde Automatic  ( Otomatik ) ve Manual ( Manuel )  olarak olarak yapılandırabilirsiniz.

Availability Group Properties – BAKICUBUKSQLAO isimli Availability Group yapısının yapılandırılmış ayarlarımızda Availability Mode sekmesini Synchronous commit olarak yapılandırıyoruz. Failover sekmesini Automatic  ( Otomatik ) olarak olarak yapılandırıyoruz ve OK diyoruz.

Always On High Availability Group altında bulunan yapısı Availability Groups altında bulunan BAKICUBUKSQLAO isimli yapılandırmış olduğumuz SQL Server Always ON Listener ismi altında bulunan Availability Replicas sekmesinde SQL Server Always ON yapısı içindeki W19SQLNOD1 isimli sunucumuz Primary olarak yani birinci sunucu olarak görünmektedir. W19SQLNOD2 isimli sunucumuz Secondary olarak yani ikinci sunucu olarak görünmektedir.

W19SQLNOD1 isimli sunucumuz kapatıyoruz.

Always On High Availability Group altında bulunan yapısı Availability Groups altında bulunan BAKICUBUKSQLAO isimli yapılandırmış olduğumuz SQL Server Always ON Listener ismi altında bulunan Availability Replicas sekmesinde SQL Server Always ON yapısı içindeki W19SQLNOD2 isimli sunucumuz Primary olarak yani birinci sunucu olarak görünmektedir. W19SQLNOD1 isimli sunucumuzunda ulaşılmadığını görüyoruz.

W19SQLNOD1 isimli sunucumuz açıyoruz.

Always On High Availability Group altında bulunan yapısı Availability Groups altında bulunan BAKICUBUKSQLAO isimli yapılandırmış olduğumuz SQL Server Always ON Listener ismi altında bulunan Availability Replicas sekmesinde SQL Server Always ON yapısı içindeki W19SQLNOD2 isimli sunucumuz Primary olarak yani birinci sunucu olarak görünmektedir. W19SQLNOD1 isimli sunucumuz Secondary olarak yani ikinci sunucu olarak görünmektedir.

W19SQLNOD2 isimli sunucumuz kapatıyoruz.

Always On High Availability Group altında bulunan yapısı Availability Groups altında bulunan BAKICUBUKSQLAO isimli yapılandırmış olduğumuz SQL Server Always ON Listener ismi altında bulunan Availability Replicas sekmesinde SQL Server Always ON yapısı içindeki W19SQLNOD1 isimli sunucumuz Primary olarak yani birinci sunucu olarak görünmektedir. W19SQLNOD2 isimli sunucumuzunda ulaşılmadığını görüyoruz.

W19SQLNOD2 isimli sunucumuz açıyoruz.

Always On High Availability Group altında bulunan yapısı Availability Groups altında bulunan BAKICUBUKSQLAO isimli yapılandırmış olduğumuz SQL Server Always ON Listener ismi altında bulunan Availability Replicas sekmesinde SQL Server Always ON yapısı içindeki W19SQLNOD1 isimli sunucumuz Primary olarak yani birinci sunucu olarak görünmektedir. W19SQLNOD2 isimli sunucumuz Secondary olarak yani ikinci sunucu olarak görünmektedir.

 

Başka bir yazımızda görüşmek dileğiyle…

 

 

Exit mobile version