Sdílet prostřednictvím


Provedení plánovaného ručního převzetí služeb při selhání skupiny dostupnosti AlwaysOn (SQL Server)

platí pro:SQL Server

Toto téma popisuje, jak provést ruční převzetí služeb při selhání bez ztráty dat (plánované ruční převzetí služeb při selhání) ve skupině dostupnosti AlwaysOn pomocí aplikace SQL Server Management Studio, Transact-SQL nebo PowerShellu na SQL Serveru. Skupina dostupnosti přejde do režimu selhání na úrovni repliky dostupnosti. Plánované ruční převzetí služeb při selhání, jako je převzetí služeb při selhání skupiny dostupnosti AlwaysOn, přemísní sekundární repliku na primární roli. Současně přepnutí převádí bývalou primární repliku do sekundární role.

Plánované ruční převzetí služeb při selhání se podporuje jenom v případech, kdy primární replika a cílová sekundární replika běží v režimu synchronního potvrzení a aktuálně se synchronizují. Plánované ruční převzetí služeb při selhání zachovává všechna data v sekundárních databázích, která jsou připojená ke skupině dostupnosti na cílové sekundární replice. Po přechodu bývalé primární repliky do sekundární role se její databáze stanou sekundárními databázemi. Pak se začnou synchronizovat s novými primárními databázemi. Poté, co všichni přejdou do synchronizovaného stavu, nová sekundární replika se stane způsobilou sloužit jako cíl budoucího plánovaného ručního převzetí služeb při selhání.

Poznámka

Pokud jsou sekundární i primární repliky nakonfigurované pro režim automatického převzetí služeb při selhání, může po synchronizaci sekundární repliky sloužit také jako cíl automatického převzetí služeb při selhání. Další informace najdete v tématu režimy dostupnosti (skupiny dostupnosti AlwaysOn).

Než začnete

Důležitý

Existují stanovené postupy pro přepnutí skupiny dostupnosti určené ke čtení bez správce clusteru. Pokud má skupina dostupnosti CLUSTER_TYPE = NONE, postupujte podle postupů v části Převzetí služeb při selhání primární repliky ve skupině dostupnosti na úrovni čtení.

Omezení a restrikce

  • Příkaz převzetí služeb při selhání se vrátí ihned poté, co cílová sekundární replika příkaz přijala. Obnovení databáze však probíhá asynchronně po dokončení převzetí služeb skupinou dostupnosti při selhání.

  • Konzistence mezi databázemi v rámci skupiny dostupnosti nemusí být při převzetí služeb při selhání zachována.

    Poznámka

    Podpora napříč databázemi a distribuovanými transakcemi se liší podle verzí SQL Serveru a operačního systému. Další informace najdete v tématu transakce mezi databázemi a distribuované transakce pro skupiny dostupnosti AlwaysOn a zrcadlení databáze (SQL Server).

Požadavky a omezení

  • V režimu dostupnosti synchronního potvrzení musí běžet jak cílová sekundární replika, tak primární replika.

  • V současné době musí být cílová sekundární replika synchronizovaná s primární replikou. Všechny sekundární databáze na této sekundární replice musí být připojené ke skupině dostupnosti. Musí být také synchronizovány s odpovídajícími primárními databázemi (to znamená, že místní sekundární databáze musí být SYNCHRONIZOVÁNY).

    Spropitné

    Pokud chcete určit připravenost sekundární repliky na převzetí služeb při selhání, zadejte dotaz na sloupec is_failover_ready v zobrazení sys.dm_hadr_database_replica_cluster_states dynamické správy. Nebo se můžete podívat na sloupec připravenosti na převzetí služeb při selhání na řídicím panelu skupiny Always On.

  • Tato úloha je podporována pouze na cílové sekundární replice. Musíte být připojeni k instanci serveru, která je hostitelem cílové sekundární repliky.

Bezpečnost

Dovolení

Je vyžadováno oprávnění ALTER AVAILABILITY GROUP pro skupinu dostupnosti. Je také vyžadováno oprávnění CONTROL AVAILABILITY GROUP, ALTER ANY AVAILABILITY GROUP nebo CONTROL SERVER.

