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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

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

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

  

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

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

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

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

Требования

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

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

Cost

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

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

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

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

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

Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • портал Azure: Остановка/Запуск базы данных Azure для MySQL — Гибкий экземпляр сервера
  • Azure CLI: Restart/stop/start База данных Azure для MySQL — Гибкий сервер

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

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

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

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

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

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

Замечание

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

Требования

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

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

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

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

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

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

Cost

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Это важно

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

  Для переключения на резервную систему требуется:

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

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

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

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

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

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

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

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

  Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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