Sdílet prostřednictvím

Zálohování skupin dostupnosti Always On v SQL Serveru

Azure Backup nabízí kompletní podporu zálohování SQL Serveru vždy ve skupinách dostupnosti (AG), pokud jsou všechny uzly ve stejné oblasti a předplatném jako trezor služby Recovery Services. Pokud jsou ale uzly skupiny dostupnosti rozložené mezi oblasti, předplatná nebo místní prostředí a Azure, je potřeba vzít v úvahu několik aspektů.

Poznámka:

  • Služba Azure Backup nepodporuje zálohování databází skupiny dostupnosti Basic.
  • Další informace o podporovaných konfiguracích a scénářích najdete v matici podpory zálohování SQL.

Předvolba zálohování používaná službou Azure Backup SQL AG podporuje úplné a rozdílové zálohy pouze z primární repliky. Tyto úlohy zálohování se proto vždy spouštějí na primárním uzlu bez ohledu na předvolbu zálohování. Pro úplné zálohování protokolů kopírování a transakčních protokolů se při rozhodování o uzlu, na kterém se bude spouštět zálohování, se považuje předvolba zálohování skupiny dostupnosti.

Předvolba zálohování AG Úplné a rozdílové zálohy běží na Copy-Only a zálohy protokolů jsou pořízeny z
Primární Primární replika Primární replika
Pouze sekundární Primární replika Libovolná ze sekundárních replik
Preferovat sekundární Primární replika Upřednostňované jsou sekundární repliky, ale zálohy se můžou spouštět i na primární replice.
Žádné/Jakékoliv Primární replika Libovolná replika

Rozšíření zálohování úloh se nainstaluje na uzel, když ho zaregistrujete ve službě Azure Backup. Při konfiguraci databáze skupiny dostupnosti pro zálohování se plány zálohování nasdílí do všech registrovaných uzlů skupiny dostupnosti. Plány se spustí na všech uzlech AG a rozšíření zálohování úloh na těchto uzlech se mezi sebou synchronizují, aby rozhodly, který uzel může provést zálohování. Výběr uzlu závisí na typu zálohování a předvolbě zálohování, jak je vysvětleno v části 1.

Vybraný uzel pokračuje v úloze zálohování, zatímco úloha spuštěná na ostatních uzlech se zastaví, tedy se přeskočí.

Poznámka:

Azure Backup při rozhodování mezi sekundárními replikami nebere v úvahu priority zálohování ani repliky.

Registrace uzlů AG do trezoru služby Recovery Services

Trezor služby Recovery Services podporuje zálohování databází pouze z virtuálních počítačů ve stejné oblasti a předplatném jako trezor.

  • Zaregistrujte primární uzel do trezoru (jinak nebude možné provést úplné zálohování).
  • Pokud je předvolba zálohování pouze sekundární, zaregistrujte alespoň jeden sekundární uzel do úložiště (jinak nemůže dojít k úplnému zálohování logu nebo kopírování).

Konfigurace záloh pro databáze skupiny dostupnosti selže s kódem chyby FabricSvcBackupPreferenceCheckFailedUserError, pokud nejsou splněny výše uvedené podmínky.

Podívejme se na následující nasazení AG jako vzor.

Diagram nasazení AG jako referenční

Na základě dané ukázky nasazení AG je třeba zvážit různé aspekty:

  • Protože primární uzel je v oblasti 1 a předplatném 1, musí být trezor služby Recovery Services (Trezor 1) také v oblasti 1 a předplatném 1 pro ochranu této AG.
  • VM3 Ve službě Vault 1 se nedá zaregistrovat, protože se jedná o jiné předplatné.
  • VM4 nelze zaregistrovat do Vault 1, protože se nachází v jiném regionu.
  • Pokud je předvolba zálohování jenom sekundární, virtuální počítač VM1 (primární) a virtuální počítač 2 (sekundární) musí být zaregistrované v trezoru 1 (protože úplné zálohování vyžaduje primární uzel a protokoly vyžadují sekundární uzel). V případě jiných předvoleb zálohování musí být virtuální počítač 1 (primární) zaregistrovaný ve službě Vault 1, virtuální počítač 2 je volitelný (protože všechny zálohy můžou běžet na primárním uzlu).
  • I když se virtuální počítač VM3 může být zaregistrován do trezoru 2 v předplatném 2 a databáze skupiny dostupnosti by se pak zobrazily pro ochranu v trezoru 2, kvůli absenci primárního uzlu v trezoru 2 by konfigurace zálohování nefungovala.
  • Podobně, i když lze VM4 zaregistrovat do trezoru 4 v oblasti 2, konfigurace záloh nebude úspěšná, je-li primární uzel neregistrován v trezoru 4.

Převzetí služeb při selhání

