Utför en tvingad manuell överlämning av en Always On-tillgänglighetsgrupp (SQL Server)

gäller för:SQL Server

Den här artikeln beskriver hur du utför en tvingad redundansväxling (med möjlig dataförlust) i en AlwaysOn-tillgänglighetsgrupp med hjälp av SQL Server Management Studio, Transact-SQL eller PowerShell i SQL Server. En tvingad redundansväxling är en form av manuell redundans som är avsedd enbart för haveriberedskap, när en planerad manuell redundansväxling inte är möjlig. Om du tvingar övergång till en osynkroniserad sekundär replik är viss dataförlust möjlig. Därför rekommenderar vi starkt att du endast framtvingar redundansväxling om du måste återställa tjänsten till tillgänglighetsgruppen omedelbart och du är villig att riskera att förlora data.

Efter en tvingad överflyttning blir målsystemet som tillgänglighetsgruppen överflyttades till den nya primärreplikan. De sekundära databaserna i de återstående sekundära replikerna pausas och måste återupptas manuellt. När den tidigare primära repliken blir tillgänglig övergår den till den sekundära rollen, vilket gör att de tidigare primära databaserna blir sekundära databaser och övergår till SUSPENDED tillståndet. Innan du återupptar en viss sekundär databas kanske du kan återställa förlorade data från den. Observera dock att trunkering av transaktionsloggar fördröjs på en viss primär databas medan någon av dess sekundära databaser är avstängd.

Det är nödvändigt att utföra en tvingad redundansväxling i följande nödsituationer:

• När du har tvingat kvorum på WSFC-klustret (framtvingad kvorum) måste du framtvinga en failover för varje tillgänglighetsgrupp (med möjlig dataförlust). Att tvinga fram redundans krävs eftersom det verkliga tillståndet för WSFC-klustervärdena kan ha gått förlorat. Du kan dock undvika dataförlust om du kan tvinga fram en failover på den serverinstans som var värd för den primära repliken innan du aktiverade kvorum, eller till en sekundär replik som var synkroniserad innan du aktiverade kvorum. Mer information finns i Potentiella sätt att undvika dataförlust när kvorum har tvingats, senare i den här artikeln.

  Viktig

  Om kvorumet återfås på naturligt sätt istället för att forceras, genomgår tillgänglighetsreplikerna normal återhämtning. Om den primära repliken fortfarande är otillgänglig även efter att quorum har återställts, kan du utföra en manuell planerad övergång till en synkroniserad sekundär replik.

  Information om hur du tvingar kvorum finns i WSFC-haveriberedskap via forcerad kvorum (SQL Server). Information om varför tvingad redundans krävs efter att kvorum har tvingats fram finns i redundanslägen och redundanslägen (AlwaysOn-tillgänglighetsgrupper).

• Om den primära repliken blir otillgänglig när WSFC-klustret har ett felfritt kvorum kan du framtvinga failover (med möjlig dataförlust) till vilken replik som helst vars roll är i SECONDARY-tillståndet eller RESOLVING-tillståndet. Om möjligt framtvingar du redundans till en synkron-commit sekundär replik som synkroniserades när den primära repliken förlorades.

  Tips

  När WSFC-klustret har ett hälsosamt kvorum, om du utfärdar ett *force failover*-kommando på en synkroniserad sekundär replik, utför repliken faktiskt en planerad manuell failover.

Mer information om förutsättningar och rekommendationer för att tvinga redundans och ett exempelscenario som använder en tvingad redundansväxling för att återställa från ett oåterkalleligt fel finns i Exempelscenario: Använd en tvingad redundansväxling för att återställa från ett oåterkalleligt fel senare i den här artikeln.

Begränsningar

• Den enda gången du inte kan utföra en tvingad redundansväxling är när WSFC-klustret (Windows Server Failover Clustering) saknar kvorum.

