Použití automatického počátečního nastavení k inicializaci sekundární repliky pro skupinu dostupnosti AlwaysOn

platí pro:SQL Server

V SQL Server 2012 a 2014 je jediným způsobem, jak inicializovat sekundární repliku ve skupině dostupnosti SQL Server AlwaysOn, použít zálohování, kopírování a obnovení. SQL Server 2016 zavádí novou funkci pro inicializaci sekundární repliky – automatické nasazení. Automatické nasazení počátečních dat používá přenos datového proudu protokolu k přenosu zálohy pomocí VDI do sekundární repliky pro každou databázi ve skupině dostupnosti prostřednictvím nakonfigurovaných koncových bodů. Tuto novou funkci lze použít buď při počátečním vytvoření skupiny dostupnosti, nebo při přidání databáze do jedné. Automatické seedování je ve všech edicích SQL Server, které podporují skupiny dostupnosti AlwaysOn, a lze je používat s tradičními skupinami dostupnosti i distribuovanými skupinami dostupnosti.

Zabezpečení

Oprávnění zabezpečení se liší v závislosti na typu inicializované repliky:

• U tradiční skupiny dostupnosti je nutné udělit oprávnění skupině dostupnosti na sekundární replice při jejím připojování ke skupině dostupnosti. V Transact-SQL použijte příkaz ALTER AVAILABILITY GROUP [<AGName>] GRANT CREATE ANY DATABASE.
• Pro distribuovanou skupinu dostupnosti, ve které jsou databáze repliky vytvářené na primární replice druhé skupiny dostupnosti, nejsou vyžadována žádná další oprávnění, protože už je primární. Pokud je však v druhé skupině dostupnosti pouze jedna replika, udělte oprávnění CREATE ANY DATABASE názvu sekundární skupiny dostupnosti, jinak může automatická počáteční inicializace selhat.
• Pro sekundární repliku ve druhé skupině dostupnosti, která patří do distribuované skupiny dostupnosti, musíte použít příkaz ALTER AVAILABILITY GROUP [<2ndAGName>] GRANT CREATE ANY DATABASE. Tato sekundární replika je inicializována z primární repliky druhé skupiny dostupnosti.

Dopad protokolu transakcí a výkonu na primární repliku

Automatické seedování může, ale nemusí být praktické pro inicializaci sekundární repliky v závislosti na velikosti databáze, rychlosti sítě a vzdálenosti mezi primární a sekundární replikou. Například:

• Velikost databáze je 5 TB.
• Rychlost sítě je 1 Gb/s.
• Vzdálenost mezi těmito dvěma lokalitami je 1000 mil.

Pokud je k dispozici plná šířka pásma, může síť o velikosti 1 Gb/s poskytovat trvalou propustnost 125 MB/s. V tomto příkladu by automatické seedování trvalo jen více než 11 hodin. V praxi je proces automatického seedingu pomalejší, protože se síťový signál na delší vzdálenosti zhoršuje a připojení je sdílené s dalšími zdroji v síti. Během počátečního osévání bude transakční protokol databáze na primární replice nadále růst a nelze jej zkrátit, dokud nebude automatické osévání této databáze dokončeno. Transakční protokol je pak možné zkrátit pomocí zálohy transakčního protokolu.

Automatické počáteční zpracování je proces s jedním vláknem, který dokáže zpracovat až pět databází. Jednovláknové zpracování ovlivňuje výkon, zejména pokud má skupina dostupnosti více než jednu databázi.

Komprimaci lze použít pro automatické seedování, ale ve výchozím nastavení je zakázána. Zapnutí komprese snižuje šířku pásma sítě a možná zrychluje proces, ale nevýhodou je další režie procesoru. Pokud chcete použít kompresi během automatického počátečního nastavení, povolte příznak trasování 9567 – viz Ladění komprese pro skupinu dostupnosti.

Rozložení disku

V SQL Serveru 2016 a starších verzích musí složka, ve které má být databáze vytvořena pomocí automatického seedování, již existovat a musí se shodovat s cestou na primární replice.

V SQL Server 2017 Microsoft doporučuje používat stejnou cestu k datům a souboru protokolu na všech replikách, které se účastní skupiny dostupnosti, ale v případě potřeby můžete použít různé cesty. Například ve skupině dostupnosti pro různé platformy je jedna instance SQL Server na Windows a další instance SQL Server v Linuxu. Různé platformy mají různé výchozí cesty. SQL Server 2017 podporuje repliky skupin dostupnosti na instancích SQL Server s různými výchozími cestami.

Následující tabulka uvádí příklady podporovaných konfigurací datových disků, které podporují automatické počáteční nasazení:

Primární instance Výchozí cesta k datům	Výchozí cesta k datům sekundární instance	Primární instance Umístění zdrojového souboru	Sekundární instance Umístění cílového souboru
c:\data\	/var/opt/mssql/data/	c:\data\	/var/opt/mssql/data/
c:\data\	/var/opt/mssql/data/	c:\data\group1\	/var/opt/mssql/data/group1/
c:\data\	d:\data\	c:\data\	d:\data\
c:\data\	d:\data\	c:\data\group1\	d:\data\group1\

Scénáře, kdy umístění databází primární a sekundární repliky nejsou ve výchozích cestách instance, nejsou touto změnou ovlivněny. Požadavky na cesty k souborům sekundární repliky tak, aby odpovídaly cestám k souborům primární repliky, zůstanou stejné.

Primární instance Výchozí cesta k datům	Výchozí cesta k datům sekundární instance	Primární instance Umístění souboru	Sekundární instance Umístění souboru
c:\data\	c:\data\	d:\group1\	d:\group1\
c:\data\	c:\data\	d:\data\	d:\data\
c:\data\	c:\data\	d:\data\group1\	d:\data\group1\

Pokud pro primární a sekundární repliky kombinujete výchozí a jiné cesty, SQL Server 2017 se chová jinak než předchozí verze. Následující tabulka ukazuje chování SQL Server 2017.

Primární instance Výchozí cesta k datům	Výchozí cesta k datům sekundární instance	Primární instance Umístění souboru	SQL Server 2016 Umístění souboru sekundární instance	SQL Server 2017 Umístění souboru sekundární instance
c:\data\	d:\data\	c:\data\	c:\data\	d:\data\
c:\data\	d:\data\	c:\data\group1\	c:\data\group1\	d:\data\group1\

Chcete-li obnovit chování SQL Serveru 2016 a starších verzí, povolte příznak trasování 9571. Informace o povolení příznaků trasování naleznete v tématu DBCC TRACEON (Transact-SQL).

Vytvořte skupinu dostupnosti pomocí automatického nasazení

Skupinu dostupnosti vytvoříte pomocí automatického počátečního nastavení s Transact-SQL nebo SQL Server Management Studio (SSMS, verze 17 nebo novější). Pokud chcete použít Průvodce skupinou dostupnosti v nástroji SSMS, postupujte podle těchto pokynů – když se dostanete ke kroku 9, všimněte si, že automatické počáteční nastavení je první a výchozí možnost.

Následující příklad vytvoří skupinu dostupnosti s automatickým nasazením pomocí Transact-SQL. Viz také téma Vytvoření skupiny dostupnosti (Transact-SQL). Inicializace se na sekundární replice povolí nastavením možnosti SEEDING_MODE na AUTOMATIC. Výchozí chování je MANUAL, což je chování používané před SQL Serverem 2016 – vyžaduje vytvoření zálohy databáze na primární replice, zkopírování souboru zálohy na sekundární repliku a obnovení zálohy WITH NORECOVERY.

CREATE AVAILABILITY GROUP [<AGName>]
  FOR DATABASE db1
  REPLICA ON N'Primary_Replica'
WITH (
  ENDPOINT_URL = N'TCP://Primary_Replica.Contoso.com:5022', 
  FAILOVER_MODE = AUTOMATIC, 
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
),
  N'Secondary_Replica' WITH (
    ENDPOINT_URL = N'TCP://Secondary_Replica.Contoso.com:5022', 
    FAILOVER_MODE = AUTOMATIC, 
    SEEDING_MODE = AUTOMATIC);
 GO

Nastavení SEEDING_MODE primární repliky během CREATE AVAILABILITY GROUP příkazu nemá žádný vliv, protože primární replika již obsahuje hlavní kopii databáze pro čtení a zápis. SEEDING_MODE by platilo pouze tehdy, pokud byla jako primární nastavena jiná replika a byla přidána databáze. Režim seedingu lze později změnit – viz Změna režimu počátečního nastavení repliky.

V instanci, která se stane sekundární replikou, po připojení instance se do protokolu SQL Server přidá následující zpráva:

Místní replice dostupnosti pro skupinu dostupnosti „AGName“ nebylo uděleno oprávnění k vytváření databází, ale má hodnotu SEEDING_MODEAUTOMATIC. Použijte ALTER AVAILABILITY GROUP ... GRANT CREATE ANY DATABASE, chcete-li umožnit vytváření databází inicializovaných primární replikou skupiny dostupnosti.

Udělení oprávnění k vytvoření databáze pro sekundární repliku skupině dostupnosti

