Obnovení Azure SQL Database nebo převzetí služeb při selhání sekundárnímRestore an Azure SQL Database or failover to a secondary

Azure SQL Database nabízí následující možnosti pro zotavení po výpadku:Azure SQL Database offers the following capabilities for recovering from an outage:

Další informace o scénářích kontinuity podnikových aplikací a funkcích, které tyto scénáře podporují, najdete v tématu Kontinuita podnikových aplikací.To learn about business continuity scenarios and the features supporting these scenarios, see Business continuity.

Poznámka

Pokud používáte databáze nebo fondy nadbytečná zóny nebo Pro důležité obchodní informace, proces obnovení je automatizovaný a zbytek tohoto materiálu neplatí.If you are using zone-redundant Premium or Business Critical databases or pools, the recovery process is automated and the rest of this material does not apply.

Poznámka

U primárních i sekundárních databází je potřeba, aby měly stejnou úroveň služby.Both primary and secondary databases are required to have the same service tier. Také se důrazně doporučuje vytvořit sekundární databázi se stejnou výpočetní velikostí (DTU nebo virtuální jádra) jako primární.It is also strongly recommended that the secondary database is created with the same compute size (DTUs or vCores) as the primary. Další informace najdete v tématu upgrade nebo downgrading jako primární databáze.For more information, see Upgrading or downgrading as primary database.

Poznámka

Pomocí jedné nebo několika skupin převzetí služeb při selhání můžete spravovat převzetí služeb při selhání více databází.Use one or several failover groups to manage failover of multiple databases. Pokud přidáte existující relaci geografické replikace do skupiny převzetí služeb při selhání, ujistěte se, že je geograficky sekundární nakonfigurovaná se stejnou úrovní služeb a výpočetní velikostí jako primární.If you add an existing geo-replication relationship to the failover group, make sure the geo-secondary is configured with the same service tier and compute size as the primary. Další informace najdete v tématu použití skupin automatického převzetí služeb při selhání k zajištění transparentního a koordinovaného převzetí služeb při selhání více databází.For more information, see Use auto-failover groups to enable transparent and coordinated failover of multiple databases.

Příprava na případ výpadkuPrepare for the event of an outage

V případě úspěchu s obnovením do jiné oblasti dat pomocí skupin pro převzetí služeb při selhání nebo geograficky redundantního zálohování je nutné připravit server v jiném výpadku datového centra, aby se stal novým primárním serverem, pokud by to bylo nutné, a měly by být zdokumentovány dobře definované kroky a Testováno pro zajištění hladkého obnovení.For success with recovery to another data region using either failover groups or geo-redundant backups, you need to prepare a server in another data center outage to become the new primary server should the need arise as well as have well-defined steps documented and tested to ensure a smooth recovery. Tyto přípravné kroky zahrnují:These preparation steps include:

  • Identifikujte server SQL Database v jiné oblasti, který se stane novým primárním serverem.Identify the SQL Database server in another region to become the new primary server. V případě geografického obnovení se jedná o server v spárované oblasti pro oblast, ve které se nachází vaše databáze.For geo-restore, this is generally a server in the paired region for the region in which your database is located. Tím se eliminují dodatečné náklady na provoz během geografického obnovení.This eliminates the additional traffic cost during the geo-restoring operations.
  • Identifikujte a volitelně definujte pravidla brány firewall IP na úrovni serveru potřebná pro uživatele, kteří budou mít přístup k nové primární databázi.Identify, and optionally define, the server-level IP firewall rules needed on for users to access the new primary database.
  • Určete, jak budete přesměrovat uživatele na nový primární server, například změnou připojovacích řetězců nebo změnou položek DNS.Determine how you are going to redirect users to the new primary server, such as by changing connection strings or by changing DNS entries.
  • Identifikujte a volitelně Vytvořte přihlašovací údaje, které se musí nacházet v hlavní databázi na novém primárním serveru, a ujistěte se, že tato přihlášení mají v hlavní databázi příslušná oprávnění, pokud existují.Identify, and optionally create, the logins that must be present in the master database on the new primary server, and ensure these logins have appropriate permissions in the master database, if any. Další informace najdete v tématu SQL Database Security po zotavení po havárii .For more information, see SQL Database security after disaster recovery
  • Identifikujte pravidla výstrah, která je potřeba aktualizovat, aby se namapovala na novou primární databázi.Identify alert rules that need to be updated to map to the new primary database.
  • Dokumentuje konfiguraci auditování v aktuální primární databázi.Document the auditing configuration on the current primary database
  • Provedení postupu zotavení po havárii.Perform a disaster recovery drill. Chcete-li simulovat výpadek geografického obnovení, můžete zdrojovou databázi odstranit nebo přejmenovat a způsobit tak selhání připojení aplikace.To simulate an outage for geo-restore, you can delete or rename the source database to cause application connectivity failure. Chcete-li simulovat výpadky pomocí skupin převzetí služeb při selhání, můžete zakázat webovou aplikaci nebo virtuální počítač připojený k databázi nebo převzetí služeb při selhání databáze a způsobit tak selhání připojení aplikace.To simulate an outage using failover groups, you can disable the web application or virtual machine connected to the database or failover the database to cause application connectivity failures.