• Dataförlust är möjlig i samband med en tvingad överflyttning av en tillgänglighetsgrupp. Om den primära repliken körs när du initierar en tvingad redundansväxling kan klienterna dessutom fortfarande vara anslutna till tidigare primära databaser. Därför rekommenderar vi starkt att du endast framtvingar redundansväxling om den primära repliken inte längre körs och om du är villig att riskera att förlora data för att återställa åtkomsten till databaser i tillgänglighetsgruppen.

• När en sekundär databas är i REVERTING- eller INITIALIZING-tillstånd, skulle en framtvingad övertagande leda till att databasen inte kan starta som en primär databas. Om databasen var i tillståndet INITIALIZING måste du tillämpa de saknade loggposterna från en databassäkerhetskopia eller helt återställa databasen från grunden. Om databasen var i tillståndet REVERTING måste du helt återställa databasen från säkerhetskopior.

• Ett redundanskommando returneras så snart redundansmålet har godkänt kommandot. Databasåterställning sker dock asynkront när tillgänglighetsgruppen är klar med redundansväxlingen.

• Konsekvens mellan databaser i tillgänglighetsgruppen kanske inte underhålls vid växling.

  Not

  Stöd för transaktioner mellan databaser och distribuerade transaktioner varierar beroende på versionerna av SQL Server och operativsystemet. Mer information finns i Transaktioner – tillgänglighetsgrupper och databasspegling.

Förutsättningar

• WSFC-klustret har kvorum. Om klustret saknar kvorum, se havariåterställning för WSFC genom forcerad kvorum (SQL Server).

• Du måste kunna ansluta till en serverinstans som är värd för en replik vars roll är i SECONDARY tillståndet eller RESOLVING.

Rekommendationer

• Tvinga inte övergång medan den primära kopian fortfarande körs.

• Om möjligt tvingar du endast redundans till ett redundansmål vars sekundära databaser antingen är i NOT SYNCHRONIZEDtillståndet , SYNCHRONIZEDeller SYNCHRONIZING . För information om konsekvenserna av att tvinga redundans när en sekundär databas är i tillståndet INITIALIZING eller REVERTING, se Begränsningar tidigare i den här artikeln.

• Normalt bör svarstiden för en viss sekundär databas, i förhållande till den primära databasen, vara liknande på olika asynkrona sekundära repliker. Men när du tvingar fram en failover kan dataförlust vara ett stort problem. Överväg därför att ta tid att fastställa den relativa svarstiden för kopiorna av databaserna på olika sekundära repliker. Om du vill ta reda på vilken kopia av en viss sekundär databas som har minst svarstid jämför du deras LSN i slutet av loggen. En högre LSN i slutet av loggen anger mindre svarstid.

  Tips

  Om du vill jämföra LSN:er i slutet av loggen ansluter du till varje sekundär onlinereplik och frågar end_of_log_lsn efter värdet för varje lokal sekundär databas. Jämför sedan LSN:erna för slutet av loggen för de olika kopiorna av varje databas. Olika databaser kan ha sina högsta LSN på olika sekundära repliker. I det här fallet beror det lämpligaste redundansmålet på den relativa betydelse som du lägger på data i de olika databaserna. Vilket av dessa databaser vill du minimera möjliga dataförluster för?

• Om klienter kan ansluta till den ursprungliga primära kan en tvingad omkoppling medföra en viss risk för splitbrain-beteende. Innan du tvingar fram redundans rekommenderar vi starkt att du hindrar klienter från att komma åt den ursprungliga primära repliken. När övertagningen har tvingats kan de ursprungliga och aktuella primära databaserna uppdateras oberoende av de andra.

Möjliga sätt att undvika dataförlust efter att quorum har tvingats

Under vissa felförhållanden när kvorumet har gått förlorat kan du förhindra dataförlust på följande sätt:

• Om den ursprungliga primära repliken är online

  Om kvorum går förlorat och tvingar WSFC-kvorumet att återställa klusternoden som är värd för den primära repliken för en tillgänglighetsgrupp, kan du förhindra dataförlust för den här tillgänglighetsgruppen. Anslut till den primära repliken och utför en tvingad failover (FAILOVER_ALLOW_DATA_LOSS). Detta gör att den primära repliken är online igen. Eftersom du utför den tvingade övergången till den ursprungliga primära repliken sker ingen dataförlust.

