Přehled kontinuity podnikových procesů s jednoúčelovým serverem Azure Database for MySQL

  • Článek

PLATÍ PRO: Jednoúčelový server Azure Database for MySQL

Důležité

Jednoúčelový server Azure Database for MySQL je na cestě vyřazení. Důrazně doporučujeme upgradovat na flexibilní server Azure Database for MySQL. Další informace o migraci na flexibilní server Azure Database for MySQL najdete v tématu Co se děje s jednoúčelovým serverem Azure Database for MySQL?

Tento článek popisuje možnosti, které azure Database for MySQL poskytuje pro provozní kontinuitu a zotavení po havárii. Přečtěte si informace o možnostech zotavení z rušivých událostí, které by mohly způsobit ztrátu dat nebo způsobit nedostupnost databáze a aplikace. Zjistěte, co dělat, když chyba uživatele nebo aplikace ovlivňuje integritu dat, oblast Azure má výpadek nebo vaše aplikace vyžaduje údržbu.

Funkce, které můžete použít k zajištění kontinuity podnikových procesů

Při vývoji plánu provozní kontinuity musíte pochopit maximální přijatelnou dobu, než se aplikace plně obnoví po rušivé události – jedná se o plánovanou dobu obnovení (RTO). Musíte také pochopit maximální množství nedávných aktualizací dat (časový interval), které může aplikace tolerovat ztrátu při obnovení po rušivé události – jedná se o cíl bodu obnovení (RPO).

Jednoúčelový server Azure Database for MySQL poskytuje funkce provozní kontinuity a zotavení po havárii, které zahrnují geograficky redundantní zálohy s možností inicializovat geografické obnovení a nasazovat repliky pro čtení v jiné oblasti. Jednotlivé funkce mají různé vlastnosti týkající se doby potřebné k obnovení a potenciální ztráty dat. Pomocí funkce geografického obnovení se vytvoří nový server pomocí zálohovaných dat replikovaných z jiné oblasti. Celková doba potřebná k obnovení a zotavení závisí na velikosti databáze a množství protokolů k obnovení. Celková doba potřebná ke zřízení serveru se může lišit od několika minut až po několik hodin. U replik pro čtení se transakční protokoly z primární repliky asynchronně streamují do repliky. V případě výpadku primární databáze kvůli selhání na úrovni zóny nebo oblasti poskytuje převzetí služeb při selhání repliky kratší plánovanou dobu obnovení a snížení ztráty dat.

Poznámka:

Prodleva mezi primárním serverem a replikou závisí na latenci mezi lokalitami, množství dat, která se mají přenášet, a hlavně na úloze zápisu primárního serveru. Úlohy s velkým počtem zápisů můžou generovat významnou prodlevu.

Vzhledem k asynchronní povaze replikace používané pro repliky pro čtení by se neměly považovat za řešení s vysokou dostupností (HA), protože vyšší prodlevy můžou znamenat vyšší rto a cíl bodu obnovení. Pouze u úloh, u kterých prodleva zůstává menší přes špičku a ne špičku úlohy, můžou repliky pro čtení fungovat jako alternativa pro vysokou dostupnost. V opačném případě jsou repliky pro čtení určené pro skutečné škálování pro čtení pro náročné úlohy a scénáře zotavení po havárii (zotavení po havárii).

Následující tabulka porovnává plánovanou dobu obnovení a cíl bodu obnovení (RPO) v typickém scénáři úloh :

Schopnosti Basic Obecné použití Optimalizované pro paměť
Obnovení k určitému bodu v čase ze zálohy Jakýkoli bod obnovení v rámci doby uchovávání
RTO – liší se
RPO < 15 min		 Jakýkoli bod obnovení v rámci doby uchovávání
RTO – liší se
RPO < 15 min		 Jakýkoli bod obnovení v rámci doby uchovávání
RTO – liší se
RPO < 15 min
Geografické obnovení z geograficky replikovaných záloh Nepodporováno RTO – liší se
RPO < 1 h		 RTO – liší se
RPO < 1 h
Čtení replik RTO – minuty*
RPO < 5 min*		 RTO – minuty*
RPO < 5 min*		 RTO – minuty*
RPO < 5 min*

