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

База данных Azure для одного сервера MySQL

  • Статья

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

Внимание

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

База данных Azure для MySQL на базе MySQL Community Edition доступна в двух режимах развертывания:

  • Гибкий сервер
  • Отдельный сервер

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

Обзор

База данных Azure для MySQL один сервер — это полностью управляемая служба баз данных, предназначенная для минимальной настройки. Платформа отдельного сервера рассчитана на обработку большинства функций управления базами данных, как, например, установка исправлений, резервное копирование, обеспечение высокого уровня доступности и безопасности с минимальным вмешательством пользователя дли их настройки и управления. Эта архитектура оптимизирована для поддержки уровня доступности 99,99 % без применения дополнительных средств при использовании одной зоны доступности. Она поддерживает MySQL Community Edition версий 5.6 (поддержка прекращена), 5.7 и 8.0. Эта служба сейчас доступна во многих регионах Azure.

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

Высокая доступность

Модель развертывания отдельного сервера оптимизирована для обеспечения высокой доступности и эластичности по доступной цене. В этой архитектуре ресурсы вычислений и хранилища разделены. Ядро СУБД работает в собственном контейнере вычислений, а файлы данных размещаются в службе хранилища Azure. Хранилище поддерживает три локально избыточные синхронные копии файлов базы данных, обеспечивающие устойчивость данных.

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

  1. подготавливается новый контейнер вычислений;
  2. хранилище с файлами данных сопоставляется с новым контейнером;
  3. ядро СУБД MySQL запускается в новом контейнере вычислений.
  4. служба шлюза обеспечивает прозрачную отработку отказа, не требуя изменений на стороне приложения.

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

Соглашение об уровне обслуживания (SLA) в Azure, предусматривающее самый высокий в отрасли уровень доступности (99,99 %) с поддержкой глобальной сети центров обработки данных под управлением Майкрософт, обеспечит непрерывную работу приложения — 24 часа в сутки и 7 дней в неделю.

Автоматическое исправление

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

Автоматическое резервное копирование

Служба отдельного сервера автоматически создает резервные копии и сохраняет их в локально избыточном или геоизбыточном хранилище, настроенном пользователем. Резервные копии можно использовать для восстановления сервера на любой момент в течение периода хранения резервной копии. По умолчанию срок хранения резервных копий составляет 7 дней. Хранение можно дополнительно продлить до 35 дней. Все резервные копии шифруются с помощью 256-битового шифрования AES. Дополнительные сведения см. в документации по резервных копиях.

Быстрая настройка производительности и масштабирования

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

Безопасность, соответствие требованиям и система управления корпоративного уровня.

Служба отдельного сервера использует криптографический модуль с сертификацией FIPS 140-2 для шифрования неактивных данных. Шифруются все данные, включая резервные копии и временные файлы, создаваемые при выполнении запросов. Служба использует 256-разрядный шифр AES, включенный в шифрование службы хранилища Azure, а управление ключами клиент может доверить системе (вариант по умолчанию) или осуществлять самостоятельно. Служба по умолчанию шифрует все перемещаемые данные по протоколу SSL/TLS. Служба поддерживает версии TLS 1.2, 1.1 и 1.0 с возможностью принудительно применять минимальную версию TLS.

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

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

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

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

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

Мониторинг и оповещения

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

Миграция

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

  • Создание резервной копии и восстановление. Для миграций в автономной среде, где допустим некоторый простой для пользователей, самым быстрым способом миграции будет создание резервной копии с последующим восстановлением, для которой применяются такие средства сообщества, как mysqldump/mydumper. Дополнительные сведения см. в статье Миграция с использованием дампа и восстановления.
  • Azure Database Migration Service. Для упрощенной автономной миграции на отдельный сервер с высокой скоростью переноса данных можно применить Azure Database Migration Service.
  • Репликация входных данных. Для минимального времени простоя миграции можно также использовать репликацию входных данных на основе binlog. Репликация входных данных предпочтительна для миграции с минимальным временем простоя, выполняемой практикующими экспертами, которым нужен более полный контроль над миграцией. Дополнительные сведения см. в разделе Репликация входных данных.

Отзывы и поддержка

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

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

Итак, вы завершили знакомство с режимом развертывания Базы данных Azure для MySQL с отдельным сервером и теперь готовы: