Přehled provozní kontinuity se službou Azure SQL DatabaseOverview of business continuity with Azure SQL Database

Kontinuita podnikových procesů v Azure SQL Database odkazuje na mechanismy, zásady a postupy, které umožní vašemu podniku pokračovat v práci na tváři přerušení, zejména pro výpočetní infrastrukturu.Business continuity in Azure SQL Database refers to the mechanisms, policies, and procedures that enable your business to continue operating in the face of disruption, particularly to its computing infrastructure. Ve většině případů Azure SQL Database zpracuje rušivé události, které se mohou vyskytnout v cloudovém prostředí, a udržuje aplikace a obchodní procesy spuštěné.In the most of the cases, Azure SQL Database will handle the disruptive events that might happen in the cloud environment and keep your applications and business processes running. Existují však některé rušivé události, které nemohou být zpracovány SQL Database automaticky jako:However, there are some disruptive events that cannot be handled by SQL Database automatically such as:

  • Uživatel omylem odstranil nebo aktualizoval řádek v tabulce.User accidentally deleted or updated a row in a table.
  • Škodlivý útočník úspěšně odstranil data nebo vyřazení databáze.Malicious attacker succeeded to delete data or drop a database.
  • Zemětřesení způsobil výpadek napájení a dočasné zakázané datové centrum.Earthquake caused a power outage and temporary disabled data-center.

Tento přehled popisuje možnosti, které služba Azure SQL Database nabízí pro zajištění provozní kontinuity a zotavení po havárii.This overview describes the capabilities that Azure SQL Database provides for business continuity and disaster recovery. Seznamte se s možnostmi, doporučeními a kurzy pro obnovování z rušivých událostí, které mohou způsobit ztrátu dat nebo způsobit nedostupnost databáze a aplikace.Learn about options, recommendations, and tutorials 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 služby SQL Database, pomocí kterých můžete zajistit provozní kontinuituSQL Database features that you can use to provide business continuity

Z perspektivy databáze existují čtyři scénáře s případnými výpadky:From a database perspective, there are four major potential disruption scenarios:

  • Selhání místních hardwarových nebo softwarových uzlů ovlivňujících uzel databáze, jako je například selhání diskového jednotky.Local hardware or software failures affecting the database node such as a disk-drive failure.
  • Poškození dat nebo odstranění je obvykle způsobeno chybou aplikace nebo lidskou chybou.Data corruption or deletion typically caused by an application bug or human error. Taková selhání jsou specifická pro jednotlivé aplikace a obvykle se nedají detekovat databázovou službou.Such failures are application-specific and typically cannot be detected by the database service.
  • Výpadek datového centra, možná způsobené přírodní katastrofou.Datacenter outage, possibly caused by a natural disaster. Tento scénář vyžaduje určitou úroveň geografické redundance s převzetím služeb při selhání do alternativního datového centra.This scenario requires some level of geo-redundancy with application failover to an alternate datacenter.
  • Chyby upgradu nebo údržby, neočekávané problémy, ke kterým dojde během plánované údržby nebo údržby infrastruktury, mohou vyžadovat rychlé vrácení zpět do předchozího stavu databáze.Upgrade or maintenance errors, unanticipated issues that occur during planned infrastructure maintenance or upgrades may require rapid rollback to a prior database state.

Pro zmírnění selhání místního hardwaru a softwaru SQL Database zahrnuje architekturu s vysokou dostupností, která garantuje automatické obnovení z těchto selhání s 99,995% dostupností smlouvy SLA.To mitigate the local hardware and software failures, SQL Database includes a high availability architecture, which guarantees automatic recovery from these failures with up to 99.995% availability SLA.

Z důvodu ochrany vaší firmy před ztrátou dat SQL Database automaticky vytvoří úplné zálohy databáze každý týden, odrozdílové zálohy databáze každých 12 hodin a zálohování protokolů transakcí každé 5-10 minut.To protect your business from data loss, SQL Database automatically creates full database backups weekly, differential database backups every 12 hours, and transaction log backups every 5 - 10 minutes . Zálohy se ukládají do úložiště RA-GRS po dobu alespoň 7 dnů pro všechny úrovně služeb.The backups are stored in RA-GRS storage for at least 7 days for all service tiers. Všechny úrovně služeb s výjimkou podpora Basic konfigurovatelný doba uchovávání záloh pro obnovení k určitému bodu v čase, až 35 dní.All service tiers except Basic support configurable backup retention period for point-in-time restore, up to 35 days.

