Общие сведения о службе базы данных Azure для MySQL

  • 14 мин

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

Разработчик базы данных с большим опытом выполнения локальных установок MySQL и управления ими, вы хотите изучить, как база данных Azure для MySQL поддерживает и масштабирует ее функции.

В этом уроке вы изучите цены, поддержку версий, репликацию и масштабирование базы данных Azure для PostgreSQL.

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

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

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

Что предоставляет сервер Базы данных Azure для MySQL?

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

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

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

Ценовые категории

Ценовые категории обеспечивают широкий диапазон производительности и емкости от одного до 64 виртуальных ядер и от 5 ГБ до 4 ТБ хранилища. Базовая ценовая категория предназначена для легких вычислительных рабочих нагрузок и поддерживает до двух виртуальных ядер с 2 ГБ памяти на ядро. Ценовая категория общего назначения подходит для большинства бизнес-рабочих нагрузок и поддерживает от двух до 64 виртуальных ядер с 5 ГБ памяти на ядро. Ценовая категория, оптимизированная для памяти, поддерживает две до 32 виртуальных ядер, имеет 10 ГБ памяти на виртуальные ядра и предназначена для высокопроизводительных рабочих нагрузок, включая анализ данных в режиме реального времени. Хотя вы можете переключаться между ценовой категорией общего назначения и оптимизированной для памяти ценовой категорией, а также изменять количество виртуальных ядер или хранилища в течение нескольких секунд, вы не можете перейти к базовой ценовой категории или из нее.

изображение , показывающее ценовые категории на портале Azure

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

Управление версиями и обновления

База данных Azure для MySQL поддерживает версию 5.6 (с исправлением ошибок версии 5.6.42), 5.7 (с исправлением ошибки 5.7.24) и 8.0 (с исправлением ошибок версии 8.0.15).

Примечание.

Шлюз перенаправляет подключения к экземплярам сервера. Клиенты MySQL будут отображать версию шлюза, а не версию экземпляра сервера. Чтобы просмотреть версию экземпляра сервера, используйте SELECT VERSION(); команда.

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

Масштабируемость

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

Обратите внимание, что хранилище только увеличивается, не уменьшается и может быть настроено автоматическое увеличение. Если автоматическое увеличение включено, хранилище увеличивается на 5 ГБ, если доступное хранилище меньше 1 ГБ или 10% тома хранилища (независимо от того, что больше) для серверов с менее чем 100 ГБ хранилища. Для серверов с более чем 100 ГБ хранилище увеличивается на 5%, если доступное хранилище меньше 5%.

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

База данных Azure для MySQL включает соглашение об уровне обслуживания с финансовой поддержкой (SLA) для доступности 99,99%. Если произошел сбой оборудования или развертывание службы, новый узел создается автоматически, а хранилище подключено к этому узлу. Отработка отказа завершится в течение десятков секунд.

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

Сведения об обработке временных ошибок см. в обработке временных ошибок подключения для базы данных Azure для MySQL.

Репликация данных в Базе данных Azure для MySQL

Репликация данных

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

Рекомендации по репликации данных

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

  • Главные серверы и серверы-реплики должны быть той же версией и по крайней мере версией 5.6.
  • Главный и реплика должны использовать подсистему InnoDB.
  • Каждая таблица должна иметь первичный ключ.
  • Сервер Базы данных Azure для MySQL должен иметь общего назначения или ценовую категорию "Оптимизированная для памяти".
  • У вас должны быть права на создание пользователей и настройка двоичного ведения журнала на главном сервере.
  • системной базе данных mysql не реплицируется. Учетные записи и разрешения не реплицируются с главного сервера на реплику и должны быть созданы вручную.

Действия по настройке репликации данных

Существует несколько шагов по настройке репликации данных:

  • Создайте базу данных Azure для MySQL Server, которая будет использоваться в качестве узла для реплики, и создайте все необходимые учетные записи пользователей и привилегии.
  • Настройте репликацию на главном сервере.
  • Дампа и восстановления главного сервера.
  • Используйте хранимые процедуры репликации данных для настройки целевого сервера.

Дополнительные сведения см. в статье Настройка репликации базы данных Azure для MySQL.

Копии для чтения

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

Используется для реплик чтения

серверах отчетов

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

перенос данных, близких к пользователей

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

Изображение с регионами реплики

Настройка реплик чтения

Вы настраиваете реплику чтения на портале Azure:

изображение с параметром репликации на портале Azure

Затем укажите имя и регион реплики:

изображение с репликацией на портале Azure

Примечание.

Реплики чтения недоступны в базовой ценовой категории.

Дополнительные сведения о репликах чтения см. в реплик чтения в базе данных Azure для MySQL.

Управление и мониторинг

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

