Поделиться через

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

Гибкий сервер Базы данных Azure для MySQL позволяет настроить высокий уровень доступности с помощью автоматической отработки отказа. Это решение гарантирует, что сбои никогда не приводят к потере зафиксированных данных и что база данных не является одной точкой сбоя в архитектуре программного обеспечения. При настройке высокой доступности гибкий сервер автоматически подготавливает резервную реплику и управляет ими. Вы оплачиваете подготовленные вычислительные ресурсы и хранилище как для первичных, так и вторичных реплик. Доступны две модели архитектуры с высоким уровнем доступности:

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

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

Архитектура высокого уровня доступности с избыточностью между зонами (HA)

При развертывании сервера с высоким уровнем доступности, избыточного между зонами, Azure создает два сервера:

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

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

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

Файлы данных и журналов размещаются в хранилище, избыточном между зонами (ZRS). Резервный сервер постоянно считывает и воспроизводит файлы журналов из учетной записи хранения сервера-источника, которая защищает репликацию на уровне хранилища.

Если происходит отработка отказа:

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

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

Имя сервера базы данных используется для подключения приложений к основному серверу. Решение не предоставляет сведения о резервной реплике для прямого доступа. Фиксации и записи подтверждаются, после того как файлы журнала записываются в ZRS главного сервера. Благодаря технологии синхронной репликации, используемой в хранилище ZRS, приложения могут рассчитывать на увеличение задержки на 5-10% при записи и фиксации.

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

Архитектура высокого уровня доступности (HA) с избыточностью на локальном уровне

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

  • Главный сервер
  • Резервный сервер реплики с той же конфигурацией, что и главный сервер (включая уровень и объем вычислительных ресурсов, размер хранилища и конфигурацию сети)

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

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

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

Если происходит отработка отказа:

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

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

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

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

Примечание.

Для зонально-избыточного и локально-избыточного обеспечения высокого уровня доступности:

  • Если происходит сбой, время, необходимое для резервной реплики, в зависимости от времени, необходимого для воспроизведения двоичного журнала из основной учетной записи хранения в резервный. Чтобы сократить время отработки отказа, используйте первичные ключи во всех таблицах. Время отработки отказа обычно занимает от 60 до 120 секунд.
  • Резервный сервер недоступен для операций чтения и записи. Это пассивный резервный сервер, обеспечивающий быструю отработку отказа.
  • Всегда используйте полное доменное имя (FQDN) для подключения к главному серверу. Подключаться с помощью IP-адреса не рекомендуется. Если происходит отработка отказа, после переключения ролей основного и резервного сервера запись DNS A может измениться. Это изменение предотвращает подключение приложения к новому основному серверу, если IP-адрес используется в строке подключения.

Процесс отработки отказа

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

Примечание.

Чтобы уменьшить зависимость времени переключения на кэширование DNS, начиная с октября 2025 года, все новые HA-серверы, созданные с общедоступным доступом или приватным каналом, будут применять новую архитектуру с выделенным балансировщиком нагрузки (SLB) для каждого HA-сервера. Управляя путем трафика данных MySQL, SLB устраняет необходимость изменений DNS во время отказоустойчивости и значительно повышает её эффективность. Он перенаправляет трафик на текущий основной экземпляр во время переключения на резервный режим с помощью правил балансировки нагрузки. Существующие серверы с общедоступным доступом или приватным каналом будут постепенно перенесены, чтобы свести к минимуму влияние. Клиенты, которые предпочитают раннюю миграцию, могут отключить и повторно включить HA. Эта функция не поддерживается для серверов с помощью закрытого доступа с интеграцией виртуальной сети.

Плановый режим. Принудительный переход на другой ресурс вручную

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

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

Общее время отработки отказа зависит от текущей рабочей нагрузки и времени последней контрольной точки. В общем случае это занимает от 60 до 120 секунд.

Примечание.

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

Внеплановая ситуация. Автоматический переход на другой ресурс

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

Общее время отработки отказа обычно составляет от 60 до 120 секунд. Однако в зависимости от действия на сервере базы данных-источника во время отработки отказа (например, больших транзакций и времени восстановления) отработка отказа может занять больше времени.

Примечание.

Событие Работоспособности ресурсов Azure создается во время незапланированной отработки отказа. Событие представляет время отработки отказа, когда сервер недоступен. События триггеров отображаются при выборе работоспособности ресурсов на левой панели. Автоматическая отработка отказа показывает состояние "Недоступно" и помечен как "Незапланированный".

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

Как работает автоматический переход на другой ресурс на серверах с высоким уровнем доступности

Основной сервер и сервер-получатель имеют две сетевые конечные точки:

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

Компонент монитора работоспособности выполняет следующие проверки:

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

Примечание.

Проверка работоспособности не отслеживает проблемы с сетью между приложением и конечной точкой сети клиента (частный или общедоступный доступ). Эти проблемы могут возникать в сетевом пути, конечной точке или в проблемах DNS на стороне клиента. Если вы используете частный доступ, убедитесь, что правила NSG для виртуальной сети не блокируют связь с конечной точкой сети клиента экземпляра через порт 3306. Для общедоступного доступа убедитесь, что правила брандмауэра заданы, а сетевой трафик разрешен через порт 3306 (если сетевой путь имеет другие брандмауэры). Кроме того, необходимо заботиться о разрешении DNS на стороне клиентского приложения.

Мониторинг высокой доступности

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

Состояние Описание
NotEnabled (Невключено) Высокий уровень доступности не включен.
Репликация Данных Резервный сервер синхронизируется с основным сервером во время подготовки сервера высокой доступности или при включении параметра высокой доступности.
отработки отказа Сервер базы данных выполняет отработку отказа с первичного сервера на резервный.
Работоспособен Включен параметр высокой доступности.
удаление Процесс удаления выполняется при отключении параметра высокой доступности.

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

Отображаемое имя метрики Метрика Единица измерения Описание
Состояние высокого уровня доступности IO ha_io_running Штат Состояние высокого уровня доступности IO показывает состояние репликации высокого уровня доступности. Значение метрики равно 1, если поток ввода-вывода запущен и 0, если нет.
Состояние SQL высокого уровня доступности ha_sql_running Штат Состояние SQL высокого уровня доступности показывает состояние репликации высокого уровня доступности. Значение метрики равно 1, если поток SQL запущен и 0, если нет.
Задержка репликации высокой доступности задержка репликации сек. Задержка репликации — это количество секунд, отстающих от резервного выполнения транзакций, полученных на первичном сервере.

Ограничения

При использовании высокой доступности следует учитывать следующие рекомендации.

  • Во время создания сервера можно настроить избыточность между зонами.

  • Высокодоступный уровень вычислений не поддерживает высокий уровень доступности.

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

  • Решение включает режим GTID, так как он использует GTID. Убедитесь, что ваша рабочая нагрузка имеет ограничения или ограничения на репликацию с помощью GTID.

Примечание.

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

Проверки работоспособности

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

Мониторинг работоспособности

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

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

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

  • Last updated on