Dela via

Utföra en tvingad manuell redundansväxling av en AlwaysOn-tillgänglighetsgrupp (SQL Server)

  • Artikel

gäller för:SQL Server

Det här avsnittet 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 tillståndet SUSPENDED. 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.

Viktig

Datasynkronisering med den primära databasen sker inte förrän den sekundära databasen återupptas. För att återuppta en sekundär databas, se Uppföljning: Viktiga uppgifter efter en tvingad omkoppling längre fram i artikeln.

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 överflyttning på den serverinstans som var värd för huvudreplikan innan du tvingade kvorum, eller till en sekundär replik som synkroniserades innan du tvingade kvorum. För mer information, se Potentiella sätt att undvika dataförlust när kvorum tvingas, senare i det här avsnittet.

    Viktig

    Om kvorumet återställs på naturlig väg snarare än genom tvång kommer tillgänglighetskopiorna att genomgå normal återställning. 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 friskt kvorum kan du framtvinga en omställning (med möjlig dataförlust) till en replik vars roll är i tillståndet SEKUNDÄR eller RESOLVERING. 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.

Not

Mer information om förutsättningarna och rekommendationerna för att tvinga övergång och ett exempelscenario som använder en tvingad övergång för att återhämta sig från ett katastrofalt fel finns i Exempelscenario: Använda en tvingad övergång för att återhämta sig från ett katastrofalt fel, senare i denna text.

Begränsningar och restriktioner

  • 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 tvingar fram en failover om den primära repliken inte längre körs och om du är villig att riskera dataförlust för att återfå åtkomst till databaserna i tillgänglighetsgruppen.

  • När en sekundär databas är i tillståndet REVERTING eller INITIALIZING skulle det leda till att databasen inte startas som en primär databas om redundansväxlingen framtvingas. Om databasen var i tillståndet INITIALIZING måste du använda de saknade loggposterna från en databassäkerhetskopia eller återställa databasen helt från grunden. Om databasen var i ett återgående tillstånd måste du återställa databasen helt 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. För mer information, se Transaktioner mellan databaser och distribuerade transaktioner för Always On-tillgänglighetsgrupper och databasspegling (SQL Server).

Förutsättningar

Rekommendationer

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

  • Om möjligt framtvingar du endast redundans till ett redundansmål vars sekundära databaser antingen är i tillståndet INTE SYNKRONISERAD, SYNKRONISERAD eller SYNKRONISERING. Information om konsekvenserna av att tvinga övergång när en sekundär databas är i tillståndet INITIALISERING eller ÅTERSTÄLLNING finns i Begränsningar och inskränkningartidigare i detta avsnitt.

  • 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, anslut till varje online sekundär replik i tur och ordning och fråga efter sys.dm_hadr_database_replica_states för värdet av end_of_log_lsn i varje lokal sekundär databas. Jämför sedan LSN:erna för slutet av loggen för de olika kopiorna av varje databas. Observera att 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 när kvorum tvingas fram

Under vissa feltillstånd när kvorumet har gått förlorat kan du undvika att data går förlorade 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 tvungna övergången till den 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 aktiv när kvorum gick förlorat kan du avgöra om dataförlust kan inträffa på en viss databas genom att fråga efter kolumnen is_failover_ready i den dynamiska hanteringsvyn sys.dm_hadr_database_replica_cluster_states. 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ällde noden inte var uppe när kvorumet förlorades kanske is_failover_ready inte återspeglar klustrets faktiska tillstånd när den primära repliken gick offline. Därför är is_failover_ready-värdet endast relevant om det gäller 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 markeras databasen som synkroniserad i klustret och är redo för en failover. Om is_failover_ready = 1 på varje databas på en viss sekundär replik kan du utföra en tvingad redundansväxling (FORCE_FAILOVER_ALLOW_DATA_LOSS) utan dataförlust på den här sekundära repliken. 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 markeras inte databasen som synkroniserad i klustret och är inte redo för en planerad manuell redundansväxling. Om du tvingar redundans till den sekundära värdrepliken går data förlorade på den här databasen.

    Not

    När du tvingar fram överflyttning till en sekundär replik beror mängden dataförlust på hur mycket överflyttningsmålet släpar efter den primära repliken. 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 ändringstillstånd för tillgänglighetsgruppen, kontrolltillstånd för tillgänglighetsgrupp, tillstånd att ändra alla tillgänglighetsgrupper, eller kontrolltillstånd för servern.

