Обзор обеспечения непрерывности бизнес-процессов с помощью Базы данных SQL AzureOverview of business continuity with Azure SQL Database

Непрерывность бизнес-процессов в Базе данных SQL Azure относится к механизмам, политикам и процедурам, которые позволяют вашим бизнес-процессам продолжать работу при возникновении сбоев, особенно в вычислительной инфраструктуре.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. В большинстве случаев База данных SQL Azure будет обрабатывать аварийные события, которые могут произойти в облачной среде, и поддерживать выполнение приложений и бизнес-процессов.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. Однако существуют некоторые события, которые не могут быть автоматически обработаны базой данных SQL, например:However, there are some disruptive events that cannot be handled by SQL Database automatically such as:

  • Пользователь случайно удалил или обновил строку в таблице.User accidentally deleted or updated a row in a table.
  • Злоумышленник удалил данные или базу данных.Malicious attacker succeeded to delete data or drop a database.
  • Землетрясение привело к отключению электроэнергии и временному отключению центра обработки данных.Earthquake caused a power outage and temporary disabled data-center.

В этом обзоре описываются возможности Базы данных SQL Azure по обеспечению непрерывности бизнес-процессов и аварийного восстановления.This overview describes the capabilities that Azure SQL Database provides for business continuity and disaster recovery. Вы узнаете о параметрах, рекомендациях и руководствах по восстановлению после аварийных событий, которые могут приводить к потере данных или недоступности базы данных и приложений.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. Здесь также содержатся сведения о том, как действовать в ситуациях, когда ошибка пользователя или приложения нарушает целостность данных, происходит сбой региона Azure или приложение требует обслуживания.Learn what to do when a user or application error affects data integrity, an Azure region has an outage, or your application requires maintenance.

Функции базы данных SQL, которые можно использовать для обеспечения непрерывности бизнес-процессовSQL Database features that you can use to provide business continuity

С точки зрения базы данных существуют четыре основных сценария возможных нарушений:From a database perspective, there are four major potential disruption scenarios:

  • Локальные сбои оборудования или программного обеспечения, затрагивающие узел базы данных, например сбой диска.Local hardware or software failures affecting the database node such as a disk-drive failure.
  • Повреждение или удаление данных, которое, как правило, возникает из-за ошибки приложения или пользователя.Data corruption or deletion typically caused by an application bug or human error. Такие сбои зависят от приложения и обычно не могут быть обнаружены службой базы данных.Such failures are application-specific and typically cannot be detected by the database service.
  • Отключение центра обработки данных, возможно, вызванное стихийным бедствием.Datacenter outage, possibly caused by a natural disaster. Этот сценарий требует определенного уровня геоизбыточности с отработкой отказа приложений в альтернативном центре обработки данных.This scenario requires some level of geo-redundancy with application failover to an alternate datacenter.
  • Ошибки обновления или обслуживания. непредвиденные проблемы, возникающие во время запланированного обслуживания или обновления инфраструктуры, могут потребовать быстрого отката до состояния предыдущей базы данных.Upgrade or maintenance errors, unanticipated issues that occur during planned infrastructure maintenance or upgrades may require rapid rollback to a prior database state.

Чтобы устранить неполадки с локальным оборудованием и программным обеспечением, база данных SQL включает в себя архитектуру высокого уровня доступности, которая гарантирует автоматическое восстановление из этих сбоев до 99,995% соглашения об уровне обслуживания.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.

Чтобы защитить бизнес от потери данных, база данных SQL автоматически создает полные резервные копии баз данных еженедельно, разностные резервные копии каждые 12 часов, а резервные копии журналов транзакций — каждые 5-10 минут.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 . Резервные копии хранятся в хранилище RA-GRS по крайней мере за 7 дней для всех уровней служб.The backups are stored in RA-GRS storage for at least 7 days for all service tiers. Все уровни служб, за исключением поддержка Basic настраиваемого срока хранения резервных копий для восстановления до точки во времени, до 35 дней.All service tiers except Basic support configurable backup retention period for point-in-time restore, up to 35 days.

База данных SQL также предоставляет несколько функций обеспечения непрерывности бизнес-процессов, которые можно использовать для устранения различных незапланированных сценариев.SQL Database also provides several business continuity features, that you can use to mitigate various unplanned scenarios.

Восстановление базы данных в том же регионе AzureRecover a database within the same Azure region