* RtO a RPO mohou být v některých případech mnohem vyšší v závislosti na různých faktorech, mezi které patří latence mezi lokalitami, objem přenášených dat a důležité úlohy zápisu do primární databáze.

Obnovení serveru po chybě uživatele nebo aplikace

Zálohy služby můžete použít k obnovení serveru z různých rušivých událostí. Uživatel může omylem odstranit některá data, neúmyslně odstranit důležitou tabulku nebo dokonce odstranit celou databázi. Aplikace může omylem přepsat dobrá data chybnými daty kvůli vadě aplikace atd.

Provedením obnovení k určitému bodu v čase můžete vytvořit kopii vašeho serveru ke známému bodu v čase, kdy byl v pořádku. Tento bod v čase musí spadat do období uchovávání záloh, které jste pro svůj server nakonfigurovali. Po obnovení dat na nový server můžete původní server nahradit nově obnoveným serverem nebo zkopírovat potřebná data z obnoveného serveru do původního serveru.

Důležité

Odstraněné servery je možné obnovit pouze do pěti dnů od odstranění, po kterém se zálohy odstraní. K zálohování databáze je možné přistupovat a obnovovat pouze z předplatného Azure, které je hostitelem serveru. Pokud chcete obnovit vyřazený server, projděte si zdokumentované kroky. K ochraně prostředků serveru, po nasazení, před náhodným odstraněním nebo neočekávanými změnami můžou správci využívat zámky správy.

Zotavení z výpadku regionálního datacentra Azure

Přestože je taková situace výjimečná, i u datového centra Azure může dojít k výpadku. Když dojde k výpadku, způsobí přerušení firmy, které může trvat jenom několik minut, ale může trvat několik hodin.

Jednou z možností je počkat, až se server vrátí do online režimu, když dojde k výpadku datového centra. To funguje pro aplikace, které si můžou dovolit, aby byl server po určitou dobu offline, například pro vývojové prostředí. Pokud dojde k výpadku datového centra, nevíte, jak dlouho může výpadek trvat, takže tato možnost funguje jenom v případě, že server nějakou dobu nepotřebujete.

Geografické obnovení

Funkce geografického obnovení obnoví server pomocí geograficky redundantních záloh. Zálohy se hostují ve spárované oblasti vašeho serveru. Tyto zálohy jsou přístupné i v případě, že je server hostovaný v offline režimu. Z těchto záloh můžete provést obnovení do jakékoli jiné oblasti a přenést server zpět do režimu online. Další informace o geografickém obnovení najdete v článku o konceptech zálohování a obnovení.

Důležité

Geografické obnovení je možné pouze v případě, že jste server zřídili s geograficky redundantním úložištěm zálohování. Pokud chcete přepnout z místně redundantního na geograficky redundantní zálohy pro existující server, musíte pomocí nástroje mysqldump existujícího serveru provést výpis paměti a obnovit ho na nově vytvořený server nakonfigurovaný s geograficky redundantními zálohami.

Repliky pro čtení mezi oblastmi

Repliky pro čtení mezi oblastmi můžete použít k vylepšení provozní kontinuity a plánování zotavení po havárii. Repliky pro čtení se aktualizují asynchronně pomocí technologie replikace binárních protokolů MySQL. Přečtěte si další informace o replikách pro čtení, dostupných oblastech a o tom, jak převzít služby při selhání z článku konceptů replik pro čtení.

Často kladené dotazy

Kde Azure Database for MySQL ukládá zákaznická data?

Ve výchozím nastavení Azure Database for MySQL nepřesouvají ani neukládají zákaznická data z oblasti, ve které jsou nasazená. Zákazníci ale můžou volitelně povolit geograficky redundantní zálohy nebo vytvořit repliku pro čtení mezi oblastmi pro ukládání dat v jiné oblasti.

Další kroky