изображение с инструментом MySQL Workbench, подключенным к базе данных Azure для MySQL

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

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

  • метрики Azure. Метрики предоставляют числовые данные каждую минуту и хранятся в течение 30 дней. Существует широкий массив метрик, используемых для мониторинга сервера, вы также можете настроить оповещения для реагирования на метрики.

    Изображение с метриками Azure

    Дополнительные сведения см. в платформы данных Azure Monitor.

  • сервера и журналы аудита. Журналы сервера позволяют отслеживать медленные запросы и предоставлять ведение журнала аудита для сервера. Журналы сервера доступны вне базы данных SQL для MySQL с помощью журналов диагностики Azure.

    Изображение с журналами сервера Azure

    Дополнительные сведения см. в журналах медленных запросов в Базе данных Azure для MySQL. Журналы аудита — это предварительная версия функции для ведения журнала аудита для отслеживания действий базы данных. Чтобы включить ведение журнала аудита, задайте параметру audit_log_enabled значение ON. Дополнительные сведения о журналах аудита см. в журналах аудита в базе данных Azure для MySQL.

  • хранилище запросов. Это используется для отслеживания производительности сервера с течением времени и предоставления сведений об устранении неполадок. Хранилище запросов сохраняет журнал запросов и статистику времени выполнения, чтобы определить ресурсоемкие или длительные запросы. Чтобы включить хранилище запросов, задайте для параметра сервера query_store_capture_mode значение ALL: изображение с режимом записи хранилища запросов

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

    SELECT * FROM mysql.query_store;

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

    SELECT * FROM mysql.query_store_wait_stats;

    Примечание.

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

    Дополнительные сведения о хранилище запросов см. в статье Мониторинг производительности Базы данных Azure для MySQL с помощью хранилища запросов.

  • Анализ производительности запросов. Аналитика производительности запросов отображает данные из хранилища запросов в качестве визуализаций, чтобы определить запросы, влияющие на производительность. Аналитика производительности запросов находится в разделе интеллектуальной производительности базы данных Azure для MySQL на портале Azure.

    Примечание.

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

    Дополнительные сведения о анализе производительности запросов см. в статье Анализ производительности запросов в базе данных Azure для MySQL.

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

    Примечание.

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

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

Возможность подключения клиента

Драйверы MySQL

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

изображение с строками подключения

Дополнительные сведения о драйверах MySQL см. в драйверах и средствах управления MySQL, совместимых с базой данных Azure для MySQL

Настройка брандмауэра

Самый простой способ настройки брандмауэра — использовать параметры безопасности подключения для службы на портале Azure. Добавьте правило для каждого диапазона IP-адресов клиента. Эту страницу также можно использовать для принудительного применения SSL-подключений к службе.

изображение с конфигурацией брандмауэра для Базы данных Azure для PostgreSQL

Щелкните Добавить IP-адрес клиента на панели инструментов, чтобы добавить IP-адрес настольном компьютере.

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

Временные ошибки подключения

При подключении к базе данных через Интернет временные ошибки подключения неизбежны и должны обрабатываться клиентскими приложениями.

Сведения об временных ошибках подключения см. в обработке временных ошибок подключения для базы данных Azure для MySQL.

Функции MySQL, которые не поддерживаются в Базе данных Azure для MySQL

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

Подсистемы хранилища

База данных Azure для MySQL поддерживает подсистемы хранилища InnoDB и MEMORY. InnoDB — это подсистема хранилища по умолчанию для MySQL, обеспечивающая баланс между высокой производительностью и высокой надежностью. Все новые таблицы в MySQL будут использовать подсистему хранилища InnoDB, если не указано иное.

Дополнительные сведения о подсистеме хранилища InnoDB см. в статье Введение в innoDB.

Для хранения данных в памяти доступна подсистема хранилища ПАМЯТИ. Эти данные подвержены риску из-за сбоя или сбоя— подсистема хранилища ПАМЯТИ должна использоваться только в качестве временного, высокопроизводительного хранилища.

Дополнительные сведения о подсистеме хранилища ПАМЯТИ см. вподсистеме хранилища ПАМЯТИ.

Обработчики хранилища MyISAM, BLACKHOLE, ARCHIVE и FEDERATED не поддерживаются в Базе данных Azure для MySQL. Данные MyISAM должны быть преобразованы в подсистему хранилища InnoDB. Обработчики хранилища BLACKHOLE, ARCHIVE и FEDERATED имеют специальные роли и не используются в качестве типичных хранилищ данных.

Привилегии и роли

Роль DBA не предоставляется, так как многие параметры сервера и параметры могут нарушить правила транзакций и снизить производительность. По аналогичным причинам права SUPER ограничены, как и предложение DEFINER, использующее привилегию SUPER.

Восстановить

Две функции восстановления работают по-разному в Базе данных Azure для MySQL:

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