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

  • Статья

Важно!

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

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

Функции обеспечения непрерывности бизнес-процессов

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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