SQL Server Always ON AG (AVAILABILITY GROUP) Yapısı

Merhabalar, bu makalemde sizlere SQL Server Always ON AG(Availability Group) yapısından bahsedeceğim. SQL Server Always ON, HA(Yüksek erişebilirlik) üzerine kurulmuş SQL Server mimarilerinden bir tanesi olup, en gelişmişidir. Yüksek erişilebilirlik artık günümüzün olmazsa olmaz mimarileri arasındadır. Kurum ve kuruluşlar için özellikle üretim bazlı firmalar için ise önemi çok yüksektir. Bu nedenle bu sistemleri yapılandırırken sistemlerin sürekliliğinin sağlanması kesintisi olmaması adına yüksek erişilebilirlik mimarisi çok önem arz etmektedir. HA yapı ile birlikte sistemsel, donanımsal veya doğal afete karşın kesintisiz çalışma sağlanmaya çalışılmaktadır. Anlaşılacağı üzere HA yapı için öncelikle gerekli alt yapının kurulması gerekmektedir. Sonrasında ise bu alt yapı üzerindeki üst yapının devreye alınması ve yükün değişik bölgelere yayılımı önemlidir. Örnek verecek olursak bir bölgede meydana gelecek olan yangın esnasında bir DataCenter devre dışı kalacak olur ise sistemlerin bundan etkilenmeden çalışması için yüksek erişilebilirlik mimarisinin farklı lokasyonlar üzerine dağıtılması gerekmektedir. Bu bir bakımı sürekli olarak duyduğumuz Disaster Recovery teriminin karşılığıdır. Always ON […]

SQL Server Always ON AG (AVAILABILITY GROUP) Yapısı

Merhabalar, bu makalemde sizlere SQL Server Always ON AG(Availability Group) yapısından bahsedeceğim.

SQL Server Always ON, HA(Yüksek erişebilirlik) üzerine kurulmuş SQL Server mimarilerinden bir tanesi olup, en gelişmişidir. Yüksek erişilebilirlik artık günümüzün olmazsa olmaz mimarileri arasındadır. Kurum ve kuruluşlar için özellikle üretim bazlı firmalar için ise önemi çok yüksektir. Bu nedenle bu sistemleri yapılandırırken sistemlerin sürekliliğinin sağlanması kesintisi olmaması adına yüksek erişilebilirlik mimarisi çok önem arz etmektedir.

HA yapı ile birlikte sistemsel, donanımsal veya doğal afete karşın kesintisiz çalışma sağlanmaya çalışılmaktadır. Anlaşılacağı üzere HA yapı için öncelikle gerekli alt yapının kurulması gerekmektedir. Sonrasında ise bu alt yapı üzerindeki üst yapının devreye alınması ve yükün değişik bölgelere yayılımı önemlidir. Örnek verecek olursak bir bölgede meydana gelecek olan yangın esnasında bir DataCenter devre dışı kalacak olur ise sistemlerin bundan etkilenmeden çalışması için yüksek erişilebilirlik mimarisinin farklı lokasyonlar üzerine dağıtılması gerekmektedir. Bu bir bakımı sürekli olarak duyduğumuz Disaster Recovery teriminin karşılığıdır.

Always ON yapısını ele aldığımızda, Always ON SQL Server üzerinde kesintisiz çalışma esasına dayanmaktadır. SQL Server üzerinde ihtiyaçlara göre farklı seviyede uygulanan SQL Server Mirroring, SQL Server Log Shipping gibi farklı mimariler bulunmaktadır. Ancak SQL Server Always ON bunlardan en gelişmişidir. Dolayısıyla maliyeti en yüksek olanıdır.

SQL Server üzerinde Always On’u enable etmek için configuration manager ile SQL Server Services kısmında instance’a sağ tıklayıp properties alanına gidiyoruz.

Açılan sekmede AlwaysOn High Availability kısmına gelip Enable AlwaysOn Availability Groups’u tıklayıp ok diyerek bu instance üzerinde Always On’u aktif hale getiriyoruz. Bu işlemi iki sunucuda da Always On yapacağımız instance için gerçekleştirmemiz gerekiyor. Bu işlem servis restart’ı gerektirecektir. Kontrollü olarak sql server servislerinizi restart edebilirsiniz.

Always On’u iki sunucu üzerindeki instance’da aktif hale getirdikten sonra aşağıdaki gibi SSMS üzerinden AlwaysOn High Availability kısmından New Availability Group Wizard’a tıklıyoruz.

Gelen ekranda AG’ye bir isim vermemiz gerekiyor. Ben TEST_AG ismini verdim. Next diyerek ilerliyoruz.

Gelen ekranda oluşturacağımız AG’ye dahil edeceğimiz veritabanları seçiyoruz. AG’ye almaya uygun veritabanlarının Status’u Meets prerequisities şeklinde gelir. SAMPLEDATA’yı seçerek ilerliyoruz.

