Концепции высокого уровня доступности в Базе данных Azure для MySQL — гибкий сервер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

Примечание.

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

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

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

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

Примечание.

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

Ограничения

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

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

Примечание.

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

Примечание.

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

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

• Каковы соглашения об уровне обслуживания для одного и того же зоны и избыточного между зонами высокого уровня доступности с поддержкой гибкого сервера?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Можно ли использовать репликацию входных данных для серверов с высоким уровнем доступности?
  Поддержка реплика поддержки данных для сервера с поддержкой высокой доступности (HA) доступна только через реплика на основе GTID. Хранимая процедура для реплика tion с помощью GTID доступна на всех серверах с поддержкой высокого уровня доступности по имениmysql.az_replication_with_gtid.

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

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

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

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