• Om en synkroniserad sekundär replik med synkron incheckning kommer online

  Om kvorum går förlorat och därmed tvingar WSFC-kvorumet att återställa en klusternod som är värd för den synkroniserade sekundära repliken i tillgänglighetsgruppen, bör du kunna förhindra dataförlust för denna tillgänglighetsgrupp. Om den återställda noden var igång när kvorumet gick förlorat kan du avgöra om det finns risk för dataförlust i en viss databas genom att fråga efter kolumnen i is_failover_readysys.dm_hadr_database_replica_cluster_states dynamisk hanteringsvy. För en serverinstans med namnet sql108w2k8r22utfärdar du till exempel följande fråga:

  SELECT *
  FROM sys.dm_hadr_database_replica_cluster_states
  WHERE replica_id = (
      SELECT replica_id
      FROM sys.availability_replicas
      WHERE replica_server_name = 'sql108w2k8r22'
  );
  

  Försiktighet

  Om den återställda noden inte var uppe när kvorumet förlorades kan is_failover_ready kanske inte återspegla klustrets verkliga tillstånd när den primära replikan gick offline. Därför is_failover_ready är värdet bara bra om värdnoden vid tidpunkten för felet. För mer information, se "Varför tvingad omkoppling krävs efter att kvorum har tvingats fram" i omkoppling och omkopplingslägen (Always On tillgänglighetsgrupper).

  Om is_failover_ready = 1 är uppfyllt markeras databasen som synkroniserad i klustret och är redo för en redundansväxling. Om du på varje databas på en given sekundär replik kan utföra en tvingad failover (FORCE_FAILOVER_ALLOW_DATA_LOSS) utan dataförlust på denna sekundära replik. Den synkroniserade sekundära repliken är online i den primära rollen, dvs. som den nya primära repliken, med alla data intakta.

  Om is_failover_ready = 0 är databasen markerad som icke-synkroniserad i klustret och inte redo för en planerad manuell övergång. Om du tvingar en failover till den sekundära värdrepliken, förloras data i denna databas.

  Not

  När du tvingar överflyttning till en sekundär instans beror mängden dataförlust på hur långt överflyttningsmålet släpar efter den primära instansen. Tyvärr, när WSFC-klustret saknar kvorum eller när kvorum har tvingats, kan du inte bedöma mängden potentiell dataförlust. Observera dock att när WSFC-klustret återfår ett felfritt kvorum kan du börja spåra potentiell dataförlust. Mer information finns i "Spåra potentiell dataförlust" i redundans och redundanslägen (Always On-tilgänglighetsgrupper).

Behörigheter

Kräver ALTER AVAILABILITY GROUP behörighet för tillgänglighetsgruppen, CONTROL AVAILABILITY GROUP behörigheten, ALTER ANY AVAILABILITY GROUP behörigheten eller CONTROL SERVER behörigheten.

Använda SQL Server Management Studio

1. I Object Explorer ansluter du till en serverinstans som är värd för en replik vars roll är i SECONDARY- eller RESOLVING-läget i tillgänglighetsgruppen som måste växlas över, och expanderar serverträdet.

2. Expandera noden Always On High Availability och noden Tillgänglighetsgrupper.

3. Högerklicka på tillgänglighetsgruppen som ska överväxlas och välj kommandot Växla över.

4. Det här startar guiden för Failover-tillgänglighetsgruppen. Mer information finns i Använda guiden För redundansväxlingstillgänglighetsgrupp (SQL Server Management Studio).

5. När du har tvingat en tillgänglighetsgrupp att växla över, slutför du de nödvändiga uppföljningsstegen. Mer information finns i Uppföljning: Viktiga uppgifter efter en tvingad felövergång, senare i den här artikeln.

Använd Transact-SQL

1. Anslut till en serverinstans som är värd för en replik vars roll är i tillståndet SECONDARY eller RESOLVING i tillgänglighetsgruppen som behöver genomgå en failover.

