Microsoft SQL Server 2022 Always ON Kurulumu 4

bakicubuk

2 yıl önce

Merhaba

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 yazımız da

Microsoft SQL Server 2022 Always ON Kurulumu 1

W22SQL22NOD1 ve W22SQL22NOD2 isimli sunucularımız üzerinde Windows Failover Cluster kurulumu ve yapılandırmasını sizlere paylaşmıştık.

Daha sonraki yazımız da

Microsoft SQL Server 2022 Always ON Kurulumu 2

W22SQL22NOD1 ve W22SQL22NOD2 isimli sunucularımız üzerinde Microsoft SQL Server 2022 kurulumlarını tamamlayarak sizlere paylaşmıştık.

Daha sonraki yazımız da

Microsoft SQL Server 2022 Always ON Kurulumu 3

W22SQL22NOD1 ve W22SQL22NOD2 isimli sunucularımız üzerinde Microsoft SQL Server 2022 Always ON kurulumu ve yapılandırması için Microsoft SQL Server 2022 servislerindeki gerekli yapılandırmayı tamamlayarak sizlere paylaşmıştık.

Bu yazımız da Microsoft SQL Server 2022 SQL Always ON yapılandırmasını anlatıyor olacağız.

W22SQL22NOD1 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio ( SSMS ) konsolunu açıyoruz.

Connect to Server ekranın da Server name bölümüne W22SQL22NOD1 isimli sunucumuzun ismini yazıyoruz.

W22SQL22NOD1 isimli sunucumuz üzerine Microsoft SQL Server 2022 Always ON kurulumu ve yapılandırması için Authentication bölümünü Windows Authentication seçiyoruz ve Connect diyoruz.

W22SQL22NOD1 isimli sunucumuz üzerinde Always ON High Availability sekmesine tıkladığımız da yani Microsoft SQL Server 2022 Always ON yapılandırmasını kontrol ettiğimizde herhangi bir hata almadığımızı görüyoruz.

W22SQL22NOD2 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio ( SSMS ) konsolunu açıyoruz.

Connect to Server ekranın da Server name bölümüne W22SQL22NOD2 isimli sunucumuzun ismini yazıyoruz.

W22SQL22NOD2 isimli sunucumuz üzerine Microsoft SQL Server 2022 Always ON kurulumu ve yapılandırması için Authentication bölümünü Windows Authentication seçiyoruz ve Connect diyoruz.

W22SQL22NOD2 isimli sunucumuz üzerinde Always ON High Availability sekmesine tıkladığımız da yani Microsoft SQL Server 2022 Always ON yapılandırmasını kontrol ettiğimizde herhangi bir hata almadığımızı görüyoruz.

Microsoft SQL Server 2022 Always ON yapılandırması öncesinde W22SQL22NOD1 isimli sunucumuz üzerinde Database ( Veritabanı ) oluşturuyoruz. Çünkü yapıda bir Database ( Veritabanı ) olmadan Microsoft SQL Server 2022 Always ON yapılandırmasına devam edemiyoruz.

W22SQL22NOD1 isimli sunucumuz da Microsoft SQL Server Management Studio ( SSMS ) konsolun da Databases seçeneği üzerinde sağ tuş New Database diyerek yeni bir Database ( Veritabanı ) oluşturuyoruz.

New Database ekranın da General sekmesin de Database name bölümün de oluşturacağımız Database ( Veritabanı ) için bir Name ( İsim ) belirlememiz gerekiyor.

New Database ekranın da General sekmesin de Database name bölümün de BAKICUBUKDB isimli bir Database ( Veritabanı ) oluşturacağız.

New Database ekranın da General sekmesin de Database files bölümün de oluşturacağımız Database ( Veritabanı ) için yapılandırma bilgisini görüyoruz.

New Database ekranın da General sekmesin de Database files bölümün de Patch sekmesin de BAKICUBUKDB isimli Database ( Veritabanı ) Microsoft SQL Server 2022 kurulumu sırasında yapılandırmış olduğumuz dizin üzerinde oluşturulacağını görüyoruz.

Microsoft SQL Server 2022 Failover Cluster yapısında Data, Log, Temp ve Backup dizinleri Cluster Volume Disklerimiz üzerinde tutulurken.

