Az automatikus vetés használatával inicializálhat egy másodlagos replikát egy Always On rendelkezésre állási csoporthoz

A következőkre vonatkozik:SQL Server

2012-ben és 2014-ben SQL Server csak úgy inicializálhat másodlagos replikát egy SQL Server Always On rendelkezésre állási csoportban, ha biztonsági mentést, másolást és visszaállítást használ. SQL Server 2016 egy új funkciót vezet be egy másodlagos replika inicializálásához – automatikus vetés. Az automatikus kezdeti feltöltés a konfigurált végpontokon keresztül, a naplóadatfolyam-alapú átvitel segítségével, VDI-n keresztül továbbítja a biztonsági mentést a rendelkezésre állási csoport minden adatbázisához tartozó másodlagos replikára. Ez az új funkció egy rendelkezésre állási csoport kezdeti létrehozásakor vagy adatbázis hozzáadásakor használható. Az automatikus magvetés a SQL Server minden olyan kiadásában megtalálható, amely támogatja az Always On rendelkezésre állási csoportokat, és használható a hagyományos rendelkezésre állási csoportokkal és az elosztott rendelkezésre állási csoportokkal is.

Biztonság

A biztonsági engedélyek az inicializálandó replika típusától függően változnak:

• Hagyományos rendelkezésre állási csoport esetén engedélyeket kell adni a másodlagos replika rendelkezésre állási csoportjának a rendelkezésre állási csoporthoz való csatlakozáskor. A Transact-SQL használja a parancsotALTER AVAILABILITY GROUP [<AGName>] GRANT CREATE ANY DATABASE.
• Olyan elosztott rendelkezésre állási csoport esetén, ahol a replika létrehozott adatbázisai a második rendelkezésre állási csoport elsődleges replikáján találhatók, nincs szükség további engedélyekre, mivel az már elsődleges. Ha azonban csak egy replika található a második rendelkezésre állási csoportban, adja meg az CREATE ANY DATABASE engedélyt a másodlagos rendelkezésre állási csoport nevének, vagy az automatikus vetés meghiúsulhat.
• Az elosztott rendelkezésre állási csoport második rendelkezésre állási csoportjában lévő másodlagos replikához a parancsot ALTER AVAILABILITY GROUP [<2ndAGName>] GRANT CREATE ANY DATABASEkell használnia. Ez a másodlagos replika a második rendelkezésre állási csoport elsődleges replikájából van inicializálva.

A teljesítmény és a tranzakciós napló hatása az elsődleges replikára

Az automatikus vetés az adatbázis méretétől, a hálózati sebességtől és az elsődleges és a másodlagos replikák közötti távolságtól függően praktikus lehet egy másodlagos replika inicializálásához. Például:

• Az adatbázis mérete 5 TB
• A hálózati sebesség 1 Gb/s
• A két hely közötti távolság 1000 mérföld

Ha a teljes sávszélesség elérhető, az 1 Gb/s-os hálózat 125 MB/s tartós átviteli sebességet biztosíthat. Ebben a példában az automatikus vetés alig több mint 11 órát vesz igénybe. A gyakorlatban az automatikus magvetési folyamat lassabb, mivel a hálózati jelek nagyobb távolságokra csökkennek, és a kapcsolat meg van osztva a hálózat többi erőforrásával. Az inicializálás során az elsődleges replikán lévő adatbázis tranzakciónaplója továbbra is növekszik, és nem csonkítható, amíg az adatbázis automatikus inicializálása be nem fejeződik. A tranzakciós napló ezután a tranzakciós napló biztonsági mentésével csonkítható.

Az automatikus magvetés egy egyszálas folyamat, amely legfeljebb öt adatbázist képes kezelni. Az egyszálú feldolgozás befolyásolja a teljesítményt, különösen, ha a rendelkezésre állási csoport egynél több adatbázist tartalmaz.

A tömörítés automatikus vetéshez használható, de alapértelmezés szerint le van tiltva. A tömörítés bekapcsolása csökkenti a hálózati sávszélesség-igényt, és esetleg fel is gyorsíthatja a folyamatot, ennek ára azonban a további processzorterhelés. Ha a tömörítést az automatikus vetés során szeretné használni, engedélyezze a 9567-es nyomkövetési jelzőt – lásd a rendelkezésre állási csoport tömörítésének finomhangolását.

Lemezkiosztás

2016 SQL Server és korábban az adatbázis automatikus vetéssel létrehozott mappájának már léteznie kell, és meg kell egyeznie az elsődleges replika útvonalával.

2017 SQL Server Microsoft ugyanazt az adat- és naplófájl-elérési utat javasolja a rendelkezésre állási csoportban részt vevő összes replikán, de szükség esetén különböző elérési utakat is használhat. Platformfüggetlen rendelkezésre állási csoportban például a SQL Server egy példánya Windows, a SQL Server egy másik példánya pedig Linuxon van. A különböző platformok eltérő alapértelmezett elérési útokkal rendelkeznek. SQL Server 2017 támogatja a rendelkezésre állási csoport replikáit a különböző alapértelmezett elérési utakkal rendelkező SQL Server példányokon.

Az alábbi táblázat példákat mutat be az automatikus magvetést támogató támogatott adatlemez-elrendezésekre:

Elsődleges példány Alapértelmezett adatútvonal	Másodlagos példány Alapértelmezett adatútvonal	Elsődleges példány forrásfájl helye	Másodlagos példány célfájl helye
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\

A változás nem érinti azokat az eseteket, amikor az elsődleges és másodlagos replikaadatbázis helye nem a példány alapértelmezett elérési útja. Az elsődleges replikafájl elérési útjának megfelelő másodlagos replikafájl-elérési utakra vonatkozó követelmények változatlanok maradnak.

Elsődleges példány Alapértelmezett adatútvonal	Másodlagos példány Alapértelmezett adatútvonal	Elsődleges példány Fájl helye	másodlagos példány fájl helye
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\

Ha az elsődleges és másodlagos replikák alapértelmezett és nem alapértelmezett elérési útját keveri össze, SQL Server 2017 másképp viselkedik, mint a korábbi kiadások. Az alábbi táblázat a 2017-SQL Server viselkedését mutatja be.

Elsődleges példány Alapértelmezett adatútvonal	Másodlagos példány Alapértelmezett adatútvonal	Elsődleges példány Fájl helye	SQL Server 2016 Másodlagos példány fájljának helye	SQL Server 2017 Másodlagos példány fájl helye
c:\data\	d:\data\	c:\data\	c:\data\	d:\data\
c:\data\	d:\data\	c:\data\group1\	c:\data\group1\	d:\data\group1\

Ha vissza szeretne térni a 2016-os és korábbi SQL Server viselkedéséhez, engedélyezze a nyomkövetési jelző 9571-et. A nyomkövetési jelzők engedélyezéséről a DBCC TRACEON (Transact-SQL) című témakörben olvashat.

Rendelkezésre állási csoport létrehozása automatikus vetéssel

Egy rendelkezésre állási csoportot automatikus vetéssel hozhat létre Transact-SQL vagy SQL Server Management Studio (SSMS, 17-es vagy újabb verzió). A Rendelkezésre állási csoport varázsló SSMS-ben való használatához kövesse az alábbi utasításokat – amikor a 9. lépéshez ér, figyelje meg, hogy az automatikus vetés az első és az alapértelmezett beállítás.

Az alábbi példa egy rendelkezésre állási csoportot hoz létre automatikus vetéssel a Transact-SQL használatával. Lásd még a Rendelkezésre állási csoport létrehozása (Transact-SQL) című témakört. A seedelés egy másodlagos replikán a SEEDING_MODE beállítás AUTOMATIC értékre állításával engedélyezhető. Az alapértelmezett viselkedés a 2016-SQL Server előtti viselkedésMANUAL, amely megköveteli az adatbázis biztonsági mentését az elsődleges replikán, a biztonsági mentési fájl másolatát a másodlagos replikára, valamint a biztonsági mentés WITH NORECOVERYvisszaállítását.

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

A SEEDING_MODE utasítás során az elsődleges replikán végzett CREATE AVAILABILITY GROUP beállításnak nincs hatása, mivel az elsődleges replika már tartalmazza az adatbázis fő olvasási/írási példányát. SEEDING_MODE csak akkor alkalmazható, ha egy másik replika lett az elsődleges, és egy adatbázis lett hozzáadva. A bevetési mód később módosítható – lásd : Replika vetésmódjának módosítása.

Egy másodlagos replikává váló példányon a példány csatlakoztatása után a következő üzenet lesz hozzáadva a SQL Server naplóhoz:

Az „AGName” rendelkezésre állási csoport helyi rendelkezésre állási replikája nem kapott engedélyt adatbázisok létrehozására, de SEEDING_MODE értéke AUTOMATIC. A(z) ALTER AVAILABILITY GROUP ... GRANT CREATE ANY DATABASE használatával engedélyezheti az elsődleges rendelkezésre állási replika által inicializált adatbázisok létrehozását.

Adatbázis-létrehozási engedély megadása másodlagos replikán a rendelkezésre állási csoportnak

A csatlakozás után adjon engedélyt a rendelkezésre állási csoportnak, hogy adatbázisokat hozzon létre a SQL Server másodlagos replikapéldányán. Az automatikus vetés működéséhez a rendelkezésre állási csoportnak engedélyre van szüksége egy adatbázis létrehozásához.

Tip

Amikor a rendelkezésre állási csoport létrehoz egy adatbázist egy másodlagos replikán, az "sa" (pontosabban a sid 0x01) fiókot állítja be az adatbázis tulajdonosaként.

Ha módosítani szeretné az adatbázis tulajdonosát, miután egy másodlagos replika automatikusan létrehoz egy adatbázis-használatot ALTER AUTHORIZATION. Lásd ALTER AUTHORIZATION : (Transact-SQL).

Az alábbi példa ezt az engedélyt egy AGName nevű rendelkezésre állási csoportnak adja.

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

Szükség esetén állítsa be az adatbázis tulajdonosát a másodlagos replikán.

Automatikus vetés ellenőrzése

Ha sikeres, az adatbázis(ok) automatikusan létrejönnek a másodlagos replikán a következő állapottal:

• SZINKRONIZÁLVA, ha a másodlagos replika szinkronizálásra van konfigurálva, és az adatok szinkronizálva lesznek.
• SZINKRONIZÁLÁS, ha a másodlagos replika aszinkron adatáthelyezéssel van konfigurálva, vagy szinkronizált, de még nincs szinkronizálva az elsődleges replikával.

Az alábbiakban ismertetett dinamikus felügyeleti nézetek mellett az automatikus vetés megkezdése és befejezése is látható a SQL Server naplóban:

A biztonsági mentés és a visszaállítás kombinálása automatikus vetéssel

A hagyományos biztonsági mentést, másolást és visszaállítást kombinálhatja az automatikus vetéssel. Ebben az esetben először állítsa vissza az adatbázist egy másodlagos replikára, az összes elérhető tranzakciónaplóval együtt. Ezután engedélyezze az automatikus inicializálást a rendelkezésre állási csoport létrehozásakor, hogy a másodlagos replika adatbázisa „felzárkózzon”, mintha visszaállították volna a naplófájl végéről készült biztonsági mentést (lásd: Naplófájl-végi biztonsági mentések (SQL Server)).

Adatbázis hozzáadása egy rendelkezésre állási csoporthoz automatikus vetéssel

Adatbázist adhat hozzá egy rendelkezésre állási csoporthoz automatikus vetéssel Transact-SQL vagy SQL Server Management Studio használatával (SSMS, 17-es vagy újabb verzió). Ha a másodlagos replika automatikus vetést használt a rendelkezésre állási csoporthoz való hozzáadásakor, nincs szükség további teendőkre. Ha a másodlagos replika biztonsági mentést, másolást és visszaállítást használt, először módosítsa a bevetési módot (lásd a következő szakaszt), majd az adatbázis hozzáadásakor használja az GRANT utasítást – lásd : Rendelkezésre állási csoport – Adatbázis hozzáadása.

Replika vetésmódjának módosítása

A replika vetésmódja a rendelkezésre állási csoport létrehozása után módosítható, így az automatikus vetés engedélyezhető vagy letiltható. Az automatikus vetés engedélyezése a létrehozás után lehetővé teszi egy adatbázis hozzáadását a rendelkezésre állási csoporthoz automatikus vetéssel, ha biztonsági mentéssel, másolással és visszaállítással hozták létre. Például:

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

Az automatikus vetés letiltásához használja a MANUÁLIS értéket.

Automatikus magvetés megakadályozása rendelkezésre állási csoport létrehozása után

Ha nem szeretné teljesen letiltani az automatikus szinkronizálást egy másodlagos replika számára, de ideiglenesen meg szeretné akadályozni, hogy a másodlagos replika automatikusan hozzon létre adatbázisokat, tagadja meg a rendelkezésre állási csoport CREATE engedélyét. Ez a helyzet akkor, ha új adatbázist adnak hozzá a rendelkezésre állási csoporthoz, de a rendelkezésre állási csoport nem hozhatja létre az adatbázist egy másodlagos replikán.

ALTER AVAILABILITY GROUP [AGName] 
    DENY CREATE ANY DATABASE
GO

Automatikus vetés monitorozása

