WSFC Zorunlu Quorum (SQL Server) Üzerinden Felaket Kurtarma

Şunlar için geçerlidir: SQL Server

Kadro arızası genellikle sistemik bir felaket, kalıcı bir iletişim arızası veya WSFC kümesindeki birkaç düğümü içeren yanlış yapılandırma nedeniyle oluşur. Yeter sayısı eksikliğinden kurtulmak için manuel müdahale gereklidir.

Prerequisites

Zorunlu Çoğunluk Prosedürü, çoğunluk arızasından önce sağlıklı bir çoğunluğun mevcut olduğunu varsayar.

Warning

Kullanıcı, Windows Server Failover Kümeleme, WSFC Quorum Modelleri, SQL Server ve ortamın özel dağıtım yapılandırması kavramları ve etkileşimleri hakkında iyi bilgilendirilmelidir.

Daha fazla bilgi için bkz.: SQL Server ile Windows Server Yük Devretme Kümelemesi (WSFC), WSFC Çekirdek Modları ve Oylama Yapılandırması (SQL Server)

Security

Kullanıcı, WSFC kümesinin her düğümünde yerel Yöneticiler grubunun üyesi olan bir alan hesabı olmalıdır.

WSFC Zorunlu Quorum Prosedürü Aracılığıyla Felaket Kurtarma

Unutmayın ki, yeterli kapasite arızası, WSFC kümesinde tüm kümelenmiş servislerin, SQL Server örneklerinin ve Always On erişilebilirlik gruplarının çevrimdışı olmasına neden olur, çünkü küme, yapılandırıldığı şekliyle, düğüm düzeyinde hata toleransını sağlayamıyor. Bir kvorum hatası, WSFC kümesindeki çalışır durumdaki oylama düğümlerinin artık kvorum modelini karşılamadığı anlamına gelir. Bazı düğümler tamamen başarısız olmuş olabilir ve bazıları ise yalnızca WSFC hizmetini kapatmış, quorum ile iletişim kurabilme yeteneğini kaybetmiş olmaları dışında sağlıklı durumda olabilir.

WSFC kümesini tekrar çevrimiçi hale getirmek için, mevcut yapılandırmada yeterlilik süresi arızasının temel nedenini düzeltmeli, etkilenen veritabanlarını gerektiğinde kurtarmalı ve WSFC kümesinde kalan düğümleri hayatta kalan küme topolojisini yansıtacak şekilde yeniden yapılandırmak isteyebilirsiniz.

Bir WSFC küme düğümündeki zorunlu yeterlilik prosedürünü kullanarak kümeyi çevrimdışı alan güvenlik kontrollerini geçersiz kılabilirsiniz. Bu, kümenin çoğunluk (quorum) oylama denetimlerini askıya almasını sağlar ve WSFC küme kaynaklarını ve SQL Server'ı kümedeki düğümlerin herhangi birinde yeniden çevrimiçi duruma getirmenize olanak tanır.

Bu tür bir felaket kurtarma süreci aşağıdaki adımları içermelidir:

