Aktivní geografická replikace

PLATÍ PRO: Azure SQL Database

Aktivní geografická replikace je funkce, která umožňuje vytvořit trvale synchronizovanou čitelnou sekundární databázi pro primární databázi. Čitelná sekundární databáze může být ve stejné oblasti Azure jako primární, nebo častěji v jiné oblasti. Tento druh čitelných sekundárních databází se také označuje jako geografické a geografické repliky.

Aktivní geografická replikace je navržená jako řešení pro provozní kontinuitu, které umožňuje provádět rychlé zotavení po havárii jednotlivých databází v případě regionálních havárií nebo výpadku velkého rozsahu. Po nastavení geografické replikace můžete v jiné oblasti Azure iniciovat geografické převzetí služeb při selhání geograficky sekundárního. Geografické převzetí služeb při selhání inicializuje programově aplikace nebo ručně uživatelem.

Pokud vaše aplikace vyžaduje pro geografickou replikaci stabilní koncový bod připojení a automatickou podporu geografického převzetí služeb při selhání, použijte skupiny s automatickým převzetím služeb při selhání.

Následující diagram znázorňuje typickou konfiguraci geograficky redundantní cloudové aplikace pomocí aktivní geografické replikace.

Pokud z nějakého důvodu dojde k selhání vaší primární databáze, můžete zahájit geografické převzetí služeb při selhání do kterékoli z vašich sekundárních databází. Když je sekundární role povýšená na primární roli, všechny ostatní sekundární repliky se automaticky propojí s novým primárním objektem.

Můžete spravovat geografickou replikaci a iniciovat geografické převzetí služeb při selhání pomocí následujících kroků:

• Azure Portal
• PowerShell: izolovaná databáze
• PowerShell: elastický fond
• Transact-SQL: jedna databáze nebo elastický fond
• REST API: izolovaná databáze

Aktivní geografická replikace využívá technologii skupiny dostupnosti Always On k asynchronní replikaci transakčního protokolu vygenerovaného v primární replice na všechny geografické repliky. V kterémkoli okamžiku může být sekundární databáze mírně za primární databází. data v sekundárním počítači jsou zaručena jako nejednotná. Jinými slovy, nejsou viditelné změny provedené nepotvrzenými transakcemi.

Regionální redundance poskytovaná geografickou replikací umožňuje aplikacím rychlé obnovení z trvalé ztráty celé oblasti Azure nebo částí oblasti, způsobené přirozenými katastrofami, závažnými lidskými chybami nebo škodlivými činy. Cílení na geografickou replikaci najdete v článku Přehled provozní kontinuity.

Následující obrázek ukazuje příklad aktivní geografické replikace nakonfigurované s primárním umístěním v Střed USA – sever oblasti a geograficky sekundární v Střed USA – jih oblasti.

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

• Migrace databáze: můžete použít aktivní geografickou replikaci k migraci databáze z jednoho serveru na jiný s minimálními výpadky.
• Upgrady aplikací: během upgradování aplikace můžete vytvořit další sekundární kopii jako back-mailové kopie.

Pokud chcete dosáhnout plné provozní kontinuity, přidejte do řešení redundanci databáze jenom část řešení. Kompletní obnovení aplikace (služby) po závažných chybách vyžaduje obnovení všech součástí, 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 velmi důležité, aby všechny součásti byly odolné vůči stejnou selhání a byly k dispozici v rámci plánované doby obnovení (RTO) vaší aplikace. Proto je potřeba identifikovat všechny závislé služby a porozumět zárukám a funkcím, které poskytují. Pak musíte provést vhodné kroky, abyste zajistili, že vaše služba funguje při 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 navrhování cloudových řešení pro zotavení po havárii pomocí aktivní geografické replikace.

Aktivní terminologie a funkce pro geografickou replikaci

