WINDOWS FAILOVER CLUSTER’DA BULUNAN NODE’UN DOWN OLMA DURUMU

Bu yazımda sizlere karşılaştığım ilginç bir hatayı paylaşacağım. Başınıza gelme ihtimali düşükte olsa konuyu bilmekte fayda var diye düşünmekteyim. Şöyle ki; gün içerisinde aynı anda birçok uygulamamızın bağlı olduğu Always On çalışan SQL serverler aynı anda secondary replikalar ile haberleşmesini kaybetti. Always on dashboard’dan başlayarak sql taraflı kontrolleri yaptık. Secondary SQL node’u kopmuş ve “Availability replika disconnected” hatasının veriyordu.(Hatanın genel çözümüne dair yazımıza linkten ulaşabilirsiniz.(GÖRSEL-1) (https://www.veritabani.org/availability-replica-is-disconnected-hatasi/) Bu hataya dair kontrolleri yaptık. Replica konfigürasyonunda uygun olmayan bir durum yoktu. GÖRSEL-1 DMV’ler, kullanıcılar, yetkiler, sql servis kullanıcıları, aklınıza ne geliyorsa her yerden sql ve cluster kontrolü yaptık. Windows Failover cluster’ı kontrol ettiğimizde ise secondary replika clusterının down olduğunu fark ettik.(GÖRSEL-2).  SQL cluster, windows cluster’ın çatısı altında çalıştığı için always on replike olamıyordu. Primary ve secondary replikalar arasında ping attığımızda herhangi bir sorun yaşanmamasında rağmen primary ve secondary node’lar arasında cluster haberleşmesi yapamıyordu. GÖRSEL-2 Önce firewall engellemelerini kontrol ettik, engelleme yoktu. Hatta primary […]

WINDOWS FAILOVER CLUSTER’DA BULUNAN NODE’UN DOWN OLMA DURUMU

Bu yazımda sizlere karşılaştığım ilginç bir hatayı paylaşacağım. Başınıza gelme ihtimali düşükte olsa konuyu bilmekte fayda var diye düşünmekteyim.

Şöyle ki; gün içerisinde aynı anda birçok uygulamamızın bağlı olduğu Always On çalışan SQL serverler aynı anda secondary replikalar ile haberleşmesini kaybetti. Always on dashboard’dan başlayarak sql taraflı kontrolleri yaptık. Secondary SQL node’u kopmuş ve “Availability replika disconnected” hatasının veriyordu.(Hatanın genel çözümüne dair yazımıza linkten ulaşabilirsiniz.(GÖRSEL-1) (https://www.veritabani.org/availability-replica-is-disconnected-hatasi/) Bu hataya dair kontrolleri yaptık. Replica konfigürasyonunda uygun olmayan bir durum yoktu.

GÖRSEL-1

DMV’ler, kullanıcılar, yetkiler, sql servis kullanıcıları, aklınıza ne geliyorsa her yerden sql ve cluster kontrolü yaptık. Windows Failover cluster’ı kontrol ettiğimizde ise secondary replika clusterının down olduğunu fark ettik.(GÖRSEL-2).  SQL cluster, windows cluster’ın çatısı altında çalıştığı için always on replike olamıyordu. Primary ve secondary replikalar arasında ping attığımızda herhangi bir sorun yaşanmamasında rağmen primary ve secondary node’lar arasında cluster haberleşmesi yapamıyordu.

GÖRSEL-2

Önce firewall engellemelerini kontrol ettik, engelleme yoktu. Hatta primary ve secondary makineler arasında any-any yetkisine kadar işi ilerlettik ancak haberleşmede engelleme yoktu. Sorunun failover cluster tarafında olduğu artık kesin gibiydi. Power Shell scriptleri ile down olan node’u ayağa kaldırmaya çalışmakta işe yaramadı. Manuel bir şekilde node ayağa kalkmıyordu. Sorun SQL’den bağımsız bir hale geldi. SQL updateler ve Windows updateler ile gelen policylere kadar işi ilerlettik ancak yine de bir sonuç alamadık. Tüm haberleşmeleri kontrol ettik gayet stabildi. Availability replika portu 5022’den kontrolleri sağladık yine bir sıkıntı görünmemekteydi.

Daha sayamadığım bir çok şey denememize rağmen secondary node windows failover cluster bir türlü ayağa kalkmıyordu. Bundan dolayı da Always on data eşitlemesi de geride kalmıştı.

Failover cluster üzerinde sorun ararken, problemin WSCF eşitleme dosyasında olduğunu tespit ettik. Sorun Windows failover cluster’ın heartbeat haberleşmesini kaybetmesi sonucu WSCF eşitlemesini yapamamasında ötürü kaynaklanıyordu.

Çözüme geçecek olursak;

1.ADIM: Tüm node’larda cluster servisleri durdurup disable’a çekiyoruz. (GÖRSEL-3)

GÖRSEL-3

2.ADIM: Her node’da bulunan windows failover cluster manager’a ait bir dosya var.  C:\Windows\Cluster dosyasının içerisinde ‘CLUSDB’ isminde uzantısı olmayan bir dosya. Bu dosya bir anlamda windows cluster’ın database dosyası. Bu dosyayı ‘UP’ durumda olan bir cluster’dan kopyalayıp ‘DOWN’ olan cluster’larda aynı yola yapıştırdık(Yapıştırmadan önce DOWN node’un CLUSDB dosyasını yedekledik). Bu dosya kopyalama işlemi ile aslında heartbeat’leri eşitlemiş oluyoruz.

GÖRSEL-4

3.ADIM: Son olarak failover cluster servisini restart ediyoruz. (GÖRSEL-5)

GÖRSEL-5

 

Sıkıntılı olan node’un ayağa kalktığını görüyoruz. (GÖRSEL-6)

GÖRSEL-6

Yaşanan network kesintisinin; ağ trafiğinde meydana gelen yüksek trafik sonucu olduğu anladık. Windows Failover cluster, CLUSDB dosyası üzerinde heartbeat haberleşmesi ve eşitlemesi yapıyor. Bu yüksek trafikte bu eşitlemeyi yapamayan node’un geri kaldığı için down oluyor.

Buradaki heartbeat tam olarak aynı olmamakla birlikte always on heartbeat mantığı ile çalışıyor. ÖZETLE; Ayakta ve güncel olan node’un CLUSDB dosyasını down olan node’a kopyaladığımızda da sorunumuz çözülmüş oluyor.

SON NOT: Windows cluster ayağa kalktıktan sonra geri de kalan secondary sql node’ları resume etmeyi unutmayalım.

Kaynaklar:

https://gaptheguru.wordpress.com/sql-server/backup-and-restore-of-the-failover-cluster-configuration-using-vss/

https://www.altaro.com/backup-dr/clusdb-backup-recovery/

 

Benzer Yazılar

SQL SERVER RIGHT-LEFT PARTITION

SQL Server 5 gün önce

SQL Server’da partitioning, büyük veritabanı tablolarını daha yönetilebilir ve performanslı hale getirmek amacıyla kullanılan bir tekniktir. Bu teknik, tablonun verilerini fiziksel olarak değil, mantıksal olarak parçalara ayırır. Veriler, belirli bir partition function ve partition scheme kullanılarak farklı bölümlere yönlendirilir. Partitioning, özellikle büyük veri kümeleriyle çalışan veri tabanlarında sorgu performansını artırır ve veri yönetimini kolaylaştırır. Partition Function ve Partition Scheme nedir? Partition Function: Verilerin hangi kriterlere göre bölüneceğini belirler. Örneğin, bir tarih aralığına göre verileri ayırmak. Partition Scheme: Verilerin hangi filegroup’larda depolanacağını belirler.   Örnek olarak Range LEFT ve Range RIGHT olmak üzere iki ayrı tabloda partition nasıl yapılır sizlere göstereceğim. İlk olarak Range LEFT olan partition yapısından başlayacağım. Öncelikle Veri tabanıma yeni filegroup ve file ekliyorum Şimdi sıra FUNCTION ve SCHEME oluşturmakta ben tablomu yıllık olarak partition yaptım sizler ihtiyaçlarınız doğrultusunda aylık,günlük vs yapabilirsiniz. LEFT partition dediğimiz olay vermiş olduğunuz tarih aralığına eşit bir veri geldiğinde bu veriyi solundaki partition […]

Veritabanı Recovery Pending Durumu ve Düzeltme Seçenekleri

SQL Server 2 hafta önce

İçindekilerVeritabanı Recovery Pending Durumu Nedir?Veritabanı Neden Recover Pending Duruma Düşer?Recovery Pending Durumu Nasıl Çözülür?SonuçKaynaklarVeritabanı Recovery Pending Durumu Nedir? SQL Server’da veritabanları bazı nedenlere bağlı olarak “Recovery Pending” (Kurtarma Bekleme)  moduna geçebilir. Veritabanın düzgün bir şekilde kapatılmaması, eksik veya bozuk log dosyaları, disk depolama sorunları, sistemde yaşanan anormal şekilde çökmeler veya MS SQL Server’daki hatalar bu duruma sebep olabilir. Recovery durumu, aslında veritabanını tekrar kullanılabilir hale getirmek için bir kurtarma işlemi yürüttüğünü ifade eder ve üç aşamadan oluşur; Analysis (Analiz): Transaction log incelemesi yapılması ve işlemlerin tamamlanma (Commit) durumunun kontrol edilmesi, Redo (Yeniden İşleme): Tamamlanmış (Commit) ancak henüz diske yazılamamış olan işlemlerin yeniden işlenmesi, Undo (Geri Alma): Başlamış (Begin) ancak tamamlanmamış (Commit) işlemlerin  geri alınmasıdır.   Veritabanı Neden Recover Pending Duruma Düşer? SQL Server Restart Süreci SQL Server servisi restart edildiğinde üzerinde bulunan tüm veritabanları tutarlılığın sağlanması için otomatik olarak recovery moduna girer ve redo/undo işlemleri sürecince devam eder. Ani Sistem […]

SQL Server DMV ve DMF – 6

SQL Server 2 hafta önce

Bu yazımızda DMV ve DMF Serimizin 6.sına devam edeceğiz. Bir önceki seride Memory’ye ilişkin DMV ve DMF’leri ele almıştık. Bu yazıda Memory konusunda devam edeceğiz. SQL server’da Memory kavramı en önemli kavramlardan biridir. Özellikle tüm transaction işlemlerinin önce Buffer sonra disk üzerinden devam ettiğini düşünürsek buffer’ın oynadığı kritik rolü daha iyi anlayabiliriz. Bu yazıda Memory’nin durumunu ve monitör edilmesine bakacağız. Özellikle Performans sorunlarında memory konusunda sorun yaşandığı durumda nasıl okumak gerektiği önemli rol oynamaktadır. Hangi database’de, hangi tablo’da sorun yaşandığına ilişkin bilgilere bu paylaşım sonrasında görebileceğiz. SQL Server’ın Memory kullanım durumunu incelediğimde; select physical_memory_in_use_kb/1048576.0 AS ‘physical_memory_in_use (GB)’, locked_page_allocations_kb/1048576.0 AS ‘locked_page_allocations (GB)’, virtual_address_space_committed_kb/1048576.0 AS ‘virtual_address_space_committed (GB)’, available_commit_limit_kb/1048576.0 AS ‘available_commit_limit (GB)’, page_fault_count as ‘page_fault_count’ from  sys.dm_os_process_memory; Görsel – 1   Physical_memory_in_use: Kullanımda olan Fiziksel Memory miktarını gösterir. locked_page_allocations: Memory’de lock’lanmış olan Page’lerin miktarını belirtir. virtual_address_space_contained: SQL Server VAS(Virtual Adress Space) için ayrılan miktarı belirtir. available_commit_limit: SQL Server tarafından kullanılabilecek Memory Miktarını gösterir. […]

1 Yorum

  • Oğuzhan şahin 7 Nisan 2024

    Merhaba
    Aynı sorun bende de oldu, server 1 node down görünüyor, server 2 clusdb kopyaladım ama çalışmadı, server2 cluster stop olduğu zaman server1 node up oluyor, yardımlarınız için teşekkür ederim 05446341038

Yorum Yaz

Rastgele