Aktivní geografická replikace

Applies to:Azure SQL Database

Tento článek obsahuje přehled funkce aktivní geografické replikace pro Azure SQL Database, která umožňuje nepřetržitě replikovat data z primární databáze do čitelné sekundární databáze. Sekundární databáze čitelná může být ve stejné Azure oblasti jako primární nebo častěji v jiné oblasti. Tento druh čitelné sekundární databáze se také označuje jako geografická sekundární nebo geografická replika.

Aktivní geografická replikace je nakonfigurovaná pro každou databázi. Pokud chcete převzít služby při selhání skupiny databází nebo pokud vaše aplikace vyžaduje stabilní koncový bod připojení, zvažte místo toho skupiny převzetí služeb při selhání.

Můžete také migrovat databázi SQL s aktivní geografickou replikací.

Přehled

Aktivní geografická replikace je navržená jako řešení provozní kontinuity. Aktivní geografická replikace umožňuje provádět rychlé zotavení po havárii jednotlivých databází, pokud dojde k regionální havárii nebo rozsáhlému výpadku. Po nastavení geografické replikace můžete v jiné oblasti Azure zahájit geografické převzetí na sekundární oblast. Geografické převzetí služeb při selhání je programově řízeno ze strany aplikace nebo je prováděno ručně uživatelem.

Následující diagram znázorňuje typickou konfiguraci geograficky redundantní cloudové aplikace využívající aktivní geografickou replikaci.

Diagram aktivní geografické replikace

Pokud vaše primární databáze z nějakého důvodu selže, můžete zahájit geografické převzetí služeb při selhání do jakékoli sekundární databáze. Při povýšení sekundárního na primární roli se všechny ostatní sekundární role automaticky propojí s novou primární rolí.

Geografickou replikaci můžete spravovat a zahájit geografické převzetí služeb při selhání pomocí některé z následujících metod:

Aktivní geografická replikace používá technologii skupiny dostupnosti AlwaysOn k asynchronní replikaci transakčního protokolu generovaného na primární replice do všech geografických replik. Přestože sekundární databáze může v libovolném okamžiku mírně zaostávat za primární databází, je zaručeno, že data v sekundární databázi jsou transakčně konzistentní. Jinými slovy, změny provedené nepotvrzenými transakcemi nejsou viditelné.

Poznámka:

Aktivní geografická replikace replikuje změny streamováním transakčního protokolu databáze z primární repliky do sekundárních replik. Nesouvisí s transakční replikací, která replikuje změny spuštěním příkazů DML (INSERT, UPDATE, DELETE) pro odběratele.

Geografická replikace poskytuje regionální redundanci. Regionální redundance umožňuje aplikacím rychle se zotavit z trvalé ztráty celé Azure oblasti nebo částí oblasti, způsobené přírodními katastrofami, katastrofickými lidskými chybami nebo škodlivými činy. RPO (cíl bodu obnovení) geografické replikace najdete v Provozní kontinuita v Azure SQL Database.

Následující obrázek znázorňuje příklad aktivní geografické replikace nakonfigurované s primární oblastí USA – západ 2 a geografickou sekundární oblastí v oblasti USA – východ.

Screenshot portálu Azure zobrazující relaci geografické replikace databáze SQL Database.

Kromě zotavení po havárii je možné aktivní geografickou replikaci použít v následujících scénářích:

  • Migrace databáze: K migraci databáze z jednoho serveru do druhého s minimálními výpadky můžete použít aktivní geografickou replikaci.
  • Upgrady aplikací: Během upgradů aplikací můžete vytvořit další sekundární kopii jako kopii pro návrat v případě potřeby.

