Надежность в База данных Azure для MySQL

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

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

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

Рекомендации по развертыванию в производственной среде

Платформа Azure Well-Architected Framework предоставляет рекомендации по надежности, безопасности, затратам, операциям и производительности. Чтобы понять, как эти области влияют друг на друга и способствуют надежному решению База данных Azure для MySQL, ознакомьтесь с рекомендациями по архитектуре для База данных Azure для MySQL.

Обзор архитектуры надежности

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

Логическая архитектура

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

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

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

Физическая архитектура

• Разделение вычислительных ресурсов и хранилищ: База данных Azure для MySQL использует архитектуру разделения вычислительных ресурсов и хранилища для поддержки высокой доступности. Ядро СУБД выполняется на виртуальной машине. Файлы данных хранятся в служба хранилища Azure, которые синхронно поддерживают три копии данных для защиты от сбоев оборудования хранилища. В зависимости от конфигурации высокой доступности (HA) сервера файлы данных могут храниться в хранилище с зональной избыточностью (ZRS) или в локально избыточном хранилище (LRS).

• ХА: При необходимости можно включить конфигурацию высокого уровня доступности на сервере. При включении конфигурации высокой доступности служба создаёт и поддерживает резервный сервер-реплику в режиме тёплого ожидания. Изменения данных на основном сервере синхронно реплицируются на резервный сервер реплики, чтобы обеспечить нулевой потери данных во время сбоя основного сервера.

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

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

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

  Дополнительные сведения см. в статье Высокая доступность в База данных Azure для MySQL.

• Backups: База данных Azure для MySQL автоматически создает резервные копии серверов. Дополнительные сведения см. в разделе "Резервное копирование и восстановление".

Устойчивость к временным сбоям

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

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

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

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

• По возможности используйте клиентские библиотеки , которые автоматически обрабатывают повторные попытки.

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

Устойчивость к сбоям зоны доступности

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

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

Служба хранит данные в хранилище Файлы Azure класса Premium. В зависимости от конфигурации высокой доступности сервера используется либо ZRS, либо LRS, при этом хранятся три копии данных в пределах одной зоны доступности или в разных зонах доступности.

База данных Azure для MySQL поддерживает два типа конфигурации зоны доступности при использовании высокого уровня доступности:

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

  Вы выбираете зоны доступности для основных и резервных серверов.

  Используйте развертывания с избыточностью между зонами для серверов рабочей среды.

  

  Схема состоит из трех разделов. В первом разделе перечислены клиентские приложения, такие как Azure виртуальные машины, Azure Kubernetes Service (AKS) и Служба приложений Azure. Следующий раздел помечен как зона доступности 1. Он содержит основной сервер и два подраздела, вычислительные ресурсы и хранилище, разделенные пунктирной линией. Третий раздел — это зона доступности 2. Она зеркально отражает зону доступности 1, но содержит резервный сервер. Стрелки указывают от клиентских приложений к стандартному балансировщику нагрузки. Одна стрелка ведёт от балансировщика нагрузки к виртуальной машине на основном сервере в зоне доступности 1. Двунаправленные стрелки соединяют виртуальную машину с файловым ресурсом уровня Premium и твердотельным накопителем (SSD). Еще одна стрелка указывает от файлового ресурса уровня "Премиум" к резервному хранилищу BLOB-объектов. Стрелка с подписью «асинхронная репликация на основе хранилища» направлена из зоны доступности 1 в зону доступности 2.

  Операции записи могут столкнуться с небольшим увеличением задержки фиксации, так как служба синхронно реплицирует данные на резервный сервер. В среднем можно ожидать увеличения задержки на 5–10 % при операциях записи и фиксации приложения. Влияние зависит от рабочей нагрузки, выбранного номера SKU и региона.

