Сравнение параметров непрерывности бизнес-процессов и аварийного восстановления

  • 10 мин

База данных Azure для MySQL . Гибкий сервер предоставляет функции непрерывности бизнес-процессов для защиты базы данных в случае запланированных или незапланированных сбоев. Чтобы устранить различные типы сбоев, можно применить различные уровни защиты от сбоев с различным временем восстановления или риском потери данных.

Примеры простоя

Ниже приведены несколько примеров сценариев планирования и незапланированного простоя.

Запланированные сценарии простоя

Два наиболее распространенных запланированных сценария простоя — масштабирование вычислений, инициированное пользователем, и запланированное обслуживание, выполняемое Azure.

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

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

Незапланированный простой

База данных может неожиданно выйти из-за нескольких причин, например:

  • Сбой оборудования базы данных.
  • Сбой диска хранилища.
  • Ошибки приложения или пользователя (например, случайное удаление таблиц).
  • Сбои зоны доступности и региона.

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

Высокая доступность

База данных Azure для MySQL . Гибкий сервер предоставляет высокий уровень доступности с автоматическим отработкой отказа, который предоставляет решение, которое никогда не теряет зафиксированные данные и предотвращает создание базы данных в одной точке сбоя. При настройке высокого уровня доступности гибкий сервер MySQL автоматически подготавливает и управляет резервной репликой.

Существует два типа высокой доступности с различными компромиссами отказоустойчивости и задержки: избыточностью между зонами и одной и той же зоной.

Высокий уровень доступности, избыточный между зонами

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

Высокая доступность в пределах одной зоны

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

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

Резервное копирование и восстановление

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

Существует два типа резервных копий. При автоматическом резервном копировании гибкий сервер MySQL принимает моментальные снимки файлов данных базы данных, а также связанные журналы транзакций. Автоматическое резервное копирование моментальных снимков происходит один раз в день, а резервные копии журналов транзакций происходят каждые пять минут. Если резервное копирование завершается сбоем, сервер повторяется каждые 20 минут до тех пор, пока резервная копия не будет выполнена.

Резервное копирование по запросу позволяет создавать резервную копию базы данных в любое время. С обоими типами резервных копий файлы резервного копирования хранятся в течение семи дней по умолчанию. Однако в зависимости от бизнес-потребностей можно настроить значение срока хранения от одного до 35 дней.

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

Помимо резервного копирования базы данных, можно экспортировать файлы резервного копирования в хранилище BLOB-объектов Azure, которое затем можно использовать для миграции, восстановления данных или архивации. Экспорт по запросу в настоящее время доступен в общедоступной предварительной версии и доступен только в общедоступных облачных регионах.

Чтобы сохранить файлы резервной копии, можно выбрать несколько вариантов хранения:

  • При локально избыточном хранилище (том же центре обработки данных, той же зоне) файлы резервного копирования хранятся в том же центре обработки данных, что и база данных. Этот параметр обеспечивает одиннадцать 9s (99,999999999999%) устойчивости объектов резервного копирования в течение года. По умолчанию серверы без высокой доступности или с одной зоной высокого уровня доступности используют локально избыточное хранилище.

  • С хранилищем резервных копий с избыточностью между зонами (разными зонами, одним регионом) файлы резервного копирования хранятся в зоне доступности сервера и реплицируются в другую зону доступности в том же регионе. Этот вариант обеспечивает двенадцать 9-х (99,999999999999999%) устойчивости в течение заданного года. Хранилище, избыточное между зонами, важно для высокой доступности, избыточной между зонами, и требуется, если данные должны оставаться в одном регионе.

  • При использовании геоизбыточного хранилища резервных копий (разных регионов) файлы резервного копирования хранятся в регионе сервера, а затем реплицируются в другой геопарированный регион. Этот параметр обеспечивает шестнадцать 9s (99,99999999999999999999999999%) устойчивости в течение заданного года. Геоизбыточное хранилище поддерживается только в парных регионах Azure.

Примечание. Если База данных Azure для MySQL — гибкий сервер, место резервного копирования составляет до 100 % подготовленного хранилища, не взимается дополнительная плата. Плата за дополнительное хранилище взимается в ГБ в месяц. Дополнительные сведения см. в документации по ценам.

После резервного копирования можно восстановить резервную копию на новом гибком сервере MySQL. Можно выбрать три способа резервного копирования: вручную выбрать полную резервную копию, автоматически выбрать последнюю точку восстановления или автоматически выбрать самую быструю точку восстановления. При наличии геоизбыточного резервного копирования можно также восстановить в парном регионе (между регионами).

Запланированные периоды простоя и обслуживания

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

Вы можете выбрать управляемое системой расписание или определить пользовательское расписание для каждого гибкого сервера MySQL в подписке Azure.

Вы можете получать уведомления о запланированном обслуживании одним из нескольких способов. Уведомления могут быть:

  • Отправлено по электронной почте на определенный адрес или роль Azure Resource Manager.
  • Отправлено с помощью текстового сообщения (SMS).
  • Отправлено как уведомление о приложении Azure.
  • Доставлено через голосовое сообщение.

Пользовательские периоды обслуживания

По умолчанию с расписанием, управляемым системой, система выбирает одночасовое окно между 11 вечера и 7 утра в часовом поясе гибкого сервера MySQL. С помощью настраиваемого расписания можно указать период обслуживания сервера, выбрав день недели и одночасовое время.

Почти нулевое время простоя для серверов высокой доступности (общедоступная предварительная версия)

Серверы с поддержкой высокой доступности получают преимущества от обслуживания почти нулевого простоя, что значительно сокращает время простоя обслуживания. Ожидаемое время простоя составляет от 40 до 60 секунд. Техническое обслуживание почти нулевого времени простоя имеет решающее значение для приложений с очень высокими требованиями к доступности, требуя минимального прерывания подключения к базе данных.

Повторное обслуживание (общедоступная предварительная версия)

Вы можете перепланировать обслуживание при использовании уровней служб общего назначения или критически важный для бизнеса. В разделе обслуживания портал Azure можно перепланировать следующее запланированное обслуживание на другую дату и время. Вы также можете инициировать обслуживание по запросу, выбрав "Перепланировать" на "Сейчас".