Aktivní geografická replikace

  • Článek

Platí pro:Azure SQL Database

Aktivní geografická replikace je funkce, která umožňuje vytvořit nepřetržitě synchronizovanou sekundární databázi pro primární databázi. 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 a podporuje pouze ruční převzetí služeb při selhání. 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é použít službu Migrate SQL Database 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.

active geo-replication

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:

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 předplatitele.

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íle bodu geografické replikace najdete v přehledu kontinuity podnikových procesů.

Následující obrázek znázorňuje příklad aktivní geografické replikace nakonfigurované s primární oblastí USA – středosever a geografickou sekundární oblastí v oblasti USA – středojižní.

geo-replication relationship

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 navrhování řešení pro zotavení po havárii naleznete v tématu Návrh cloudových řešení pro zotavení po havárii pomocí aktivní geografické replikace.

Terminologie a možnosti aktivní geografické replikace

  • 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 Zabezpečení služby SQL Database po zotavení po havárii. 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ů. Podrobnosti najdete v tématu Automatizované zálohování služby 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 převzetí služeb při selhání pro skupinu. Pokud potřebujete provést převzetí služeb při selhání jednotlivé databáze, musíte ji nejprve odebrat ze skupiny převzetí služeb při selhání. Podrobnosti najdete ve skupinách převzetí služeb při selhání.

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 .

Tip

Omezování vstupně-výstupních operací transakčního protokolu na primárním serveru kvůli nižší velikosti výpočetních prostředků v sekundární geografické oblasti je hlášeno pomocí typu čekání HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO, který je viditelný v zobrazeních databáze sys.dm_exec_requests a sys.dm_os_wait_stats .

Vstupně-výstupní operace transakčního protokolu na primárním serveru můžou být omezené z důvodů nesouvisejících s nižší velikostí výpočetních prostředků v sekundární geografické oblasti. K tomuto druhu omezování může dojít i v případě, že má sekundární geografická oblast stejnou nebo vyšší velikost výpočetních prostředků než primární. Podrobnosti, včetně typů čekání pro různé druhy omezování vstupně-výstupních operací protokolu, najdete v tématu Zásady správného řízení rychlosti transakčních protokolů.

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í jazyka Transact-SQL (T-SQL) vytvořte v předplatném geografickou sekundární oblast, která se liší od předplatného primárního (ať už je to pod stejným tenantem Microsoft Entra ID (dříve Azure Active Directory) nebo ne). Další informace najdete v tématu Konfigurace aktivní geografické replikace .

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 přihlášení a uživatelů.

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

Poznámka:

Pokud jste databázi v sekundární geografické oblasti vytvořili v rámci konfigurace skupiny převzetí služeb při selhání, nedoporučujeme vertikálně snižovat její kapacitu. Tím se zajistí, že vaše datová vrstva bude mít po geografickém převzetí služeb při selhání dostatečnou kapacitu na zpracování běžného zatížení.

Důležité

Primární databáze ve skupině převzetí služeb při selhání nemůže škálovat na vyšší úroveň služby (edici), pokud sekundární databáze není poprvé škálována na vyšší úroveň. Pokud například chcete vertikálně navýšit kapacitu primárního objektu z úrovně Pro obecné účely na Pro důležité obchodní informace, musíte nejprve škálovat geografickou sekundární oblast na Pro důležité obchodní informace. Pokud se pokusíte škálovat primární nebo geograficky sekundární způsobem, který porušuje toto pravidlo, zobrazí se následující chyba:

The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

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.

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 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 například prodleva jedna sekunda, znamená to, že pokud je primární server 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ě se ztratí.

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.

Tip

Pokud replication_lag_sec na primárním serveru má hodnotu NULL, znamená to, že primární server v současné době neví, jak daleko je geograficky sekundární. K tomu obvykle dochází po restartování procesu a mělo by se jednat o přechodnou podmínku. Zvažte odeslání upozornění, 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 rozdíl mezi last_commit časem v sekundární geografické oblasti a na primárním serveru. 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

