Dela via


Utför en planerad manuell redundansväxling av en Always On-tillgänglighetsgrupp (SQL Server)

gäller för:SQL Server

Det här avsnittet beskriver hur du utför en manuell redundansväxling utan dataförlust (en planerad manuell redundansväxling) i en AlwaysOn-tillgänglighetsgrupp med hjälp av SQL Server Management Studio, Transact-SQL eller PowerShell i SQL Server. En tillgänglighetsgrupp växlar över på nivån för en tillgänglighetsreplika. En planerad manuell växling, som med alla Always On-tillgänglighetsgruppsväxlingar, övergår en sekundär replik till en primär roll. Samtidigt flyttar övergången den tidigare huvudrepliken till en sekundär roll.

En planerad manuell överflyttning stöds endast när den primära repliken och den sekundära målrepliken körs i synkroniserat överföringsläge och är synkroniserade. En planerad manuell redundans bevarar alla data i de sekundära databaser som är anslutna till tillgänglighetsgruppen på den sekundära målrepliken. När den tidigare primära repliken övergår till den sekundära rollen blir dess databaser sekundära databaser. Sedan börjar de synkronisera med de nya primära databaserna. När alla övergår till tillståndet SYNKRONISERAD blir den nya sekundära repliken berättigad att fungera som mål för en framtida planerad manuell redundansväxling.

Notera

Om både den sekundära och den primära repliken är konfigurerade för automatiskt överlämningsläge kan den sekundära repliken, efter att ha synkroniserats, även fungera som mål för ett automatiskt överlämnande. Mer information finns i Tillgänglighetslägen (AlwaysOn-tillgänglighetsgrupper).

Innan du börjar

Viktig

Det finns specifika procedurer för att växla över tillstånd för en lässkalig tillgänglighetsgrupp utan klusterhanterare. När en tillgänglighetsgrupp har CLUSTER_TYPE = NONE följer du procedurerna under Växla över den primära repliken i en tillgänglighetsgrupp för lässkalning.

Begränsningar och restriktioner

Krav och begränsningar

  • Både den sekundära målrepliken och den primära repliken måste köras i synkront bekräftelseläge för tillgänglighet.

  • För närvarande måste den sekundära målrepliken synkroniseras med den primära repliken. Alla sekundära databaser på den här sekundära repliken måste vara anslutna till tillgänglighetsgruppen. De måste också synkroniseras med motsvarande primära databaser (det vill: de lokala sekundära databaserna måste vara SYNKRONISERAde).

    Tips

    Om du vill fastställa beredskap för överlämning för en sekundär replik, frågar du efter kolumnen is_failover_ready i den dynamiska hanteringsvyn sys.dm_hadr_database_replica_cluster_states. Eller så kan du titta på kolumnen redundansberedskap i AlwaysOn-gruppinstrumentpanelen.

  • Detta uppdrag stöds bara på den sekundära målrepliken. Du måste vara ansluten till den serverinstans som hostar den sekundära målrepliken.

Säkerhet

Behörigheter

För att ändra tillgänglighetsgruppen krävs behörigheten ALTER AVAILABILITY GROUP. Behörigheten för att kontrollera tillgänglighetsgruppen, behörigheten för att ändra vilken tillgänglighetsgrupp som helst, eller behörigheten för att kontrollera servern krävs också.

Använda SQL Server Management Studio

Så här redundansväxlar du en tillgänglighetsgrupp manuellt:

  1. I Object Explorer ansluter du till en serverinstans som är värd för en sekundär replik av tillgänglighetsgruppen som måste växlas över. Expandera serverträdet.

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

  3. Högerklicka på tillgänglighetsgruppen som ska överföras, och välj failover.

  4. Guiden Redundanstillgänglighetsgrupp startar. Mer information finns i Använda guiden För redundanstillgänglighetsgrupp (SQL Server Management Studio).

Använd Transact-SQL

Så här växlar du manuellt över en tillgänglighetsgrupp:

  1. Anslut till den serverinstans som är värd för den sekundära målrepliken.

  2. Använd instruktionen ALTER AVAILABILITY GROUP på följande sätt:

    ÄNDRA TILLGÄNGLIGHETSGRUPP group_name ÖVERFLYTTNING

    I uttalandet är group_name namnet på tillgänglighetsgruppen.

    Följande exempel genomför manuellt failover för tillgänglighetsgruppen MyAg till den anslutna sekundära repliken.

    ALTER AVAILABILITY GROUP MyAg FAILOVER;  
    

Använda PowerShell

För att manuellt utföra en failover av en tillgänglighetsgrupp:

  1. Ändra katalogen (cd) till den serverinstans som är värd för den sekundära målrepliken.

  2. Använd cmdleten Switch-SqlAvailabilityGroup.

    Anteckning

    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 Få hjälp för SQL Server PowerShell.

    Följande exempel utför en manuell överflyttning av tillgänglighetsgruppen MyAg till den sekundära repliken med den specificerade sökvägen:

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

    Så här konfigurerar och använder du SQL Server PowerShell-providern:

Följ upp: När du manuellt redundansväxlar en tillgänglighetsgrupp

Om du redundansväxlade utanför tillgänglighetsgruppens automatiska redundansuppsättning justerar du kvorumrösterna för noderna för Windows Server-redundanskluster så att de återspeglar din nya konfiguration av tillgänglighetsgrupper. Mer information finns i Windows Server-redundansklustring (WSFC) med SQL Server.

Växla över den primära repliken i en tillgänglighetsgrupp för läsintensiva miljöer

Varje tillgänglighetsgrupp har bara en primär replik. Den primära repliken tillåter läsningar och skrivningar. Om du vill ändra vilken replik som är primär kan du utföra en failover. I en typisk tillgänglighetsgrupp automatiserar klusterhanteraren övertagandeprocessen. I en tillgänglighetsgrupp med klustertypen NONE är redundansväxlingsprocessen manuell.

Det finns två sätt att växla över den primära repliken i en tillgänglighetsgrupp med klustertypen NONE.

  • Manuell redundans utan dataförlust
  • Tvingad manuell redundansväxling med dataförlust

Manuell omkoppling utan dataförlust

Använd den här metoden när den primära repliken är tillgänglig, men du måste tillfälligt eller permanent ändra vilken instans som är värd för den primära repliken. Se till att den sekundära målrepliken är uppdaterad innan du utfärdar den manuella redundansväxlingen för att undvika potentiell dataförlust.

Så här redundansväxlar du manuellt utan dataförlust:

  1. Gör den aktuella primära och sekundära målrepliken SYNCHRONOUS_COMMIT.

    ALTER AVAILABILITY GROUP [AGRScale] 
         MODIFY REPLICA ON N'<node2>' 
         WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
    
  2. För att identifiera att aktiva transaktioner har bekräftats till den primära repliken och minst en synkron sekundär replik, kör följande fråga:

    SELECT ag.name, 
       drs.database_id, 
       drs.group_id, 
       drs.replica_id, 
       drs.synchronization_state_desc, 
       ag.sequence_number
    FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
    WHERE drs.group_id = ag.group_id; 
    

    Den sekundära repliken synkroniseras när synchronization_state_desc är SYNCHRONIZED.

  3. Uppdatera REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT till 1.

    Följande skript anger REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT till 1 i en tillgänglighetsgrupp med namnet ag1. Innan du kör följande skript ersätter du ag1 med namnet på din tillgänglighetsgrupp:

    ALTER AVAILABILITY GROUP [AGRScale] 
         SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
    

    Den här inställningen säkerställer att varje aktiv transaktion bekräftas på den primära repliken och minst en synkroniserad sekundär replik.

    Anteckning

    Den här inställningen är inte specifik för redundans och bör anges baserat på miljökraven.

  4. Ställ in den primära repliken och de sekundära repliker som inte deltar i failover till offline-läge för att förbereda för rollförändringen.

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
    
  5. Befordra den sekundära replikan till primär.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS; 
    
  6. Uppdatera rollen för den gamla primära och andra sekundärfilen till SECONDARY, kör följande kommando på SQL Server-instansen som är värd för den gamla primära repliken:

    ALTER AVAILABILITY GROUP [AGRScale] 
         SET (ROLE = SECONDARY); 
    

    Notera

    Om du vill ta bort en tillgänglighetsgrupp använder du SLÄPP TILLGÄNGLIGHETSGRUPP. För en tillgänglighetsgrupp som skapas med klustertypen NONE eller EXTERNAL kör du kommandot på alla repliker som ingår i tillgänglighetsgruppen.

  7. Återuppta dataflytten genom att köra följande kommando för varje databas i tillgänglighetsgruppen på SQL Server-instansen som är värd för den primära repliken:

    ALTER DATABASE [db1]
         SET HADR RESUME
    
  8. Återskapa alla lyssnare som du har skapat för läsbarhet och som inte hanteras av klusterhanteraren. Om den ursprungliga lyssnaren pekar på den gamla primären, ta bort den och återskapa den så att den pekar på den nya primären.

Tvingad manuell redundansväxling med dataförlust

Om den primära repliken inte är tillgänglig och inte kan återställas omedelbart måste du tvinga fram en redundansväxling till den sekundära repliken med dataförlust. Men om den ursprungliga primära repliken återställs efter en failover, kommer den att anta den primära rollen. Om du vill undvika att varje replik är i ett annat tillstånd tar du bort den ursprungliga primära från tillgänglighetsgruppen efter en tvingad redundansväxling med dataförlust. När den ursprungliga primära servern kommer online igen, tar du bort tillgänglighetsgruppen från den helt och hållet.

Om du vill tvinga fram en manuell redundansväxling med dataförlust från den primära repliken N1 till den sekundära repliken N2 följer du dessa steg:

  1. På den sekundära repliken (N2) initierar du den framtvingade redundansväxlingen:

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;
    
  2. På den nya primära repliken (N2) tar du bort den ursprungliga primära (N1):

    ALTER AVAILABILITY GROUP [AGRScale]
    REMOVE REPLICA ON N'N1';
    
  3. Kontrollera att all applikationstrafik pekar på lyssnaren och/eller den nya primära repliken.

  4. Om den ursprungliga primära (N1) är online tar du omedelbart tillgänglighetsgruppen AGRScale offline på den ursprungliga primära (N1):

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
    
  5. Om det finns data eller osynkroniserade ändringar bevarar du dessa data via säkerhetskopior eller andra alternativ för datareplikering som passar dina affärsbehov.

  6. Ta sedan bort tillgänglighetsgruppen från den ursprungliga primära (N1):

    DROP AVAILABILITY GROUP [AGRScale];
    
  7. Släpp tillgänglighetsgruppdatabasen på den ursprungliga primära repliken (N1):

    USE [master]
    GO
    DROP DATABASE [AGDBRScale]
    GO
    
  8. (Valfritt) Om du vill kan du nu lägga till N1 som en ny sekundär replik i tillgänglighetsgruppen AGRScale.

Se även