SQL Database také nabízí několik funkcí provozní kontinuity, které můžete použít ke zmírnění různých neplánovaných scénářů.SQL Database also provides several business continuity features, that you can use to mitigate various unplanned scenarios.

Obnovení databáze ve stejné oblasti AzureRecover a database within the same Azure region

Automatické zálohování databáze můžete použít k obnovení databáze k určitému bodu v čase v minulosti.You can use automatic database backups to restore a database to a point in time in the past. Tímto způsobem se můžete zotavit z poškození dat způsobených lidmi chybami.This way you can recover from data corruptions caused by human errors. Obnovení k určitému bodu v čase umožňuje vytvořit novou databázi na stejném serveru, který představuje stav dat před poškozenou událostí.The point-in-time restore allows you to create a new database in the same server that represents the state of data prior to the corrupting event. U většiny databází trvá operace obnovení méně než 12 hodin.For most databases the restore operations takes less than 12 hours. Obnovení velmi rozsáhlé nebo vysoce aktivní databáze může trvat déle.It may take longer to recover a very large or very active database. Další informace o čase obnovení najdete v tématu čas obnovení databáze.For more information about recovery time, see database recovery time.

Pokud není maximální podporovaná doba uchovávání záloh pro obnovení k určitému bodu v čase (PITR) dostatečná pro vaši aplikaci, můžete ji prodloužit konfigurací zásad pro dlouhodobé uchovávání (LTR) pro databáze.If the maximum supported backup retention period for point-in-time restore (PITR) is not sufficient for your application, you can extend it by configuring a long-term retention (LTR) policy for the database(s). Další informace najdete v tématu dlouhodobé uchovávání záloh.For more information, see Long-term backup retention.

Porovnání geografické replikace se skupinami převzetí služeb při selháníCompare geo-replication with failover groups

Skupiny s automatickým převzetím služeb při selhání zjednodušují nasazení a používání geografické replikace a přidávají další možnosti, jak je popsáno v následující tabulce:Auto-failover groups simplify the deployment and usage of geo-replication and add the additional capabilities as described in the following table:

Geografická replikaceGeo-replication Skupiny převzetí služeb při selháníFailover groups
Automatické převzetí služeb při selháníAutomatic failover NeNo AnoYes
Převzetí služeb při selhání více databází současněFail over multiple databases simultaneously NeNo AnoYes
Po převzetí služeb při selhání aktualizovat připojovací řetězecUpdate connection string after failover AnoYes NeNo
Spravovaná instance je podporovaná.Managed instance supported NeNo AnoYes
Může být ve stejné oblasti jako primárníCan be in same region as primary AnoYes NeNo
Více replikMultiple replicas AnoYes NeNo
Podporuje čtení i škálování.Supports read-scale AnoYes AnoYes
     

