Общие сведения об обеспечении непрерывности бизнес-процессов с помощью Базы данных Azure для MySQL — гибкий сервер

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

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

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

Функция Description Ограничения
Резервное копирование и восстановление Служба автоматически выполняет ежедневные резервные копии файлов базы данных и постоянно создает резервные копии журналов транзакций. Резервные копии могут храниться в течение любого времени в диапазоне от 1 до 35 дней. Сервер базы данных можно восстановить в любой момент времени в течение периода хранения резервных копий. Время восстановления зависит от размера данных для восстановления и времени выполнения восстановления журнала. Дополнительные сведения см. в разделе Основные понятия — резервное копирование и восстановление. Данные резервного копирования остаются в пределах региона.
Локально избыточное резервное копирование Резервные копии служб автоматически и безопасно хранятся в локальном избыточном хранилище в пределах региона и в той же зоне доступности. Локально избыточные резервные копии реплицируют файлы данных резервных копий сервера три раза в пределах одного физического расположения в основном регионе. Локально избыточное хранилище резервных копий обеспечивает устойчивость объектов на уровне как минимум 99,999999999 % (11 девяток) в течение заданного года. Дополнительные сведения см. в разделе Основные понятия — резервное копирование и восстановление. Применимо ко всем регионам
Геоизбыточное резервное копирование Резервные копии служб можно настроить как геоизбыточные во время создания. При включении геоизбыточности реплицируются файлы данных резервных копий сервера в парном регионе основного региона, чтобы обеспечить устойчивость регионов. Геоизбыточное хранилище резервных копий обеспечивает устойчивость объектов на уровне как минимум 99,99999999999999 % (16 девяток) в течение заданного года. Дополнительные сведения см. в разделе Основные понятия — резервное копирование и восстановление. Доступно во всех Парных регионах Azure
Высокий уровень доступности с избыточностью в пределах зоны Служба может быть развернута в режиме высокой доступности, который развертывает первичные и резервные серверы в двух разных зонах доступности в пределах региона. Высокий уровень доступности избыточности зоны защищает от сбоев уровня зоны, а также помогает сократить время простоя приложения во время запланированных и незапланированных событий простоя. Данные с главного сервера реплицируются на резервную реплику в синхронном режиме. Во время любого события простоя сервер базы данных автоматически выполняет отработку отказа на резервную реплику. Дополнительные сведения см. в разделе Основные понятия — высокий уровень доступности. Поддерживается на уровнях вычислительных ресурсов "Общего назначения" и "Критически важный для бизнеса". Доступно только в регионах, где доступно несколько зон.
Общие папки ценовой категории "Премиум" Файлы базы данных хранятся в общих папках Azure ценовой категории "Премиум", обладающих высокой устойчивостью и надежностью. Общие папки ценовой категории "Премиум" обеспечивают избыточность данных с помощью трех копий реплики, хранящихся в зоне доступности, с возможностью автоматического восстановления данных. Дополнительные сведения см. в разделе Общие папки ценовой категории "Премиум". Данные хранятся в зоне доступности.

Уменьшение продолжительности запланированных простоев

Ниже перечислен ряд сценариев проведения планового обслуживания, включающих время простоя:

Сценарий Обработать
Масштабирование вычислительных ресурсов (пользователь) При выполнении операции масштабирования вычислительных ресурсов выполняется подготовка нового гибкого сервера с использованием масштабируемой конфигурации вычислительных ресурсов. На имеющемся сервере базы данных ожидается завершение работы активных контрольных точек, останавливаются клиентские подключения, все незафиксированные транзакции отменяются, и затем сервер завершает работу. Затем хранилище присоединяется к новому серверу и запускается база данных, которая выполняет восстановление при необходимости перед принятием клиентских подключений.
Развертывание нового программного обеспечения (Azure) Внедрение новых функций и исправление ошибок происходит автоматически в рамках планового обслуживания службы, и вы можете запланировать, когда эти действия должны произойти. Дополнительные сведения см. в документации, а также на портале.
Обновление дополнительных версий (Azure) База данных Azure для MySQL гибкий сервер автоматически исправляет серверы баз данных до дополнительной версии, определенной Azure. Это происходит в рамках планового обслуживания службы. Такое обновление вызывает краткосрочный простой, порядка нескольких секунд, после чего автоматически перезапускается сервер базы данных (уже с новой промежуточной версией). Дополнительные сведения см. в документации, а также на портале.