Quorum Hatasından Kurtulmak İçin:

  1. Arızanın kapsamını belirleyin. Hangi erişilebilirlik gruplarının veya SQL Server örneklerinin yanıt vermediğini, hangi küme düğümlerinin çevrimiçi ve felaket sonrası kullanıma uygun olduğunu belirleyin ve Windows olay kayıtlarını ile SQL Server sistem kayıtlarını inceleyin. Mümkünse, daha sonra analiz için adli verileri ve sistem kayıtlarını saklamalısınız.

    Tip

    Yanıt veren bir SQL Server örneğinde, yerel sunucu örneğinde kullanılabilirlik replikasına sahip olan erişilebilirlik gruplarının sağlığı hakkında bilgi edinebilirsiniz; sys.dm_hadr_availability_group_states dinamik yönetim görüşü (DMV) sorgusu yapılabilir.

  2. WSFC kümesini tek bir düğümde zorunlu yeter kapasite kullanarak başlatın. WSFC küme hizmetinin kapatılması dışında, en az sayıda bileşen arızası olan bir düğümü belirleyin. Bu düğümün diğer düğümlerin çoğunluğuyla iletişim kurabildiğinden emin olun.

    Bu düğümde, zorunlu çoğunluk prosedürünü kullanarak kümeyi manuel olarak çevrimiçi duruma gelmeye zorlayın. Olası veri kaybını en aza indirmek için, en son erişilebilirlik grubu birincil replikasını barındıran bir düğümü seçin.

    Daha fazla bilgi için bkz. WSFC Kümesini Çoğunluk Olmadan Başlatmaya Zorlama

    Note

    Zorunlu yeter sayı ayarı, mantıksal WSFC kümesi oyların çoğunluğunu elde edene ve otomatik olarak normal yeter sayı çalışma moduna geçene kadar yeter sayı denetimlerini engelleyen küme genelinde bir etkiye sahiptir.

  3. WSFC hizmetini normal olarak sağlıklı olan her düğümde teker teker başlatın. Diğer düğümlerde küme hizmetini başlatırken zorunlu çoğunluk seçeneğini belirtmeniz gerekmez.

    Her düğümdeki WSFC servisi tekrar çevrimiçi olduğunda, diğer sağlıklı düğümlerle pazarlık yaparak yeni küme yapılandırma durumunu senkronize eder. Kümenin son bilinen durumunun belirlenmesinde ortaya çıkabilecek yarış koşullarını önlemek için, bunu her seferinde bir düğüm için yapmayı unutmayın.

    Warning

    Başladığınız her düğümün diğer yeni çevrimiçi düğümlerle iletişim kurabildiğinden emin olun. Diğer düğümlerde WSFC servisini devre dışı bırakmayı düşünün. Aksi takdirde, birden fazla quorum düğümü seti oluşturma riski taşır; Bu bölünmüş bir beyin senaryosu. Eğer birinci adımdaki bulgularınız doğruysa, bu olmamalıydı.

  4. Yeni kuvorum modu ve düğüm oyu yapılandırmasını uygulayın. Eğer quorum’u zorla başlatmak kümedeki tüm düğümleri başarıyla yeniden başlattıysa ve quorum hatasının temel nedeni düzeltildiyse, özgün quorum modu ve düğüm oy yapılandırmasında değişiklik yapılması gerekmez.

    Aksi takdirde, yeni kurtarılan küme düğümünü ve kullanılabilirlik replikası topolojisini değerlendirmeli ve her düğüm için yeterli kapasite modunu ve oy atamalarını uygun şekilde değiştirmelisiniz. Kurtarılmamış düğümler çevrimdışı olmalı veya düğüm oyları sıfıra ayarlanmalıdır.

    Tip

    Bu noktada, kümedeki düğümler ve SQL Server örnekleri normal çalıştığı gibi görünebilir. Ancak sağlıklı bir çoğunluk hâlâ mevcut olmayabilir. Failover Küme Yöneticisi, SQL Server Management Studio'daki Always On Dashboard veya uygun DMV'ler kullanılarak bir yeter kapasitenin geri getirildiğini doğrulayın.

  5. Kullanılabilirlik grubu veritabanı replikalarını gerektiğinde kurtarın. Erişilebilirlik olmayan grup veritabanları, normal SQL Server başlatma sürecinin bir parçası olarak kendi başlarına geri dönmeli ve yeniden çevrimiçi olmalıdır.

    Kullanılabilirlik grubu replikalarını bu dizide tekrar çevrimiçi hale getirerek olası veri kaybı ve kurtarma süresini en aza indirebilirsiniz: birincil replika, senkron ikincil replikalar, asenkron ikincil replikalar.

Note

Zorunlu yeter güç kullanıldıktan sonra, kullanılabilirlik grubunu tekrar çevrimiçi hale getirmek için olası veri kaybı nedeniyle zorunlu bir yedek devre yapmak gerekir. Daha fazla bilgi için, Bir erişilebilirlik grubunun (SQL Server) zorunlu manuel failover gerçekleştirmesini inceleyin.

  1. Arızalı bileşenleri tamir edin veya değiştirin ve kümeyi yeniden doğrulayın. Başlangıçtaki felaket durumundan ve quorum hatasından kurtulduktan sonra, arızalı düğümleri onarmalı ya da değiştirmeli ve ilgili WSFC ile Always On yapılandırmalarını buna göre ayarlamalısınız. Bu, kullanılabilirlik grubu replikalarının kaldırılması, düğümlerin kümeden çıkarılması veya yazılımın düzleştirilip bir düğüme yeniden yüklenmesini içerebilir.

    Tüm arızalı kullanılabilirlik replikalarını tamir etmeli veya kaldırmalısınız. SQL Server, işlem günlüğünü, en geride kalan erişilebilirlik replikasının son bilinen noktasından öteye kadar kesmez. Başarısız bir replika onarılmaz veya erişilebilirlik grubundan çıkarılmazsa, işlem kayıtları büyür ve diğer replikalarda işlem günlüğü alanı tükenme riski taşır.

    Note

    WSFC kümesinde kullanılabilirlik grubu dinleyicisi bulunduğunda WSFC Yapılandırma Büyücüsü Doğrulama Büyücüsü çalıştırılırsa, sihirbaz aşağıdaki yanlış uyarı mesajını oluşturur:

    "'Name:<network_name>' ağ adı için RegisterAllProviderIP özelliği 1 olarak ayarlandı Geçerli küme yapılandırması için bu değer 0 olarak ayarlanmalıdır."

    Lütfen bu iletiyi yoksayın.

  2. 4. adımı gerektiği gibi yineleyin. Amaç, sağlıklı operasyonlar için uygun hata toleransı ve yüksek erişilebilirlik seviyesini yeniden tesis etmektir.

  3. RPO/RTO analizi yapın. SQL Server sistem kayıtlarını, veritabanı zaman damgalarını ve Windows olay kayıtlarını analiz ederek arızanın kök nedenini belirlemeli ve gerçek kurtarma noktası ile recovery zaman deneyimlerini belgelemelisiniz.

İlgili Görevler

İlgili içerik

  • Last updated on