Az automatikus vetés monitorozásának és hibaelhárításának négy módja van:

• SQL Server napló a már leírt módon
• Dinamikus felügyeleti nézetek
• Biztonsági mentési előzménytáblák
• Bővített események

Dinamikus felügyeleti nézetek

A magvetés monitorozásához két dinamikus felügyeleti nézet (DMV) érhető el: sys.dm_hadr_automatic_seeding és sys.dm_hadr_physical_seeding_stats.

• sys.dm_hadr_automatic_seeding tartalmazza az automatikus vetés általános állapotát, és megőrzi az előzményeket minden egyes végrehajtáskor (akár sikeres, akár nem). Az oszlop current_state értéke KÉSZ vagy SIKERTELEN. Ha az érték FAILED, használja a(z) failure_state_desc mezőben lévő értéket a probléma diagnosztizálásához. Előfordulhat, hogy kombinálnia kell a SQL Server naplóban szereplő adatokkal, hogy lássa, mi történt. Ez a DMV az elsődleges és az összes másodlagos replikán is fel van töltve adatokkal.

• sys.dm_hadr_physical_seeding_stats az automatikus vetési művelet állapotát jeleníti meg a végrehajtás során. A sys.dm_hadr_automatic_seeding-hoz hasonlóan ez az elsődleges és a másodlagos replika értékeit is visszaadja, de ez az előzmény nincs tárolva. Az értékek csak az aktuális végrehajtáshoz tartoznak, és nem maradnak meg. Az érintett oszlopok közé tartoznak start_time_utc, end_time_utc, estimate_time_complete_utc, total_disk_io_wait_time_ms, total_network_wait_time_ms, valamint sikertelen inicializálási művelet esetén a failure_message.

A biztonsági mentések előzménytáblái

Az automatikus vetés emellett bejegyzéseket is elhelyez a msdb táblákban, amelyek a biztonsági mentések és visszaállítások előzményeit tárolják. Az automatikus inicializálást fogadó másodlagos replikán a backupmediafamily tábla physical_device_name oszlopában egy GUID szerepel értékként, és a backupset megfelelő bejegyzésében a server_name és machine_name mezőkben az elsődleges replika neve szerepel.

Bővített események

Az automatikus vetés új kiterjesztett eseményeket ad hozzá az állapotváltozások, a hibák és a teljesítménystatisztikák inicializálás során történő nyomon követéséhez. Az alábbi szkript például egy bővített esemény munkamenetet hoz létre, amely rögzíti az automatikus vetéssel kapcsolatos eseményeket.

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

Az alábbi táblázat az automatikus vetéssel kapcsolatos kiterjesztett eseményeket sorolja fel.

Név	Description
hadr_db_manager_seeding_request_msg	A vetéskérés üzenete.
hadr_physical_seeding_backup_state_change	A fizikai beültetés biztonsági mentési oldali állapotváltozása.
hadr_physical_seeding_restore_state_change	A fizikai magvetés visszaállítási oldalának állapota megváltozik.
hadr_physical_seeding_forwarder_state_change	A fizikai vetéstovábbító oldalállapotának változása.
A fizikai inicializálási továbbító célállapotának változása a HADR-ben	A fizikai vetéstovábbító céloldali állapotváltozása.
hadr_physical_seeding_submit_callback	A fizikai magvetés visszahívási eseményt küld.
hadr_physical_seeding_failure	Fizikai magvetési hibaesemény.
HADR fizikai inicializálás előrehaladása	Fizikai magvetési folyamat eseménye.
A HADR fizikai inicializálási hosszú feladat ütemezése sikertelen	A fizikai vetés ütemezésének hosszúfeladat-sikertelenségi eseménye.
hadr_automatic_seeding_start	Akkor fordul elő, amikor egy automatikus seedelési műveletet beküldenek.
hadr_automatic_seeding_state_transition	Akkor fordul elő, ha egy automatikus vetési művelet állapota megváltozik.
hadr_automatic_seeding_success	Akkor fordul elő, ha egy automatikus vetés sikeres.
hadr_automatic_seeding_failure	Akkor fordul elő, ha egy automatikus vetési művelet meghiúsul.
hadr_automatic_seeding_timeout	Akkor fordul elő, ha egy automatikus vetési művelet túllépi az időkorlátot.

Lásd még

ALTER AVAILABILITY GROUP (Transact-SQL)

CREATE AVAILABILITY GROUP (Transact-SQL)

Always On rendelkezésre állási csoportok hibaelhárítási és monitorozási útmutatója