Microsoft SQL Server 2022 Failover Cluster yapısında farklı olarak Microsoft SQL Server 2022 Server Always ON yapısında Data, Log, Temp ve Backup dizinleri sunucularımız üzerindeki disklerimizde tutulacaktır.

New Database ekranın da Options sekmesin de oluşturacağımız BAKICUBUKDB isimli Database ( Veritabanı ) için gerekli yapılandırma seçeneklerini görüyoruz.

New Database ekranın da Options sekmesin de Recovery model bölümünün Full olması gerekmektedir. SQL Server 2022 Always ON yapısı için bu şekilde yapılandırması gerekmektedir.

Recovery model bölümün de Full, Simple ve Bulk-Logged olarak 3 farklı seçenek bulunmaktadır.

Simple : Simple Recovery modeldeki veritabanlarında tutulan transaction loglar Checkpoint işleminden sonra silinirler. Bu nedenle Simple Recovery modelde transaction logların sürekli büyümesi söz konusu değildir. Fakat burada bir çok kişi tarafından yanlış anlaşılan bir noktaya değinmek istiyorum. Simple Recovery model de dahil olmak üzere tüm recovery modellerde transaction loglar tutulur. Fakat diğerlerinden farklı olarak Simple Recovery modelde transaction loglar checkpoint işleminden sonra otomatik olarak silinirler.

Simple Recovery modelde log yönetimi kolay olmasına rağmen Simple Recovery modelin dezavantajı ise geriye dönük transaction loglar silindiği için transaction logların yedeklenmesi ve dolayısıyla restore işlemleri mümkün değildir. Bu nedenle veri kaybı olaslığı çok büyüktür. Çünkü herhangibir felaket durumunda en iyi ihtimalle bir önceki aldığımız Full veya Differential backup tarihine kadar veritabanımızı restore edebiliriz. Bu nedenle Simple Recovery model Production ortamlarında tercih edilmemelidir.

Full Recovery Model : Full Recovery Modeldeki bir veritabanında yapılan tüm işlemler transaction log dosyasına kaydedilir ve manuel olarak müdahale etmedikce silinmez. Bu nedenle Full Recovery Modeldeki bir veritabanı için belli bir zaman veya işlem öncesine veritabanımızı restore etmek mümkündür. Full Recovery Modelde her işlem transaction loglara yazıldığı için en güvenilir Recovery modeldir. Fakat Full Recovery Modelde transaction logların yönetimi manuel yapıldığını söylemiştik. Bu nedenle belli aralıklar transaction loglar silinmelidir. SQL Serverda transaction logların silinmesi için iki farklı yöntem izleyebiliriz. Birinci yöntem olarak transaction log backup alabiliriz. İkinci yöntem ise veritabanımızın transaction loglarının Shrink edilmesidir.

SQL Server 2005 sonrası sürümlerinde Transaction logların shrink edilmesi için veritabanımızın Recovery modelini önce Simple olarak set edip daha sonra Shrink işlemini bitirdikten sonra Recovery modelimizi tekrar Full olarak set etmeliyiz.

Full Recovery Modelde insert,delete ve update gibi DML işlemlerinin yanında index oluşturma gibi Maintenance işlemleri, bcp veya bulk insert işlemleri de loglandığı için bu tür işlemlerden sonra transaction loglar hem aşırı büyümekte hem de bu işlemler transaction loga yazıldığı için işlemleri de az da olsa yavaşlatmaktadır. Bu nedenle bu tür toplu işlemlerin transaction loga yansıtılmaması için üçüncü recovery mkodelimiz olan Bulk Logged Recovery Modeli kullanmalıyız.

Bulk Logged Recovery Model : Bulk Logged Recovery Modelde Full Recovery modelden farklı olarak bulk işlmeler dışında tüm işlemler loglanırken herhangibir bulk işlem yapıldığında tüm işlem için tek bir kayıt log dosyasına yazılır. Bu gibi durumlarda veritabanımızı herhangibir zamana restore etmek mümkün olmaz. Bulk Logged Recovery Modelde bulk işlemler tek tek transaction log dosyasına yazılmadığı için Full Recovery modele göre bulk işlemler daha hızlı yapılır.

