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

Область применения: База данных Azure для MySQL — гибкий сервер

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

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

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

Архитектура высокой доступности с избыточностью между зонами

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

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

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

Diagram that shows the architecture for zone-redundant high availability.

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

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

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

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

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

Архитектура с высокой доступностью в одной зоне

При развертывании сервера с высоким уровнем доступности в одной зоне будут созданы два сервера:

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

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

Diagram that shows the architecture for same-zone high availability.

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

При отработке отказа:

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

Компонент монитора работоспособности непрерывно выполняет описанные ниже проверки.

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

Примечание

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

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

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

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

Ограничения

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

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

Примечание

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

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

  • Как выставляется счет за использование серверов с высоким уровнем доступности? Серверы, включенные с высоким уровнем доступности, имеют первичную и вторичную реплики. Вторичная реплика может находиться в одной зоне или при избыточности между зонами. За использование подготовленных вычислений и хранилища для первичной и вторичной реплики взимается плата. Например, если у вас первичная реплика с 4 виртуальными ядрами вычислений и 512 ГБ подготовленного хранилища, то вторичная реплика также будет иметь 4 виртуальных ядра и 512 ГБ подготовленного хранилища. За сервер с высоким уровнем доступности и избыточностью между зонами плата будет взиматься за 8 виртуальных ядер и 1024 ГБ хранилища. В зависимости от объема хранилища резервных копий также может взиматься плата него.

  • Можно ли использовать резервный сервер реплики для операций чтения или записи?
    Резервный сервер недоступен для операций чтения или записи. Это пассивный резервный сервер, обеспечивающий быструю отработку отказа.

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

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

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

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

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

  • Влияет ли на производительность использовании высокого уровня доступности?
    Высокий уровень доступности с избыточностью между зонами может вызвать снижение задержки на 5–10 %, если приложение подключается к серверу базы данных через зоны доступности, где задержка в сети относительно выше (2–4 мс). Для высокого уровня доступности в одной зоне задержка репликации ниже, так как основная и резервная реплики находятся в одной зоне. Существует меньше задержек между сервером приложений и сервером базы данных, если они находятся в одной зоне доступности Azure.

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

  • Можно ли выполнить восстановление до точки во времени (PITR) сервера высокого уровня доступности?
    Вы можете выполнить восстановление PITR для гибкого сервера Базы данных Azure для MySQL с включенным высоким уровнем доступности на новом гибком сервере Базы данных Azure для MySQL с отключенным высоким уровнем доступности. Если исходный сервер был создан с высоким уровнем доступности с избыточностью между зонами, позже можно будет включить высокий уровень доступности с избыточностью между зонами или высоким уровнем доступности с избыточностью в одной зоне на восстановленном сервере. Если исходный сервер был создан с высоким уровнем доступности с избыточностью в одной зоне, на восстановленном сервере можно включить только высокий уровень доступности с избыточностью в одной зоне.

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

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

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

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

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

    1. Создайте сервер с поддержкой высокого уровня доступности, избыточного между зонами.
    2. Отключите высокий уровень доступности.
    3. Выполните действия по настройке репликация входных данных. Убедитесь, что gtid_mode одинаково настроен на сервере-источнике и целевом сервере.
    4. После перехода удалите конфигурацию репликации входных данных.
    5. Включите высокий уровень доступности.
  • Можно ли выполнять отработку отказа на резервном сервере при перезагрузке сервера или вертикальном увеличении либо уменьшении масштаба для сокращения времени простоя?
    В настоящее время при вертикальном увеличении или уменьшении масштаба резервный и основной серверы масштабируются одновременно. Поэтому отработка отказа не помогает. Мы планируем разрешение на вертикальное увеличение масштаба резервного сервера в первую очередь с последующей отработкой отказа, а затем масштабирование главного сервера, но эта стратегия еще не поддерживается.

  • Можно ли изменить режим доступности (высокий уровень доступности, избыточный между зонами/высокий уровень доступности в одной зоне) сервера?
    Если вы создаете сервер с высоким уровнем доступности, избыточным между зонами, то можете изменить переключаться между высоким уровнем доступности, избыточным между зонами, и высоким уровнем доступности в одной зоне. Чтобы изменить режим доступности, можно установить для высокого уровня доступности значение Отключено на панели высокого уровня доступности, а затем снова установить для него избыточность между зонами или одну зону и выберите режим высокой доступности.

Дальнейшие действия