Если для гибкого сервера настроен высокий уровень доступности с избыточностью зоны, гибкий сервер сначала выполняет операции на резервном сервере, а затем на главном сервере без отработки отказа. Дополнительные сведения см. в разделе Основные понятия — высокий уровень доступности.

Уменьшение продолжительности незапланированного простоя

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

Незапланированный простой: сценарии сбоев и восстановление службы

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

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

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

Другие доступные параметры восстанавливаются из резервной копии. Вы можете использовать восстановление до точки во времени или географическое восстановление из парного региона.
PITR : RTO: Зависит, RPO=0sec
Географическое восстановление: RTO: значения варьируются, RPO <1 ч.

Вы также можете использовать Реплику чтения в качестве решения аварийного восстановления. Вы можете остановить реплика, что делает чтение реплика чтение и запись (автономная запись, а затем перенаправлять трафик приложения в эту базу данных). В большинстве случаев RTO составляет несколько минут и RPO < 1 ч. RTO и RPO могут быть гораздо выше в некоторых случаях в зависимости от различных факторов, включая задержку между сайтами, объем передаваемых данных и важно рабочую нагрузку записи базы данных-источника.
Если обнаружен сбой сервера базы данных или неисправные ошибки, активируется резервный сервер базы данных, что снижает время простоя. Дополнительные сведения см. на странице концепций высокого уровня доступности. Значение RTO должно находиться в интервале 60–120 с, а значение RPO должно быть равно 0.

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

В редком или наихудшем сценарии, если все копии повреждены, можно использовать восстановление из геовосстановления (парный регион). Значение RPO будет <1 ч, а RTO будет иметь разные значения.

Также можно использовать реплику чтения в качестве решения аварийного восстановления, как описано выше.
В этом сценарии параметры совпадают с параметрами для процесса восстановления [non-HA].
Логические ошибки/ошибки пользователя Для восстановления после ошибок пользователя, таких как случайное удаление таблиц или неправильное обновление данных, требуется выполнить восстановление на определенный момент времени (PITR). При этом данные восстанавливаются до состояния на момент времени, предшествующий допущенной ошибке.

Вы можете восстановить удаленный гибкий ресурс сервера в течение пяти дней с момента удаления сервера. Чтобы получить подробное руководство по восстановлению удаленного сервера, [см. инструкции в документации] (../flexible-server/how-to-restore-dropped-server.md). Чтобы защитить ресурсы сервера после развертывания от случайного удаления или непредвиденных изменений, администраторы могут использовать блокировки управления.
Высокий уровень доступности не обеспечивает защиту от этих ошибок пользователя, поскольку все операции пользователя также реплицируются в резервное расположение. В этом сценарии параметры совпадают с параметрами для процесса восстановления [non-HA]
Сбой зоны доступности В редких случаях, если требуется выполнить восстановление после сбоя на уровне зоны DNS, можно выполнять географическое восстановление из парного региона. Значение RPO будет <1 ч, а значения RTO будут варьироваться.

Вы также можете использовать Реплику чтения в качестве решения аварийного восстановления, создав реплику в другой зоне доступности. RTO\RPO — как описано выше.
Если включена избыточность зоны высокой доступности, гибкий сервер выполняет автоматическую отработку отказа на резервный сайт. Дополнительные сведения см. в Концепциях высокой доступности. Значение RTO должно находиться в интервале 60–120 с, а значение RPO должно быть равно 0.

Другие доступные параметры восстанавливаются из резервной копии. Вы можете использовать восстановление до точки во времени или географическое восстановление из парного региона.
PITR : RTO: Зависит, RPO=0 с
Геовосстановление: RTO: зависит, RPO <1 ч

Примечание.Если у вас включена одна зона высокого уровня доступности, параметры совпадают с параметрами процесса восстановления [не высокой доступности].
Сбой региона В редких случаях, если вы хотите выполнить восстановление после сбоя на уровне региона, можно восстановить базу данных, создав новый сервер, используя последнюю геоизбыточную резервную копию, доступную в той же подписке, чтобы получить актуальные данные. Новый гибкий сервер развертывается в выбранном регионе. Время, необходимое для восстановления, зависит от предыдущей резервной копии и числа восстанавливаемых журналов транзакций. В большинстве случаев RPO будет <1 ч, а значения RTO будут варьироваться. В этом сценарии параметры совпадают с параметрами для процесса восстановления [non-HA].

Требования и ограничения

Расположение данных региона

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

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