Bir sonraki ekranda Replicas kısmında add diyerek diğer sunucuda Always On yapacağımız secondary instance’a bağlanıyoruz. Availability Mode ise Synchronous commit olmasına dikkat edin. Biz kuracağımız AG’yi senkron ve otomatik failover olabilecek şekilde set etmek istediğimiz için aşağıdaki şekilde gerekli alanları işaretliyoruz.

Readable Secondary’yi şimdilik No olarak bırakıyoruz. Replicas sekmesinde belirttiğimiz işlemleri yaptıktan sonra Endpoints sekmesine geçiyoruz ve karşımıza aşağıdaki gibi bir ekran geliyor.

Aynı sunucuda birden fazla instance kullanıyorsanız her instance için değişik bir endpoint portu kullanmanız gerekecektir. Default endpoint portu 5022 ‘dir. Örneğin 3 instance’ınız var. İlk instance için ag oluştururken yukardaki ekranda default olarak 5022 portu gelir. İkinci instance’ınız için bir ag oluşturacağınız zaman Enpoint URL kısmından portu değiştirmelisiniz. İkinci instance için 5023, üçüncü instance için 5024 portunu kullanabilirsiniz.

Bir değişiklik yapmadan Backup Preferences sekmesine geçiyoruz ve karşımıza aşağıdaki gibi bir ekran geliyor. Bu ekranda Backupları almak için tercih edilen instance’ı soruyor. İçlerinden birini seçmelisiniz.

Prefer Secondary :Aktif bir secondary sunucu varsa otomatik backuplar secondary sunucudan gerçekleşir. Aktif bir secondary yoksa primary sunucudan gerçekleşir.

Secondary only :Bütün otomatik backuplar secondary sunucudan gerçekleşmek zorundadır.

Primary :Bütün otomatik backuplar primary sunucudan gerçekleşmek zorundadır.

Any Replica :Backuplar primary ve secondary’den gerçekleşebilir.

Sadece primary’i seçerek başka değişiklik yapmadan devam ediyoruz.

Next diyerek ilerliyorum. Bir sonraki ekranda bizden secondary veritabanı ile senkronizasyonun ilk tanımlarken nasıl yapılacağını soruyor. Automatic seeding seçerek next diyoruz.

Bir sonraki ekranda gerekli kontrolleri yapıyor. Eğer bir sorun çıkarsa sorunu çözüp Re-run validation diyebilirsiniz. Sorunu çözmek için Back tuşuna basarak geri gidebilir ve yanlış yaptığınız bir ayarı düzeltip tekrar next diyerek ilerleyebilirsiniz. Bizim kurulumumuzda bir sorun çıkmadı.

Next diyerek ilerliyoruz ve en son summary kısmını başarılı gördükten sonra close diyoruz. Böylece kurulum ve adımları başarılı bir şekilde tamamlamış oluyoruz.

Bir sonraki makalede görüşmek üzere 🙂

Benzer Yazılar

SQL Server ‘da Detach-Attach İşlemleri Nasıl Yapılır?

SQL Server 14 saat önce

SQL Server’ da  Detach – Attach İşlemleri. Merhaba, bu yazımda SQL Serverda veri tabanımızı farklı sunuculara taşımamız gerektiğinde ya da farklı sunuculardaki veri tabanlarını listemize almak istediğimizde nasıl bir yol izlememiz gerektiğini anlatacağım.İçindekilerDETACH İşlemiATTACH İşlemi Öncelikle bir veri tabanını taşımanın birden fazla yolu var. Bunlar: Detach-Attach, Restore, Backup yöntemleridir. Neden Veri Tabanını Taşırız? Sunucularımızda kaynak yetersizliğimiz olabilir. Sürüm yükseltmemiz gerekebilir. Domain değişikliği olabilir. İlk olarak “Uygulama” isimli bir veri tabanı oluşturalım. İşlemlerimizi bu veri tabanı üzerinden yürüteceğiz. CREATE DATABASE Uygulama Sorgumuz ile veri tabanımızın nerede tutulduğunu bulalım. USE Uygulama GO EXEC sp_helpfile DETACH İşlemi Detach İşlemi, ilgili veri tabanımızı listeden çıkarmak yani taşımak istediğimizde Detach bize yardımcı oluyor. Soldaki veri tabanı listemizden Uygulama isimli veri tabanımızın üzerine gelip sağ tık >Tasks >Detach yolunu izleyeceğiz.   Karşımıza gelen panelde Message alanında “Active Connections” yazıyor. Yani bir aktif bağlantı olduğunu söylüyor. Biz de DropConnections alanındaki tiki işaretleyeceğiz ki bu aktif bağlantıyı silsin. […]

SQL SERVER SERViS RESTART HATASI

SQL Server 2 ay önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 3 ay önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

0 Yorum

Yorum Yaz

Rastgele