Kdy spustit obnoveníWhen to initiate recovery

Operace obnovení má vliv na aplikaci.The recovery operation impacts the application. Vyžaduje změnu připojovacího řetězce nebo přesměrování SQL pomocí DNS a může způsobit trvalou ztrátu dat.It requires changing the SQL connection string or redirection using DNS and could result in permanent data loss. Proto by měl být proveden pouze v případě výpadku, který je pravděpodobně naposledy delší než cíl doby obnovení vaší aplikace.Therefore, it should be done only when the outage is likely to last longer than your application's recovery time objective. Když se aplikace nasadí do produkčního prostředí, měli byste pravidelně monitorovat stav aplikace a pomocí následujících datových bodů vyhodnotit, že se obnovení opravňuje:When the application is deployed to production you should perform regular monitoring of the application health and use the following data points to assert that the recovery is warranted:

  1. Trvalá Chyba připojení z aplikační vrstvy k databázi.Permanent connectivity failure from the application tier to the database.
  2. Azure Portal zobrazuje výstrahu týkající se incidentu v oblasti s rozsáhlým dopadem.The Azure portal shows an alert about an incident in the region with broad impact.

Poznámka

Pokud používáte skupiny převzetí služeb při selhání a zvolíte automatické převzetí služeb při selhání, proces obnovení je automatizovaný a transparentní pro aplikaci.If you are using failover groups and chose automatic failover, the recovery process is automated and transparent to the application.

V závislosti na vaší tolerance vaší aplikace na výpadky a možné obchodní odpovědnosti můžete zvážit následující možnosti obnovení.Depending on your application tolerance to downtime and possible business liability you can consider the following recovery options.

K získání nejnovějšího geograficky replikovaného bodu obnovení použijte databázi Get obnovitelné databáze (LastAvailableBackupDate).Use the Get Recoverable Database (LastAvailableBackupDate) to get the latest Geo-replicated restore point.

Počkat na obnovení službyWait for service recovery

Azure Teams funguje usilovně k tomu, aby co nejrychleji obnovil dostupnost služby, ale v závislosti na hlavní příčině může trvat hodiny nebo dny.The Azure teams work diligently to restore service availability as quickly as possible but depending on the root cause it can take hours or days. Pokud vaše aplikace může tolerovat významné výpadky, můžete jednoduše počkat na dokončení obnovení.If your application can tolerate significant downtime you can simply wait for the recovery to complete. V takovém případě není nutná žádná akce s vaší částí.In this case, no action on your part is required. Aktuální stav služby můžete zobrazit na našem řídicím panelu Azure Service Health.You can see the current service status on our Azure Service Health Dashboard. Po obnovení této oblasti se obnoví dostupnost vaší aplikace.After the recovery of the region, your application’s availability is restored.

Převzetí služeb při selhání geograficky replikovaným sekundárním serverem ve skupině převzetí služeb při selháníFail over to geo-replicated secondary server in the failover group

Pokud by výpadky vaší aplikace mohly vést k obchodním zodpovědnostem, měli byste používat skupiny převzetí služeb při selhání.If your application’s downtime can result in business liability, you should be using failover groups. Umožňuje aplikaci rychle obnovit dostupnost v jiné oblasti v případě výpadku.It enables the application to quickly restore availability in a different region in case of an outage. Kurz najdete v tématu implementace geograficky distribuované databáze.For a tutorial, see Implement a geo-distributed database.