Bulk Logged Recovery Modelde bulk işlem içeren bir zamana veritabanımızı restore etmemiz mümkün olmadığı için bu model de Production ortamları için pek uygun değildir. Fakat Production ortamlarında herhangibir bulk işlem yapmadan önce veritabanımızın transaction log backupını alıp daha sonra recovery modelini Bulk Logged olarak değiştirip bulk işlemimizi yapmak ve daha sonra veritabanımızın recovery modelini tekrar full olarak set etmek tercih edilebilir. Diğer bir değişle Bulk Logged Recovery Model için kalıcı değil ama gecici olarak tercih edilebilecek bir Recovery modeldir demek yanlış olmaz.

Son olarak Bulk Logged Recovery Modelden bahsederken sürekli bulk işlemler diye genellediğimiz işlemlerden bir kaçını şu şekilde sıralayabiliriz. Index oluşturma, Silme, Rebuild, Select Into, bulk insert, bcp ile yapılan işlemler gibi işlemler bulk işlem olarak adlandırılırlar.

NOT : Options bölümün de yapılandırmalar oluşturulacak olan Database ( Veritabanı ) kullanılacağı yazılım ve uygulamalar ( Logo Tiger, Logo Bordro, Nebim, Mikro gibi ) yapılandırması için farklılık gösterebilir.

New Database ekranın da Options sekmesin de gerekli yapılandırmayı tamamladıktan sonra Filegroups sekmesine geçiyoruz.

New Database ekranın da Filegroups sekmesin de oluşturacağımız BAKICUBUKDB isimli Database ( Veritabanı ) için gerekli yapılandırmayı görüyoruz.

New Database ekranın da oluşturacağımız BAKICUBUKDB isimli Database ( Veritabanı ) için gerekli yapılandırmayı tamamladıktan sonra OK diyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolun da Databases bölümü altında BAKICUBUKDB isimli Database ( Veritabanı ) W22SQL22NOD1 isimli sunucumuz üzerinde oluşturulduğunu görüyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolu üzerinde W19SQL19NOD1 isimli sunucumuz üzerinde oluşturmuş olduğumuz BAKICUBUKDB isimli Database ( Veritabanı ) üzerinde Microsoft SQL Server 2022 Always ON yapılandırması öncesinde Full Backup alıyoruz. Eğer Microsoft SQL Server 2022 Always ON yapılandırması öncesinde Full Backup almazsanız aşağıdaki gibi Full backup is required hata alabilirsiniz.

BAKICUBUKDB isimli Database ( Veritabanı ) üzerinde sağ tuş Tasks menüsünden Back Up… diyoruz.

Back Up Database – BAKICUBUKDB üzerinde Destination bölümün de Microsoft SQL Server 2022 kurulumu sırasında yapılandırmış olduğumuz Disk üzerine Backup alınacaktır.

Back Up Database – BAKICUBUKDB üzerinde gerekli kontrolleri yaptıktan sonra OK diyerek Backup işlemini başlatıyoruz.

BAKICUBUKDB isimli Database ( Veritabanı ) üzerinde Backup işleminin tamamlandı. OK diyerek kapatıyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolunu üzerinde Always On High Availability üzerinde sağ tuş New Availability Group Wizard tıklıyoruz.

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.

Specify Availability Group Options ekranın da Availability Group için Availability Group name bölümüne bir Name ( İsim ) belirlememiz gerekiyor.

Specify Availability Group Options ekranın da Availability Group için Cluster type bölümü altındar Windows Server Failover Cluster, EXTERNAL ve NONE seçeneklerini görüyoruz.

Microsoft SQL Server 2017 ve MicrosoftSQL Server 2019 Linux işletim sistemi üzerinde çalışabilmektedir ve Microsoft SQL Server 2017 ile Windows Failover Cluster’a ihtiyaç duymadan Microsoft SQL Server Always On Availability Groups kurulumu yapılandırabilir oldu.

Microsoft SQL Server Always On klasik kullanım da Windows Server Failover Cluster ( WSFC )’a ihtiyacımız var, Linux üzerinde bu işlemi Pacemaker kullanarak yapabiliriz.

Linux da Microsoft SQL Server AlwaysOn AG iki cluster türü ile kullanabilirsiniz.

External : Pacemaker kullanarak, otomatik failover sağlamak ve devamlığı artırmak için kullanılıyor.
None : Pacemaker ihtiyacı olmadan, sadece Read Scale ve Manuel Failover için kullanılıyor.

