Always ON mimarisi yapılandırma adımları öncesinde birkaç ön hazırlık yapmamız gerekiyor. Öncelikle iki SQL Server kurulu olan sunucumuz üzerinde bu işlemleri yapmamız gerektiğinin altını çizelim. SQL Server Configuration Manager konsolunu açalım. SQL Server Network Configuration altında yer alan Protocols for MSSQLSERVER isimli instance’ımıza ait ekranı açalım. Disable durumda olan Named Pipes ekranını açalım.
Named Pipes Properties ekranımızdaki Enabled özelliğini Yes konumuna getirelim. OK ile bu ekrandan çıkalım.
Bu işlem için Instance ait SQL Server servisinin yeniden başlaması gerektiği uyarısını dikkate alarak OK ile bu ekranı kapatalım.
Sonrasında MSSQLSERVER instance özelliklerini açarak Enable Qlways ON Availability Groups özelliğini aktif duruma getirerek OK butonu ile bu ekranımızdan çıkalım.
Servisin yeniden başlatma uyarısını OK ile geçelim.
SQL-Server1 sunucumuz üzerindeki SQL Sunucumuza SQL Management Studio üzerinden bağlanalım. Always On High Availability tabına tıklayalım.
Aşağıdaki gibi bir hata bizi karşılıyor.
Bir önceki işlemlerimiz sonrasında gelen uyarıları baz alarak SQL servisini yeniden başlatmamamız durumunda bu hatayı alırız. Servis üzerinde sağ tıklayarak Restart menüsüne tıklayarak servisi yeniden başlatalım.
Tekrardan Always On High Availability tabına tıkladığımızda alt öğe olan Availability Groups kabının açıldığını görebiliyoruz.
Şimdi aynı işlemleri SQL-Server2 olan diğer sunucumuz üzerinde yapalım. SQL Server Configuration Manager konsolunu açalım. SQL Server Network Configuration altında yer alan Protocols for MSSQLSERVER isimli instance’ımıza ait ekranı açalım. Disable durumda olan Named Pipes ekranını açalım.
Named Pipes Properties ekranımızdaki Enabled özelliğini Yes konumuna getirelim. OK ile bu ekrandan çıkalım.
Bu işlem için Instance ait SQL Server servisinin yeniden başlaması gerektiği uyarısını dikkate alarak OK ile bu ekranı kapatalım.
Sonrasında MSSQLSERVER instace özelliklerini açarak Enable Qlways ON Availability Groups özelliğini aktif duruma getirerek OK butonu ile bu ekranımızdan çıkalım.
Servisin yeniden başlatma uyarısını OK ile geçelim.
Servis üzerinde sağ tıklayarak Restart menüsüne tıklayarak servisi yeniden başlatalım.
SQL-Server2 sunucumuz üzerindeki SQL Sunucumuza SQL Management Studio üzerinden bağlanalım. Always On High Availability tabına tıklayalım. Altında Availability Groups kabı sorunsuzca açılıyor. Bu kap üzerinde sağ tıklayarak New Availability Group Wizard… linkine tıklayarak artık Always ON adımlarını başlatabiliriz. Nihayetinde hazır duruma gelebildik. 😊
Bizi karşılayan sihirbazı Next ile geçelim.
Seçimler arasında Windows Server Failover Cluster, üçüncü parti yazılımlar tarafından sağlanan cluster veya cluster kullanmama gibi seçimler söz konusu, biz tabi ki Windows Failover Cluster kullanacağımız için seçimimizi bu şekilde ayarlayarak Windows Server Failover Cluster seçimini yapıyoruz.
Bu seçimden sonra Availability group name olarak bir isim belirleyip Next ile sonraki adıma ilerliyoruz.
Bu ekranımızda ise işlemlere başlamadan önce işlem yapılacak olan database özelliğinin full recovery mode yapısında olması isteniyor. Bu gereksinimi yerine getirmeden ilerleyemeyiz. Buda demek oluyor ki Always On mimarisi içerisine girerek olan database Full Recovery Mode yapısında olmak zorunda.
Yukarıdaki ekrandan çıkarak ilgili veri tabanı üzerinde sağ tıklayıp Properties menüsünü açalım.
Options tabında açılan ekrandan Recovery model kısmına gelelim. Veri tabanı şu anda Simple mod olarak ayarlanmış.
Biz Recovery Model yapısını Full olarak ayarlayıp OK ile bu ekrandan çıkalım.
Availability Group yapısını kurmak için aynı ekrana kadar ilerleyelim. Şimdi de bizden bu işlemlere başlamadan veri tabanı’nın full yedeğini almamız isteniyor.
Yedekleme işlemi için ana konsolda veri tabanı üzerinde sağ tıklayarak Task->Backup menüsüne tıklayalım.
Yedek için bir yol belirledikten sonra Full olarak bir yedeğini alalım.
Yedekleme işlemimiz başarı ile tamamlandı. OK ile bu ekranlardan çıkalım ve işlemimize kaldığımız yerden devam edelim.
Şimdi bir gereksinim kalamadı Next ile sonraki adıma geçebiliriz.
Bu ekranımız birkaç tab’dan oluşuyor ve ayarlarımızın genel olarak tümünü bu ekranda tamamlıyor olacağız. Bu nedenle ilgili yerleri gerektiği kadar açıklamaya çalışacağım. Replicas tabında Server Instance alanında SQL-Server1 isimli sunucumuzu Primary olarak algılamış durumda. Add Replica… butonuna tıklayarak secondary sunucumuzu ekleyelim.
İkinci sunucumuza bağlantı sağlamak için ismini yazalım ve kimlik doğrulama türümüzü seçerek Connect butonuna tıklayalım.
Doğrulama adımı sorunsuzca tamamlandı ve SQL-Server2 isimli sunucumuz Secondary sunucu olarak eklendi. Primary ana veri tabanı mahiyetinde olup secondary ise primary üzerinden replika alacak veri tabanı durumundadır. Automatic Failover kısmındaki onay kutuları işaretli Failover otomatik olarak devreye girecektir. Kısaca senkron ve asenkron moda değinelim.
Synchronous: Bu modda bir veri tabanında yapılan bir işlem diğer veri tabanı üzerinde yapılmadan commit edilmez. Yani primary üzerinde yapılan işlemin secondary üzerinde yapılması beklenir.
Synchronous: Bu modda primary üzerinde yapılan işlem secondary üzerine yazılmadan commit edilir yani gelen isteklere sonuç döndürür.
Bu mod seçimleri yapının büyüklüğü, performans durumu ve özel koşullara göre farklılık gösterebilir. Biz yapımızda Synchronous commit modu seçiyoruz.
Readable Secondary kısmında ise secondary olan veri tabanı üzerinde okuma yapılıp yapılmayacağının seçimidir. Genelde secondary olan veri tabanı üzerinden sistemi hafifletmek adına rapor çekilmesi, yedek alınması gibi durumlar söz konusu olabilir. Buna göre bir tercih yapmak gerekir. Biz şimdilik No olarak bırakacağız. Buradaki tercihler belirtiğimiz gibi sizin yapınız üzerindeki tasarruflarınıza bağlı olarak değişim gösterecektir.
Endpoints tabında ise sunucuların haberleşme bilgilerini bize yansıtır. Burada gördüğümüz port bilgilerini değiştirebiliriz ancak biz varsayılan portları bırakıyoruz. Güvenlik duvarlarının aktif olduğu alanlarda bu portlara izin vermemiz gerekmektedir. Varsayılan olarak 5022 portu kullanılır.
Backup Preferences tabında birden fazla seçim sunulmakta bunları kısaca açıklamamızda yarar var.
Prefer Secondary : Availability Group yapısı içinde aktif olarak yapılandırmış olduğunuz Secondary sunucu olması durumunda otomatik olarak alının yedekler, Secondary sunucusu üzerinden gerçekleşir. Ortamda aktif bir Secondary sunucu bulunmuyor ise Primary sunucusu üzerinden gerçekleşir.
Secondary only : Availability Group yapısı içinde bütün otomatik yedekler Secondary sunucusu üzerinden gerçekleşmek durumundadır.
Primary : Availability Group yapısı içinde bütün otomatik yedekler Primary sunucusu üzerinden gerçekleşmek durumundadır.
Any Replica : Availability Group yapısı içinde yedekler Primary ve Secondary sunucularınız üzerinden alınabilir durumdadır.
Buradaki tercih size kalmış durumda. Ben yapımda Primary seçimini yapıyorum.
Buradaki işlemimizi bitirip Listener tabına geliyoruz.
Listener: En kaba tabiri ile bir garson olarak düşünülebilir. Sizi restoran girişinde bekler ve uygun bir mekana oturmanızı sağlar. Eğer dolu olan yer var ise size oturmanız için boş bir yer gösterir. Bu durumu mimarimize uygulayacak olursak SQL Always ON yapısı içerisinde bir programa girilen listener bilgisi sizi uygun olan sunucuya yönlendirme görevi görür. Örnek olarak bir muhasebe programınız ve arkasında SQL Always ON mimarisi olsun. Program veri tabanı tanım alanında Listener’i görür ve arkadaki duruma, sistemlerin ayakta olup olmadığına göre sizi uygun olan veri tabanı yapınıza yönlendirir.
Bu tanımı sonradan yapabilirsiniz. Ancak biz şimdi yapılandıracağımız için Create an availability group listener kutucuğunu tıklayarak bir listener tanımlaması yapalım. DNS Name olarak SQLSERVER port olarak varsayılan port 1433 bilgisini girip Add.. butonuna tıklıyoruz.
Listener için erişim sağlamamızda sorun olmayacak aynı bloktan uygun bir ip adresi girmemiz gerekmekte.
Uygun ve boşta olan aynı bloktan 10.81.2.222 ip adresini giriyorum. OK ile bu adımı onaylıyorum.
Listener ekli duruma geldi.
Son tabımız olan Read-Only Routing tabında bir değişiklik yapmadan Next ile bir sonraki adıma ilerliyoruz.
Select Initial Data Synchronization ekranın da Secondary sunucusu üzerine veri tabanının ilk senkronizasyonun nasıl yapılacağını belirlememiz gerekiyor. Buradaki seçenekleri genel olarak açıklayacak olursak;
Automatic seeding : Bu seçenek bizim özel bir işlem yapmamıza gerek kalmadan primary sunucu üzerinden veri tabanının senkronizasyonunu otomatik olarak secondary sunucu üzerine doğru yapacaktır.
Full database and log backup : Bu seçenekte veri tabanı Full Backup ve Log Backup dosyalarını secondary sunucunun erişim sağlayacağı bir alana taşımamız gerekmektedir. Secondary sunucunun okuma ve yazma yetkisi olması gereken bu alandan secondary sunucu senkronizasyon işlemini yapar. Bu çok büyük veri tabanlarında, uzak aradaki bant genişliği düşük ağlar üzerinde tercih edilebilir.
Join only : Bu seçenekte veri tabanı Full Backup ve Log Backup’ı Manuel olarak alınıp, Manuel olarak Secondary sunucusuna kopyalama gerektirir.
Skip initial data synchronization : Join only seçeneği ile aynı olup, tek farkı bu işlemi sonra yapabilmemizdir.
Biz otomatik olarak işlemlerin gerçekleşmesi için Automatic seeding seçeneğini seçerek Next ile ilerliyoruz.
Yapılacak olan işlemler için bir doğrulama yapıldı ve sorun gözükmüyor Next ile sonraki adıma ilerleyebiliriz.
Yapılacak olan işlemlerin tümüne ait bir özet bize sunuldu. Finish ile Availability Group oluşturma ve senkronizasyon işlemlerimizi başlatalım.
İşlemlerimiz başladı.
Hata vermeden tüm işlemlerimiz başarı ile tamamlandı. Close ile bu ekranımızdan çıkabiliriz.
Şu anda SQL-Server1 sunucumuz üzerinde SQL Always ON mimarimiz devrede. Primary ve Secondary sunucularımız ayakta, verit banımız Availability Databases içerisinde ve Listener’imiz çalışır durumda.
Aynı şekilde SQL-Server2 sunucumuza göz atalım.
SQL-Server1 sunucumuzda olduğu gibi SQL-Server2 sunucumuz üzerinde SQL Always ON mimarimiz devrede. Primary ve Secondary sunucularımız ayakta, veri tabanımız Availability Databases içerisinde ve Listener’imiz çalışır durumda.
Şimdi ise bahsetmiş olduğumuz bir uygulamanın Always ON mimarisi kullanması durumunda gerekli olan Listener ismi ile bağlantı sağlamayı deneyelim. SQLSERVER listener bilgimizi girip Conenct butonuna tıklayalım.
Sorunsuz şekilde Listener yapımızda çalışır durumda.
Bu işlemler sonrasında Active Directory üzerinde Computers kabında Avaibility Group oluşturma sırasında oluşturulan Listener SQLSERVER computer öğesi olarak ekli duruma geldi.
DNS üzerinde bir kayıt oluşturulduğu için DNS Suffix ile ping isteklerine belirttiğimiz ip adresi ile yanıt verir durumda.
DNS üzerindeki A kaydımızda aşağıdaki gibi.
Geniş bir özet geçecek olursak;
SQL Always ON mimarisi nedir konusuna değindik. SQL üzerindeki yedeklilik mimarilerinden genel olarak bahsettik. SQL Always ON kurabilmek için gerekli olan sistem ve yazılım gereksinimlerinden bahsettik. Kurulum yapabilmek için test ortamımız hakkında şema üzerinde bilgilendirme yaptık. Sunucularımız üzerinde Failover Clustering özelliğini devreye aldık. Sunucularımız üzerinde SQL Server 2019 ve Sql Management Studio kurulumlarını yaptık. Sonrasında SQL Sunucularımız arasında Failover Cluster mimarisi kurduk ve test ettik. Son olarak ise sunucularımız üzerinde SQL Server 2019 içerisinde SQL Always ON Database Availability Group yapısını devreye aldık. Bir sonraki ve serimizin son makalesi üzerinde kurulan yapı üzerinde birkaç mini test yapacağımız kısa bir makalemiz olacak.
Umarım yaralı olmuştur. Bir başka makalede görüşmek dileğiyle.
SQL Server 2019 Always ON Kurulumu Bölüm 1
You are awesome Sir, Salute to your effort
Eline sağlık Rıza.