Pokud chcete dosáhnout plné kontinuity podnikových procesů, přidání regionální redundance databáze je pouze součástí řešení. Obnovení aplikace (služby) po závažném selhání vyžaduje obnovení všech komponent, které tvoří službu a všechny závislé služby. Mezi tyto komponenty patří klientský software (například prohlížeč s vlastním JavaScriptem), webové front-endy, úložiště a DNS. Je důležité, aby všechny komponenty byly odolné vůči stejným chybám a byly k dispozici v rámci cíle doby obnovení (RTO) vaší aplikace. Proto potřebujete identifikovat všechny závislé služby a porozumět zárukám a možnostem, které poskytují. Pak musíte provést odpovídající kroky, abyste zajistili, že vaše služba bude fungovat během převzetí služeb při selhání služeb, na kterých závisí. Další informace o navrhování řešení pro zotavení po havárii najdete v tématu Designing globálně dostupných služeb pomocí Azure SQL Database.

Terminologie a možnosti

  • Automatická asynchronní replikace: Pro existující databázi můžete vytvořit pouze geografickou sekundární oblast. Geograficky sekundární je možné vytvořit na libovolném logickém serveru, který není serverem s primární databází. Po vytvoření se sekundární geografická replika naplní daty primární databáze. Tento proces se označuje jako zahájení. Po vytvoření a připravení geografické sekundární repliky se aktualizace primární databáze automaticky a asynchronně replikují do této geograficky sekundární repliky. Asynchronní replikace znamená, že transakce se před replikací potvrdí v primární databázi.

  • Čitelné geograficky sekundární repliky: Aplikace má přístup k geograficky sekundární replice, aby spouštěla dotazy jen pro čtení pomocí stejných nebo různých bezpečnostních principálů používaných k přístupu k primární databázi. Další informace najdete v tématu Používání replik určených pouze pro čtení pro odlehčení dotazů určených pouze pro čtení.

Důležité

Geografickou replikaci můžete použít k vytvoření sekundárních replik ve stejné oblasti jako primární. Tyto druhotné instance můžete použít pro scénáře škálování čtení ve stejné oblasti. Sekundární replika ve stejném regionu však neposkytuje dodatečnou odolnost proti katastrofickým selháním nebo výpadkům velkého rozsahu, a proto není vhodným cílem zajištění kontinuity služeb pro účely zotavení po havárii. Nezaručuje také izolaci zón dostupnosti. K zajištění izolace zóny dostupnosti použijte úrovně služby Business Critical nebo Premium s konfigurací zónově redundantní nebo úroveň služby General Purpose s konfigurací zónově redundantní.

  • Převzetí služeb při selhání (bez ztráty dat): Při spuštění této operace se před přepnutím rolí primárních a geograficky sekundárních databází dokončí celý proces synchronizace dat. Tím zajistíte, že nedojde ke ztrátě dat. Doba trvání převzetí služeb závisí na velikosti transakčního protokolu na primárním serveru, který je potřeba synchronizovat s geosekundární oblastí. Přepnutí při selhání je určeno pro následující scénáře:

    • Provádějte nácviky zotavení po havárii v produkčním prostředí, když je ztráta dat nepřijatelná
    • Přemístění databáze do jiné oblasti
    • Po zmírnění výpadku vraťte databázi do primární oblasti (známé jako failback).

  • Vynucené převzetí služeb při selhání (potenciální ztráta dat):Vynucené převzetí služeb při selhání okamžitě přepne geograficky sekundární na primární roli bez čekání na synchronizaci s primární rolí. Všechny transakce potvrzené na primárním serveru, ale dosud nereplikované na sekundární server, jsou ztraceny. Tato operace je navržená jako metoda obnovení během výpadků, pokud primární server není přístupný, ale dostupnost databáze se musí rychle obnovit. Když je původní primární opět online, automaticky se znovu připojí, znovu inicializuje pomocí aktuálních dat z primární a stane se novým sekundárním uzlem.

Důležité

Po failoveru nebo vynuceném failoveru se koncový bod spojení pro nový primární server změní, protože teď je umístěn na jiném logickém serveru.

  • Několik čitelných geografických sekundárních instancí: Pro primární instanci je možné vytvořit až čtyři geografické sekundáry. Pokud existuje pouze jedna sekundární a selže, aplikace je vystavena vyššímu riziku, dokud se nevytvořila nová sekundární. Pokud existuje více sekundárních souborů, zůstane aplikace chráněná i v případě, že některý z sekundárů selže. Další sekundární instance lze také použít k horizontálnímu škálování úloh pouze pro čtení.