Windows üzerinde Windows Server Failover Cluster ( WSFC ); Failover, Health Monitoring ve Resource Management, Host edilen uygulama konfigürasyonu, Node’lardaki değişikliklerin güncellenmesi ve bunların cluster’a yayılması gibi işlevleri var. Baktığınızda Windows için Windows Server Failover Cluster ( WSFC )’ın önemi ve rolü çok büyük.

Specify Availability Group Options ekranın da

Database level health detection : Bu seçenek veritabanlarınız için yüksek kullanılabilirliği garanti etmeye yardımcı olmak için iyi bir seçenek olarak önerilir. Database level health detection, özellikle always on kullanıldığında database seviyesinde bütünlük kontrolü yapmakta.

Sayfa ve ayrıma bozuklukları
Disk bozulmaları
Denetim noktası hataları
Donanım ve bellek bozulmaları
Eksik dosyaların neden olduğu hatalar
FILESTREAM işlem günlüğü kaydı nedeni ile oluşan bozulmalar
Log bozulmaları

Bu gibi durumlar gerçekleştiğinde Failover diğer Microsoft SQL Server Always ON sunucusu üzerine gerçekleştirilir. Microsoft SQL Server 2016 öncesin de sadece sunucu tarafında bir olay yaşanması durumunda Otomatik Failover yapmaktaydı. Şimdi ise Database ( Veritabanı ) seviyesinde de oluşan hatalar ve bozulmalar sonucunda da Otomatik Failover gerçekleşiyor. Bunun için tabiki Database level health detection seçeneğinin seçili olması gereklidir.

Per Database DTC Support : Bu seçenek Microsoft SQL Server Always ON yapısında, dağıtık yapıda sunucular var ve yük devirleri kendi aralarında yapılıyor ise bu Failover işlemlerini takip eden ve tutarlılık kontrolü yapan bir sevise ihtiyac var idi. Microsoft bu işlem için DTC servisini yayınladı. Windows Server 2016 ve Windows Server 2012 R2 serverlerı ile kullanılabilirdi. Microsoft SQL Server versiyonu ise Microsoft SQL Server 2016 dır. Bu servisi devreye almak için Per Database DTC Support işaretlenmesi yeterlidir.

Contained : Contained Databases, diğer veritabanlarından ve veritabanını barındıran Microsoft SQL Server örneğinden yalıtılmış bir veritabanıdır . Microsoft SQL Server, kullanıcının Veritabanını 4 şekilde izole etmesine yardımcı olur.

Bir veritabanını tanımlayan meta verilerin çoğu veritabanında tutulur. ( Ana veritabanında meta verileri korumaya ek olarak veya bunun yerine. )
Tüm meta veriler aynı harmanlama kullanılarak tanımlanır.
Kullanıcı kimlik doğrulaması, veritabanı tarafından gerçekleştirilebilir, bu da Microsoft SQL Server örneğinin oturum açmalarına olan veritabanlarına bağımlılığı azaltır.
Microsoft SQL Server ortamı ( DMV’ler, XEvents, vb. ) raporlama yapar ve kapsama bilgisine göre hareket edebilir.

Teoride güzel görünen veritabanı özelliği Microsoft SQL Server 2022 ile birlikte bir Microsoft SQL Server Always ON mimarisi içerisinde kullanılabilir duruma geliyor.

Microsoft SQL Server Always ON Failover Cluster Instances ( FCI’ler ) dışındaki tüm Microsoft SQL Server kullanılabilirlik özelliklerinin ( Secondary Replica / Warm Standby / Mirror ) bir “sorunu” vardır: Bu sorun ise Failover sonrasında ikincil yeni patron olarak devraldığında, bazı öğeler ki misal Microsoft SQL Server Agent, oturum açma vb. orada gibi işlemlerin birincil sunucuda kalma durumudur. Bu işlem ise her zaman manuel olarak biz veritabanı yöneticilerin takip etmesi gereken bir konu olmuştu ve bu “sorun”, Microsoft SQL Server’ı yönetmekten sorumlu olanlar için uzun süredir devam eden bir acı noktasıydı.Böyle bir durumu ortadan kaldırmak için Microsoft SQL Server 2022 ile gelen Contained Availability Groups , Availability Group mekanizmasının bir parçası olarak kendi master ve msdb veritabanlarını senkronize ederek bu sorunu çözüme kavuşturmuş olmaktadır.