Použití aplikace SQL Server Management Studio

Ruční převzetí služeb při selhání skupiny dostupnosti:

  1. V Průzkumníku objektů se připojte k serverové instanci, která je hostitelem sekundární repliky skupiny dostupnosti, která má být převedena při selhání. Rozbalte strom serveru.

  2. Rozbalte uzel AlwaysOn s vysokou dostupností a uzel skupiny dostupnosti .

  3. Klikněte pravým tlačítkem na skupinu dostupnosti, u které chcete převzít služby při selhání, a vyberte převzetí služeb při selhání.

  4. Spouští se průvodce převzetí služeb při selhání ve skupině dostupnosti. Další informace najdete v tématu Použití průvodce pro skupinu dostupnosti při převzetí služeb při selhání (SQL Server Management Studio).

Použijte Transact-SQL

Pro ruční přepnutí skupiny dostupnosti na záložní systém:

  1. Připojte se k instanci serveru, která je hostitelem cílové sekundární repliky.

  2. Použijte příkaz ALTER AVAILABILITY GROUP následujícím způsobem:

    ALTER AVAILABILITY GROUP group_name PŘEVZETÍ SLUŽEB PŘI SELHÁNÍ

    V příkazu group_name je název skupiny dostupnosti.

    Následující příklad ručně přepne skupinu dostupnosti MyAg na připojenou sekundární repliku:

    ALTER AVAILABILITY GROUP MyAg FAILOVER;  
    

Použití PowerShellu

Ruční provedení převzetí skupiny dostupnosti při selhání:

  1. Změňte adresář (cd) na instanci serveru, která je hostitelem cílové sekundární repliky.

  2. Použijte rutinu Switch-SqlAvailabilityGroup.

    Poznámka

    Pokud chcete zobrazit syntaxi rutiny, použijte rutinu Get-Help v prostředí SQL Server PowerShell. Další informace najdete v tématu Získání nápovědy pro sql Server PowerShell.

    Následující příklad ručně přepne skupinu dostupnosti MyAg na sekundární repliku se zadanou cestou:

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

    Nastavení a použití poskytovatele POWERShellu pro SQL Server:

Navazující kroky: Po ručním převzetí skupiny dostupnosti při selhání

Pokud jste převedli služby mimo automatické převzetí služeb při selhání skupiny dostupnosti, upravte hlasy kvora uzlů Windows Server clusteringu s podporou převzetí služeb při selhání tak, aby odrážely vaši novou konfiguraci skupiny dostupnosti. Další informace najdete v tématu Failover Clusteringu Windows Serveru (WSFC) s SQL Serverem.

Převeďte primární replikaci ve skupině dostupnosti zaměřené na čtení

Každá skupina dostupnosti má pouze jednu primární repliku. Primární replika umožňuje čtení a zápisy. Pokud chcete změnit, která replika je primární, můžete provést failover. V typické skupině dostupnosti správce clusteru automatizuje proces přepnutí při selhání. Ve skupině dostupnosti s typem clusteru NONE je proces převzetí služeb při selhání prováděn ručně.

Existují dva způsoby převzetí služeb při selhání primární repliky ve skupině dostupnosti s typem clusteru NONE:

  • Ruční převzetí při selhání bez ztráty dat
  • Vynucené manuální přepnutí při selhání se ztrátou dat

Ruční "failover" bez ztráty dat

Tuto metodu použijte, pokud je primární replika dostupná, ale potřebujete dočasně nebo trvale změnit, která instance je hostitelem primární repliky. Abyste se vyhnuli potenciální ztrátě dat, před vydáním ručního převzetí služeb se ujistěte, že je cílová sekundární replika synchronizovaná.