Poté, co skupina dostupnosti selhala a přešla na jeden ze sekundárních uzlů:

  • Úplné a rozdílové zálohy budou pokračovat z nového primárního uzlu, pokud je zaregistrovaný v úložišti.
  • Úplné zálohy logů a kopie pouze úplné zálohy budou prováděny z primárního nebo sekundárního uzlu na základě nastavení zálohování.

Poznámka:

K přerušení řetězu protokolů nedojde při přepnutí při selhání, pokud se toto neshoduje se zálohováním.

Na základě výše uvedeného ukázkového nasazení skupiny dostupnosti existují různé možnosti převzetí služeb při selhání:

  • Převzetí služeb na virtuální stroj 2
    • Úplné a rozdílové zálohování proběhne z virtuálního počítače VM2.
    • Úplné zálohování záznamů a pouze kopírujících plných záloh bude probíhat z virtuálního počítače VM1 nebo VM2 podle preferencí zálohování.
  • Přepnutí na VM3 (jiné předplatné)
    • Vzhledem k tomu, že se v trezoru 2 nenakonfigurují zálohy, nedojde k žádným zálohám.
    • Pokud předvolba zálohování není jenom sekundární, je možné nyní v trezoru 2 nakonfigurovat zálohy, protože primární uzel je v tomto trezoru zaregistrovaný. To ale může vést ke konfliktům nebo selháním zálohování. Další informace najdete v tématu Konfigurace záloh skupiny dostupnosti ve více oblastech.
  • Přepnutí na VM4 (jiný region)
    • Vzhledem k tomu, že se zálohy ve službě Vault 4 nenakonfigurují, nedojde k žádným zálohám.
    • Pokud předvolba zálohování není jenom sekundární, je možné zálohování nakonfigurovat v trezoru 4, protože primární uzel je v tomto trezoru zaregistrovaný. To ale může vést ke konfliktům nebo selháním zálohování. Další informace najdete v tématu Konfigurace záloh skupiny dostupnosti ve více oblastech.

Konfigurace záloh pro více oblastí skupiny dostupnosti

Trezor služby Recovery Services nepodporuje zálohování mezi předplatnými ani mezi oblastmi. Tato část shrnuje, jak povolit zálohování skupin AG, které pokrývají předplatná nebo oblasti Azure, a související aspekty.

  • Vyhodnoťte, jestli opravdu potřebujete povolit zálohování ze všech uzlů. Pokud má jedna z oblastí nebo předplatných většinu AG uzlů a převzetí při selhání k jiným uzlům dochází velmi zřídka, může být nastavení zálohování v první oblasti dostačující. Pokud k přepojení do jiné oblasti nebo předplatného dochází často a na delší dobu, možná byste měli v této jiné oblasti proaktivně nastavit i zálohy.

  • Každý trezor, ve kterém se zálohování povolí, bude mít vlastní sadu řetězů bodů obnovení. Obnovení z těchto bodů obnovení je možné provést pouze na virtuální počítače zaregistrované v daném trezoru.

  • Úplné nebo rozdílové zálohování proběhne úspěšně pouze v trezoru, který má primární uzel. Tyto zálohy v jiných trezorech zůstanou neúspěšné.

  • Zálohy protokolů budou dál fungovat v předchozím trezoru, dokud se v novém trezoru nespustí záloha protokolu (to znamená v trezoru, kde je k dispozici nový primární uzel) a přeruší řetěz protokolů pro starý trezor.

    Poznámka:

    Existuje pevný limit 15 dnů, po jehož překročení začnou zálohy protokolů selhávat.

  • Zálohy typu pouze kopírování budou fungovat ve všech trezorech.

  • Ochrana v každém trezoru je považována za samostatný zdroj dat a je účtována samostatně.

Pokud se chcete vyhnout konfliktům zálohování protokolů mezi těmito dvěma trezory, doporučujeme nastavit předvolbu zálohování na primární. Podle toho, který trezor má primární uzel, pak také provede zálohování protokolů.

Tady je postup povolení zálohování ze všech uzlů na základě výše uvedeného ukázkového nasazení skupiny dostupnosti. Předpokladem je, že předvolba zálohování je ve všech krocích splněná.

Krok 1: Povolte zálohy v Regionu 1, Předplatné 1 (Trezor 1)

Vzhledem k tomu, že primární uzel je v oblasti a v rámci předplatného, budou fungovat obvyklé kroky pro aktivaci záloh.