Chcete-li obnovit dostupnost databází, je třeba zahájit převzetí služeb při selhání sekundárním serverem pomocí jedné z podporovaných metod.To restore availability of the database(s) you need to initiate the failover to the secondary server using one of the supported methods.

Pro převzetí služeb při selhání geograficky replikovanou sekundární databází použijte jedno z následujících pokynů:Use one of the following guides to fail over to a geo-replicated secondary database:

Obnovení pomocí geografického obnoveníRecover using geo-restore

Pokud výpadek vaší aplikace nevede k obchodním zodpovědnostem, můžete použít geografickou obnovu jako metodu pro obnovení databází aplikace.If your application’s downtime does not result in business liability you can use geo-restore as a method to recover your application database(s). Vytvoří kopii databáze z poslední geograficky redundantní zálohy.It creates a copy of the database from its latest geo-redundant backup.

Konfigurace databáze po obnoveníConfigure your database after recovery

Pokud k zotavení z výpadku používáte geografické obnovení, musíte zajistit, aby připojení k novým databázím bylo správně nakonfigurováno, aby bylo možné obnovit normální funkci aplikace.If you are using geo-restore to recover from an outage, you must make sure that the connectivity to the new databases is properly configured so that the normal application function can be resumed. Toto je kontrolní seznam úkolů pro přípravu obnovené databáze.This is a checklist of tasks to get your recovered database production ready.

Aktualizovat připojovací řetězceUpdate connection strings

Vzhledem k tomu, že se obnovená databáze nachází na jiném serveru, musíte aktualizovat připojovací řetězec aplikace tak, aby odkazoval na tento server.Because your recovered database resides in a different server, you need to update your application’s connection string to point to that server.

Další informace o změně připojovacích řetězců najdete v příslušném vývojovém jazyce pro knihovnu připojení.For more information about changing connection strings, see the appropriate development language for your connection library.

Konfigurace pravidel brány firewallConfigure Firewall Rules

Je nutné zajistit, aby pravidla brány firewall nakonfigurovaná na serveru a v databázi odpovídala nastavením nakonfigurovaným na primárním serveru a primární databázi.You need to make sure that the firewall rules configured on server and on the database match those that were configured on the primary server and primary database. Další informace najdete v tématu jak: Nakonfigurujte nastavení brány firewall (Azure SQL Database).For more information, see How to: Configure Firewall Settings (Azure SQL Database).

Konfigurace přihlašovacích údajů a uživatelů databázeConfigure logins and database users

Musíte zajistit, aby všechny přihlašovací údaje, které vaše aplikace používá, existovaly na serveru, který je hostitelem obnovené databáze.You need to make sure that all the logins used by your application exist on the server which is hosting your recovered database. Další informace najdete v tématu Konfigurace zabezpečení pro geografickou replikaci.For more information, see Security Configuration for geo-replication.

Poznámka

Během postupu zotavení po havárii byste měli nakonfigurovat a otestovat pravidla brány firewall serveru a přihlášení (a jejich oprávnění).You should configure and test your server firewall rules and logins (and their permissions) during a disaster recovery drill. Tyto objekty na úrovni serveru a jejich konfigurace nemusí být k dispozici během výpadku.These server-level objects and their configuration may not be available during the outage.

Nastavení výstrah telemetrieSetup telemetry alerts

Musíte zajistit, aby byla stávající nastavení pravidla upozornění aktualizována tak, aby se namapovala na obnovenou databázi a na jiný server.You need to make sure your existing alert rule settings are updated to map to the recovered database and the different server.

Další informace o pravidlech upozornění databáze najdete v tématu příjem oznámení o výstrahách a sledování Service Health.For more information about database alert rules, see Receive Alert Notifications and Track Service Health.

Povolit auditováníEnable auditing

Pokud je pro přístup k databázi vyžadováno auditování, je nutné povolit auditování po obnovení databáze.If auditing is required to access your database, you need to enable Auditing after the database recovery. Další informace najdete v tématu auditování databáze.For more information, see Database auditing.

Další krokyNext steps