• Высокая доступность с локальным резервированием: Основной и резервный серверы находятся в одной зоне доступности. Если сбой возникает на главном сервере, но зона по-прежнему работоспособна, сервер автоматически переходит в режим резервного на резервный сервер.

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

  

  Схема состоит из трех разделов. В первом разделе перечислены клиентские приложения, такие как Azure виртуальные машины, AKS и служба приложений. Следующий раздел помечен как зона доступности 1. Он содержит два отдельных раздела для основного сервера и резервного сервера. Пунктирная строка делит раздел каждого сервера на два подраздела, вычислительные ресурсы и хранилище. Стрелки указывают от клиентских приложений на стандартный балансировщик нагрузки. Одна стрелка ведёт от балансировщика нагрузки к виртуальной машине на основном сервере в зоне доступности 1. Двунаправленные стрелки соединяют виртуальную машину, файловый ресурс Premium и твердотельный накопитель (SSD). Еще одна стрелка указывает от файлового ресурса уровня "Премиум" к резервному BLOB-хранилищу. Стрелка с надписью «асинхронная репликация на основе хранилища» указывает от основного сервера к резервному серверу. Третий раздел, помеченный зоной доступности 2, пуст.

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

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

  • При развертывании в регионе, который не поддерживает зоны доступности. В этом сценарии регион функционирует как единая зона, поэтому локально-избыточная высокая доступность является единственным вариантом высокой доступности.

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

Если вы настраиваете сервер без HA, то он работает на одном сервере. Если этот сервер или его зона выйдет из строя, ваш сервер будет недоступен.

Требования

• Поддержка регионов: База данных Azure для MySQL поддерживает разные конфигурации зоны доступности в зависимости от региона Azure. Полный список регионов, включая типы поддержки зон доступности и особенности для каждого региона, см. в Регионы Azure.

• Уровень обслуживания: Для HA требуются уровни «Общего назначения» или «Оптимизированные для памяти». Уровень Burstable не поддерживает высокую доступность (с избыточностью между зонами или локальной избыточностью).

Cost

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

Рекомендации

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

• Ограничения и известные проблемы: Просмотрите список ограничений и известных проблем.

Настройка поддержки зоны доступности

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

Замечание

При выборе используемых зон доступности вы фактически выбираете логическую зону доступности. При развертывании других компонентов рабочей нагрузки в другой подписке Azure они могут использовать другой номер логической зоны доступности для доступа к той же физической зоне доступности. Дополнительные сведения см. в разделе "Физические и логические зоны доступности".

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

  • Портал Azure: Управление отказоустойчивостью с резервированием между зонами в База данных Azure для MySQL с помощью портала Azure.

  • Azure CLI: Управление высокой доступностью с избыточностью между зонами в База данных Azure для MySQL с помощью Azure CLI.

• Создайте локальный избыточный сервер. Чтобы создать сервер с локально-избыточной конфигурацией высокой доступности в одной зоне доступности, необходимо использовать Azure CLI или другой программный способ развертывания. Инструкции Azure CLI см. в разделе "Включить высокий уровень доступности" во время создания сервера.

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

  • Чтобы перевести существующий сервер на высокую доступность с резервированием между зонами, необходимо выполнить миграцию на новый сервер. Дополнительные сведения см. в статье «Миграция с существующего сервера на сервер с избыточностью по зонам».

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

    1. Отключите HA, если она включена.

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

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

Поведение, когда все зоны работоспособны

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

• Операция между зонами: Клиентские приложения MySQL подключаются к основному серверу с помощью полного доменного имени сервера базы данных (FQDN). Избегайте использования IP-адреса основного сервера, так как IP-адрес может измениться, в том числе при переключении на резервную систему.

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

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

  Эффекты репликации различаются в зависимости от конфигурации зоны доступности, используемой сервером:

  • Избыточность между зонами: Так как серверы находятся в отдельных зонах, этот подход гарантирует нулевой потери данных во время сбоя зоны. Эта ситуация также называется достижением целевой точки восстановления (RPO) равной нулю при сбоях в зоне.

    Однако репликация между зонами может привести к небольшой задержке. В среднем следует ожидать увеличения задержки на 5–10% при записи данных приложением и фиксации транзакций, однако фактическое влияние зависит от рабочей нагрузки, выбранного SKU и региона.

  • Локальная избыточность: Трафик не реплицируется между зонами.

  Замечание

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