Använda SQL Server Management Studio

Tvinga fram failover (med möjlig dataförlust)

  1. I Object Explorer ansluter du till en serverinstans som är värd för en replik vars roll är i tillstånden SECONDARY eller RESOLVING i tillgänglighetsgruppen som behöver genomgå ett failover, 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 övergång, senare i detta avsnitt.

Använda Transact-SQL

Framtvinga failover (med möjlig dataförlust)

  1. Anslut till en serverinstans som är värd för en replik vars roll befinner sig i tillståndet SEKUNDÄR eller LÖSNING i tillgänglighetsgruppen som måste överlåtas.

  2. Använd instruktionen ALTER AVAILABILITY GROUP enligt följande:

    ÄNDRA GROUP_NAME FORCE_FAILOVER_ALLOW_DATA_LOSS FÖR TILLGÄNGLIGHETSGRUPP

    där group_name är namnet på tillgänglighetsgruppen.

    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 bör du slutföra de nödvändiga uppföljningsstegen. Mer information finns i Uppföljning: Viktiga uppgifter efter en tvingad redundansväxling, senare i det här avsnittet.

Använda PowerShell

Framtvinga redundans (med möjlig dataförlust)

  1. Ändra katalog (cd) till en serverinstans som är värd för en replik vars roll är i tillståndet SEKUNDÄR eller LÖSNING 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 standard parametern -AllowDataLoss gör att Switch-SqlAvailabilityGroup uppmanar dig att påminna dig om att tvingad redundansväxling kan leda till förlust av ej bekräftade transaktioner och 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 redundans utan bekräftelse anger du 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 redundansväxla slutför du de nödvändiga uppföljningsstegen. Mer information finns i Uppföljning: Viktiga uppgifter efter en tvingad failoversenare i det här avsnittet.

Konfigurera och använda SQL Server PowerShell-providern

Uppföljning: Viktiga uppgifter efter en tvingad ö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:

  2. Efter en tvingad överflyttning pausas alla sekundära databaser. Detta inkluderar de tidigare primära databaserna, efter att den tidigare primära repliken kommer tillbaka online 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 för de primära databaserna efter failover-processen bör du därför försöka skapa en databasögonblicksbild på de pausade databaserna på en av de synkron commit sekundära databaserna.

    Viktig

    Trunkering av transaktionsloggar fördröjs på en primär databas medan någon av dess sekundära databaser pausas. Synkroniseringshälsan för en sekundär replik med synkron commit kan inte övergå till HEALTHY så länge en lokal databas är avstängd.

    Skapa en databasögonblicksbild

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

    Försiktighet

    När du har återupptagit alla sekundära databaser, innan du försöker växla över gruppen igen, väntar du på att varje sekundär databas på nästa redundansmål ska gå in i tillståndet SYNCHRONIZING. Om någon databas ännu inte synkroniseras förhindras den databasen från att komma online som en primär databas, och om datasynkronisering för databasen återupprättas kan det kräva att transaktionsloggar återställs, en fullständig databassäkerhetskopia återställs eller att den återställs till den tidigare primära repliken.

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

    Ta bort en sekundär replik

  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

Exempelscenario: Använda 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. Hur lämpligt det ä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 det här avsnittet ett möjligt katastrofå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).

Ursprunglig topologi för tillgänglighetsgrupp

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.

topologi efter fel i huvuddatacentret

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

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

steg för att svara på fel i huvuddatacentret

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

Steg Handling Länkar
1. DBA eller nätverksadministratören ser till att WSFC-klustret har ett felfritt kvorum. I det här exemplet måste kvorum tvingas fram. WSFC-kvorumlägen och röstningskonfiguration (SQL Server)

