Aktivní geografická replikace

Platí pro: Azure SQL Database

Tento článek obsahuje a přehled aktivní funkce 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 umožňující čtení se může nacházet ve stejné oblasti Azure jako primární databáze, nebo, což je běžnější, 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 zahájit geografické převzetí služeb při selhání do sekundární geografické oblasti v jiné oblasti Azure. Geografické převzetí služeb při selhání je inicializováno programově aplikací nebo ručně uživatelem.

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

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í role na primární roli se všechny ostatní sekundární soubory automaticky propojily s novým primárním serverem.

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:

• Azure Portal
• PowerShell: Jednoúčelová databáze
• PowerShell: Elastický fond
• Transact-SQL: Jednoúčelová databáze nebo elastický fond
• REST API: Jednoúčelová databáze

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é.

Geografická replikace poskytuje regionální redundanci. Regionální redundance umožňuje aplikacím rychle se zotavit z trvalé ztráty celé oblasti Azure nebo částí oblasti, způsobené přírodními katastrofami, katastrofickými lidskými chybami nebo škodlivými činy. Cíl bodu obnovení geografické replikace najdete v tématu Přehled provozní kontinuity se službou 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.

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 navrácení služeb po obnovení.

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 návrhu řešení pro zotavení po havárii najdete v tématu Návrh 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 sekundární geografickou 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 počáteční. Po vytvoření a počátečním vytvoření sekundární geografické oblasti se aktualizace primární databáze automaticky a asynchronně replikují do 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 a spouštět dotazy jen pro čtení pomocí stejných nebo různých objektů zabezpečení používaných pro přístup k primární databázi. Další informace najdete v tématu Použití replik jen pro čtení k přesměrování zpracování úloh dotazů jen 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 sekundární soubory můžete použít ke splnění scénářů škálování na více instancí čtení ve stejné oblasti. Sekundární replika ve stejné oblasti 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 převzetí služeb při selhání pro účely zotavení po havárii. Nezaručuje také izolaci zón dostupnosti. K zajištění izolace zóny dostupnosti použijte Pro důležité obchodní informace nebo zónově redundantní konfiguraci úrovně služby Premium nebo zónově redundantní konfiguraci úrovně služby Pro obecné účely.

• Převzetí služeb při selhání (bez ztráty dat)

  Převzetí služeb při selhání přepne role primárních a geograficky sekundárních databází po dokončení úplné synchronizace dat, takže nedojde ke ztrátě dat. Doba trvání převzetí služeb při selhání závisí na velikosti transakčního protokolu na primárním serveru, který je potřeba synchronizovat s geografickou sekundární oblastí. Převzetí služeb při selhání je navržené pro následující scénáře:

  • Provádění podrobností zotavení po havárii v produkčním prostředí v případech, kdy ztráta dat není přijatelná
  • Přemístění databáze do jiné oblasti
  • Po zmírnění výpadku vraťte databázi do primární oblasti (označuje se jako navrácení služeb po obnovení).

• 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í roli na primární roli bez čekání na synchronizaci s primární rolí. Všechny transakce potvrzené na primární, ale dosud nereplikované do sekundární 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í server opět online, automaticky se znovu připojí, znovu obnoví pomocí aktuálních dat z primárního serveru a stane se novou geografickou sekundární.

  Důležité

  Po převzetí služeb při selhání nebo vynuceném převzetí služeb při selhání se koncový bod připojení pro nové primární změny změní, protože nový primární server se teď nachází na jiném logickém serveru.

• Několik čitelných geografických sekundárních souborů

  Pro primární server je možné vytvořit až čtyři geografické sekundární soubory. 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. K horizontálnímu navýšení kapacity úloh jen pro čtení je možné použít další sekundární soubory.

  Tip

  Pokud k vytvoření globálně distribuované aplikace používáte aktivní geografickou replikaci 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í (proces označovaný jako řetězení) a vytvořit další geografické 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 webu Azure Portal.

• Geografická replikace databází v elastickém fondu

  Každá geografická sekundární oblast 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ý fond je součástí jednoho logického serveru. Vzhledem k tomu, že názvy databází na logickém serveru musí být jedinečné, nemůže elastický fond sdílet více geografických sekund stejného primárního fondu.

• Geografické převzetí služeb při selhání řízené uživatelem a navrácení služeb po obnovení

  Geograficky sekundární oblast, která dokončila počáteční počáteční počáteční předsazení, může aplikace nebo uživatel explicitně přepnout na primární roli (převzetí služeb při selhání). Během výpadku, kdy je primární nepřístupný, lze použít pouze vynucené převzetí služeb při selhání, které okamžitě podporuje geografickou sekundární oblast jako novou primární. Když dojde ke zmírnění výpadku, systém automaticky vytvoří obnovenou primární geografickou sekundární oblast a aktualizuje ji s novou primární. Vzhledem k asynchronní povaze geografické replikace můžou být nedávné transakce během vynuceného převzetí služeb při selhání ztraceny, pokud primární selže dříve, než se tyto transakce replikují do geografické sekundární oblasti. Když dojde k převzetí služeb při selhání primárního serveru s více geografickými sekundami, systém automaticky překonfiguruje relace replikace a propojí zbývající geografické sekundy s nově povýšeným primárním serverem bez nutnosti zásahu uživatele. Po výpadku, který způsobil zmírnění geografického převzetí služeb při selhání, může být žádoucí vrátit primární server do původní oblasti. Provedete to ručním převzetím služeb 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 repliku určit jako pohotovostní , abyste ušetřili náklady na licence.

Příprava na geografické převzetí služeb při selhání

