Konfigurace vysoké dostupnosti a zotavení po havárii
Hlavní část konfigurace zotavení po havárii a řešení s vysokou dostupností v SQL Serveru zůstává stejná v SQL Serveru spuštěném na virtuálním počítači Azure. Řešení s vysokou dostupností je navržené tak, aby se zajistilo, že se neztratí žádná potvrzená data kvůli selháním, že vaše úloha nebude ovlivněná operacemi údržby a že databáze se nestane jediným bodem selhání ve vaší softwarové architektuře.
Většina úrovní služby Azure SQL nabízí celou řadu možností vysoké dostupnosti, od místní redundance až po modely redundance zón.
Dále prozkoumáme konkrétní řešení pro zotavení po havárii a vysokou dostupnost nabídek PaaS v Azure.
Průběžné zálohování
Azure SQL Database zajišťuje pravidelné a průběžné zálohování databází, které se pak replikují do geograficky redundantního úložiště s přístupem pro čtení (RA-GRS).
Týdenní úplné zálohování, rozdílové zálohování každých 12 až 24 hodin a zálohy transakčních protokolů každých 5 až 10 minut jsou součástí strategie automatizovaného zálohování. Pro rozšířenou dostupnost zálohování (až 10 let) je možné nakonfigurovat dlouhodobé uchovávání (LTR) pro jednoúčelové databáze i databáze ve fondu.
Dlouhodobé uchovávání
Azure nabízí zásady uchovávání informací, které můžete nastavit nad rámec obvyklých limitů, což je užitečné pro scénáře vyžadující dlouhodobé uchovávání. Zásady uchovávání informací můžete nastavit až na 10 let a tato možnost je ve výchozím nastavení zakázaná.
Obrázek ukazuje, jak nastavit zásady dlouhodobého uchovávání na webu Azure Portal. Po výběru databáze se na pravé straně obrazovky zobrazí panel, kde můžete změnit výchozí nastavení.
Další informace o dlouhodobém uchovávání najdete v tématu Dlouhodobé uchovávání – Azure SQL Database a Azure SQL Managed Instance.
Geografické obnovení
Zálohy pro službu SQL Database a spravovanou instanci SQL jsou ve výchozím nastavení geograficky redundantní. To vám umožní snadno obnovit databáze do jiné geografické oblasti, což je funkce, která je užitečná pro méně přísné scénáře zotavení po havárii.
Úložiště zálohování se účtuje kromě běžného úložiště databázových souborů. Při zřizování služby SQL Database se však vytvoří úložiště zálohování s maximální velikostí datové vrstvy vybrané pro vaši databázi bez dalších poplatků.
Doba trvání operace geografického obnovení může být ovlivněna několika základními komponentami, včetně velikosti databáze, počtu transakčních protokolů zahrnutých v operaci obnovení a množství souběžných žádostí o obnovení zpracovávaných v cílové oblasti.
Obnovení k určitému bodu v čase (PITR)
Databáze můžete obnovit k určitému bodu v čase podle definovaného uchovávání informací, ale obnovení k určitému bodu v čase je podporováno pouze v případě, že obnovujete databázi na stejném serveru, ze které záloha pochází. K obnovení služby SQL Database můžete použít Azure Portal, Azure PowerShell, Azure CLI nebo rozhraní REST API.
Aktivní geografická replikace
Jednou z metod zvýšení dostupnosti služby Azure SQL Database je použití aktivní geografické replikace. Aktivní geografická replikace vytvoří sekundární repliku databáze v jiné oblasti, která je asynchronně aktuální.
Tato replika je čitelná, podobně jako skupina dostupnosti AlwaysOn v SQL Serveru. Pod povrchem Azure používá skupiny dostupnosti k údržbě této funkce, což je důvod, proč jsou některé terminologie podobné.
Aktivní geografická replikace zajišťuje kontinuitu podnikových procesů tím, že zákazníkům umožňuje programově nebo ručně provést převzetí služeb při selhání primárních databází do sekundárních oblastí během závažné havárie.
Poznámka:
Spravovaná instance Azure SQL nepodporuje aktivní geografickou replikaci. Místo toho musíte použít skupiny automatického převzetí služeb při selhání, téma, které prozkoumáme později v této lekci.
Všechny databáze, které jsou součástí vztahu geografické replikace, musí mít stejnou úroveň služby. Pokud chcete zabránit problémům s výkonem replikace kvůli náročné úloze zápisu, doporučujeme nakonfigurovat sekundární repliku se stejnou velikostí výpočetních prostředků jako primární replika.
Geografickou replikaci služby Azure SQL Database můžete ručně nakonfigurovat tak, že v části Správa dat přejdete do okna databáze, vyberete Repliky a pak vyberete + Vytvořit repliku.
Po vytvoření sekundární repliky máte možnost ručně zahájit převzetí služeb při selhání. V tomto procesu jsou role obrácené – sekundární replika předpokládá roli primárního serveru, zatímco původní primární server se stane sekundárním.
Geografická replikace mezi předplatnými
V určitých scénářích možná budete muset nakonfigurovat sekundární repliku v jiném předplatném než primární databázi. Tady přichází funkce geografické replikace mezi předplatnými.
Poznámka:
Geografická replikace mezi předplatnými je dostupná pouze prostřednictvím kódu programu.
Další informace o krocích potřebných ke konfiguraci geografické replikace mezi předplatnými najdete v tématu Geografická replikace mezi předplatnými.
Skupiny převzetí služeb při selhání
Skupina automatického převzetí služeb při selhání je funkce vysoké dostupnosti podporovaná službou Azure SQL Database i službou Azure SQL Managed Instance. Skupiny automatického převzetí služeb při selhání umožňují spravovat, jak se databáze replikují do jiné oblasti a jak by mohlo dojít k převzetí služeb při selhání. Název přiřazený skupině automatického převzetí služeb při selhání musí být jedinečný v rámci domény *.database.windows.net .
Skupina automatického převzetí služeb při selhání může obsahovat více databází. Primární i sekundární mají stejnou velikost databáze.
Skupiny automatického převzetí služeb při selhání poskytují funkce podobné skupině dostupnosti označované jako naslouchací proces, který umožňuje jak aktivitu čtení i zápisu, tak jen pro čtení. Existují dva různé typy naslouchacích procesů: jeden pro čtení i zápis a jeden pro provoz jen pro čtení. Na pozadí převzetí služeb při selhání se DNS aktualizuje, aby klienti mohli odkazovat na abstraktní název naslouchacího procesu a nemusí znát nic jiného. Databázový server obsahující kopie pro čtení i zápis je primární a server, který přijímá transakce z primárního serveru, je sekundární.
Existují dvě různé zásady pro skupiny automatického převzetí služeb při selhání.
| Typ zásad | Popis |
|---|---|
| Automatické | Když se zjistí selhání, systém ve výchozím nastavení automaticky aktivuje převzetí služeb při selhání. V případě potřeby ale můžete automatické převzetí služeb při selhání zakázat. |
| Jen pro čtení | Během převzetí služeb při selhání modul ve výchozím nastavení zakáže naslouchací proces jen pro čtení, aby při výpadku sekundárního serveru zachoval výkon nového primárního serveru. Toto chování ale můžete změnit tak, aby umožňovalo oba typy provozu po převzetí služeb při selhání. |
Převzetí služeb při selhání je proces, který lze ručně zahájit, i když je povolené automatické převzetí služeb při selhání. Typ převzetí služeb při selhání ale může ovlivnit, jestli dojde ke ztrátě dat. Neplánované převzetí služeb při selhání může například vést ke ztrátě dat, pokud je vynucená a sekundární databáze není plně synchronizovaná s primární databází.
Určuje GracePeriodWithDataLossHours dobu čekání Azure před zahájením převzetí služeb při selhání s výchozí hodnotou nastavenou na jednu hodinu. Pokud je cíl bodu obnovení (RPO) přísný a ztráta dat není možnost, můžete tuto hodnotu nastavit výš. I když to znamená, že Azure před zahájením převzetí služeb při selhání čeká déle, může potenciálně snížit ztrátu dat, protože sekundární databáze bude mít více času na úplnou synchronizaci s primární databází.
Poznámka:
Sekundární databáze se vytvoří automaticky prostřednictvím procesu označovaného jako počáteční, což může v závislosti na velikosti databáze nějakou dobu trvat. Proto je důležité naplánovat dopředu s ohledem na faktory, jako je rychlost sítě.
Další informace o vysoké dostupnosti a zotavení po havárii pro Azure SQL Database najdete v kontrolním seznamu k vysoké dostupnosti a zotavení po havárii ve službě Azure SQL Database.