2. Använd ALTER AVAILABILITY GROUP-instruktionen , enligt följande, där group_name är namnet på tillgänglighetsgruppen:

   ALTER AVAILABILITY GROUP <group_name> FORCE_FAILOVER_ALLOW_DATA_LOSS.

   I följande exempel tvingas tillgänglighetsgruppen AccountsAG att växla över till den lokala sekundära repliken.

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

3. När du har tvingat en tillgänglighetsgrupp att växla över, slutför du de nödvändiga uppföljningsstegen. Mer information finns i Viktiga uppgifter efter en tvingad systemövergång, senare i den här artikeln.

Använda PowerShell

1. Byt katalog (cd) till en serverinstans som värdar en replik med en roll som är i tillståndet SECONDARY eller RESOLVING i tillgänglighetsgruppen som behöver växlas över.

2. Använd cmdleten Switch-SqlAvailabilityGroup med parametern AllowDataLoss i något av följande formulär:

   • -AllowDataLoss

     Som standardinställning orsakar parametern -AllowDataLoss att Switch-SqlAvailabilityGroup uppmanar dig att komma ihåg att tvungen redundansväxling kan leda till förlust av obekräftade transaktioner samt att begära bekräftelse. Om du vill fortsätta anger du Y; om du vill avbryta åtgärden anger du N.

     I följande exempel utförs en tvingad failover (med möjlig dataförlust) till den sekundära repliken av tillgänglighetsgruppen MyAg på serverinstansen med namnet SecondaryServer\InstanceName. Du uppmanas att bekräfta den här åtgärden.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss
     

   • -AllowDataLoss-Force

     Om du vill initiera en tvingad failover utan bekräftelse anger du både parametrarna -AllowDataLoss och -Force. Detta är användbart om du vill inkludera kommandot i ett skript och köra det utan användarinteraktion. Använd dock alternativet -Force med försiktighet eftersom en tvingad redundansväxling kan leda till förlust av data från databaser som deltar i tillgänglighetsgruppen.

     I följande exempel utförs en tvingad redundansväxling (med möjlig dataförlust) av tillgänglighetsgruppen MyAg till serverinstansen med namnet SecondaryServer\InstanceName. Alternativet -Force undertrycker bekräftelsen av den här åtgärden.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss -Force
     

   Not

   Om du vill visa syntaxen för en cmdlet använder du cmdleten Get-Help i SQL Server PowerShell-miljön. Mer information finns i Hämta hjälp för SQL Server PowerShell.

3. När du har tvingat en tillgänglighetsgrupp att växla över, slutför du de nödvändiga uppföljningsstegen. För mer information, se Uppföljning: Viktiga uppgifter efter en tvingad övertagning, senare i den här artikeln.

Konfigurera och använda SQL Server PowerShell-providern

• SQL Server PowerShell-Provider

Uppföljning: Viktiga uppgifter efter en tvungen övergång till reservsystem

1. Efter ett tvingat felövergång blir den sekundära repliken som du växlade över till den nya primära repliken. För att göra tillgänglighetsrepliken tillgänglig för klienter kan du dock behöva konfigurera om WSFC-kvorumet eller justera tillgänglighetsgruppens konfiguration av tillgänglighetsläget på följande sätt:

   • Om du utförde redundansväxling utanför den automatiska redundansuppsättningen: Justera kvorumrösterna för WSFC-noderna så att de återspeglar den nya konfigurationen av din tillgänglighetsgrupp. Om WSFC-noden som värdar den sekundära målrepliken inte har en WSFC-kvorumröstning kan du behöva tvinga fram ett WSFC-kvorum.

     En automatisk redundansuppsättning finns bara om två tillgänglighetsrepliker (inklusive den tidigare primära repliken) har konfigurerats för synkront incheckningsläge med automatisk redundans.

     Justera kvorumröster

     • Visa nodviktsinställningar för klusterkvorum
     • Konfigurera nodviktsinställningar för klusterkvorum
     • Tvinga ett WSFC-kluster att starta utan kvorum

   • Om du växlat över utanför failover-uppsättningen för synkron commit: Vi rekommenderar att du överväger att justera tillgänglighetsläget och failover-läget på den nya primära repliken och på återstående sekundära repliker för att återspegla önskad synkron commit och automatisk failoverkonfiguration.

     Not

     Det finns bara en redundansuppsättning för synkron incheckning om den aktuella primära repliken har konfigurerats för synkront incheckningsläge.

     Ändra tillgänglighetsläge och redundansläge

     • Ändra tillgänglighetsläget för en replik i en AlwaysOn-tillgänglighetsgrupp
     • Ändra redundansläget för en replik i en AlwaysOn-tillgänglighetsgrupp