Jak je popsáno dříve, 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).

T-SQL: Správa geografického převzetí služeb při selhání jednoúčelových databází a databází ve fondu

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í. Proto se také nevztahují na spravovanou instanci SQL, která podporuje pouze skupiny převzetí služeb při selhání.

Příkaz Popis
ALTER DATABASE Použití argumentu ADD SECONDARY ON SERVER k vytvoření sekundární databáze pro existující databázi a spuštění replikace dat
ALTER DATABASE Použití převzetí služeb při selhání nebo FORCE_FAILOVER_ALLOW_DATA_LOSS k přepnutí sekundární databáze na primární k zahájení převzetí služeb při selhání
ALTER DATABASE Pomocí příkazu REMOVE SECONDARY ON SERVER ukončete replikaci dat mezi službou SQL Database a zadanou sekundární databází.
sys.geo_replication_links 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.

PowerShell: Správa geografického převzetí služeb při selhání jednoúčelových databází a databází ve fondu

Poznámka:

Tento článek používá modul Azure Az PowerShell, což je doporučený modul PowerShellu pro interakci s Azure. Pokud chcete začít s modulem Az PowerShell, projděte si téma věnované instalaci Azure PowerShellu. Informace o tom, jak migrovat na modul Az PowerShell, najdete v tématu Migrace Azure PowerShellu z AzureRM na Az.

Důležité

Azure SQL Database stále podporuje modul Azure Resource Manageru v PowerShellu, ale veškerý budoucí vývoj je určený pro modul Az.Sql. Tyto rutiny najdete v tématu AzureRM.Sql. Argumenty pro příkazy v modulu Az a v modulech AzureRm jsou podstatně identické.

Rutina Popis
Get-AzSqlDatabase Získá jednu nebo více databází.
New-AzSqlDatabaseSecondary Vytvoří sekundární databázi pro existující databázi a spustí replikaci dat.
Set-AzSqlDatabaseSecondary Přepne sekundární databázi na primární a zahájí tak převzetí služeb při selhání.
Remove-AzSqlDatabaseSecondary Ukončí replikaci dat mezi službou SQL Database a zadanou sekundární databází.
Get-AzSqlDatabaseReplicationLink Získá propojení geografické replikace pro databázi.

Tip

Ukázkové skripty najdete v tématu Konfigurace a převzetí služeb při selhání izolované databáze pomocí aktivní geografické replikace a konfigurace a převzetí služeb při selhání databáze ve fondu pomocí aktivní geografické replikace.

REST API: Správa geografického převzetí služeb při selhání jednoúčelových databází a databází ve fondu

API Popis
Vytvoření nebo aktualizace databáze (createMode=Restore) Vytvoří, aktualizuje nebo obnoví primární nebo sekundární databázi.
Získání stavu vytvoření nebo aktualizace databáze Vrátí stav během operace vytvoření.
Nastavení sekundární databáze jako primární (plánované převzetí služeb při selhání) Nastaví, která sekundární databáze je primární, převzetím služeb při selhání z aktuální primární databáze. Tato možnost není pro spravovanou instanci SQL podporovaná.
Nastavení sekundární databáze jako primární (neplánované převzetí služeb při selhání) Nastaví, která sekundární databáze je primární, převzetím služeb při selhání z aktuální primární databáze. Tato operace může vést ke ztrátě dat. Tato možnost není pro spravovanou instanci SQL podporovaná.
Získání odkazu replikace Získá konkrétní odkaz replikace pro danou databázi v partnerství geografické replikace. Načte informace viditelné v zobrazení katalogu sys.geo_replication_links. Tato možnost není pro spravovanou instanci SQL podporovaná.
Odkazy replikace – výpis podle databáze Získá všechny odkazy replikace pro danou databázi v partnerství geografické replikace. Načte informace viditelné v zobrazení katalogu sys.geo_replication_links.
Odstranit odkaz replikace Odstraní propojení replikace databáze. Během převzetí služeb při selhání není možné provést.

Další kroky