Можно использовать автоматическое резервное копирование базы данных для восстановления базы данных до точки во времени в прошлом.You can use automatic database backups to restore a database to a point in time in the past. Таким образом можно выполнить восстановление после повреждения данных, вызванных ошибками человека.This way you can recover from data corruptions caused by human errors. Восстановление на момент времени позволяет создать новую базу данных на том же сервере, который представляет состояние данных до повреждения события.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. Для большинства баз данных операции восстановления выполняются менее 12 часов.For most databases the restore operations takes less than 12 hours. Восстановление очень большой или очень активной базы данных может занять больше времени.It may take longer to recover a very large or very active database. Дополнительные сведения см. в разделе Время восстановления.For more information about recovery time, see database recovery time.

Если максимальный поддерживаемый период хранения резервных копий для восстановления на момент времени (PITR) недостаточно для вашего приложения, его можно расширить, настроив политику долгосрочного хранения (LTR) для баз данных.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). Дополнительные сведения см. в разделе Долгосрочное хранение резервных копий.For more information, see Long-term backup retention.

Сравнение георепликации с группами отработки отказаCompare geo-replication with failover groups

Группы автоматической отработки отказа упрощают развертывание и использование георепликации и добавляют дополнительные возможности, как описано в следующей таблице.Auto-failover groups simplify the deployment and usage of geo-replication and add the additional capabilities as described in the following table:

ГеорепликацияGeo-replication Группы отработки отказаFailover groups
Автоматический переход на другой ресурсAutomatic failover НетNo ДаYes
Одновременное отработка отказа нескольких баз данныхFail over multiple databases simultaneously НетNo ДаYes
Обновление строки подключения после отработки отказаUpdate connection string after failover ДаYes НетNo
Поддерживаемый управляемый экземплярManaged instance supported НетNo ДаYes
Может находиться в том же регионе, что и первичныйCan be in same region as primary ДаYes НетNo
Несколько репликMultiple replicas ДаYes НетNo
Поддерживает чтение и масштабированиеSupports read-scale ДаYes ДаYes
     

Восстановление базы данных на имеющемся сервереRecover a database to the existing server

В редких случаях возможен сбой центра обработки данных Azure.Although rare, an Azure data center can have an outage. Такой сбой вызывает нарушение работы компании, которое может длиться от считанных минут до нескольких часов.When an outage occurs, it causes a business disruption that might only last a few minutes or might last for hours.

  • Один из вариантов — дождаться возобновления работы базы данных после того, как сбой центра обработки данных будет устранен.One option is to wait for your database to come back online when the data center outage is over. Это подходит для приложений, которые допускают отключение базы данных от сети.This works for applications that can afford to have the database offline. Например, вам не нужно непрерывно работать с проектом по разработке или бесплатной пробной версией.For example, a development project or free trial you don't need to work on constantly. После того как произошел сбой центра обработки данных, неизвестно, как долго будет длиться простой. Поэтому этот вариант используется, только если база данных некоторое время не нужна.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.
  • Другим вариантом является восстановление базы данных на любом сервере в любом регионе Azure с использованием резервных копий геоизбыточных баз данных (геовосстановление).Another option is to restore a database on any server in any Azure region using geo-redundant database backups (geo-restore). В качестве источника геовосстановление использует геоизбыточную резервную копию для восстановления базы данных, даже если она или центр обработки данных недоступны из-за сбоя.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.
  • Наконец, вы можете быстро восстановиться после сбоя, если вы настроили геовторичную репликацию с помощью активной георепликации или группы автоматической отработки отказа для базы данных или баз.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. В зависимости от выбора технологии можно использовать переход на другой ресурс автоматически или вручную.Depending on your choice of these technologies, you can use either manual or automatic failover. Хотя отработка отказа занимает всего несколько секунд, службе понадобится как минимум 1 час, чтобы активировать ее.While failover itself takes only a few seconds, the service will take at least 1 hour to activate it. Нужно удостовериться, что отработка отказа соответствует масштабу сбоя.This is necessary to ensure that the failover is justified by the scale of the outage. Кроме того, при отработке отказа возможна небольшая потеря данных из-за характера асинхронной репликации.Also, the failover may result in small data loss due to the nature of asynchronous replication.

