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

Статья
2025-04-06

Применимо к: База данных SQL Azure базе данных SQL в Fabric

В этой статье представлен обзор возможностей непрерывности бизнес-процессов и аварийного восстановления База данных SQL Azure, описывающих параметры и рекомендации по восстановлению после разрушительных событий, которые могут привести к потере данных или привести к недоступности базы данных и приложения. Узнайте, что делать, когда ошибка пользователя или приложения влияет на целостность данных, происходит сбой в зоне доступности Azure или регионе, или приложение требует обслуживания.

Обзор

Непрерывность бизнес-процессов в База данных SQL Azure относится к механизмам, политикам и процедурам, которые позволяют бизнесу продолжать работать в условиях нарушения, обеспечивая доступность, высокий уровень доступности и аварийное восстановление.

В большинстве случаев База данных SQL обрабатывает разрушительные события, которые могут произойти в облачной среде и сохраняет выполнение приложений и бизнес-процессов. Однако существуют некоторые разрушительные события, когда устранение рисков может занять некоторое время, например:

Пользователь случайно удаляет или обновляет строку в таблице.
Злоумышленник успешно удаляет данные или удаляет базу данных.
Катастрофическое событие стихийных бедствий приведет к сбою центра обработки данных или зоны доступности или региона.
Редкий сбой центра обработки данных, зоны доступности или всего региона, вызванный изменением конфигурации, ошибкой программного обеспечения или сбоем оборудования.

Рекомендации по повышению доступности и повышению непрерывности бизнес-процессов см. в следующей статье:

Высокий уровень доступности

База данных SQL Azure поставляется с основным обещанием устойчивости и надежности, которое защищает его от сбоев программного обеспечения или оборудования. Резервные копии базы данных автоматизированы для защиты данных от повреждения или случайного удаления. Как услуга "Платформа как услуга" (PaaS), служба База данных SQL Azure обеспечивает доступность как стандартную функцию с соглашением об уровне обслуживания 99,99%.

Чтобы обеспечить высокий уровень доступности в облачной среде Azure, включите избыточность зоны. При зональной избыточности база данных или эластичный пул использует зоны доступности Azure, чтобы обеспечить устойчивость к сбоям в отдельных зонах.

Многие регионы Azure предоставляют зоны доступности, которые разделены группами центров обработки данных в пределах региона с независимым питанием, охлаждением и сетевой инфраструктурой.
Зоны доступности предназначены для обеспечения региональных служб, производственных мощностей и высокой доступности в оставшихся зонах в случае сбоя в одной из зон.

Благодаря обеспечению избыточности зоны база данных или эластичного пула устойчива к зональным сбоям оборудования и программного обеспечения, а восстановление прозрачно для приложений. Если включена высокая доступность, служба База данных SQL Azure может обеспечить более высокую доступность 99,995 %.

Аварийное восстановление

Чтобы обеспечить более высокую доступность и избыточность в разных регионах, можно включить возможности аварийного восстановления для быстрого восстановления базы данных из катастрофического регионального сбоя. Варианты аварийного восстановления с помощью База данных SQL Azure:

Активная георепликация позволяет создавать непрерывно синхронизированную вторичную базу данных, доступную для чтения, в любом регионе для основной базы данных.
Группы отработки отказа, помимо обеспечения непрерывной синхронизации между основной и вторичной базами данных, также позволяют управлять репликацией и отработкой отказа некоторых или всех баз данных на логическом сервере и перенаправлением их на вторичный логический сервер в другом регионе. Группы отработки отказа предоставляют конечные точки прослушивателя для чтения-записи и только для чтения, которые остаются неизменными, поэтому обновление строк подключения приложения после отработки отказа не требуется.
Геовосстановление позволяет восстановиться после регионального сбоя путем восстановления из геореплицированных резервных копий, когда вы не сможете получить доступ к базе данных в основном регионе, создав базу данных на любом существующем сервере в любом регионе Azure.

В следующей таблице сравниваются активная гео-репликация и группы автовосстановления, два варианта аварийного восстановления для Azure SQL Database.

	Активная георепликация	Группы аварийного переключения
Непрерывная синхронизация данных между первичной и вторичной	Да	Да
Одновременное переключение в случае отказа многих баз данных	Нет	Да
Строка подключения остается неизменной после переключения на резервный сервер	Нет	Да
Поддерживает масштабирование для чтения	Да	Да
Несколько реплик	Да	Нет
Может быть в том же регионе, что и основной	Да	Нет

RTO и RPO

При разработке плана непрерывности бизнес-процессов уточните максимально допустимое время до полного восстановления приложения после дестабилизирующего события. Ниже приведены два распространенных способа оценки бизнес-требований к аварийному восстановлению:

Цель времени восстановления (RTO) — время, необходимое для полного восстановления приложения после незапланированного нарушения.
Цель точки восстановления (RPO) — объём потерь данных во времени, который может быть приемлем в результате незапланированного аварийного события.

В следующей таблице сравнивается RPO и RTO каждого варианта непрерывности бизнес-процессов:

Вариант непрерывности бизнес-процессов	RTO (время простоя)	RPO (потеря данных)
Высокая доступность (использование зональной избыточности)	Обычно менее 30 секунд	0
Аварийное восстановление (использование групп отказоустойчивости с политикой отказоустойчивости, управляемой клиентом или активной георепликацией)	Обычно менее 60 секунд	Равно или больше 0 (зависит от изменения данных до нарушающего события, которые еще не были реплицированы).
Аварийное восстановление (с использованием геовосстановления)	Обычно это минуты или часы, зависящие от репликации службы хранилища Azure	Время обычно исчисляется в минутах или часах и зависит от размера резервной копии базы данных.

Функции, обеспечивающие непрерывность бизнес-процессов

С точки зрения базы данных существует четыре основных возможных сценария нарушения. В следующей таблице перечислены База данных SQL функции непрерывности бизнес-процессов, которые можно использовать для устранения потенциального сценария нарушения бизнес-процессов:

Сценарий нарушения бизнес-процессов	Функция обеспечения непрерывности бизнес-процессов
Локальные сбои оборудования или программного обеспечения, влияющие на узел базы данных.	Для устранения локальных сбоев оборудования и программного обеспечения база данных SQL Azure включает архитектуру доступности, которая гарантирует автоматическое восстановление от этих сбоев до 99,99% уровне обслуживания.
Повреждение или удаление данных, которое, как правило, возникает из-за ошибки приложения или пользователя. Такие сбои зависят от приложения и обычно не могут быть обнаружены службой базы данных.	Чтобы защитить бизнес от потери данных, База данных SQL автоматически создает полные резервные копии базы данных еженедельно, разностные резервные копии баз данных каждые 12 или 24 часа, а резервные копии журналов транзакций создаются каждые 5 – 10 минут. По умолчанию резервные копии хранятся в геоизбыточное хранилище в течение семи дней для всех уровней служб. Все уровни служб, кроме базовых, поддерживают настраиваемый период хранения резервных копий для восстановления на определенный момент времени (PITR) до 35 дней. Вы можете восстановить удаленную базу данных до точки, в которой она была удалена, если сервер не был удален, или если вы настроили долгосрочное хранение (LTR).
Редкий сбой центра обработки данных или зоны доступности, возможно, вызванный событием стихийных бедствий, изменением конфигурации, ошибкой программного обеспечения или сбоем оборудования.	Чтобы смягчить сбои на уровне центра обработки данных или зоны доступности, включите зональную избыточность для базы данных или эластичного пула для использования Azure Availability Zones и обеспечения избыточности в нескольких физических зонах в регионе Azure. Включение зональной избыточности обеспечивает устойчивость базы данных или эластичного пула к зональным сбоям с уровнем доступности до 99,995 %.
Редкий региональный сбой , влияющий на все зоны доступности и центры обработки данных, составляющие его, возможно, вызван катастрофическим событием стихийных бедствий.	Чтобы устранить сбой на уровне региона, включите аварийное восстановление с помощью одного из вариантов: — параметры непрерывной синхронизации данных, такие как группы отработки отказа (рекомендуется) или активная георепликация, позволяющие создавать реплики в дополнительном регионе в случае отказа. — настройка избыточности резервного хранилища на геоизбыточное хранилище для использования геовосстановления.

Подготовка к отключению в регионе

Независимо от того, какие функции обеспечения непрерывности бизнес-процессов вы используете, необходимо подготовить вторичную базу данных в другом регионе. Если вы не готовитесь должным образом, перевод приложений в режим онлайн после сбоя или восстановления занимает дополнительное время и, скорее всего, требует устранения неполадок, что может отложить достижение целевого времени восстановления (RTO). Следуйте контрольному списку для подготовки вторичных систем в случае сбоя в регионе.

Восстановление базы данных в одном регионе Azure

Для восстановления базы данных до точки во времени в прошлом можно использовать автоматическое резервное копирование базы данных. Таким образом можно выполнить восстановление после повреждения данных, вызванного ошибками человека. Восстановление на момент времени (PITR) позволяет создать новую базу данных на том же сервере, отражающую состояние данных до появления события, вызвавшего повреждение. Сведения о времени восстановления см. в разделе RTO и RPO.

Если максимальное поддерживаемое время хранения резервных копий для восстановления на определенный момент времени недостаточно для приложения, его можно расширить, настроив политику долгосрочного хранения (LTR). Дополнительные сведения см. в статье Storing Azure SQL Database Backups for up to 10 years (Хранение резервных копий баз данных SQL Azure до 10 лет).

Обновление приложения с минимальным простоем

Иногда приложение должно быть отключено из-за обслуживания, например обновления приложения. Вы можете управлять последовательными обновлениями облачных приложений с помощью активной георепликации базы данных SQL. Георепликация также может предоставить путь восстановления, если что-то пошло не так.

Экономия на затратах с помощью резервной реплики

Если вторичная реплика используется только для аварийного восстановления и не имеет рабочих нагрузок чтения или записи, вы можете сэкономить на затратах на лицензирование, назначив базу данных в режим ожидания при настройке нового активного отношения георепликации.

Ознакомьтесь с безлицензионной резервной репликой, чтобы узнать больше.

Следующий шаг

Контрольный список для высокого уровня доступности и аварийного восстановления