Krok 2: Aktivace záloh v oblasti 1, předplatné 2 (Úložiště 2)

  1. Přepněte AG na virtuální počítač 3, aby byl primární uzel v trezoru 2.
  2. Nakonfigurujte zálohy pro databáze AG ve službě Vault 2.
  3. V tomto okamžiku:
    1. Úplné nebo rozdílové zálohy v trezoru 1 selžou, protože tuto zálohu nemůže provést žádný z registrovaných uzlů.
    2. Zálohování protokolů bude v trezoru Vault 1 úspěšné dokud se nespustí záloha protokolu ve trezoru Vault 2 a přeruší řetěz protokolů pro trezor Vault 1.
  4. Přepněte AG zpět na VM1.

Krok 3: Povolení záloh v Regionu 2, Předplatné 1 (Vault 4)

Stejné jako krok 2.

Zálohování AG zahrnující Azure a on-premises

Azure Backup pro SQL Server nejde spustit místně. Pokud je primární uzel v Azure a předvolba zálohování je splněna uzly v Azure, můžete postupovat podle výše uvedených pokynů pro skupiny dostupnosti napříč regiony a povolit zálohování replik v Azure. Pokud dojde k převzetí služeb při selhání do místního uzlu, úplné a rozdílové zálohy v Azure se začnou selhávat. Zálohování protokolů může pokračovat, dokud nedojde k přerušení řetězu protokolů nebo neuplyne 15 dní.

Omezování úloh zálohování v databázi AG

Limity omezování zálohování se v současné době vztahují na úrovni jednotlivých počítačů. Výchozí limit je 20 – pokud se souběžně aktivuje více než 20 záloh, spustí se prvních 20 a ostatní se zařadí do fronty. Po dokončení spuštěných úloh se začnou spouštět zařazené úlohy.

Tuto hodnotu můžete změnit na menší hodnotu, pokud souběžné zálohování způsobuje zatížení paměti, vstupně-výstupních operací a procesoru na uzlu. Jelikož je omezování na úrovni uzlu, nevyvážené uzly skupiny dostupnosti (AG) mohou vést k problémům se synchronizací zálohování. Abyste tomu porozuměli, zvažte například 2 uzly dostupnostní skupiny.

První uzel má například 50 samostatných databází chráněných a oba uzly mají chráněnou 5 databází skupiny dostupnosti. Uzel 1 má naplánováno 55 úloh zálohování databáze, zatímco uzel 2 má pouze 5. Všechny tyto zálohy se také konfigurují tak, aby běžely současně každou hodinu. V určitém okamžiku bude všech 55 záloh aktivováno na uzlu 1 a 35 z nich bude zařazeno do fronty. Některé z nich by byly zálohy databáze AG. Na uzlu 2 by ale zálohy databáze AG pokračovaly bez jakéhokoli řazení do fronty.

Protože se úlohy databáze AG zařadí do fronty na jednom uzlu a běží na jiném, synchronizace zálohování (uvedená v části 6) nebude správně fungovat. Uzel 2 může předpokládat, že uzel 1 je mimo provoz, a proto se nechystá synchronizace úloh. To může vést k přerušení řetězu protokolů nebo dalším zálohám, protože oba uzly mohou nezávisle provádět zálohy.

Podobný problém může nastat, pokud je počet chráněných databází dostupnostní skupiny větší než hranice omezování. V takovém případě může být zálohování například databáze DB1 zařazeno do fronty na uzlu 1, zatímco běží na uzlu 2.

Doporučujeme použít následující předvolby zálohování, abyste se vyhnuli těmto problémům se synchronizací:

  • V případě 2 uzlové skupiny dostupnosti nastavte předvolbu zálohování pouze na primární nebo sekundární – pak zálohy může provádět pouze jeden uzel, druhý se vždy vzdá.
  • V případě skupiny dostupnosti s více než 2 uzly nastavte předvolbu zálohování na Primární – poté může zálohování provádět pouze primární uzel, ostatní se nebudou podílet.

Fakturace záloh skupiny dostupnosti

Stejně jako samostatná instance SQL se jedna zálohovaná instance skupiny dostupnosti považuje za jednu chráněnou instanci. Celková velikost přední části všech chráněných databází v instanci je zpoplatněna. Zvažte následující nasazení:

Diagram znázorňující výpočet chráněných instancí databází

Chráněné instance se počítají takto:

Chráněná instance nebo instance fakturace Databáze, které se považují za výpočet velikosti front-endu
Skupina dostupnosti 1 DB1, DB2
Skupina dostupnosti 2 DB4
Virtuální počítač 2 DB3
VM3 DB6
Virtuální počítač 4 DB5

Přesun chráněné databáze do a ze skupiny dostupnosti

Azure Backup považuje název instance SQL nebo název skupiny dostupnosti\Název databáze za jedinečný název databáze. Když byla samostatná databáze chráněna, její jedinečný název byl StandAloneInstanceName\DBName. Když se přesune pod AG, název se změní na AGName\DBName. Zálohy pro samostatnou databázi začnou selhávat s kódem chyby: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