2. Efter en tvingad överflyttning pausas alla sekundära databaser. Detta omfattar de tidigare primära databaserna, efter att den tidigare primära repliken kommer online igen och upptäcker att den nu är en sekundär replik. Du måste återuppta varje pausad databas manuellt individuellt på varje sekundär replik.

   När en sekundär databas återupptas initieras datasynkronisering med motsvarande primära databas. Den sekundära databasen återställer alla loggposter som aldrig har bekräftats i den nya primära databasen. Om du är orolig för eventuell dataförlust på de primära databaserna efter att överföringen till en sekundär databas har misslyckats bör du därför försöka skapa en ögonblicksbild av databasen på de databaser som är i pausat läge i en av de sekundära databaserna med synkron commit.

   Viktig

   Trunkering av transaktionsloggar fördröjs på en primär databas medan någon av dess sekundära databaser pausas. Statusen för synkronisering av en sekundär replik med synkront åtagande kan inte heller övergå till HEALTHY så länge någon lokal databas förblir inaktiv.

   Skapa en databasögonblicksbild

   • Skapa en ögonblicksbild av databasen (Transact-SQL)

   Så här återupptar du en tillgänglighetsdatabas

   • Återuppta en tillgänglighetsdatabas (SQL Server)

   Försiktighet

   Efter att ha återupptagit alla sekundära databaser, innan du försöker att återigen genomföra en failover av gruppen, vänta tills varje sekundär databas på nästa failover-mål går in i SYNCHRONIZING -tillståndet. Om någon databas ännu inte är SYNCHRONIZING förhindras den från att komma online som en primär databas, och för att återupprätta datasynkronisering kan det krävas återställning av transaktionsloggar, återställning av en fullständig databassäkerhetskopia eller växling tillbaka till den tidigare primära repliken.

3. Om en tillgänglighetsreplik som misslyckades inte återgår till tillgänglighetsrepliken eller kan komma tillbaka för sent för att fördröja trunkeringen av transaktionsloggen på den nya primära databasen kan du överväga att ta bort den misslyckade repliken från tillgänglighetsgruppen för att undvika att diskutrymmet för loggfilerna tar slut.

   Ta bort en sekundär replik

   • Ta bort en sekundär replik från en tillgänglighetsgrupp (SQL Server)

4. Om du följer en tvingad redundansväxling med en eller flera ytterligare framtvingade redundansväxlingar utför du en loggsäkerhetskopia efter varje ytterligare tvingad redundansväxling i serien. Information om orsaken till detta finns i "Risker med att tvinga redundans" i avsnittet "Tvingad manuell redundans (med möjlig dataförlust)" i redundans- och redundanslägen (AlwaysOn-tillgänglighetsgrupper).

   Så här utför du en loggsäkerhetskopia

   • Säkerhetskopiera en transaktionslogg

Exempelscenario: Använd en tvingad redundansväxling för att återställa från ett oåterkalleligt fel