При разработке плана обеспечения непрерывности бизнес-процессов нужно понимать, какое максимальное время до полного восстановления приложения после аварийного события допустимо.As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after the disruptive event. Время, необходимое для полного восстановления приложения, называется целевым временем восстановления (RTO).The time required for application to fully recover is known as Recovery time objective (RTO). Кроме того, необходимо определить максимальный период последних обновлений данных (интервал времени), который приложение может потерять при восстановлении после незапланированного аварийного события.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. Возможная потеря данных известна как Целевая точка восстановления (RPO).The potential data loss is known as Recovery point objective (RPO).

Различные методы восстановления предлагают разные уровни RPO и RTO.Different recovery methods offer different levels of RPO and RTO. Можно выбрать конкретный метод восстановления или использовать сочетание методов для полного восстановления приложения.You can choose a specific recovery method, or use a combination of methods to achieve full application recovery. В следующей таблице сравниваются RPO и RTO каждого варианта восстановления.The following table compares RPO and RTO of each recovery option. Группы автоматической отработки отказа упрощают развертывание и использование георепликации и добавляет дополнительные возможности, описанные в следующей таблице.Auto-failover groups simplify the deployment and usage of geo-replication and adds the additional capabilities as described in the following table.

Метод восстановленияRecovery method RTORTO RPORPO
Геовосстановление из геореплицированных резервных копийGeo-restore from geo-replicated backups 12 ч12 h 1 ч1 h
Группы автоматической отработки отказаAuto-failover groups 1 ч1 h 5 с5 s
Отработка отказа базы данных вручнуюManual database failover 30 с30 s 5 с5 s

Примечание

Ручная отработка отказа базы данных означает отработку отказа отдельной базы данных до геореплицированной вторичной реплики с использованием незапланированного режима.Manual database failover refers to failover of a single database to its geo-replicated secondary using the unplanned mode. Для дополнительной информации об автоматической отработке отказа RTO и RPO см. таблицу, приведенную выше.See the table earlier in this article for details of the auto-failover RTO and RPO.

Используйте группы автоматической отработки отказа, если приложение соответствует любому из следующих критериев:Use auto-failover groups if your application meets any of these criteria:

  • оно является критически важным;Is mission critical.
  • его условия Соглашения об уровне обслуживания (SLA) не допускают более 12 часов простоя;Has a service level agreement (SLA) that does not allow for 12 hours or more of downtime.
  • его простой может повлечь финансовую ответственность;Downtime may result in financial liability.
  • имеет высокую частоту изменения данных, и потеря данных за час не допускается;Has a high rate of data change and 1 hour of data loss is not acceptable.
  • дополнительные затраты на активную георепликацию ниже, чем потенциальная финансовая ответственность и связанная с ней утрата деловых возможностей.The additional cost of active geo-replication is lower than the potential financial liability and associated loss of business.

В зависимости от требований приложения вы можете использовать сочетание резервных копий базы данных и активной георепликации.You may choose to use a combination of database backups and active geo-replication depending upon your application requirements. Обсуждение вопросов проектирования автономных баз данных и эластичных пулов с использованием этих функций обеспечения непрерывности бизнеса см. в статье Разработка приложения для аварийного восстановления облака и стратегий аварийного восстановления эластичного пула.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.

В следующих разделах описываются инструкции по восстановлению с использованием резервных копий базы данных или активной георепликации.The following sections provide an overview of the steps to recover using either database backups or active geo-replication. Подробные инструкции, включающие в себя планирование требований, действия после восстановления и сведения о том, как имитировать сбой для отработки аварийного восстановления, см. в статье Восстановление базы данных SQL Azure или переход на базу данных-получатель при отказе.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.

Подготовка к сбоюPrepare for an outage

Независимо от выбранной функции обеспечения непрерывности бизнес-процессов необходимо выполнить следующее.Regardless of the business continuity feature you use, you must:

  • Определите и подготовьте целевой сервер, включая правила брандмауэра для IP-адресов, имена для входа и разрешения уровня базы данных master.Identify and prepare the target server, including server-level IP firewall rules, logins, and master database level permissions.
  • Определите, как клиенты и клиентские приложения будут перенаправляться на новый сервер.Determine how to redirect clients and client applications to the new server
  • Задокументируйте прочие зависимости, такие как параметры аудита и оповещения.Document other dependencies, such as auditing settings and alerts

Без соответствующей подготовки возобновление работы приложений после отработки отказа или восстановления базы данных занимает больше времени и, вероятно, также требует устранения неполадок во время стрессовой нагрузки, а это весьма неудачное сочетание.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.