Поведение во время сбоя зоны

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

• Обнаружение и реакция: Azure периодически проверяет работоспособность основных и резервных серверов. После нескольких пингов, если мониторинг работоспособности обнаруживает, что первичный сервер недоступен, служба инициирует автоматическую отработку отказа на резервный сервер. Алгоритм мониторинга работоспособности использует несколько точек данных, чтобы избежать ложных положительных ситуаций.

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

  • Зональная избыточность: В Azure Database для MySQL сбои в зонах доступности выявляются автоматически благодаря непрерывному мониторингу нескольких серверных точек доступа. Дополнительные сведения см. в статье Как работает обнаружение автоматического переключения при отказе на серверах с поддержкой HA.

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

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

• Уведомление: Microsoft не уведомляет вас автоматически, когда зона отключена. Однако вы можете использовать Azure Работоспособность ресурсов для отслеживания работоспособности отдельного ресурса и настроить оповещения Работоспособность ресурсов для уведомления о проблемах. Вы также можете использовать Работоспособность служб Azure для понимания общего состояния службы, включая любые сбои зоны, и настроить оповещения Service Health для уведомления о проблемах.

  База данных Azure для MySQL создает событие Azure Работоспособность ресурсов при незапланированном сбое.

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

• Ожидаемая потеря данных: Объем потери данных зависит от конфигурации зоны доступности сервера.

  • Избыточность между зонами: Ожидается нулевая потеря данных во время отказа зоны благодаря синхронной репликации между основным и резервным серверами в разных зонах.

  • Локально-избыточные: Данные на серверах в затронутой зоне недоступны до восстановления зоны.

• Ожидаемое время простоя: Время простоя зависит от конфигурации зоны доступности, используемой сервером.

  • С избыточностью по зонам: Переключение при отказе обычно занимает от 60 до 120 секунд. Если ваши клиенты обрабатывают временные сбои правильно и повторно пытаются через короткий промежуток времени, они обычно избегают значительных последствий.

  • Локально-избыточное: Серверы в затронутой зоне недоступны до восстановления зоны доступности.

• Перераспределение: Поведение перенаправки трафика зависит от конфигурации зоны доступности, используемой сервером.

  • С резервированием между зонами: После переключения при отказе резервный сервер становится новым основным сервером и начинает принимать новые подключения. Azure автоматически устанавливает резервный сервер в исходной основной зоне после восстановления. Дополнительные сведения см. в разделе Незапланированное переключение при отказе.

  • Локально-резервируемое: Если зона недоступна, сервер недоступен. Если у вас есть отдельный сервер, который вы создали в другой зоне доступности или регионе, вы несете ответственность за перенаправку трафика на этот сервер.

Восстановление зоны

Поведение восстановления зоны зависит от конфигурации зоны доступности, используемой сервером.

• Избыточность на уровне зон: Когда зона доступности снова становится доступной, База данных Azure для MySQL автоматически повторно создает резервный сервер в восстановленной зоне и синхронизирует его с текущим основным сервером. Затем восстановленная зона служит резервным расположением. Служба не перемещает основную роль обратно в исходную зону, чтобы избежать ненужных сбоев. Если вы хотите вернуть основной ресурс в исходную зону, вы можете вручную инициировать плановое переключение.

• Локальная избыточность: После восстановления зоны серверы в зоне будут доступны снова. Вы несете ответственность за процедуры восстановления на уровне зоны и синхронизацию данных, необходимые вашим рабочим нагрузкам.

Тестирование на сбои в зоне

Параметры тестирования сбоев зоны зависят от конфигурации зоны доступности, которую использует экземпляр.