Návod

Pokud používáte aktivní geografickou replikaci k vytvoření globálně distribuované aplikace a potřebujete poskytnout přístup jen pro čtení k datům ve více než čtyřech oblastech, můžete vytvořit sekundární ze sekundárního (proces známý jako řetězení) a tím vytvořit další geo-repliky. Prodleva replikace u zřetězených geografických replik může být vyšší než u geografických replik připojených přímo k primárnímu serveru. Nastavení zřetězených topologií geografické replikace se podporuje jenom prostřednictvím kódu programu, a ne z portálu Azure.

  • Geografická replikace databází v elastickém fondu: Každá geografická sekundární databáze může být jedna databáze nebo databáze v elastickém fondu. Volba elastického fondu pro každou geografickou sekundární databázi je oddělená a nezávisí na konfiguraci žádné jiné repliky v topologii (primární nebo sekundární). Každý elastický pool je součástí jednoho logického serveru. Vzhledem k tomu, že názvy databází na logickém serveru musí být jedinečné, nemohou geografické sekundární repliky stejné primární databáze nikdy sdílet elastický databázový fond.

  • Geograficky řízené geografické převzetí služeb při selhání a navrácení služeb po obnovení: Geograficky sekundární oblast, která dokončila počáteční počáteční předsazení, se dá explicitně přepnout na primární roli (převzetí služeb při selhání) kdykoli aplikací nebo uživatelem. Během výpadku kdy je primární server nepřístupný, lze použít pouze vynucené převzetí služeb při selhání, které okamžitě povyšuje geografickou sekundaru na novou primární. Když dojde ke zmírnění výpadku, systém automaticky změní obnovenou primární databázi na geografickou sekundární a synchronizuje ji s novou primární. Vzhledem k asynchronní povaze geografické replikace mohou být nedávné transakce během vynuceného převzetí při selhání ztraceny, pokud primární systém selže dříve, než se tyto transakce replikují na geografické sekundární. Když dojde k převzetí při selhání primárního serveru s více geografickými sekundárními servery, systém automaticky překonfiguruje relace replikace a propojí zbývající geografické sekundární servery s nově povýšeným primárním serverem bez nutnosti zásahu uživatele. Po zmírnění výpadku, který způsobil geografické přepnutí při selhání, může být žádoucí vrátit primární server do původní oblasti. Provedete to ručním přepnutím při selhání.

  • Pohotovostní replika: Pokud se sekundární replika používá jenom pro zotavení po havárii (DR) a nemá žádné úlohy čtení nebo zápisu, můžete tuto repliku určit jako pohotovostní , abyste ušetřili náklady na licence.

Příprava na geografický failover

Abyste se ujistili, že vaše aplikace bude mít po geografickém selhání okamžitý přístup k novému primárnímu serveru, ověřte, že máte správně nakonfigurováno ověřování a síťový přístup na váš sekundární server. Podrobnosti najdete v tématu Konfigurování a správa zabezpečení Azure SQL Database pro geografické obnovení nebo převzetí služeb při selhání. Ověřte také, že zásady uchovávání záloh v sekundární databázi odpovídají zásadám uchovávání záloh primární databáze. Toto nastavení není součástí databáze a nereplikuje se z primární databáze. Ve výchozím nastavení je geosekundární nakonfigurována s výchozí dobou uchovávání PITR sedm dnů. Další informace najdete v Automatizované zálohování v Azure SQL Database.

Důležité

Pokud je vaše databáze členem skupiny převzetí služeb při selhání, nemůžete zahájit převzetí služeb při selhání pomocí příkazu převzetí služeb při selhání geografické replikace. Použijte příkaz pro převzetí pro skupinu. Pokud potřebujete provést převzetí služeb jednotlivé databáze, musíte ji nejprve odebrat ze skupiny převzetí služeb. Prostudujte si přehled skupin pro převzetí služeb při selhání a osvědčené postupy (Azure SQL Database) pro podrobnosti.

Nastavit geografickou sekundární oblast