Specify Availability Group Options ekranın da Availability Group yapısı için Availability Group name bölümüne bir Name ( İsim ) belirliyoruz.

Specify Availability Group Options ekranın da Availability Group için Cluster type bölümünü Windows Server Failover Cluster olarak seçiyoruz

Specify Availability Group Options ekranın da gerekli yapılandırmayı tamamladıktan sonra Next diyerek devam ediyoruz.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) seçmemiz gerekiyor.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) Status bölümün de Meets prerequisities olarak görünmesi gerekmektedir.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) Status bölümün de Full recovery mode is required hatası alırsanız. Database ( Veritabanı ) üzerinde Recovery model seçeneğini Full yapmanız gerekmektedir.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) Status bölümün de Full backup is required hatası alırsanız. 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 Database ( Veritabanı ) Status bölümün de Meets prerequisities tıkladığımız da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) uygun olduğu bilgisini görüyoruz.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz BAKICUBUKDB isimli Database ( Veritabanı ) seçiyoruz ve Next diyerek devam ediyoruz.

Specify Replicas ekranın da Replicas sekmesin de Server Instance bölümün de W22SQL22NOD1 isimli sunucumuzu görüyoruz.

Specify Replicas ekranın da Replicas sekmesin de Initial role bölümün de W22SQL22NOD1 isimli sunucumuzu Primary olarak görüyoruz.

Specify Replicas ekranın da W22SQL22NOD2 isimli sunucumuzu Secondary olarak yapılandıracağız.

Specify Replicas ekranın da Replicas sekmesin de Add Replica tıklıyoruz.

Connect to Server ekranın da Server name bölümüne W22SQL22NOD2 olarak seçiyoruz ve Connect diyoruz.

Specify Replicas ekranın da Replicas sekmesin de Server Instance bölümün de W22SQL22NOD1 isimli sunucumuzu Initial role bölümün de Primary olarak görüyoruz.

Specify Replicas ekranın da Replicas sekmesin de Server Instance bölümün de W22SQL22NOD2 isimli sunucumuzu Initial role bölümün de Secondary olarak görüyoruz.

Specify Replicas ekranın da Replicas sekmesin de Automatic Failover (Up to 5) bölümüne işaretliyoruz. Microsoft SQL Server 2022 Always ON Automatic Failover ( Otomatik Yük Devretme ) yapacaktır.

Specify Replicas ekranın da Replicas sekmesin de Availability mode bölümünü Asynchronous commit ve Synchronous commit seçenekleri görünmektedir.

Asynchronous commit : Asynchronous commit seçeneğinde Birincil çoğaltma, işlem günlüğü bloklarını ikincil bir çoğaltmaya gönderir, ancak işlem tamamlamak için onay beklemez. Felaket kurtarma çözümleri için uygundur

Synchronous commit : Synchronous commit seçeneğinde Birincil çoğaltma, ikincil bir çoğaltmadan işlemin tamamlanmasını bekler. Onay alındıktan sonra, SQL Server Always ON istemciye onay verir.

Specify Replicas ekranın da Replicas sekmesin de Readable Secondary bölümünü No, Yes ve Read-intent only seçenekleri görünmektedir.

Asynchronous commit : Bu seçenekte birincil çoğaltma, işlem günlüğü bloklarını ikincil bir çoğaltmaya gönderir, ancak işlem tamamlamak için onay beklemez. Felaket kurtarma çözümleri için uygundur

Synchronous commit : Bu seçenekte eşzamanlı taahhüt modunda, birincil çoğaltma, ikincil bir çoğaltmadan işlemin tamamlanmasını bekler. İşlem tamamlandınta ve onay alındıktan sonra, Microsoft SQL Server istemciye onay verir.

Specify Replicas ekranın da Replicas sekmesin de gerekli yapılandırmayı tamamladıktan sonra Endpoints sekmesine geçiyoruz.

Specify Replicas ekranın da Endpoints sekmesin de default olarak gelen ayarlarda herhangi bir değişiklik yapmıyoruz.

