WSFC-haveriberedskap med hjälp av framtvingad kvorummajoritet (SQL Server)

Gäller för:SQL Server

Kvorumfel orsakas vanligtvis av en systemkatastrof, ett ihållande kommunikationsfel eller en felkonfiguration som involverar flera noder i WSFC-klustret. Manuell intervention krävs för att återhämta sig från ett beslutsmässigt misslyckande.

Förutsättningar

Forced Quorum-proceduren antar att ett hälsosamt quorum existerade före quorummisslyckandet.

Varning

Användaren bör vara väl insatt i koncepten och interaktionerna kring Windows Server Failover Clustering, WSFC Quorum Models, SQL Server och miljöns specifika distributionskonfiguration.

För mer information, se: Windows Server Failover Clustering (WSFC) med SQL Server, WSFC-kvorumlägen och röstningskonfiguration (SQL Server)

Security

Användaren måste vara ett domänkonto som tillhör den lokala administratörsgruppen på varje nod i WSFC-klustret.

WSFC:s katastrofåterhämtning genom den tvingade kvorumproceduren

Kom ihåg att quorum-fel kommer att göra att alla klustrade tjänster, SQL Server-instanser och Always On-tillgänglighetsgrupper i WSFC-klustret sätts offline, eftersom klustret, som konfigurerat, inte kan säkerställa nodnivå-feltolerans. Ett kvorumfel innebär att fungerande röstberättigade noder i WSFC-klustret inte längre uppfyller kvorummodellen. Vissa noder kan ha misslyckats helt, och vissa kan ha stängt ner WSFC-tjänsten och är i övrigt friska, förutom förlusten av förmågan att kommunicera med ett quorum.

För att få WSFC-klustret online igen måste du korrigera grundorsaken till quorumsfelet under den befintliga konfigurationen, återställa de berörda databaserna vid behov, och du kan vilja omkonfigurera de återstående noderna i WSFC-klustret för att spegla den överlevande klustertopologin.

Du kan använda den tvingade kvorumproceduren på en WSFC-klusternod för att åsidosätta säkerhetskontrollerna som tog klustret offline. Detta innebär i praktiken att klustret tillfälligt stänger av kontrollerna för kvorumomröstning och låter dig ta WSFC-klusterresurserna och SQL Server i drift igen på valfri nod i klustret.

Denna typ av katastrofåterställningsprocess bör inkludera följande steg:

För att återhämta sig från kvorummisslyckande:

  1. Fastställ omfattningen av felet. Identifiera vilka tillgänglighetsgrupper eller SQL Server-instanser som inte svarar, vilka klusternoder som är online och tillgängliga för användning efter katastrofer, och granska Windows händelseloggar och SQL Server-systemloggar. Där det är praktiskt bör du bevara forensiska data och systemloggar för senare analys.

    Tip

    På en responsiv instans av SQL Server kan du få information om hälsan hos tillgänglighetsgrupper som har en tillgänglighetsreplika på den lokala serverinstansen genom att fråga sys.dm_hadr_availability_group_states dynamic management view (DMV).

  2. Starta WSFC-klustret genom att använda tvingat kvorum på en enda nod. Identifiera en nod med ett minimalt antal komponentfel, förutom att WSFC-klustertjänsten stängdes ner. Verifiera att denna nod kan kommunicera med majoriteten av de andra noderna.

    På den här noden framtvingar du manuellt att klustret går online med hjälp av proceduren för tvingat kvorum. För att minimera potentiell dataförlust, välj en nod som senast var värd för en primär tillgänglighetsgruppsreplika.

    För mer information, se: Tvinga ett WSFC-kluster att starta utan kvorum

    Note

    Den tvingade kvoruminställningen har en klusteromfattande effekt att blockera kvorumkontroller tills det logiska WSFC-klustret får majoritet av rösterna och automatiskt övergår till ett vanligt kvorumläge.

  3. Starta WSFC-tjänsten normalt på varje annars frisk nod, en i taget. Du behöver inte ange det tvingade kvorumalternativet när du startar klustertjänsten på de andra noderna.

    När WSFC-tjänsten på varje nod kommer online igen förhandlar den med de andra felfria noderna för att synkronisera det nya tillståndet för klusterkonfigurationen. Kom ihåg att göra detta en nod i taget för att förhindra potentiella kapplöpningstillstånd när klustrets senast kända tillstånd fastställs.

    Varning

    Se till att varje nod du startar kan kommunicera med de andra nyligen uppkopplade noderna. Överväg att inaktivera WSFC-tjänsten på de andra noderna. Annars riskerar du att skapa mer än en uppsättning av kvorumnoder; det är ett split-brain-scenario. Om dina slutsatser i steg 1 var korrekta borde detta inte ske.

  4. Tillämpa nytt kvorumläge och nodomröstningskonfiguration. Om tvingande kvorum framgångsrikt startade om alla noder i klustret och grundorsaken till kvorummisslyckandet har åtgärdats, är ändringar i det ursprungliga kvorumläget och nodomröstningskonfigurationen onödiga.

    Annars bör du utvärdera den nyligen återvunna klusternoden och tillgänglighetsreplikatopologin samt ändra kvorumläget och röstfördelningen för varje nod efter behov. Noder som inte återhämtas bör vara offline eller ha sina nodröster satt till noll.

    Tip

    Vid denna punkt kan noderna och SQL Server-instanserna i klustret verka återställda till normal drift. Men ett hälsosamt quorum kanske fortfarande inte existerar. Använd Failover Cluster Manager, Always On-instrumentpanelen i SQL Server Management Studio eller relevanta DMV:er för att verifiera att ett quorum har återställts.

  5. Återställ tillgänglighetsgruppsdatabaskopior vid behov. Databaser som inte ingår i tillgänglighetsgrupper bör återhämta sig och bli tillgängliga igen av sig själva som en del av den normala startprocessen för SQL Server.

    Du kan minimera potentiell dataförlust och återställningstid för tillgänglighetsgruppens repliker genom att ta dem online igen i denna sekvens: primär replik, synkrona sekundära repliker, asynkrona sekundära repliker.

Note

Efter att ha använt tvingat quorum är det nödvändigt att utföra en tvingad failover med möjlig dataförlust för att återställa tillgänglighetsgruppen online. För mer information, se Utföra en framtvingad manuell redundansväxling av en tillgänglighetsgrupp (SQL Server).

  1. Reparera eller byt ut defekta komponenter och validera klustret på nytt. Nu när du har återhämtat dig från den initiala katastrofen och quorum-felet bör du reparera eller byta ut de trasiga noderna och justera relaterade WSFC- och Always On-konfigurationer därefter. Detta kan innefatta att ta bort repliker i en tillgänglighetsgrupp, avlägsna noder från klustret eller rensa och installera om programvaran på en nod.

    Du måste reparera eller ta bort alla defekta tillgänglighetsrepliker. SQL Server kommer inte att trunkera transaktionsloggen förbi den senast kända punkten för den tillgänglighetsreplik som ligger längst efter. Om en misslyckad replika inte repareras eller tas bort från tillgänglighetsgruppen kommer transaktionsloggarna att växa och du riskerar att få slut på transaktionsregisterutrymme på de andra replikerna.

    Note

    Om du kör WSFC Validate a Configuration Wizard när en tillgänglighetsgruppslyssnare finns på WSFC-klustret, genererar guiden följande felaktiga varningsmeddelande:

    "Egenskapen RegisterAllProviderIP för nätverksnamnet "Name:<network_name>" är inställd på 1 För den aktuella klusterkonfigurationen ska det här värdet anges till 0."

    Ignorera det här meddelandet.

  2. Upprepa steg 4 efter behov. Målet är att återupprätta rätt nivå av feltolerans och hög tillgänglighet för sund verksamhet.

  3. Genomför RPO/RTO-analys. Du bör analysera SQL Server-systemloggar, databastidsstämplar och Windows-händelseloggar för att fastställa grundorsaken till felet och dokumentera faktiska återställningspunkter och återställningstider.

Relaterade uppgifter

Relaterat innehåll

  • Last updated on