Informace o kontinuitě podnikových aplikací v Azure Database for MySQLUnderstand business continuity in Azure Database for MySQL

Tento článek popisuje možnosti, které Azure Database for MySQL poskytuje pro provozní kontinuitu a zotavení po havárii.This article describes the capabilities that Azure Database for MySQL provides for business continuity and disaster recovery. Seznamte se s možnostmi pro zotavení z rušivých událostí, které by mohly způsobit ztrátu dat nebo způsobit nedostupnost databáze a aplikace.Learn about options for recovering from disruptive events that could cause data loss or cause your database and application to become unavailable. Přečtěte si, co dělat, když dojde k chybě uživatele nebo aplikace při vlivu na integritu dat, když dojde k výpadku oblasti Azure nebo když vaše aplikace vyžaduje údržbu.Learn what to do when a user or application error affects data integrity, an Azure region has an outage, or your application requires maintenance.

Funkce, které můžete použít k zajištění kontinuity podnikových aplikacíFeatures that you can use to provide business continuity

Azure Database for MySQL poskytuje funkce pro provozní kontinuitu, které zahrnují automatizované zálohování a schopnost uživatelů zahájit geografické obnovení.Azure Database for MySQL provides business continuity features that include automated backups and the ability for users to initiate geo-restore. Každý má různé charakteristiky pro odhadovanou dobu obnovení (ERT) a potenciální ztrátu dat.Each has different characteristics for Estimated Recovery Time (ERT) and potential data loss. Jakmile tyto možnosti pochopíte, můžete si je vybrat mezi nimi a použít je společně pro různé scénáře.Once you understand these options, you can choose among them, and use them together for different scenarios. Při vývoji plánu provozní kontinuity je potřeba pochopit maximální přijatelnou dobu, než aplikace plně obnoví po přerušení události – to je vaše plánovaná doba obnovení (RTO).As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after the disruptive event - this is your Recovery Time Objective (RTO). Také je potřeba pochopit maximální množství nedávných aktualizací dat (časový interval), které může aplikace tolerovat při obnovování po přerušení události – to je váš cíl bodu obnovení (RPO).You also need to understand the maximum amount of recent data updates (time interval) the application can tolerate losing when recovering after the disruptive event - this is your Recovery Point Objective (RPO).

Následující tabulka porovnává ERT a RPO pro dostupné funkce:The following table compares the ERT and RPO for the available features:

PodporuCapability BasicBasic Pro obecné účelyGeneral Purpose Optimalizované z hlediska pamětiMemory optimized
Obnovení k určitému bodu v čase ze zálohyPoint in Time Restore from backup Libovolný bod obnovení v rámci doby uchováníAny restore point within the retention period Libovolný bod obnovení v rámci doby uchováníAny restore point within the retention period Libovolný bod obnovení v rámci doby uchováníAny restore point within the retention period
Geografické obnovení ze geograficky replikovaných zálohGeo-restore from geo-replicated backups NepodporovánoNot supported ERT < 12 hERT < 12 h
RPO < 1 hRPO < 1 h
ERT < 12 hERT < 12 h
RPO < 1 hRPO < 1 h

Důležité

Odstraněné servery nelze obnovit.Deleted servers cannot be restored. Pokud server odstraníte, odstraní se i všechny databáze patřící do serveru a nebude možné je obnovit.If you delete the server, all databases that belong to the server are also deleted and cannot be recovered.

Obnovení serveru po chybě uživatele nebo aplikaceRecover a server after a user or application error

Zálohy služby můžete použít k obnovení serveru z různých rušivých událostí.You can use the service’s backups to recover a server from various disruptive events. Uživatel může omylem odstranit některá data, neúmyslně odstranit důležitou tabulku nebo dokonce odstranit celou databázi.A user may accidentally delete some data, inadvertently drop an important table, or even drop an entire database. Aplikace může omylem přepsat dobrá data s chybnými daty z důvodu vady aplikace atd.An application might accidentally overwrite good data with bad data due to an application defect, and so on.

Můžete provést obnovení k určitému bodu v čase a vytvořit tak kopii serveru pro známý dobrý bod v čase.You can perform a point-in-time-restore to create a copy of your server to a known good point in time. Tento bod v čase musí být v období uchovávání záloh, které jste nakonfigurovali pro váš server.This point in time must be within the backup retention period you have configured for your server. Po obnovení dat na novém serveru můžete původní server nahradit novým obnoveným serverem nebo zkopírovat potřebná data z obnoveného serveru na původní server.After the data is restored to the new server, you can either replace the original server with the newly restored server or copy the needed data from the restored server into the original server.

Zotavení z výpadku regionálního datového centra AzureRecover from an Azure regional data center outage

Přestože je taková situace výjimečná, i u datového centra Azure může dojít k výpadku.Although rare, an Azure data center can have an outage. Pokud dojde k výpadku, způsobí to narušení podniku, které může trvat jenom několik minut, ale může to trvat i hodinu.When an outage occurs, it causes a business disruption that might only last a few minutes, but could last for hours.

Jednou z možností je počkat, až se váš server vrátí zpátky do režimu online, když dojde k výpadku datového centra.One option is to wait for your server to come back online when the data center outage is over. To funguje u aplikací, které můžou umožnit, aby byl server v určitou dobu offline, například vývojové prostředí.This works for applications that can afford to have the server offline for some period of time, for example a development environment. Když 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 ještě nepotřebujete.When data center has an outage, you do not know how long the outage might last, so this option only works if you don't need your server for a while.

Druhou možností je použít funkci geografického obnovení Azure Database for MySQL, která obnoví Server pomocí geograficky redundantních záloh.The other option is to use the Azure Database for MySQL's geo-restore feature that restores the server using geo-redundant backups. Tyto zálohy jsou přístupné i v případě, že je oblast, ve které je server hostovaný, v režimu offline.These backups are accessible even when the region your server is hosted in is offline. Můžete obnovit z těchto záloh do jakékoli jiné oblasti a převést Server zpátky do online režimu.You can restore from these backups to any other region and bring your server back online.

Důležité

Geografické obnovení je možné pouze v případě, že jste zřídili Server s geograficky redundantním úložištěm záloh.Geo-restore is only possible if you provisioned the server with geo-redundant backup storage. Pokud chcete přepnout z místně redundantního na geograficky redundantní zálohy pro existující server, musíte použít výpis paměti s použitím mysqldump stávajícího serveru a obnovit ho na nově vytvořený server nakonfigurovaný pomocí geograficky redundantních záloh.If you wish to switch from locally redundant to geo-redundant backups for an existing server, you must take a dump using mysqldump of your existing server and restore it to a newly created server configured with geo-redundant backups.

Další krokyNext steps