Отработка отказа в геореплицируемую базу данных-получательFail over to a geo-replicated secondary database

Если в качестве механизма восстановления используется активная Георепликация или группы автоматической отработки отказа, можно настроить политику автоматической отработки отказа или использовать незапланированную отработку отказа вручную.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. После запуска отработка отказа приводит к повышению базы данных-получателя до новой базы данных-источника и делает ее доступной для записи новых транзакций и реагирования на запросы. При этом происходят минимальные потери данных, которые еще не реплицированы.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. Сведения о разработке процесса отработки отказа см. в статье Проектирование приложения для облачного аварийного восстановления с использованием активной георепликации в базе данных SQL.For information on designing the failover process, see Design an application for cloud disaster recovery.

Примечание

После возобновления работы центра обработки данных старые базы данных-источники автоматически переподключаются к новым базам данных-источникам и становятся базами данных-получателями.When the data center comes back online the old primaries automatically reconnect to the new primary and become secondary databases. Если базу данных-источник необходимо повторно переместить в исходный регион, вы можете вручную запустить плановую отработку отказа (восстановление размещения).If you need to relocate the primary back to the original region, you can initiate a planned failover manually (failback).

Процедура геовосстановленияPerform a geo-restore

При использовании автоматически создаваемых резервных копий и геоизбыточного хранилища (включено по умолчанию) базу данных можно восстановить с помощью функции геовосстановление.If you are using the automated backups with geo-redundant storage (enabled by default), you can recover the database using geo-restore. Обычно восстановление выполняется в пределах 12 часов с потерей данных за период до одного часа, что зависит от времени создания и репликации последней резервной копии журналов.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. До завершения восстановления база данных не может записывать какие-либо транзакции или отвечать на запросы.Until the recovery completes, the database is unable to record any transactions or respond to any queries. Обратите внимание, что функция геовосстановления восстанавливает базу данных до последней доступной точки во времени.Note, geo-restore only restores the database to the last available point in time.

Примечание

Если работа центра обработки данных возобновится до переключения приложения на восстановленную базу данных, то можно будет отменить восстановление.If the data center comes back online before you switch your application over to the recovered database, you can cancel the recovery.

Выполнение задач после восстановления размещения и восстановленияPerform post failover / recovery tasks

После восстановления посредством любого из механизмов восстановления необходимо выполнить следующие дополнительные задачи, прежде чем данные пользователей и приложений будут заархивированы, а они смогут возобновить работу.After recovery from either recovery mechanism, you must perform the following additional tasks before your users and applications are back up and running:

  • Перенаправьте клиенты и клиентские приложения на новый сервер и восстановленную базу данных.Redirect clients and client applications to the new server and restored database
  • Убедитесь, что заданы соответствующие правила брандмауэра для IP-адресов уровня сервера, позволяющие пользователям подключаться к брандмауэрам уровня базы данных или использовать их, чтобы включить соответствующие правила.Ensure appropriate server-level IP firewall rules are in place for users to connect or use database-level firewalls to enable appropriate rules.
  • Убедитесь, что заданы соответствующие имена для входа и разрешения уровня базы данных master (или используйте автономных пользователей).Ensure appropriate logins and master database level permissions are in place (or use contained users)
  • Настройте аудит соответствующим образом.Configure auditing, as appropriate
  • Настройте оповещения соответствующим образом.Configure alerts, as appropriate

Примечание

Если вы используете группу отработки отказа и подключаетесь к базе данных, используя прослушиватель для чтения и записи, после отработки отказа произойдет автоматическое и прозрачное перенаправление в приложение.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 an application with minimal downtime

Иногда приложение нужно перевести в автономный режим для планового обслуживания, например, чтобы обновить его.Sometimes an application must be taken offline because of planned maintenance such as an application upgrade. В статье Управление последовательными обновлениями для облачных приложений с помощью активной георепликации базы данных SQL описывается, как с помощью активной георепликации обеспечить последовательное обновление облачного приложения, чтобы свести к минимуму простой при обновлениях и обеспечить путь восстановления, если случится сбой.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.

Дальнейшие действияNext steps

Вопросы разработки приложений для автономных баз данных и эластичных пулов рассматриваются в статьях Разработка глобально доступных служб с помощью Базы данных SQL Azure и Стратегии аварийного восстановления для приложений с использованием пула эластичных баз данных SQL.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.