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

Важно!

База данных Azure для MariaDB находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить миграцию в База данных Azure для MySQL. Дополнительные сведения о переходе на База данных Azure для MySQL см. в статье "Что происходит с База данных Azure для MariaDB?".

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

  • Запланированные события, такие как операции масштабирования, инициированные пользователем.
  • Незапланированные события, такие как базовые аппаратные, программные или сетевые сбои.

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

Компоненты в Базе данных Azure для MariaDB

Компонент Description
Сервер базы данных MariaDB База данных Azure для MariaDB реализует функции безопасности, изоляции, средства защиты ресурсов и возможность быстрого перезапуска серверов баз данных. Эти возможности упрощают такие операции, как масштабирование и восстановление сервера базы данных (в секундах) после сбоя.
Изменения данных на сервере базы данных обычно происходят в контексте транзакции базы данных. Все изменения базы данных записываются синхронно в виде журналов перед записью (ib_log файлов) на служба хранилища Azure, подключенных к серверу базы данных. В процессе отработки контрольных точек базы данных страницы данных из памяти сервера базы данных также сбрасываются в хранилище.
Удаленное хранилище Все файлы физических данных MariaDB и файлы журналов хранятся в служба хранилища Azure, в котором хранятся три копии данных в регионе для обеспечения избыточности данных, доступности и надежности. Уровень хранилища не зависит от сервера базы данных. Его можно отсоединить от неудачного сервера базы данных и повторно подключиться к новому серверу базы данных через несколько секунд.
служба хранилища Azure постоянно отслеживает ошибки хранилища. Если он обнаруживает повреждение блока, он автоматически исправляет проблему путем создания экземпляра новой копии хранилища.
Шлюз Шлюз выступает в качестве прокси-сервера базы данных путем маршрутизации всех клиентских подключений к серверу базы данных.

Устранение запланированного простоя

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

Diagram of elastic scaling in Azure Database for MariaDB.

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

Сценарий Description
Увеличение масштаба вычислений или уменьшение масштаба При выполнении операции масштабирования вычислений вверх или уменьшения масштаба База данных Azure для MariaDB подготавливать новый сервер базы данных с помощью масштабируемой конфигурации вычислений. На старом сервере базы данных служба позволяет активным проверка точкам завершить работу, очищать клиентские подключения и отменять все незафиксированные транзакции. Затем служба завершает работу старого сервера базы данных. Он отсоединяет хранилище от старого сервера базы данных и подключает хранилище к новому серверу базы данных. Когда клиентское приложение повторяет подключение или пытается создать новое подключение, шлюз направляет запрос на подключение к новому серверу базы данных.
Масштабирование хранилища Масштабирование хранилища является оперативной операцией и не прерывает сервер базы данных.
Развертывание нового программного обеспечения (Azure) Развертывание новых функций или исправлений ошибок происходит автоматически в рамках планового обслуживания службы. Дополнительные сведения см. в документации и проверка портале.
Обновление промежуточных версий База данных Azure для MariaDB автоматически исправляет серверы баз данных до дополнительной версии, которую определяет Azure. Автоматическое исправление происходит в рамках планового обслуживания службы. Он вызывает короткое время простоя в секундах, и сервер базы данных автоматически перезапускается с новой дополнительной версией. Дополнительные сведения см. в документации и проверка портале.

Устранение незапланированного простоя

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

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

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

Diagram of high availability in Azure Database for MariaDB.

Незапланированное время простоя: сценарии сбоя и восстановление служб

Ниже приведены два сценария сбоя и автоматическое восстановление База данных Azure для MariaDB.

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

Ниже приведены сценарии сбоя, требующие восстановления действия пользователя:

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

Итоги

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

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