• Избыточность между зонами: Вы можете проверить устойчивость приложения к отработке отказа, инициируя плановую отработку отказа. Используйте плановую отработку отказа, чтобы имитировать незапланированный сбой во время выполнения рабочей нагрузки и наблюдать за временем простоя приложения. Выполнение моделирования в непроизводственных средах или в спокойное время. Для получения дополнительной информации см. раздел «Плановая отработка отказа».

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

  • портал Azure. Остановите и запустите гибкий экземпляр сервера База данных Azure для MySQL.

  • Azure CLI: перезапуск, остановка и запуск гибкого экземпляра сервера База данных Azure для MySQL.

Устойчивость к сбоям на уровне региона

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

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

Межрегионные реплики чтения

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

Технология физической репликации MySQL асинхронно обновляет реплики для чтения с исходного сервера в первичном регионе, что означает, что реплики могут отставать от исходного сервера. Межрегиональные реплики чтения могут опционально обслуживать только чтение, чтобы снизить задержку для глобально распределенных приложений или разгрузить трафик чтения с исходного сервера. Дополнительные сведения о возможностях и особенностях использования реплик для чтения см. в разделе «Реплики для чтения».

Схема состоит из основного региона, дополнительного региона и помеченного значком приложения. Сплошная стрелка от значка приложения к основному серверу в основном регионе. Пунктирная стрелка с надписью «асинхронная репликация» идёт от первичного сервера к реплике для чтения во вторичном регионе.

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

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

Замечание

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

Требования

• Region support: Вы можете создавать межрегиональные реплики чтения в любом из регионов, которые поддерживают База данных Azure для MySQL. Вы не ограничены парными регионами Azure.

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

Рекомендации

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

• Мониторинг задержки репликации: Для асинхронного процесса репликации требуется задержка репликации, которая может отличаться в зависимости от нескольких факторов. Если задержка репликации очень высока, сервер может столкнуться с проблемами. Важно отслеживать задержку репликации, чтобы устранить проблемы перед их эскалацией. Дополнительные сведения см. в разделе "Мониторинг репликации".

• HA: Реплики для чтения не могут иметь включенную высокую доступность, и при их аварийном переключении в основной сервер они также не имеют высокой доступности. Вы отвечаете за настройку HA после аварийного переключения на реплику.

Cost

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

Настройка поддержки нескольких регионов

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

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

  • Azure CLI. Создание реплик чтения и управление ими на гибком сервере База данных Azure для MySQL с помощью Azure CLI

  После создания исходного сервера можно настроить реплики, только если исходный сервер запущен и доступен.

• Остановка репликации: Сведения об остановке репликации см. в разделе "Остановка репликации на сервер реплики".

• Удаление реплики чтения: Сведения об удалении реплики чтения см. в статье "Удаление сервера реплики".

Поведение, когда все регионы работоспособны

В этом разделе описано, чего ожидать при настройке сервера с репликой чтения в другом регионе, если все регионы доступны:

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

• Репликация данных между регионами: Реплики чтения между регионами используют асинхронную репликацию, чтобы свести к минимуму влияние на производительность исходного сервера. Объем задержки репликации зависит от нескольких факторов, включая нагрузку записи и задержку между исходным сервером и репликами. Задержка репликации обычно составляет не менее нескольких минут, но это может быть гораздо дольше. Дополнительные сведения см. в разделе Monitor replication и подробные инструкции см. в разделе Монитор репликации на портале Azure.

Поведение во время сбоя региона

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

• Обнаружение и реагирование: Вы отвечаете за обнаружение сбоя в основном регионе и ручной запуск аварийного переключения. Это действие может привести к потере нереплицированных данных.

  Это важно

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

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

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

  2. Перенастройка приложения для использования нового первичного сервера.

  Для получения дополнительной информации см. Failover.

• Notification: Microsoft автоматически не уведомляет вас об отключении региона. Однако вы можете использовать Работоспособность служб Azure, чтобы понять общее состояние службы, включая сбои в любом регионе, и настроить оповещения Service Health для уведомления о проблемах.

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

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

  Объем потери данных зависит от задержки репликации во время сбоя. Задержка репликации обычно составляет не менее нескольких минут, но это может быть гораздо дольше. Дополнительные сведения см. в разделе "Мониторинг репликации".

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

