Přehled kontinuity podnikových procesů se službou Azure Database for MariaDB

  • Článek

Důležité

Azure Database for MariaDB je na cestě vyřazení. Důrazně doporučujeme migrovat do služby Azure Database for MySQL. Další informace o migraci na Azure Database for MySQL najdete v tématu Co se děje se službou Azure Database for MariaDB?.

Tento článek popisuje možnosti, které azure Database for MariaDB 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 chyba aplikace ovlivňuje integritu dat, oblast Azure má výpadek nebo vaše aplikace potřebuje údržbu.

Funkce pro provozní kontinuitu

Při vývoji plánu provozní kontinuity potřebujete porozumět:

  • Cíl doby obnovení (RTO):Maximální přijatelná doba před úplným obnovením aplikace po rušivé události.
  • Cíl bodu obnovení (RPO): Maximální množství nedávných aktualizací dat (časový interval), které může aplikace tolerovat ztrátu, když se obnoví po rušivé události.

Azure Database for MariaDB 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.

Při geografickém obnovení vytvoří Azure Database for MariaDB nový server pomocí zálohovaných dat replikovaných z jiné oblasti. Celková doba obnovení a obnovení závisí na velikosti databáze a množství dat protokolu, která se mají obnovit. 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í databáze asynchronně streamují do repliky. Pokud dojde k výpadku primární databáze kvůli selhání na úrovni zóny nebo oblasti, převzetí služeb při selhání repliky poskytuje kratší plánovanou dobu obnovení a snížení ztráty dat.

Poznámka:

Prodleva mezi primární databází a replikou závisí na latenci mezi lokalitami, množství přenášených dat a (nejdůležitější) úloha zápisu primárního serveru. Úlohy náročného zápisu můžou generovat významnou prodlevu.

Vzhledem k asynchronní povaze replikace, která se používá pro repliky pro čtení, zvažte, aby repliky pro čtení byly řešením s vysokou dostupností. Vyšší prodlevy můžou znamenat vyšší rto a cíl bodu obnovení. Repliky pro čtení můžou fungovat jako alternativa s vysokou dostupností pouze pro úlohy, u kterých prodleva zůstává menší až po špičku a mimo špičku. V opačném případě jsou repliky pro čtení určené pro skutečné škálování čtení pro úlohy náročné na čtení a scénáře 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 :

Schopnost Basic Obecné účely 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 se liší
Cíl bodu obnovení je kratší než 15 minut.		 Jakýkoli bod obnovení v rámci doby uchovávání
RtO se liší
Cíl bodu obnovení je kratší než 15 minut.		 Jakýkoli bod obnovení v rámci doby uchovávání
RtO se liší
Cíl bodu obnovení je kratší než 15 minut.
Geografické obnovení z geograficky replikovaných záloh Nepodporováno RtO se liší
Cíl bodu obnovení je větší než 24 hodin		 RtO se liší
Cíl bodu obnovení je větší než 24 hodin
Čtení replik RTO je minuty
Cíl bodu obnovení je kratší než 5 minut.		 RTO je minuty
Cíl bodu obnovení je kratší než 5 minut.		 RTO je minuty
Cíl bodu obnovení je kratší než 5 minut.

RtO a RPO můžou být v některých případech mnohem vyšší v závislosti na faktorech, jako je latence mezi lokalitami, objem přenášených dat a úloha zápisu 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 například 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.

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í být v rámci doby uchovávání záloh, kterou jste nakonfigurovali pro server. 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 na původní server.

Důležité

Odstraněné servery můžete obnovit pouze do pěti dnů od odstranění. Po pěti dnech se zálohy odstraní. K zálohování databáze můžete 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 před náhodným odstraněním nebo neočekávanými změnami po nasazení můžou správci používat zámky správy.

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

I když je to vzácné, datacentrum Azure může mít výpadek. Když dojde k výpadku, způsobí přerušení firmy, které může trvat jen 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 datacentra. Pokud dojde k výpadku datacentra, nevíte, jak dlouho může výpadek trvat. Tato možnost tedy funguje jenom pro aplikace, které si můžou dovolit, aby byl server po určitou dobu offline (například vývojové prostředí).

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ý offline. Z těchto záloh můžete provést obnovení do jakékoli jiné oblasti a potom 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 vygenerovat zálohu stávajícího serveru. Potom proveďte obnovení na nově vytvořený server, který je nakonfigurovaný s geograficky redundantními zálohami.

Repliky pro čtení mezi oblastmi

Repliky pro čtení mezi oblastmi můžete použít k vylepšení plánování provozní kontinuity a zotavení po havárii. Repliky pro čtení se aktualizují asynchronně prostřednictvím replikační technologie MySQL pro binární protokoly. Přečtěte si další informace o replikách pro čtení, dostupných oblastech a o převzetí služeb při selhání v článku o konceptech replik pro čtení.

Často kladené dotazy

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

Ve výchozím nastavení Azure Database for MariaDB nepřesouvají ani neukládají zákaznická data z oblasti, ve které je nasazená. Volitelně ale můžete povolit geograficky redundantní zálohy nebo vytvořit repliky pro čtení mezi oblastmi pro ukládání dat v jiné oblasti.

Další kroky