Po připojení udělte skupině dostupnosti oprávnění vytvářet databáze v sekundární instanci repliky SQL Server. Aby automatické nasazení fungovalo, skupina dostupnosti potřebuje oprávnění k vytvoření databáze.

Tip

Když skupina dostupnosti vytvoří databázi na sekundární replice, nastaví jako vlastníka databáze "sa" (konkrétně účet s identifikátorem sid 0x01).

Ke změně vlastníka databáze poté, co sekundární replika automaticky vytvoří databázi, použijte ALTER AUTHORIZATION. Viz ALTER AUTHORIZATION (Transact-SQL).

Následující příklad udělí toto oprávnění skupině dostupnosti s názvem AGName.

ALTER AVAILABILITY GROUP [<AGName>] 
    GRANT CREATE ANY DATABASE
 GO

V případě potřeby nastavte vlastníka databáze na sekundární replice.

Ověřte automatické nasazení

V případě úspěchu se databáze automaticky vytvoří na sekundární replice se stavem:

• SYNCHRONIZOVÁNO, pokud je sekundární replika nakonfigurovaná tak, aby byla synchronní a data se synchronizují.
• SYNCHRONIZUJE SE, pokud je sekundární replika nakonfigurována pro asynchronní přenos dat nebo je nakonfigurována pro synchronní přenos dat, ale ještě není synchronizována s primární replikou.

Kromě níže popsaných zobrazení dynamické správy lze zahájení a dokončení automatického nasazení počátečních dat sledovat také v protokolu SQL Serveru:

Kombinovat zálohování a obnovení pomocí automatického nasazení

Tradiční zálohování, kopírování a obnovení je možné kombinovat s automatickým nasazením. V takovém případě nejprve obnovte databázi na sekundární replice včetně všech dostupných transakčních protokolů. Dále při vytváření skupiny dostupnosti povolte automatické předvyplňování databáze sekundární repliky, jako by se obnovila záloha protokolu tail-log (vizTail-Log Zálohování (SQL Server)).

Přidat databázi do skupiny dostupnosti pomocí automatického nasazení

Databázi můžete přidat do skupiny dostupnosti pomocí automatického seedingu pomocí Transact-SQL nebo SQL Server Management Studio (SSMS verze 17 nebo novější). Pokud sekundární replika použila automatické nasazení, když byla přidána do skupiny dostupnosti, není třeba dělat nic dalšího. Pokud sekundární replika použila zálohování, kopírování a obnovení, nejprve změňte režim počátečního nastavení (viz další část) a pak při přidání databáze použijte tento GRANT příkaz – viz Skupina dostupnosti – Přidání databáze.

Změnit režim inicializace repliky

Režim inicializace repliky lze po vytvoření skupiny dostupnosti změnit, takže automatickou inicializaci lze povolit nebo zakázat. Povolení automatického osazení po jejím vytvoření umožňuje přidat databázi do skupiny dostupnosti pomocí automatického osazení, pokud byla vytvořena pomocí zálohování, kopírování a obnovení. Příklad:

ALTER AVAILABILITY GROUP [AGName]
  MODIFY REPLICA ON 'Replica_Name'
  WITH (SEEDING_MODE = AUTOMATIC)

Chcete-li zakázat automatické seedování, použijte hodnotu MANUAL.

Zabránění automatickému seedování po vytvoření skupiny dostupnosti

Pokud nechcete automatické seedování úplně zakázat pro sekundární repliku, ale chcete dočasně zabránit tomu, aby sekundární replika mohla automaticky vytvářet databáze, zamítejte oprávnění CREATE skupiny dostupnosti. To je případ, kdy je do skupiny dostupnosti přidána nová databáze, ale skupina dostupnosti by neměla být povolena k vytvoření databáze na sekundární replice.

ALTER AVAILABILITY GROUP [AGName] 
    DENY CREATE ANY DATABASE
GO

Monitor automatického osévání

Existují čtyři způsoby, jak sledovat automatické seedování a řešit související potíže:

• protokol SQL Server, jak už je popsáno
• Zobrazení dynamické správy
• Tabulky historie zálohování
• Rozšířené události

Dynamická zobrazení správy

Existují dvě zobrazení dynamické správy (DMV) pro monitorování počátečního nastavení: sys.dm_hadr_automatic_seeding a sys.dm_hadr_physical_seeding_stats.

