MSSQL FILE SHARE WITNESS’IN DEĞİŞTİRİLMESİ

Bu yazımızdaki failover cluster manager içerisinde yer file share witness dosyasının başka bir konuma taşınması işlemini anlatacağız. File Share Witness ne işe yarar kısaca bahsedecek olursak; Cluster oylamasında çoğunluk sağlamaktır. Örneğin; 2 sunucu var diyelim 1’i düştü cluster çökedebilir çökmeyedebilir. Kararsız kalabilme ihtimali vardır. Witness, primary ve secondary olmak üzere toplam üç oy olur. Primary çökerse witness ve secondary kalır. Witness’ın oyu %50’den fazla olduğu için vereceği oy ile cluster çökmekten korunmuş olur. 1. ADIM: Önce file share witness kaldırma işlemini yapacağız. Always on cluster’da bulunan herhangi bir sunucu üzerinde Failover Cluster Manager’ı açıyoruz.(GÖRSEL-1) GÖRSEL-1 Cluster name üzerinde sağ tık-> More Actions -> Configure Cluster Quorum Settings’e tıklıyoruz. (GÖRSEL-2) GÖRSEL-2 Gelen ilk ekranda next seçeneğini tıkladıktan sonra GÖRSEL-3’te gelen ekranda, ilk defa file share witness kurar gibi “Select the quorum witness”ı seçip next diyoruz.   GÖRSEL-3 Sonra gelen GÖRSEL-4’teki ekranda ise “Do not configure a quorum witness” seçeneği tıklayıp next […]

MSSQL FILE SHARE WITNESS’IN DEĞİŞTİRİLMESİ

Bu yazımızdaki failover cluster manager içerisinde yer file share witness dosyasının başka bir konuma taşınması işlemini anlatacağız.

File Share Witness ne işe yarar kısaca bahsedecek olursak; Cluster oylamasında çoğunluk sağlamaktır. Örneğin; 2 sunucu var diyelim 1’i düştü cluster çökedebilir çökmeyedebilir. Kararsız kalabilme ihtimali vardır. Witness, primary ve secondary olmak üzere toplam üç oy olur. Primary çökerse witness ve secondary kalır. Witness’ın oyu %50’den fazla olduğu için vereceği oy ile cluster çökmekten korunmuş olur.

1. ADIM: Önce file share witness kaldırma işlemini yapacağız.

Always on cluster’da bulunan herhangi bir sunucu üzerinde Failover Cluster Manager’ı açıyoruz.(GÖRSEL-1)

GÖRSEL-1

Cluster name üzerinde sağ tık-> More Actions -> Configure Cluster Quorum Settings’e tıklıyoruz. (GÖRSEL-2)

GÖRSEL-2

Gelen ilk ekranda next seçeneğini tıkladıktan sonra GÖRSEL-3’te gelen ekranda, ilk defa file share witness kurar gibi “Select the quorum witness”ı seçip next diyoruz.

 

GÖRSEL-3

Sonra gelen GÖRSEL-4’teki ekranda ise “Do not configure a quorum witness” seçeneği tıklayıp next diyoruz. Bu seçenek ile burada bulunan eski file share witness’ı silmiş olacağız.


GÖRSEL-4

GÖRSEL-5’teki ekranında uyarımızı alıyoruz. Herhangi bir quorum witness ayarlamadığımıza dair. Burada da next diyoruz.

GÖRSEL-5

GÖRSEL-6’daki ekranda finish diyerek file share witness’ı silmiş oluyoruz. Eski file share witness’ı siliyoruz ki yeni kuracağımız file share witness dosyamız ile dublicate olmasın.

GÖRSEL-6

GÖRSEL-7 üzerinde file share witness’ın kaybolduğunu göreceksiniz.

GÖRSEL-7

 

2. ADIM: Yeni file share witness için konum belirliyoruz ve dosyaya gereken yetkileri veriyoruz.

File share witness dosyasının konumunun seçiminde başka bir sunucuda yer belirlemek sağlıklı olacaktır. Eğer sql sunucuları içerisinde bir konum seçersek sunucuların başına bir şey gelmesi durumunda witness share zarar görebilir.

Tüm sistemlerimizdeki instanceler için bir sunucu içerisinde tüm “file share witness” dosyalarınız saklayabilirsiniz. Bu sunucunun tek görevi file share witness dosyalarının tutulması olabilir. Ve o sunucunun bakım ve güncelleme işlemlerinin dikkatli bir şekilde yapılması gerekmektedir.

 

Ben kendi laboratuvar ortamımda olan domain controller makinesi içerisinde bir yol vereceğim.

GÖRSEL-8

GÖRSEL-8’de görülen FSW_SQLCLUSTER dosyası üzerinde özellikler’e gelip. Share kısmı üzerinden;

=> SQL1 (PRIMARY)

=> SQL2 (SECONDARY)

=> SQL3 (SECONDARY)

=> MERTSAHIN\sqldb (SQL Servis Hesabı)

=> SQL_CLUSTER  (Cluster PC) hesaplarını paylaşıma ekleyerek  “Full Control” veriyoruz.

GÖRSEL-9

GÖRSEL-9 üzerinde security kısmı üzerinde yine aynı şekilde sql nodelarına, servis hesabına ve cluster makine adına full control veriyoruz.

Buradaki tüm yetkileri vermekteki amaç otomatik failover sırasında yapılacak olan haberleşme esnasında, yetki sebebiyle herhangi bir kesinti yaşanmadan ve sağlıklı bir şekilde failover olunmasını sağlamaktır.

 

3. ADIM: Bu adımda yetkilerini verdiğimiz dosya üzerine yeni bir file share witness kurulumu yapacağız.

Paylaşım verdiğimiz dosya’nın Network Path yolunu kopyalıyoruz. (GÖRSEL-10)

 

GÖRSEL-10

 

Yine sql node’larının herhangi birinden failover cluster manager’ı açıyoruz. GÖRSEL-2’de olduğu gibi Cluster name üzerinde sağ tık-> More Actions -> Configure Cluster Quorum Settings’e tıklıyoruz. İlk gelen ekranda next seçeneğini tıklıyoruz.

GÖRSEL-11’de olduğu gibi select quorum witness’ı seçip next diyoruz.

GÖRSEL-11

 

GÖRSEL-12’de configure a file share witness’ı seçip next diyoruz.

GÖRSEL-12

 

GÖRSEL-13’te yer alan kısma GÖRSEL-10’da kopyaladığımız yolu yapıştırıyoruz ve next diyoruz.

GÖRSEL-13

GÖRSEL-14’de next sonrasındaki GÖRSEL-15’te finish diyerek file share witness kurulumunu tamamlıyoruz.

GÖRSEL-14

 

GÖRSEL-15

4. ADIM: Failover testlerinin yapılması.

Ben kendi sistemlerimde primary sql node’unu restart ederek failover testlerini yaptığımda olumlu sonuç aldım. Sizde kritik sistemler üzerinde çalışıyorsanız tavsiyem file share witness’ı kurduktan sonra failover testi yapmanızdır.

Benzer Yazılar

SQL SERVER SERViS RESTART HATASI

SQL Server 2 hafta ö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 1 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 […]

Query Store Nedir?

SQL Server 1 ay önce

Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]

0 Yorum

Yorum Yaz

Rastgele