WSFC-katastrofåterställning genom tvingat kvorum (SQL Server)
2. DBA ansluter till serverinstansen med minst latens (på Node 04) och utför en tvingad manuell övertagning. Den framtvingade övergången överför den här sekundära repliken till den primära rollen och suspenderar de sekundära databaserna på den återstående sekundära repliken (på Node 05). sys.dm_hadr_database_replica_states (Transact-SQL) (Fråga efter kolumnen end_of_log_lsn. Mer information finns i Rekommendationer, tidigare i det här avsnittet.)
3. DBA återupptar var och en av de sekundära databaserna manuellt på den återstående sekundära repliken. Återuppta en tillgänglighetsdatabas (SQL Server)

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.

Viktig

Om WSFC-klusterkvorumet har tvingats, när offlinenoderna startar om, kan de bilda ett nytt kvorum om följande villkor är uppfyllda: (a) det inte finns någon nätverksanslutning mellan någon av noderna i uppsättningen med tvingat kvorum, och (b) de omstartande noderna är majoriteten av klusternoderna. Detta skulle resultera i ett "delat hjärntillstånd" där tillgänglighetsgruppen skulle ha två oberoende primära repliker, en i varje datacenter. Innan du tvingar kvorumet att skapa en minoritetskvorumuppsättning kan du läsa WSFC Disaster Recovery through Forced Quorum (SQL Server).

Steg för att returnera gruppen till den ursprungliga topologin

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

Steg Länkar
1. Noderna i huvuddatacentret är online igen och återupprättar kommunikationen med WSFC-klustret. Deras tillgänglighetsrepliker kommer online som sekundära repliker med pausade databaser, och databasadministratören måste snart återuppta var och en av dessa databaser manuellt. Återuppta en tillgänglighetsdatabas (SQL Server)

Tips: Om du är orolig för eventuell dataförlust på de primära databaserna efter failover bör du försöka skapa en ögonblicksbild av databasen på de pausade databaserna på en av de synkroniserade-kommitterade sekundära databaserna. Tänk på att trunkeringen av transaktionsloggen fördröjs på en primär databas medan någon av dess sekundära databaser avbryts. Synkroniseringshälsan för den sekundära repliken med synkron commit kan inte övergå till FRISK så länge en lokal databas förblir pausad.
2. När databaserna har återupptagits ändrar DBA tillfälligt den nya primära repliken till synkron-committläge. Detta omfattar två steg:

1) Ändra en offline-tillgänglighetskopi till asynkront commit-läge.

2) Ändra den nya huvudrepliken till synkront kommitteringsläge. Obs! Det här steget gör att synkrona åtaganden kan återuppta sekundära databaser för att bli SYNKRONISERADE.		 Ändra tillgänglighetsläget för en tillgänglighetsreplik (SQL Server)
3. När den synkrona commit-sekundära repliken på Node 03- (den ursprungliga primära repliken) går in i synkroniseringsstatusen FRISK utför DBA en planerad manuell omkoppling till den repliken för att åter göra den till den primära repliken. Kopian på Node 04 återgår till att vara en sekundär kopia. sys.dm_hadr_database_replica_states (Transact-SQL)

Använda AlwaysOn-principer för att visa hälsotillståndet för en tillgänglighetsgrupp (SQL Server)

Utföra en planerad manuell överväxling av en tillgänglighetsgrupp (SQL Server)
4. DBA ansluter till den nya primära repliken och:

1) Ändrar den föregående primära repliken (i fjärrcentret) tillbaka till asynkront commit-läge.

2) Ändrar tillbaka den sekundära repliken i huvuddatacentret från asynkron-commit till synkron-commit-läge.		 Ändra tillgänglighetsläget för en tillgänglighetsreplik (SQL Server)

Relaterade uppgifter

Justera kvorumröster

Planerad manuell omkoppling:

Felsöka:

Relaterat innehåll

Se även

översikt över AlwaysOn-tillgänglighetsgrupper (SQL Server)
tillgänglighetslägen (Always On-tillgänglighetsgrupper)
Failover och failover-lägen (Always On-tilgänglighetsgrupper)
om klientanslutningsåtkomst till tillgänglighetsrepliker (SQL Server)
övervakning av tillgänglighetsgrupper (SQL Server)
Windows Server Failover Clustering (WSFC) (redundansklustring för Windows Server) med SQL Server