• Перенаправка трафика: Вы несете ответственность за перенастройку приложений для подключения к новому основному серверу.

  Замечание

  После отработки отказа реплики чтения, чтобы стать основным сервером, сервер не включает высокий уровень доступности. Необходимо вручную включить HA или добавить её в автоматизацию.

Восстановление региона

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

• Перенесите приложение в автономный режим и подождите, пока репликация догонит все изменения. Для этого подхода требуется время простоя приложения, примерно такое же, как задержка репликации.

• Выполните аварийное переключение и примите потерю нереплицированных данных.

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

Проверка сбоев в регионе

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

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

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

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

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

• Хранилище резервных копий: Если сервер настроен с высокой доступностью с избыточностью между зонами, резервные копии хранятся в ZRS. Для серверов, настроенных без высокой доступности (HA) или с локально-избыточной высокой доступностью, система сохраняет резервные копии в LRS.

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

  Срок хранения резервных копий по умолчанию составляет 7 дней, но вы можете продлить срок хранения до 35 дней. Все резервные копии шифруются.

• Восстановление: Восстановление на момент времени (PITR) позволяет восстановить базу данных в любой момент в течение периода хранения резервных копий. Процесс восстановления создает новый сервер базы данных с новым именем сервера, предоставленным пользователем. Вы можете использовать новый сервер as-is или скопировать данные из него.

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

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

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

Дополнительные сведения см. в разделе Backup и восстановление в База данных Azure для MySQL.

Устойчивость к обслуживанию служб

База данных Azure для MySQL автоматически обрабатывает критически важные задачи обслуживания, включая исправление базового оборудования, операционной системы и ядра СУБД. Служба включает обновления системы безопасности, обновления программного обеспечения и дополнительные обновления версий в рамках планового обслуживания. Дополнительные сведения см. в разделе Scheduled maintenance in База данных Azure для MySQL.

Чтобы убедиться, что сервер остается доступным во время периода обслуживания, следуйте приведенным ниже рекомендациям.

• Избегайте операций управления в периоды обслуживания. Не выполняйте операции управления серверами во время обслуживания, так как эти операции могут повлиять на надежность сервера.

• Используйте обслуживание с практически нулевым временем простоя. Если на вашем сервере включен режим высокой доступности и он соответствует другим требованиям, операции обслуживания обычно завершаются в течение 10–30 секунд. Если включить высокий уровень доступности, операции обслуживания обычно используют последовательные обновления, чтобы свести к минимуму время простоя. Периодические действия обслуживания, такие как незначительные обновления версий, происходят сначала на резервной реплике. Чтобы сократить время простоя, резервный сервер повышен до основного, чтобы рабочие нагрузки могли продолжать выполняться, пока задачи обслуживания применяются на оставшемся узле. Эта последовательность применяется независимо от того, использует ли ваш сервер высокую доступность с избыточностью по зонам или локальную избыточность высокой доступности. Дополнительные сведения см. в разделе "Почти нулевое время простоя".

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

• Реализуйте логику повторных попыток. Убедитесь, что приложения могут обрабатывать короткие прерывания подключения, которые могут возникнуть во время перезапуска обслуживания. Чтобы сделать приложения устойчивыми к этим типам проблем, см. статью "Устойчивость к временным сбоям".

• Включите обслуживание виртуальных канареечных сред на серверах разработки и тестирования. Обслуживание Virtual Canary обеспечивает ранний доступ к обновлениям. Включив его на серверах разработки и тестирования, вы можете убедиться, что предстоящие обновления не влияют на рабочую нагрузку, прежде чем они достигают рабочих серверов. Дополнительные сведения см. в разделе "Обслуживание виртуальных канарий".

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLAs для онлайн-сервисов.

База данных Azure для MySQL предоставляет разные соглашения об уровне обслуживания доступности на основе конфигурации сервера:

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

Связанный контент

• Надежность Azure
• Лучшие практики архитектуры для База данных Azure для MySQL
• Обзор непрерывной работы бизнеса с База данных Azure для MySQL