• sys.dm_hadr_automatic_seeding obsahuje obecný stav automatického seedingu a uchovává historii při každém spuštění (bez ohledu na to, jestli je úspěšné nebo ne). current_state Sloupec má hodnotu COMPLETED nebo FAILED. Pokud je hodnota FAILED, použijte při diagnostice problému hodnotu v failure_state_desc. Možná ho budete muset zkombinovat s tím, co se stalo v protokolu SQL Server, abyste zjistili, co se nepovedlo. Toto zobrazení dynamické správy je naplněno na primární replice i na všech sekundárních replikách.

• sys.dm_hadr_physical_seeding_stats zobrazuje stav operace automatického seedování během jejího provádění. Stejně jako sys.dm_hadr_automatic_seeding tato funkce vrací hodnoty pro primární i sekundární repliky, ale tato historie se neukládá. Hodnoty jsou určené pouze pro aktuální spuštění a nezachovají se. Mezi sloupce zájmu patří start_time_utc, end_time_utc, estimate_time_complete_utc, total_disk_io_wait_time_ms, total_network_wait_time_ms a pokud operace seedingu selže, failure_message.

Tabulky historie zálohování

Automatické zavedení počátečních dat také vloží záznamy do tabulek msdb, které uchovávají historii zálohování a obnovení. Na sekundární replice, která přijímá automatické seedování, obsahuje sloupec physical_device_name v tabulce backupmediafamily jako hodnotu identifikátor GUID a odpovídající záznam v backupset má pro server_name a machine_name název primární repliky.

Rozšířené události

Automatické inicializační nasazení přidává nové rozšířené události pro sledování změn stavu, selhání a statistik výkonu během inicializace. Následující skript například vytvoří relaci rozšířených událostí, která zachycuje události související s automatickým předvytvářením.

CREATE EVENT SESSION [AlwaysOn_autoseed] ON SERVER 
    ADD EVENT sqlserver.hadr_automatic_seeding_state_transition,
    ADD EVENT sqlserver.hadr_automatic_seeding_timeout,
    ADD EVENT sqlserver.hadr_db_manager_seeding_request_msg,
    ADD EVENT sqlserver.hadr_physical_seeding_backup_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_failure,
    ADD EVENT sqlserver.hadr_physical_seeding_forwarder_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_forwarder_target_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_progress,
    ADD EVENT sqlserver.hadr_physical_seeding_restore_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_submit_callback
    ADD TARGET package0.event_file(
        SET filename=N'autoseed.xel',
        max_file_size=(5),
        max_rollover_files=(4)
        )
    WITH (
        MAX_MEMORY=4096 KB,
        EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
        MAX_DISPATCH_LATENCY=30 SECONDS,
        MAX_EVENT_SIZE=0 KB,
        MEMORY_PARTITION_MODE=NONE,
        TRACK_CAUSALITY=OFF,
        STARTUP_STATE=ON
        )
GO

ALTER EVENT SESSION AlwaysOn_autoseed ON SERVER STATE=START
GO

V následující tabulce jsou uvedeny rozšířené události související s automatickým nasazováním.

Name	Description
hadr_db_manager_seeding_request_msg	Zpráva požadavku na zasévání
hadr_physical_seeding_backup_state_change	Změna stavu fyzického zálohování na straně zálohování
hadr_physical_seeding_restore_state_change	Změna stavu na straně obnovení během fyzické inicializace.
hadr_physical_seeding_forwarder_state_change	Změna stavu fyzického předsílaného bočního stavu.
hadr_physical_seeding_forwarder_target_state_change	Změna stavu na cílové straně předávací služby pro fyzické zavedení počátečních dat.
hadr_physical_seeding_submit_callback	Fyzická počáteční událost odeslání zpětného volání
hadr_physical_seeding_failure	Událost selhání fyzického počátečního nasazení
hadr_physical_seeding_progress	Událost průběhu fyzického zavádění počátečních dat.
hadr_physical_seeding_schedule_long_task_failure	Událost selhání dlouhotrvající úlohy plánu fyzického počátečního naplnění
hadr_automatic_seeding_start	Nastane, když je odeslána operace automatické inicializace.
hadr_automatic_seeding_state_transition	Nastane, když automatická operace počátečního naplnění změní stav.
hadr_automatic_seeding_success	Nastane při úspěšném dokončení operace automatického nasazení.
hadr_automatic_seeding_failure	Nastane, když se nezdaří operace automatického nasazení.
hadr_automatic_seeding_timeout	Nastane, když vyprší časový limit pro automatickou operaci počáteční replikace.

Viz také

ALTER AVAILABILITY GROUP (Transact-SQL)

CREATE AVAILABILITY GROUP (Transact-SQL)

Průvodce odstraňováním potíží a monitorováním skupin dostupnosti AlwaysOn