• Automatická asynchronní replikace

  Pro existující databázi můžete vytvořit jenom geografickou sekundární databázi. Geograficky-Secondary lze vytvořit na jakémkoli logickém serveru, který je jiný než server s primární databází. Po vytvoření se geograficky sekundární replika naplní daty primární databáze. Tento proces se označuje jako osazení. Po vytvoření a osazení geograficky sekundárních se aktualizace primární databáze automaticky a asynchronně replikují do geograficky sekundární repliky. Asynchronní replikace znamená, že transakce jsou potvrzeny v primární databázi před jejich replikací.

• Čitelná geograficky sekundární repliky

  Aplikace může získat přístup k geografické sekundární replice, aby prováděla dotazy jen pro čtení pomocí stejných nebo odlišných objektů zabezpečení, které se používaly pro přístup k primární databázi. Další informace najdete v tématu použití replik jen pro čtení k převedení ú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í. Pomocí těchto sekundárních scénářů můžete ve stejné oblasti naplnit scénáře pro čtení s možností horizontálního navýšení kapacity. Sekundární replika ve stejné oblasti ale neposkytuje větší odolnost proti závažným chybám nebo velkým výpadkům škálování, 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óny dostupnosti. pro dosažení izolace zóny dostupnosti použijte Pro důležité obchodní informace nebo Premium redundantní konfiguraci zóny služeb nebo Pro obecné účely.

• Plánované geografické převzetí služeb při selhání

  Po dokončení úplné synchronizace dat se plánované geografické převzetí služeb při selhání přepíná role primárních a geografických sekundárních databází. Plánované převzetí služeb při selhání nevede ke ztrátě dat. Doba plánovaného geografického převzetí služeb při selhání závisí na velikosti transakčního protokolu na primárním počítači, který musí být synchronizovaný s geograficky sekundární. Plánované geografické převzetí služeb při selhání je navržené pro následující scénáře:

  • Postup zotavení po havárii v produkčním prostředí, když je ztráta dat přijatelná;
  • Přemístěte databázi do jiné oblasti.
  • Po omezení výpadku (známého jako navrácení služeb po obnovení) Vraťte databázi do primární oblasti.

• Neplánované geografické převzetí služeb při selhání

  Neplánované nebo vynucené geografické převzetí služeb při selhání okamžitě přepne geograficky sekundární na primární roli bez jakékoli synchronizace s primární. Všechny transakce potvrzené na primární, ale dosud nereplikované do sekundárního jsou ztraceny. Tato operace je navržena jako metoda obnovení během výpadků, když není primární přístup dostupný, ale je nutné rychle obnovit dostupnost databáze. Když je původní primární primární počítač znovu online, bude automaticky znovu připojen, znovu se použije aktuální primární data a stane se novou geografickou sekundární.

  Důležité

  Po plánovaném nebo neplánovaném geografické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 je teď umístěný na jiném logickém serveru.

