Общие сведения об обеспечении непрерывности бизнес-процессов с помощью службы "База данных Azure для MySQL" (отдельный сервер)

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для MySQL — отдельный сервер

Важно!

База данных Azure для MySQL один сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для MySQL гибкого сервера. Дополнительные сведения о миграции на гибкий сервер База данных Azure для MySQL см. в статье "Что происходит с одним сервером База данных Azure для MySQL?"

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

Функции, которые можно использовать для обеспечения непрерывности бизнес-процессов

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

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

Примечание.

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

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

В таблице ниже сравниваются значения RTO и RPO в типичном сценарии рабочей нагрузки.

Возможность Базовая Общего назначения Оптимизированные для памяти
Восстановление до точки во времени из резервной копии Любая точка восстановления в течение периода хранения
RTO — зависит
RPO < 15 мин		 Любая точка восстановления в течение периода хранения
RTO — зависит
RPO < 15 мин		 Любая точка восстановления в течение периода хранения
RTO — зависит
RPO < 15 мин
Геовосстановление из геореплицированных резервных копий Не поддерживается RTO — зависит
RPO < 1 ч		 RTO — зависит
RPO < 1 ч
Реплики чтения RTO — минуты*
RPO < 5 мин*		 RTO — минуты*
RPO < 5 мин*		 RTO — минуты*
RPO < 5 мин*

* В некоторых случаях значения RTO и RPO могут быть намного выше. Это зависит от различных факторов: задержки между расположениями, объема передаваемых данных и, что важнее всего, рабочей нагрузки записи базы данных-источника.

Восстановление сервера после ошибки пользователя или приложения

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

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

Важно!

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

Восстановление после отключения регионального центра обработки данных Azure

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

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

Геовосстановление

Возможность геовосстановления восстанавливает сервер с помощью геоизбыточных резервных копий. Резервные копии размещаются в парном регионе сервера. Эти резервные копии доступны даже в том случае, если регион размещения сервера отключен. Из этих копий можно выполнить восстановление в любом другом регионе и восстановить подключение сервера. Дополнительные сведения о геовосстановлении см. в статье об основных понятиях резервного копирования и восстановления.

Важно!

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

Реплики чтения в других регионах

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

Вопросы и ответы

Где База данных Azure для MySQL хранит данные клиентов?

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

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