Primární i geograficky sekundární musí mít stejnou úroveň služby. Důrazně se také doporučuje nakonfigurovat sekundární geografickou oblast se stejnou redundancí úložiště zálohování, úrovní výpočetních prostředků (zřízenou nebo bezserverovou) a velikostí výpočetních prostředků (DTU nebo virtuálními jádry) jako primární. Pokud primární zátěž při zápisu zažívá velké zatížení, nemusí být geografický sekundární server s nižší výpočetní kapacitou schopný udržet krok. To způsobí prodlevu replikace v sekundární geografické oblasti a nakonec může způsobit nedostupnost geografické sekundární oblasti. Pro snížení těchto rizik aktivní geografická replikace v případě potřeby sníží rychlost transakčního záznamu primárního serveru, aby se sekundární servery mohly dohnat.

Dalším důsledkem nevyvážené geosekundární konfigurace je, že po převzetí služeb při selhání může výkon aplikace trpět kvůli nedostatečné výpočetní kapacitě nového primárního serveru. V takovém případě je potřeba vertikálně navýšit kapacitu databáze, aby získala dostatečné prostředky, což může trvat podstatně dlouho a vyžaduje failover s vysokou dostupností na konci procesu vertikálního navýšení kapacity, což může přerušit pracovní zátěž aplikací.

Návod

Podrobné pokyny k řešení potíží s prodlevou při geografické replikaci najdete v tématu Řešení potíží s opětovnou prodlevou geografické replikace.

Pokud se rozhodnete vytvořit geografickou sekundární oblast s jinou konfigurací, měli byste monitorovat rychlost vstupně-výstupních operací protokolu na primárním serveru v průběhu času. To vám umožní odhadnout minimální výpočetní kapacitu v sekundární geografické oblasti potřebnou pro udržení zátěže replikace. Pokud je například vaše primární databáze P6 (1000 DTU) a její vstupně-výstupní operace protokolu se udržují na 50 %, musí být geografická sekundární databáze alespoň na úrovni P4 (500 DTU). K načtení historických vstupně-výstupních dat protokolu použijte zobrazení sys.resource_stats . Pokud chcete načíst nedávné vstupně-výstupní data protokolu s vyšší členitostí, která lépe odráží krátkodobé špičky, použijte zobrazení sys.dm_db_resource_stats .

Návod

K omezování vstupně-výstupních operací transakčního protokolu může dojít v následujících scénářích:

Ve výchozím nastavení je redundance geografického sekundárního úložiště zálohování stejná jako pro primární databázi. Můžete nakonfigurovat geografickou sekundární oblast s jinou redundancí úložiště zálohování. Zálohy se vždy provádějí v primární databázi. Pokud je sekundární úložiště nakonfigurováné s jinou redundancí zálohovacího úložiště, po geografickém převzetí, kdy je geografické sekundární úložiště proměněno na primární, budou nové zálohy ukládány a účtovány podle typu úložiště (RA-GRS, ZRS, LRS) vybraného na nově primárním (dříve sekundárním) úložišti.

Úspora nákladů s pohotovostní replikou

Pokud se sekundární replika používá jenom pro zotavení po havárii (DR) a nemá žádné úlohy čtení nebo zápisu, můžete ušetřit náklady na licencování tím, že databázi navrhnete pro pohotovostní režim při konfiguraci nového aktivního vztahu geografické replikace.

Přezkoumejte pohotovostní repliku bez licence, abyste se dozvěděli více.

Geografická replikace mezi předplatnými

  • Pomocí portálu Azure můžete nastavit aktivní geografickou replikaci napříč předplatnými, pokud jsou obě předplatná ve stejném tenantovi Microsoft Entra.

    • Pokud chcete vytvořit geografickou sekundární repliku v jiném předplatném než je předplatné primárního tenanta v jiné organizaci Microsoft Entra, použijte ověřování SQL a T-SQL. Microsoft Entra ověření pro Azure SQL pro geografickou replikaci mezi předplatnými není podporováno, pokud je logický server v jiném tenantovi Azure.
    • Operace geografické replikace napříč předplatnými, včetně nastavení a geografického převzetí služeb, se podporují také pomocí rozhraní Databases Create nebo Update REST API.

  • Vytvoření geografické sekundární oblasti napříč předplatnými na logickém serveru ve stejném nebo jiném tenantovi Microsoft Entra se nepodporuje, pokud je na primárním nebo sekundárním logickém serveru povoleno pouze Microsoft Entra ověřování pro Azure SQL a vytvoření je-li použito uživatelem Microsoft Entra ID.