Om den primära repliken misslyckas och ingen synkroniserad sekundär replik är tillgänglig kan det vara ett lämpligt svar att tvinga över tillgänglighetsgruppen till en failover. Lämpligheten för att tvinga fram en redundansväxling beror på: (1) om du förväntar dig att den primära repliken ska vara offline längre än vad ditt serviceavtal (SLA) tolererar, och (2) om du är villig att riskera potentiell dataförlust för att göra primära databaser tillgängliga snabbt. Om du bestämmer dig för att en tillgänglighetsgrupp kräver en tvingad redundansväxling är den faktiska framtvingade redundansväxlingen bara ett steg i en process i flera steg.

För att illustrera de steg som krävs för att använda en tvingad failover för att återhämta sig från ett katastrofalt fel presenterar den här artikeln ett möjligt återställningsscenario. Exempelscenariot tar hänsyn till en tillgänglighetsgrupp vars ursprungliga topologi består av ett huvuddatacenter som är värd för tre synkrona tillgänglighetsrepliker, inklusive den primära repliken och ett fjärrdatacenter som är värd för två asynkrona sekundära repliker. Följande bild illustrerar den ursprungliga topologin för den här exempeltillgänglighetsgruppen. Tillgänglighetsgruppen hanteras av ett WSFC-kluster med flera undernät med tre noder i huvuddatacentret (Node 01, Node 02och Node 03) och två noder i ett fjärranslutet datacenter (Node 04 och Node 05).

Huvuddatacentret stängs oväntat av. Deras tre tillgänglighetsrepliker går offline, och deras databaser blir otillgängliga. Följande bild illustrerar effekten av det här felet på tillgänglighetsgruppens topologi.

Databasadministratören (DBA) fastställer att det bästa möjliga svaret är att tvinga en failover av tillgänglighetsgruppen till en av de fjärranslutna, asynkront commit sekundära replikerna. Det här exemplet illustrerar de typiska stegen när du tvingar fram överflyttning av tillgänglighetsgruppen till en fjärrreplik och till sist återställer tillgänglighetsgruppen till dess ursprungliga topologi.

Felsvaret som visas här består av följande två faser:

• Svara på det katastrofala felet i huvuddatacentret
• Returnera tillgänglighetsgruppen till den ursprungliga topologin

Svara på det katastrofala felet i huvuddatacentret

Följande bild visar serien med åtgärder som utförs i fjärrdatacentret som svar på ett oåterkalleligt fel i huvuddatacentret.

Stegen i den här bilden anger följande steg:

Returnera tillgänglighetsgruppen till den ursprungliga topologin

Följande bild illustrerar de åtgärder som returnerar tillgänglighetsgruppen till den ursprungliga topologin när huvuddatacentret är online igen och WSFC-noderna återupprättar kommunikationen med WSFC-klustret.

Stegen i den här bilden anger följande steg:

Relaterade uppgifter

Justera kvorumröster

• Visa nodviktsinställningar för klusterkvorum
• Konfigurera nodviktsinställningar för klusterkvorum
• Tvinga ett WSFC-kluster att starta utan kvorum

Planerad manuell omställning

• Utföra en planerad manuell redundansväxling av en AlwaysOn-tillgänglighetsgrupp (SQL Server)
• Använd guiden Växla över till en Tillgänglighetsgrupp (SQL Server Management Studio)

Felsökning

• Felsöka Konfiguration av AlwaysOn-tillgänglighetsgrupper (SQL Server)
• Felsöka en misslyckad Add-File åtgärd (Always On-tillgänglighetsgrupper)

Relaterat innehåll

• SQL Server Always On Team-bloggar: Den officiella SQL Server Always On Team-bloggen
• CSS SQL Server Engineers-bloggar
• Microsoft SQL Server Always On Solutions Guide för hög tillgänglighet och katastrofåterställning
• Vad är en AlwaysOn-tillgänglighetsgrupp?
• Skillnader mellan tillgänglighetslägen för en AlwaysOn-tillgänglighetsgrupp
• Failover och failover-lägen (Always On-tilgänglighetsgrupper)
• Typer av klientanslutningar till repliker i en AlwaysOn-tillgänglighetsgrupp
• Verktyg för att övervaka AlwaysOn-tillgänglighetsgrupper
• Windows Server-redundansklustring med SQL Server