Endpoints sekmesin de dikkat etmemiz gereken eğer sunucularımız üzerinde bir den fazla Instance kullanıyorsanız sunucularınız üzerinde her Instance için farklı bir Endpoint Port Number kullanmanız gerekmektedir. Örneğin 2 Instance varsa ilk Instance için Availability Group yapısını yapılandırırken default olarak 5022 portu gelecektir. İkinci Instance’ınız için bir Availability Group yapısını yapılandıracağınız zaman Enpoint Port Number değiştirmelisiniz. İkinci Instance için 5023 portunu kullanabilirsiniz.

Specify Replicas ekranın da Endpoints sekmesin de gerekli yapılandırmayı tamamladıktan sonra Backup Preferences sekmesine geçiyoruz

Prefer Secondary : Availability Group yapısı içinde aktif olarak yapılandırmış olduğunuz Secondary sunucu varsa otomatik Backuplar ortamınız da Secondary sunucusu üzerinden gerçekleşir. Eğer ortamınızda aktif bir Secondary sunucunuz yoksa Primary sunucusu üzerinden gerçekleşir.

Secondary only : Availability Group yapısı içinde bütün otomatik Backuplar ortamınız da bulunan Secondary sunucusu üzerinden gerçekleşmek zorundadır.

Primary : Availability Group yapısı içinde bütün otomatik Backuplar Primary sunucusu üzerinden gerçekleşmek zorundadır.

Any Replica : Availability Group yapısı içinde Backuplar Primary ve Secondary sunucularınız üzerinden gerçekleşebilir.

Specify Replicas ekranın da Backup Preferences sekmesin de gerekli yapılandırmayı Primary olarak seçtikten sonra Listener sekmesine geçiyoruz

Specify Replicas ekranın da Listener sekmesin de Availability Group yapısı için Listener yapılandırıyor olacağız.

Peki Nedir Listener : Ortamınız da Availability Group yapısı içinde iki sunucumuz var ve Database ( Veritabanı ) o anda hangi sunucuda aktif çalışıyor olursa olsun, Database ( Veritabanı ) ulaşacak olan uygulamalarımız ( Logo Tiger, Logo Bordro, Mikro, Eta, Nebim gibi ) yapılandırmış olduğunuz Listener IP Address ( Dinleyici IP Adresi ) üzerinden aktif olan sunuculardaki Database ( Veritabanı ) gider. Listener DNS Name ( Dinleyici DNS İsmi ) ve Listener IP Address ( Dinleyici IP Adresi ) olur. Uygulamalarımız ( Logo Tiger, Logo Bordro, Mikro, Eta, Nebim gibi ) Microsoft SQL 2022 Server Always On yapısı içinde çalışan iki ya da daha fazla sunucunun DNS Name ( DNS İsmi ) ve IP Address ( IP Adresi ) bilmez.

Specify Replicas ekranın da Listener sekmesin de Do not create an availabiliry group listener now seçeneği ile Listener yapılandırmasını Microsoft SQL 2022 Server Always On yapılandırmasından sonra yapabilirsiniz.

Specify Replicas ekranın da Listener sekmesin de Create an availabiliry group listener seçeneği ile Listener yapılandırmasını yapılandırabilirsiniz.

Specify Replicas ekranın da Listener sekmesin de Create an availabiliry group listener seçeneğini seçiyoruz ve Listener yapılandırmasını yapıyoruz.

Listener DNS Name bölümün de Availability Group yapısı için bir Name ( İsim ) belirlememiz gerekiyor.

Port bölümün de Availability Group yapısı için uygulamalarımız ( Logo Tiger, Logo Bordro, Mikro, Eta, Nebim gibi ) Database ( Veritabanı ) bağlanacağı Port’u belirlememiz gerekiyor.

Network Mode bölümün de Availability Group yapısı için Static IP ( Statik IP ) olarak yapılandırmamız gerekiyor. Availability Group yapısı için uygulamalarımız ( Logo Tiger, Logo Bordro, Mikro, Eta, Nebim gibi ) Database ( Veritabanı ) bağlantı için Listener IP Address ( Dinleyici IP Adresi ) kullanacaktır.

Specify Replicas ekranın da Listener sekmesin de Create an availabiliry group listener seçeneğini seçiyoruz.

Listener DNS Name bölümün de Availability Group yapısı için bir Name ( İsim ) belirliyoruz.

Port bölümün de Availability Group yapısı için uygulamalarımız ( Logo Tiger, Logo Bordro, Mikro, Eta, Nebim gibi ) Database ( Veritabanı ) bağlanacağı Port’u belirliyoruz. 1433 Portu SQL Server’in default TCP/IP Port’dur.