Metody a podrobné pokyny najdete v tématu Tutorial: Konfigurace aktivní geografické replikace a převzetí služeb při selhání (Azure SQL Database).

Privátní koncové body

Přidání geografické sekundární oblasti pomocí T-SQL se při připojování k primárnímu serveru přes privátní koncový bod nepodporuje.

Pokud je privátní koncový bod nakonfigurovaný, ale je povolený přístup k veřejné síti, přidání geografické sekundární oblasti se podporuje při připojení k primárnímu serveru z veřejné IP adresy.

Po přidání geo-sekundární oblasti může být odepřen přístup k veřejné síti.

Udržujte přihlašovací údaje a pravidla firewallu v synchronizaci

Při použití přístupu k veřejné síti pro připojení k databázi doporučujeme použít pravidla brány firewall protokolu IP na úrovni databáze pro geograficky replikované databáze. Tato pravidla jsou replikována do databáze, která zajišťuje, že všechny geografické sekundární servery mají stejná pravidla IP firewallu jako primární server. Tento přístup eliminuje potřebu ruční konfigurace a údržby pravidel brány firewall na serverech, které hostují primární a sekundární databáze. Podobně použití uživatelů databáze s omezením pro přístup k datům zajišťuje, že primární i sekundární databáze mají vždy stejné ověřovací přihlašovací údaje. Díky tomu po geografickém obnovení po havárii nedochází k přerušením kvůli neshodám přihlašovacích údajů. Pokud používáte přihlášení a uživatele (nikoli uživatele s omezením), musíte provést další kroky, abyste zajistili, že pro sekundární databázi existují stejná přihlášení. Podrobnosti o konfiguraci najdete v tématu Konfigurace a správa zabezpečení Azure SQL Database pro geografické obnovení nebo převzetí služeb při selhání.

Škálování primární databáze

Kapacitu primární databáze můžete zvýšit nebo snížit na jinou velikost výpočetních prostředků (ve stejné úrovni služby), aniž byste odpojili jakékoli geografické sekundární databáze. Při vertikálním navýšení kapacity doporučujeme nejprve vertikálně navýšit kapacitu databáze v sekundární geografické oblasti, a teprve pak vertikálně navýšit kapacitu primární databáze. V případě vertikálního snižování kapacity postupujte v opačném pořadí: nejprve vertikálně snižte kapacitu primární databáze, a teprve pak vertikálně snižte kapacitu sekundární databáze.

Informace o skupinách převzetí služeb při selhání najdete v tématu škálování repliky ve skupině převzetí služeb při selhání.

Zabránění ztrátě důležitých dat

Kvůli vysoké latenci širokých sítí používá geografická replikace mechanismus asynchronní replikace. Asynchronní replikace činí možnost ztráty dat nevyhnutelnou, pokud primární systém selže. Aby bylo možné chránit důležité transakce před ztrátou dat, vývojář aplikace může okamžitě po potvrzení transakce zavolat sp_wait_for_database_copy_sync uloženou proceduru. Volání sp_wait_for_database_copy_sync blokuje volající vlákno, dokud poslední potvrzená transakce nebyla přenesena a zakotvena v transakčním protokolu sekundární databáze. Také čeká na opakované přehrání odeslaných transakcí na sekundárním systému. Uložená sp_wait_for_database_copy_sync procedura systému je vymezena na konkrétní linku geografické replikace. Tento postup může volat každý uživatel s právy k připojení k primární databázi.

Poznámka:

sp_wait_for_database_copy_sync zabraňuje ztrátě dat po geografickém převzetí služeb při selhání pro konkrétní transakce, ale nezaručuje úplnou synchronizaci pro přístup ke čtení. Zpoždění způsobené voláním sp_wait_for_database_copy_sync procedury může být významné a závisí na velikosti dosud nepřesílaného transakčního protokolu v primárním okamžiku volání.