Databáze musí být nakonfigurovaná pro ochranu pod AG. To bude považováno za nový zdroj dat s odděleným řetězem bodů obnovení. Aby se zabránilo aktivaci a selhání budoucích záloh, starší ochranu nezávislé databáze lze zastavit při zachování dat. Podobně platí, že když se chráněná databáze skupiny dostupnosti přesune mimo skupinu dostupnosti a stane se samostatnou databází, její zálohy začnou selhávají s kódem chyby : UserErrorBackupFailedDatabaseMovedOutOfAG.

Databáze musí být nakonfigurována pro ochranu ze samostatné instance. To bude považováno za nový zdroj dat s odděleným řetězem bodů obnovení. Původní ochrana databáze skupiny dostupnosti může být zastavena s možností uchování dat, aby se předešlo aktivaci a selhání budoucích záloh.

Přidání nebo odebrání uzlu ve skupině dostupnosti

Když se do skupiny dostupnosti, která je nakonfigurovaná pro zálohování, přidá nový uzel, rozšíření zálohování úloh spuštěná na již registrovaných uzlech skupiny dostupnosti zjistí změnu topologie skupiny dostupnosti a během další naplánované úlohy zjišťování databáze informuje službu Azure Backup. Když je tento nový uzel zaregistrován pro zálohování do stejného trezoru služby Recovery Services jako ostatní existující uzly, služba Azure Backup spustí pracovní postup, který nakonfiguruje tento nový uzel s potřebnými metadaty pro provádění záloh dostupnostních skupin.

Poté nový uzel synchronizuje informace o plánu zálohování z Azure Backup služby a začne se podílet na synchronizovaném procesu zálohování. Pokud nový uzel nedokáže synchronizovat harmonogramy zálohování a účastnit se zálohovacích procesů, spuštění opětovné registrace uzlu vynutí také jeho rekonfiguraci pro zálohy v rámci skupiny dostupnosti. Při přidání uzlu rozšíření úloh podobně detekují změnu topologie skupiny dostupnosti a informují službu Azure Backup v tomto případě. Služba spustí pracovní postup zrušení konfigurace uzlu na odebraném uzlu, který vymaže plány zálohování pro databáze skupiny dostupnosti a odstraní metadata související se skupinami dostupnosti.

Odstranit registraci uzlu AG ze služby Azure Backup

Pokud je uzel součástí skupiny dostupnosti, která má jednu nebo více databází nakonfigurovaných pro zálohování, Azure Backup nepovolí odregistraci tohoto uzlu. Tím zabráníte budoucím selháním zálohování v případě, že se předvolba zálohování nedá splnit bez tohoto uzlu. Pokud chcete zrušit registraci uzlu, musíte ho nejprve odebrat z AG. Jakmile se pracovní postup zrušení konfigurace uzlu dokončí, můžete ho vyčistit a zrušit jeho registraci.

Obnovení databáze ze služby Azure Backup do skupin dostupnosti SQL skupiny dostupnosti nepodporuje přímé obnovení databáze do skupiny dostupnosti. Databázi je potřeba obnovit do samostatné instance SQL a pak je potřeba ji připojit ke skupině dostupnosti.

Scénáře opětovného vytvoření skupiny dostupnosti pro databázový server SQL

Opětovné vytvoření skupiny dostupnosti (AG), duplicitních skupin AG a zálohovaných položek se zobrazí jako položky k ochraně nebo chráněné položky v následujících scénářích:

  • Opětovné vytvoření skupin AG, které jsou již chráněné, se zobrazí jako duplicitní skupiny AG na stránce Konfigurovat zálohování a v seznamu Chráněné položky . Pokud chcete zachovat zálohovaná data, která už existují ve starší skupině dostupnosti, zastavte zálohování pomocí možnosti Zastavit ochranu a zachovat data před opětovným vytvořením a plánováním záloh u nových položek skupiny dostupnosti.

    Služba Azure Backup vypíše duplicitní položky v seznamu chráněných položek a na stránce Konfigurovat zálohování nebo seznam chráněných položek a zobrazí tyto položky, dokud nebudete chtít zachovat zálohovaná data.

  • Pokud nechcete zálohovat data ze starší skupiny dostupnosti, zastavte operaci zálohování pomocí možnosti Zastavit ochranu a odstranit data pro starší položku před opětovným vytvořením a plánováním záloh v nové skupině dostupnosti.

    Upozornění

    Zastavení ochrany a odstranění dat je destruktivní operace.

  • Skupinu dostupnosti (AG) můžete znovu vytvořit po provedení některého z výše uvedených procesů ukončení zabezpečení, abyste předešli selhání zálohování.

Další kroky

Naučte se jak:

Související obsah

  • Last updated on