Obnovení databáze na existujícím serveruRecover a database to the existing server

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. Při výpadku dojde k narušení provozu, které může trvat jen několik minut nebo až několik hodin.When an outage occurs, it causes a business disruption that might only last a few minutes or might last for hours.

  • Jednou z možností je počkat, až výpadek skončí a databáze se vrátí do režimu online.One option is to wait for your database to come back online when the data center outage is over. Tento postup funguje pro aplikace, které si mohou dovolit mít databázi v režimu offline.This works for applications that can afford to have the database offline. Například vývojový projekt nebo bezplatná zkušební verze, na které nemusíte neustále pracovat.For example, a development project or free trial you don't need to work on constantly. 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 už nepotřebujete databázi.When a 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 database for a while.
  • Další možností je obnovit databázi na jakémkoli serveru v libovolné oblasti Azure pomocí geograficky redundantních záloh databáze (geografické obnovení).Another option is to restore a database on any server in any Azure region using geo-redundant database backups (geo-restore). Geografické obnovení používá jako zdroj geograficky redundantní zálohu a dá se použít k obnovení databáze i v případě, že je databáze nebo datacentrum nedostupné kvůli výpadku.Geo-restore uses a geo-redundant backup as its source and can be used to recover a database even if the database or datacenter is inaccessible due to an outage.
  • Nakonec můžete rychle obnovit z výpadku, pokud jste nakonfigurovali geograficky sekundární pomocí aktivní geografické replikace nebo skupiny automatického převzetí služeb při selhání pro vaši databázi nebo databáze.Finally, you can quickly recover from an outage if you have configured either geo-secondary using active geo-replication or an auto-failover group for your database or databases. V závislosti na vaší volbě těchto technologií můžete použít buď ruční nebo automatické převzetí služeb při selhání.Depending on your choice of these technologies, you can use either manual or automatic failover. I když převzetí služeb při selhání zabere jenom pár sekund, bude tato služba při aktivaci trvat aspoň 1 hodinu.While failover itself takes only a few seconds, the service will take at least 1 hour to activate it. To je nezbytné k tomu, aby bylo zajištěno, že převzetí služeb při selhání je v rámci škálování výpadku oprávněné.This is necessary to ensure that the failover is justified by the scale of the outage. Převzetí služeb při selhání může také vést k malé ztrátě dat z důvodu povahy asynchronní replikace.Also, the failover may result in small data loss due to the nature of asynchronous replication.

Při vývoji plánu provozní kontinuity musíte pochopit maximální přijatelnou dobu úplného zotavení aplikace po ničivé události.As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after the disruptive event. Čas potřebný k úplnému obnovení aplikace je známý jako cíl doby obnovení (RTO).The time required for application to fully recover is known as Recovery time objective (RTO). Také je potřeba porozumět maximálnímu intervalu nedávných aktualizací dat (časový interval), které může aplikace tolerovat při obnovování z neplánované události rušivého vlivu na ztrátu.You also need to understand the maximum period of recent data updates (time interval) the application can tolerate losing when recovering from an unplanned disruptive event. Potenciální ztráta dat se označuje jako cíl bodu obnovení (RPO).The potential data loss is known as Recovery point objective (RPO).

Různé metody obnovení nabízejí různé úrovně bodu RPO a RTO.Different recovery methods offer different levels of RPO and RTO. Můžete zvolit konkrétní metodu obnovení nebo použít kombinaci metod k dosažení úplného obnovení aplikace.You can choose a specific recovery method, or use a combination of methods to achieve full application recovery. Následující tabulka porovnává RPO a RTO jednotlivých možností obnovení.The following table compares RPO and RTO of each recovery option. Skupiny automatického převzetí služeb při selhání zjednodušují nasazení a využití geografické replikace a přidávají další možnosti, jak je popsáno v následující tabulce.Auto-failover groups simplify the deployment and usage of geo-replication and adds the additional capabilities as described in the following table.

Metoda obnoveníRecovery method RTORTO OBNOVENÍRPO
Geografické obnovení ze geograficky replikovaných zálohGeo-restore from geo-replicated backups 12 h12 h 1 h1 h
Skupiny automatického převzetí služeb při selháníAuto-failover groups 1 h1 h 5 s5 s
Ruční převzetí služeb při selhání databázeManual database failover 30 s30 s 5 s5 s

Poznámka

Ruční převzetí služeb při selhání databáze odkazuje na převzetí služeb při selhání izolované databáze na geograficky replikovanou sekundární práci pomocí neplánovaného režimu.Manual database failover refers to failover of a single database to its geo-replicated secondary using the unplanned mode. Podrobnosti o automatických převzetí služeb při selhání RTO a RPO najdete v tabulce výše v tomto článku.See the table earlier in this article for details of the auto-failover RTO and RPO.