• Více čitelných geografických sekundárních

  Pro primární se dá vytvořit až čtyři geografické sekundární databáze. Pokud je k dispozici pouze jeden sekundární objekt a dojde k jeho chybě, je aplikace vystavena vyššímu riziku, dokud nebude vytvořeno nové sekundární. Pokud existuje více sekundárních prostředí, aplikace zůstane chráněna i v případě, že se některá z nich nezdařila. K horizontálnímu navýšení kapacity úloh jen pro čtení můžete použít taky další sekundární procesy.

  Tip

  Pokud k vytvoření globálně distribuované aplikace používáte aktivní geografickou replikaci a potřebujete poskytnout přístup k datům ve více než čtyřech oblastech, můžete vytvořit sekundární sekundární objekt (což je proces označovaný jako zř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, které jsou připojené přímo k primárnímu umístění. Nastavení zřetězené topologie geografického replikace se podporují jenom programově, nikoli z Azure Portal.

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

  Každá geografická – sekundární může být jedna databáze nebo databáze v elastickém fondu. Volba elastického fondu pro každou geograficky 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 obsažený v jednom logickém serveru. Vzhledem k tomu, že názvy databází na logickém serveru musí být jedinečné, nemůže více geografických sekundárních souborů stejné primární skupiny nikdy sdílet elastický fond.

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

  Geograficky sekundární, který dokončil počáteční osazení, může být kdykoli explicitně přepnut na primární roli (převzetí služeb při selhání) aplikací nebo uživatelem. Při výpadku, kdy primární je nepřístupný, se dá použít jenom neplánované geografické převzetí služeb při selhání. Tím se okamžitě propaguje geograficky sekundární jako na novou primární. Když dojde k omezení výpadku, systém automaticky obnoví primární geografickou sekundární hodnotu a přiřadí ho k novému primárnímu serveru. Z důvodu asynchronního charakteru geografické replikace může dojít ke ztrátě poslední transakce během neplánovaných geografických převzetí služeb při selhání, pokud primární operace neproběhne úspěšně, než se tyto transakce replikují do geografické sekundární databáze. Pokud primární databáze s více geografickými sekundárními počítači převezme služby při selhání, systém automaticky překonfiguruje vztahy replikace a propojí zbývající geografické sekundární systémy s nově povýšenou primární databází bez nutnosti zásahu uživatele. Po výpadku, který způsobila omezení geografického převzetí služeb při selhání, může být žádoucí vrátit primární hodnotu do původní oblasti. K tomu je potřeba vyvolat plánované geografické převzetí služeb při selhání.

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

Abyste zajistili, že vaše aplikace bude mít hned po geografickém převzetí služeb při selhání přístup k nové primární úrovni, ověřte, jestli jsou správně nakonfigurované ověřování a přístup k síti pro váš sekundární server. podrobnosti najdete v tématu SQL Database security po zotavení po havárii. Ověřte také, že zásady uchovávání záloh v sekundární databázi odpovídají primárnímu. Toto nastavení není součástí databáze a nereplikuje se z primárního. Ve výchozím nastavení je geograficky-Secondary nakonfigurovaná s výchozí dobou uchování PITR sedmi dnů. podrobnosti najdete v tématu SQL Database automatizované zálohy.

Konfigurovat geograficky sekundární

Primární i geograficky-sekundární musí mít stejnou úroveň služby. Důrazně doporučujeme také, aby geograficky sekundární byla nakonfigurovaná se stejnou redundancí záložního úložiště a výpočetní velikostí (DTU nebo virtuální jádra) jako primární. V případě, že v primárním prostředí dochází k velké zátěži pro zápis, nemusí být geografická a nižší velikost výpočetní kapacity schopna udržet se. To způsobí prodlevu replikace u geograficky sekundárního a může nakonec způsobit nedostupnost geografické sekundární služby. Aktivní geografická replikace při zmírnění těchto rizik omezí (omezí) četnost transakčního protokolu primární, pokud je to nutné, aby bylo možné její sekundární zachycení zachytit.

Další konfigurací nevyvážené geograficky sekundární konfigurace je, že po převzetí služeb při selhání může výkon aplikace vzrazit kvůli nedostatečné výpočetní kapacitě nového primárního objektu. V takovém případě bude nutné škálovat databázi tak, aby měla dostatek prostředků, což může trvat poměrně dlouho a bude vyžadovat převzetí služeb při selhání s vysokou dostupností na konci procesu horizontálního navýšení kapacity, což může rušit zatížení aplikací.

Pokud se rozhodnete vytvořit geografickou sekundární velikost s nižší výpočetní velikostí, měli byste monitorovat rychlost v/v protokolu na primárním čase. To vám umožní odhadnout minimální výpočetní velikost geografické sekundární operace, která je nutná k udržení zatížení replikace. Pokud je vaše primární databáze například P6 (1000 DTU) a její vstupně-výstupní operace se udržuje na 50%, musí být geografická sekundární aspoň P4 (500 DTU). K načtení historických dat v/v protokolu použijte zobrazení Sys.resource_stats . Pokud chcete načíst poslední data v/v protokolu s větší členitosti, která lépe odráží krátkodobé špičky, použijte zobrazení Sys.dm_db_resource_stats .

Ve výchozím nastavení je redundance záložního úložiště geograficky sekundární služby stejná jako u primární databáze. Můžete zvolit konfiguraci geografické sekundární databáze s jinou redundancí úložiště zálohování. Zálohování se vždycky provádí v primární databázi. Pokud je sekundární nakonfigurovaná s jinou redundancí úložiště záloh, pak po geografickém převzetí služeb při selhání, když se geografická sekundární úroveň zvýší na primární, se nové zálohy uloží a účtují podle typu úložiště (RA-GRS, ZRS, LRS) vybraného na novém primárním počítači (předchozí sekundární).

Geografická replikace mezi předplatnými

pokud chcete vytvořit geograficky sekundární v rámci předplatného, které se liší od předplatného primárního portálu (jestli se nachází ve stejném tenantovi Azure Active Directory nebo ne), postupujte podle kroků v této části.

1. přidejte IP adresu klientského počítače spouštějící níže uvedené příkazy T-SQL do serverových bran firewall primárního i sekundárního serveru. Tuto IP adresu můžete potvrdit spuštěním následujícího dotazu, který se připojí k primárnímu serveru ze stejného klientského počítače.

   select client_net_address from sys.dm_exec_connections where session_id = @@SPID;
   

   Další informace najdete v tématu Konfigurace brány firewall.

2. v hlavní databázi na primárním serveru vytvořte SQL přihlášení ověřování vyhrazené pro nastavení aktivní geografické replikace. Podle potřeby upravte přihlašovací jméno a heslo.

   create login geodrsetup with password = 'ComplexPassword01';
   

3. Ve stejné databázi vytvořte uživatele pro přihlášení a přidejte ho do dbmanager role:

   create user geodrsetup for login geodrsetup;
   alter role dbmanager add member geodrsetup;
   

4. Poznamenejte si hodnotu SID nového přihlášení. Hodnotu SID získáte pomocí následujícího dotazu.

   select sid from sys.sql_logins where name = 'geodrsetup';
   

5. Připojení k primární databázi (ne k hlavní databázi) a vytvořte uživatele pro stejné přihlášení.

   create user geodrsetup for login geodrsetup;
   

6. Do stejné databáze přidejte uživatele do db_owner role.

   alter role db_owner add member geodrsetup;
   

7. V hlavní databázi na sekundárním serveru vytvořte stejné přihlašovací údaje jako na primárním serveru, přičemž použijte stejný název, heslo a SID. V níže uvedeném příkazu pro vzorkování nahraďte šestnáctkovou hodnotu SID, kterou jste získali v kroku 4.

   create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E;
   

8. Ve stejné databázi vytvořte uživatele pro přihlášení a přidejte ho do dbmanager role.

   create user geodrsetup for login geodrsetup;
   alter role dbmanager add member geodrsetup;
   

9. Připojení k hlavní databázi na primárním serveru pomocí nového geodrsetup přihlášení a spusťte geograficky sekundární vytvoření na sekundárním serveru. Podle potřeby upravte název databáze a název sekundárního serveru. Po spuštění příkazu můžete monitorovat geografické sekundární vytváření pomocí dotazu na zobrazení Sys.dm_geo_replication_link_status v primární databázi a zobrazení Sys.dm_operation_status v hlavní databázi na primárním serveru. Čas potřebný k vytvoření geografické sekundární závislosti závisí na velikosti primární databáze.

   alter database [dbrep] add secondary on server [servername];
   

10. Po úspěšném vytvoření geografické sekundárního umístění je možné odebrat uživatele, přihlašovací údaje a pravidla brány firewall vytvořená tímto postupem.

Udržování synchronizovaných přihlašovacích údajů a pravidel brány firewall

Při použití přístupu veřejné sítě 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šťuje, že všechny geografické sekundární sítě mají stejná pravidla firewallu protokolu IP jako primární. Tento přístup eliminuje potřebu zákazníků ručně konfigurovat a udržovat pravidla brány firewall na serverech hostujících primární a sekundární databázi. Podobně použití databáze uživatelů 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. Tímto způsobem po geografickém převzetí služeb při selhání nedochází k výpadkům v důsledku neshody ověřovacích přihlašovacích údajů. Pokud používáte přihlašovací jména a uživatele (místo obsažených uživatelů), musíte provést další kroky, abyste zajistili, že pro vaši sekundární databázi existují stejná přihlášení. Podrobnosti o konfiguraci najdete v tématu konfigurace přihlašovacích jmen a uživatelů.

Škálovat primární databázi

Primární databázi můžete škálovat směrem nahoru nebo dolů na jinou výpočetní velikost (v rámci stejné vrstvy služeb), aniž byste museli odpojit jakékoli geografické sekundární operace. Při vertikálním navýšení kapacity doporučujeme nejprve škálovat geograficky sekundární a pak vertikálně navyšovat velikost primárního. Při horizontálním navýšení kapacity můžete pořadí obrátit na primární úrovni a pak vertikálně snížit velikost sekundárního.

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

Vzhledem k vysoké latenci sítí WAN používá geografická replikace mechanismus asynchronní replikace. Asynchronní replikace umožňuje nemožnost ztráty dat v případě, že primární operace není úspěšná. Aby bylo možné ochránit kritické transakce před ztrátou dat, může vývojář aplikace volat sp_wait_for_database_copy_sync uloženou proceduru ihned po potvrzení transakce. Volání sp_wait_for_database_copy_sync blokuje volající vlákno, dokud poslední potvrzená transakce nebyla přenesena a zpřísněna v transakčním protokolu sekundární databáze. Nečeká ale na opětovné přehrání přenesených transakcí (znovu) na sekundárním počítači. 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 pro připojení k primární databázi.

Sledovat prodlevu geografické replikace

Chcete-li monitorovat prodlevu s ohledem na RPO, použijte replication_lag_sec sloupci Sys.dm_geo_replication_link_status v primární databázi. V sekundách se zobrazuje prodleva mezi transakcemi potvrzenými na primárním počítači a posílením protokolu transakcí v sekundárním počítači. Pokud je například prodleva jedna sekunda, znamená to, že v případě, že je primární příčinou výpadku v této chvíli a dojde k zahájení geografického převzetí služeb při selhání, budou ztraceny transakce potvrzené za poslední sekundu.

Chcete-li změřit prodlevu s ohledem na změny v primární databázi, které byly zpřísněny na geograficky sekundárním, porovnejte last_commit čas u geografické sekundární hodnoty se stejnou hodnotou na primárním poli.

Programově spravovat aktivní geografickou replikaci

jak je popsáno výše, aktivní geografická replikace se dá spravovat taky prostřednictvím T-SQL, Azure PowerShell a REST API. V následujících tabulkách jsou popsány sady příkazů, které jsou k dispozici. aktivní geografická replikace obsahuje sadu Azure Resource Manager rozhraní api pro správu, včetně rutin Azure SQL Database REST API a Azure PowerShell. Tato rozhraní API podporují řízení přístupu na základě role Azure (Azure RBAC). Další informace o tom, jak implementovat role přístupu, najdete v tématu řízení přístupu na základě role v Azure (Azure RBAC).

T-SQL: správa geografického převzetí služeb při selhání pro jednotlivé a sdružené databáze

PowerShell: Správa geografického převzetí služeb při selhání pro jednotlivé a sdružené databáze

REST API: Správa geografického převzetí služeb při selhání pro jednotlivé databáze a ve fondu

Další kroky

• Ukázkové skripty najdete v těchto tématech:
  • Konfigurace a převzetí služeb při selhání jedné databáze pomocí aktivní geografické replikace.
  • Konfigurace a převzetí služeb při selhání databáze ve fondu pomocí aktivní geografické replikace.
• SQL Database podporuje také skupiny automatického převzetí služeb při selhání. Další informace najdete v tématu používání skupin s automatickým převzetím služeb při selhání.
• Přehled provozní kontinuity a scénáře najdete v tématu Přehled provozní kontinuity.
• další informace o Azure SQL Database automatizovaných zálohách najdete v tématu SQL Database automatizované zálohy.
• Další informace o použití automatizovaných záloh pro obnovení najdete v tématu obnovení databáze ze zálohy iniciované službou.
• další informace o požadavcích na ověřování nového primárního serveru a databáze najdete v článku SQL Database zabezpečení po zotavení po havárii.