Abyste měli jistotu, že vaše aplikace bude mít po geografickém převzetí služeb při selhání okamžitý přístup k novému primárnímu serveru, ověřte, že je správně nakonfigurované ověřování a síťový přístup k vašemu sekundárnímu serveru. Podrobnosti najdete v tématu Konfigurace a správa zabezpečení služby 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 geografická sekundární oblast nakonfigurovaná s výchozí dobou uchovávání bodu obnovení k určitému bodu v čase 7 dnů. Další informace najdete v tématu Automatizované zálohování ve službě Azure SQL Database.

Konfigurace geografické sekundární oblasti

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 u primární úlohy zápisu dochází k vysokému zatížení, nemusí být geograficky sekundární s nižší velikostí výpočetních prostředků 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. Pokud chcete tato rizika zmírnit, sníží aktivní geografická replikace (omezení) rychlost transakčního protokolu primárního serveru v případě potřeby, aby se její sekundární soubory mohly dohnat.

Dalším důsledkem nevyvážené geograficky sekundární konfigurace je, že po převzetí služeb při selhání může výkon aplikace trpět nedostatečným výpočetním kapacitou nového primárního serveru. V takovém případě je potřeba vertikálně navýšit kapacitu databáze tak, aby měla dostatek prostředků, což může trvat výrazně dlouho a vyžaduje převzetí služeb při selhání s vysokou dostupností na konci procesu vertikálního navýšení kapacity, což může přerušit úlohy aplikací.

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í velikost výpočetních prostředků databáze v sekundární geografické oblasti potřebnou ke zvládnutí zatížení replikace. Pokud je například primární databáze P6 (1000 DTU) a její vstupně-výstupní operace protokolu se udržuje na 50 %, musí být geograficky sekundární alespoň P4 (500 DTU). Pokud chcete načíst historická data vstupně-výstupních operací protokolu, použijte zobrazení sys.resource_stats . Pokud chcete načíst nedávná data vstupně-výstupních operací protokolu s vyšší členitostí, která lépe odráží krátkodobé špičky, použijte zobrazení sys.dm_db_resource_stats .

Ve výchozím nastavení je redundance úložiště zálohování geografické sekundární oblasti 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ě nakonfigurované s jinou redundancí úložiště zálohování, po geografickém převzetí služeb při selhání se po povýšení na primární úložiště uloží nové zálohy a budou se účtovat podle typu úložiště (RA-GRS, ZRS, LRS) vybraného na nové primární (předchozí sekundární).

Ú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.

Další informace najdete v pohotovostní replice bez licence.

Geografická replikace mezi předplatnými

• Pomocí webu Azure Portal 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 předplatném , které se liší od předplatného primárního v jiném tenantovi Microsoft Entra, použijte ověřování SQL a T-SQL. Ověřování Microsoft Entra pro geografickou replikaci mezi předplatnými není podporováno, pokud je logický server v jiném tenantovi Azure.
  • Operace geografické replikace mezi předplatnými, včetně nastavení a geografického převzetí služeb při selhání, se podporují také pomocí rozhraní Databases Create nebo Update REST API.

• Vytvoření geografické sekundární geografické sekundární oblasti mezi 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 povolené ověřování Microsoft Entra a vytvoření se pokusí použít uživatele Microsoft Entra ID.

Metody a podrobné pokyny najdete v tématu Kurz: 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í geografické sekundární oblasti je možné odepřen přístup k veřejné síti.

Zachování přihlašovacích údajů a pravidel brány firewall 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 se replikují s databází, která zajišťují, že všechny geografické sekundáry mají stejná pravidla brány firewall protokolu IP jako primární. 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 převzetí služeb při selhání nedojde k přerušení kvůli neshodám přihlašovacích údajů ověřování. 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í služby 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 vertikálně navýšit nebo snížit na jinou velikost výpočetních prostředků (ve stejné úrovni služby), aniž byste odpojili jakékoli geografické sekundy. 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 umožňuje neuložené ztrátě dat, pokud primární 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 do poslední potvrzené transakce byla přenášena a posílena v transakčním protokolu sekundární databáze. Nečeká však na přehrání přenášených transakcí (znovu) na sekundárním serveru. sp_wait_for_database_copy_sync je vymezen na konkrétní odkaz geografické replikace. Tento postup může volat každý uživatel s právy k připojení k primární databázi.

Monitorování prodlevy geografické replikace

Pokud chcete monitorovat prodlevu s ohledem na cíl bodu obnovení (RPO), použijte sloupec replication_lag_sec tabulky sys.dm_geo_replication_link_status primární databáze. 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. Pokud je prodleva například jedna sekunda, znamená to, že pokud je primární v tuto chvíli ovlivněn výpadkem a zahájí se geografické převzetí služeb při selhání, 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.

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 PowerShellu a rozhraní REST API. Následující tabulky popisují sadu dostupných příkazů. Aktivní geografická replikace zahrnuje sadu rozhraní API Azure Resource Manageru pro správu, včetně rozhraní REST API služby Azure SQL Database a rutin Azure PowerShellu. Tato rozhraní API podporují řízení přístupu na základě role v Azure (Azure RBAC). Další informace o tom, jak implementovat přístupové role, najdete v tématu Řízení přístupu na základě role v Azure (Azure RBAC).

Související obsah

Konfigurace aktivní geografické replikace:

• Pro databázi pomocí webu Azure Portal
• Pro jednu databázi pomocí PowerShellu
• Pro databázi ve fondu pomocí PowerShellu

Další obsah provozní kontinuity:

• Přehled kontinuity podnikových procesů se službou Azure SQL Database
• Skupiny převzetí služeb při selhání
• Bezplatná pohotovostní replika
• Geografická replika Hyperscale
• Automatizované zálohování ve službě Azure SQL Database
• Obnovení databáze ze zálohy v databázi Azure SQL