Pokud vaše aplikace splňuje některá z těchto kritérií, použijte skupiny automatického převzetí služeb při selhání:Use auto-failover groups if your application meets any of these criteria:

  • Je zvlášť důležitá.Is mission critical.
  • Má smlouvu o úrovni služeb (SLA), která neumožňuje 12 hodin nebo více výpadků.Has a service level agreement (SLA) that does not allow for 12 hours or more of downtime.
  • Výpadek může vést k finanční zodpovědnosti.Downtime may result in financial liability.
  • Má vysokou míru změny dat a 1 hodina ztráty dat není přijatelné.Has a high rate of data change and 1 hour of data loss is not acceptable.
  • Další náklady na aktivní geografickou replikaci jsou nižší než potenciální finanční závazky a související ztráta podnikání.The additional cost of active geo-replication is lower than the potential financial liability and associated loss of business.

V závislosti na požadavcích vaší aplikace se můžete rozhodnout použít kombinaci záloh databáze a aktivní geografické replikace.You may choose to use a combination of database backups and active geo-replication depending upon your application requirements. Diskuzi o požadavcích na návrh pro samostatné databáze a elastické fondy, které využívají tyto funkce pro provozní kontinuitu, najdete v tématu Návrh aplikace pro zotavení po havárii cloudu a strategie zotavení po havárii elastického fondu.For a discussion of design considerations for stand-alone databases and for elastic pools using these business continuity features, see Design an application for cloud disaster recovery and Elastic pool disaster recovery strategies.

Následující části obsahují přehled kroků pro obnovení pomocí záloh databáze nebo aktivní geografické replikace.The following sections provide an overview of the steps to recover using either database backups or active geo-replication. Podrobný postup, včetně požadavků na plánování, kroků po obnovení a informací o tom, jak simulovat výpadky při provádění postupu zotavení po havárii, najdete v tématu obnovení SQL Database při výpadku.For detailed steps including planning requirements, post recovery steps, and information about how to simulate an outage to perform a disaster recovery drill, see Recover a SQL Database from an outage.

Příprava na výpadekPrepare for an outage

Bez ohledu na funkce provozní kontinuity, které používáte, musíte:Regardless of the business continuity feature you use, you must:

  • Identifikujte a připravte cílový server, včetně pravidel brány firewall na úrovni serveru, přihlašovacích údajů a oprávnění na úrovni hlavní databáze.Identify and prepare the target server, including server-level IP firewall rules, logins, and master database level permissions.
  • Určit, jak přesměrovat klienty a klientské aplikace na nový serverDetermine how to redirect clients and client applications to the new server
  • Zdokumentovat další závislosti, například nastavení auditování a výstrahyDocument other dependencies, such as auditing settings and alerts

Pokud nebudete připravovat správně, po převzetí služeb při selhání nebo obnovení databáze bude trvat déle a pravděpodobně budete potřebovat řešení potíží v době zátěže – Chybná kombinace.If you do not prepare properly, bringing your applications online after a failover or a database recovery takes additional time and likely also require troubleshooting at a time of stress - a bad combination.

Převzetí služeb při selhání geograficky replikovanou sekundární databázíFail over to a geo-replicated secondary database

Pokud jako mechanismus obnovení používáte aktivní geografickou replikaci nebo skupiny s automatickým převzetím služeb při selhání, můžete nakonfigurovat zásady automatického převzetí služeb při selhání nebo použít Ruční neplánované převzetí služeb přiselhání.If you are using active geo-replication or auto-failover groups as your recovery mechanism, you can configure an automatic failover policy or use manual unplanned failover. Po zahájení převzetí služeb při selhání způsobí, že se sekundární stane novou primární a připravený k zaznamenávání nových transakcí a reakci na dotazy – s minimální ztrátou dat pro data, která se ještě nereplikují.Once initiated, the failover causes the secondary to become the new primary and ready to record new transactions and respond to queries - with minimal data loss for the data not yet replicated. Informace o návrhu procesu převzetí služeb při selhání najdete v tématu Návrh aplikace pro zotavení po havárii cloudu.For information on designing the failover process, see Design an application for cloud disaster recovery.

Poznámka