Monitorování prodlevy geografické replikace

Pokud chcete monitorovat prodlevu s ohledem na Recovery Point Objective (RPO), použijte replication_lag_sec sloupec sys.dm_geo_replication_link_status v primární databázi. Ukazuje zpoždění v sekundách mezi transakcemi potvrzenými v primární databázi a zapsanými do protokolu transakcí v sekundární databázi. V případě, že dojde k výpadku a je zahájeno geografické převzetí služeb, pokud je prodleva jedna sekunda, znamená to, že transakce potvrzené v poslední sekundě budou ztraceny.

Chcete-li měřit prodlevu s ohledem na změny primární databáze, které byly posíleny v sekundární geografické oblasti, porovnejte last_commit čas v sekundární geografické oblasti se stejnou hodnotou v primární databázi.

Návod

Pokud replication_lag_sec je NULLna primárním serveru , znamená to, že primární v současné době neví, jak daleko za geografickou sekundární oblastí je. K tomu obvykle dochází po restartování procesu a mělo by se jednat o přechodnou podmínku. Zvažte odeslání výstrahy, pokud replication_lag_sec vrátí hodnotu NULL po delší dobu. Může to značit, že sekundární geografická oblast nemůže komunikovat s primárním serverem kvůli selhání připojení.

Existují také podmínky, které by mohly způsobit, že se rozdíl mezi last_commit časem na sekundární geografické lokalitě a na primární lokalitě výrazně zvětší. Pokud se například potvrzení provede na primárním serveru po dlouhé době beze změn, rozdíl se před rychlým návratem na nulu zvýší na velkou hodnotu. Pokud rozdíl mezi těmito dvěma hodnotami zůstává po dlouhou dobu velký, zvažte odeslání výstrahy.

Správa aktivní geografické replikace prostřednictvím kódu programu

Aktivní geografickou replikaci je možné spravovat také prostřednictvím kódu programu pomocí T-SQL, Azure PowerShell a rozhraní REST API. Následující tabulky popisují sadu dostupných příkazů. Aktivní geografická replikace zahrnuje sadu rozhraní API Azure Resource Manager pro správu, včetně Azure SQL Database REST API a rutin Azure PowerShell. Tato rozhraní API podporují Azure řízení přístupu na základě role (Azure RBAC). Další informace o tom, jak implementovat role přístupu, najdete v tématu Azure řízení přístupu na základě role (Azure RBAC).

Důležité

Tyto příkazy T-SQL se vztahují pouze na aktivní geografickou replikaci a nevztahují se na skupiny převzetí služeb při selhání.

Příkaz Popis
ZMĚNIT DATABÁZI Použití ADD SECONDARY ON SERVER argumentu k vytvoření sekundární databáze pro existující databázi a spuštění replikace dat
ZMĚNIT DATABÁZI Použijte FAILOVER nebo FORCE_FAILOVER_ALLOW_DATA_LOSS k přepnutí sekundární databáze na primární a iniciujte převzetí služeb při selhání.
ZMĚNIT DATABÁZI Slouží REMOVE SECONDARY ON SERVER k ukončení replikace dat mezi službou SQL Database a zadanou sekundární databází.
sys.geo_replikační_odkazy Vrátí informace o všech existujících odkazech replikace pro každou databázi na serveru.
sys.dm_geo_replication_link_status Získá čas poslední replikace, poslední prodlevu replikace a další informace o propojení replikace pro danou databázi.
sys.dm_operation_status Zobrazuje stav všech databázových operací včetně změn odkazů replikace.
sys.sp_wait_for_database_copy_sync Způsobí, že aplikace počká, dokud nebudou všechny potvrzené transakce posíleny do transakčního protokolu v sekundární geografické oblasti.

Troubleshooting

Další informace o odstraňování problémů s prodlevou geografické replikace najdete v tématu Řešení problémů s prodlevou geografické replikace.

Související obsah

Konfigurace aktivní geografické replikace:

Další obsah provozní kontinuity:

  • Last updated on