Ruční převzetí provozu při selhání bez ztráty dat:

  1. Nastavení aktuální primární a cílové sekundární repliky SYNCHRONOUS_COMMIT.

    ALTER AVAILABILITY GROUP [AGRScale] 
         MODIFY REPLICA ON N'<node2>' 
         WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
    
  2. Pokud chcete zjistit, že aktivní transakce jsou potvrzeny do primární repliky a alespoň jedné synchronní sekundární repliky, spusťte následující dotaz:

    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; 
    

    Sekundární replika se synchronizuje, když je synchronization_state_descSYNCHRONIZED.

  3. Aktualizujte REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT na 1.

    Následující skript nastaví REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT na 1 ve skupině dostupnosti s názvem ag1. Před spuštěním následujícího skriptu nahraďte ag1 názvem vaší skupiny dostupnosti:

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

    Toto nastavení zajišťuje, že každá aktivní transakce je potvrzena v primární replice a alespoň jedné sekundární synchronní replice.

    Poznámka

    Toto nastavení není specifické pro převzetí služeb při selhání a mělo by se nastavit na základě požadavků prostředí.

  4. Nastavte primární repliku a sekundární repliky, které se nepodílí na převzetí služeb při selhání, do režimu offline, abyste připravili změnu role:

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
    
  5. Zvýšení úrovně cílové sekundární repliky na primární.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS; 
    
  6. Aktualizujte roli starých primárních a dalších sekundárních serverů na SECONDARY, spusťte následující příkaz v instanci SYSTÉMU SQL Server, která je hostitelem staré primární repliky:

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

    Poznámka

    Pokud chcete odstranit skupinu dostupnosti, použijte DROP AVAILABILITY GROUP. Pro skupinu dostupnosti vytvořenou s typem clusteru NONE nebo EXTERNAL spusťte příkaz na všech replikách, které jsou součástí skupiny dostupnosti.

  7. Pokračujte v přesunu dat, spusťte následující příkaz pro každou databázi ve skupině dostupnosti v instanci SQL Serveru, která je hostitelem primární repliky:

    ALTER DATABASE [db1]
         SET HADR RESUME
    
  8. Znovu vytvořte jakékoli naslouchátko, které jste vytvořili pro účely škálování pro čtení a které nespravuje správce clusteru. Pokud původní nasloucháč odkazuje na starý primární server, odeberte ho a znovu ho vytvořte tak, aby odkazoval na nový primární server.

Vynucené ruční přepnutí se ztrátou dat

Pokud primární replika není dostupná a nelze ji okamžitě obnovit, je nutné vynutit převedení na sekundární repliky i se ztrátou dat. Pokud se ale původní primární replika po převzetí služeb při selhání obnoví, převezme primární roli. Aby se zabránilo tomu, že každá replika bude v jiném stavu, odeberte původní primární ze skupiny dostupnosti po vynuceném převzetí služeb při selhání se ztrátou dat. Jakmile se původní primární server vrátí zpátky do online režimu, odeberte skupinu dostupnosti úplně z ní.

Chcete-li vynutit ruční převzetí služeb s rizikem ztráty dat z primární repliky N1 na sekundární repliku N2, postupujte takto:

  1. Zahajte vynucené převzetí služeb při selhání na sekundární replice (N2):

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;
    
  2. Na nové primární replice (N2) odeberte původní primární (N1):

    ALTER AVAILABILITY GROUP [AGRScale]
    REMOVE REPLICA ON N'N1';
    
  3. Ověřte, že veškerý provoz aplikace odkazuje na naslouchadlo a/nebo novou primární repliku.

  4. Pokud je původní primární server (N1) online, okamžitě přepněte skupinu dostupnosti AGRScale do režimu offline na původní primární (N1):

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
    
  5. Pokud existují data nebo nesynchronizované změny, zachovejte tato data prostřednictvím záloh nebo jiných možností replikace dat, které vyhovují vašim obchodním potřebám.

  6. Potom odeberte skupinu dostupnosti z původní primární skupiny (N1):

    DROP AVAILABILITY GROUP [AGRScale];
    
  7. Odstraňte databázi skupiny dostupnosti na původní primární repliku (N1):

    USE [master]
    GO
    DROP DATABASE [AGDBRScale]
    GO
    
  8. (Volitelné) V případě potřeby teď můžete přidat N1 zpět jako novou sekundární repliku do skupiny dostupnosti AGRScale.

Viz také