Když se datové centrum vrátí do režimu online, staré primární základní (Base) se automaticky znovu připojí k nové primární databázi a stanou se sekundárními databázemi.When the data center comes back online the old primaries automatically reconnect to the new primary and become secondary databases. Pokud potřebujete přemístit primární zpátky do původní oblasti, můžete plánované převzetí služeb při selhání iniciovat ručně (navrácení služeb po obnovení).If you need to relocate the primary back to the original region, you can initiate a planned failover manually (failback).

Provést geografickou obnovuPerform a geo-restore

Pokud používáte automatizované zálohování s geograficky redundantním úložištěm (povoleno ve výchozím nastavení), můžete obnovit databázi pomocí geografického obnovení.If you are using the automated backups with geo-redundant storage (enabled by default), you can recover the database using geo-restore. K obnovení obvykle dochází během 12 hodin – s ztrátou dat po dobu až jedné hodiny, kterou určuje čas, kdy byla provedena a replikována poslední záloha protokolu.Recovery usually takes place within 12 hours - with data loss of up to one hour determined by when the last log backup was taken and replicated. Dokud se obnovení nedokončí, databáze není schopná zaznamenávat žádné transakce ani reagovat na dotazy.Until the recovery completes, the database is unable to record any transactions or respond to any queries. Poznámka: geografická obnova obnovuje databázi pouze do posledního dostupného bodu v čase.Note, geo-restore only restores the database to the last available point in time.

Poznámka

Pokud se datové centrum vrátí do režimu online předtím, než přepnete aplikaci do obnovené databáze, můžete obnovení zrušit.If the data center comes back online before you switch your application over to the recovered database, you can cancel the recovery.

Provedení úloh po převzetí služeb při selhání nebo obnoveníPerform post failover / recovery tasks

Po obnovení s použitím libovolného mechanismu musíte provést následující dodatečné úlohy, abyste pro uživatele zprovoznili své aplikace:After recovery from either recovery mechanism, you must perform the following additional tasks before your users and applications are back up and running:

  • Přesměrujte klienty a klientské aplikace na nový server a obnovenou databázi.Redirect clients and client applications to the new server and restored database
  • Zajistěte, aby se pro uživatele připojovala příslušná pravidla brány firewall na úrovni serveru, aby je bylo možné povolit, aby mohli používat brány firewall na úrovni databáze .Ensure appropriate server-level IP firewall rules are in place for users to connect or use database-level firewalls to enable appropriate rules.
  • Ujistěte se, že se používají odpovídající přihlášení a oprávnění na úrovni hlavní databáze (nebo použijte obsažené uživatelé)Ensure appropriate logins and master database level permissions are in place (or use contained users)
  • Podle potřeby nakonfigurujte auditování.Configure auditing, as appropriate
  • Podle potřeby nakonfigurujte výstrahy.Configure alerts, as appropriate

Poznámka

Pokud používáte skupinu převzetí služeb při selhání a připojujete se k databázím pomocí lstener pro čtení i zápis, přesměrování po převzetí služeb při selhání proběhne automaticky a transparentně do aplikace.If you are using a failover group and connect to the databases using the read-write lstener, the redirection after failover will happen automatically and transparently to the application.

Upgrade aplikace s minimálními výpadkyUpgrade an application with minimal downtime

V některých případech je třeba aplikaci odebrat z důvodu plánované údržby, jako je například upgrade aplikace.Sometimes an application must be taken offline because of planned maintenance such as an application upgrade. Správa upgradů aplikací : popisuje, jak používat aktivní geografickou replikaci k zajištění postupného upgradu vaší cloudové aplikace za účelem minimalizace výpadků během upgradů a k zadání cesty pro obnovení, pokud se něco nepovede.Manage application upgrades describes how to use active geo-replication to enable rolling upgrades of your cloud application to minimize downtime during upgrades and provide a recovery path if something goes wrong.

Další krokyNext steps

Diskuzi o faktorech návrhu aplikací pro samostatné databáze a elastické fondy najdete v tématu Návrh aplikace pro zotavení po havárii cloudu a strategie zotavení po havárii elastického fondu.For a discussion of application design considerations for stand-alone databases and for elastic pools, see Design an application for cloud disaster recovery and Elastic pool disaster recovery strategies.