Specify Replicas ekranın da Listener sekmesin de Network Mode bölümünü Static IP ( Statik IP ) olarak seçiyoruz ve Add diyoruz.

Add IP Address ekranında Listener için IPv4 Address bölümün de gerekli IP Address ( IP Adresi ) yapılandırması yapmamız gerekmektedir.

Add IP Address ekranında Listener için gerekli IP Address ( IP Adresi ) yapılandırmasını yaparak OK diyoruz.

NOT : Burada Listener IP Address ( Dinleyici IP Adresi ) ortamınız da herhangi bir sunucu üzerinde kullanılmıyor olmasına dikkat etmenizi önemle belirtmek isterim.

Specify Replicas ekranın da Listener sekmesin de Network Mode bölümünü Static IP ( Statik IP ) olarak gerekli yapılandırmamızın geldiğini görüyoruz.

Specify Replicas ekranın da Listenersekmesin de gerekli yapılandırmayı tamamladıktan sonra Ready-Only Routing sekmesine geçiyoruz.

Specify Replicas ekranın da Ready-Only Routing sekmesin de herhangi bir değişiklik yapmıyoruz.

Specify Replicas ekranın da Replicas, Endpoints, Backup Preferences, Listener ve Ready-Only Routing sekmelerinde gerekli bütün yapılandırmayı tamamladıktan sonra Next diyerek devam ediyoruz.

Select Initial Data Synchronization ekranın da Secondary sunucusu üzerine Database ( Veritabanı ) senkronizasyonun ilk yapılandırmasını nasıl yapılacağını yapılandırdığımız 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 otomatik olarak yapılması için Automatic seeding seçeneğini seçiyoruz ve Next diyerek devam ediyoruz.

Validation ekranın da Availability Group yapısının kurulması için gerekli kontroller yapılıyor. Availability Group yapısının kurulumu için bütün adımları Success olarak görüyoruz.

Validation ekranın da Availability Group yapısının kurulması için eğer bir sorun varsa Error olarak görürdük ve Previous 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 Availability Group yapısının kurulması için herhangi bir sorun olmadığı için Next diyerek devam ediyoruz.

Summary ekranın da Availability Group yapısının kurulması için gerekli olan yapılandırmanın bir özetini görüyoruz.

Summary ekranın da Availability Group yapısının kurulması için gerekli olan yapılandırmanın bir özetini kontrol ettikten sonra Finish diyerek kurulumu başlatıyoruz.

Summary ekranın da Script bölümün de Availability Group yapısı için yapılandırmış olduğunuz yapılandırmayı Script ( Senaryo ) olarak alabilirsiniz.

Progress ekranın da Availability Group yapısının kurulduğunu görüyoruz.

Results ekranın da Availability Group yapısının başarılı bir şekilde kurulduğunu görüyoruz.

Close diyerek New Availability Group Wizard ekranını kapatıyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolunu açıyoruz.

Connect to Server ekranın da Server name bölümüne BAKICUBUKSQLAO isimli Listener DNS Name ( Dinleyici DNS Name ) yazıyoruz.

Connect to Server ekranın da Windows Authentication seçiyoruz ve Connect diyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolunu üzerinde Database bölümü altında BAKICUBUKDB isimli Database ( Veritabanı ) BAKICUBUKDB (Synchronized ) olarak görüyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolunu üzerinde Always On High Availability bölümü altında bulunan Availability Groups bölümün de BAKICUBUKAO ismi ile yapılandırmış olduğumuz Availability Group yapılandırmasını geldiğini görüyoruz.

Availability Replicas bölümü altında W22SQL22NOD1 isimli sunucumuzu ( Primary ) olarak W22SQL22NOD2 isimli sunucumuzu ( Secondary ) olarak görüyoruz.

Availability Databases bölümü altında BAKICUBUKDB isimli Database ( Veritabanı ) görüyoruz.

Availability Listeners bölümü altında BAKICUBUKSQLAO isimli Listener DNS Name ( Dinleyici DNS Name ) görüyoruz.

Failover Cluster Manager konsolunda Roles ( Rol ) menüsün de BAKICUBUKAO ismi ile yapılandırmış olduğumuz Availability Group yapılandırmasını geldiğini görüyoruz.

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