Общие сведения о службе базы данных Azure для MySQL
База данных Azure для MySQL можно развернуть как гибкий сервер (предварительная версия) для размещения базы данных MySQL в Azure. Это полностью управляемая база данных как услуга, которая может управлять критически важными рабочими нагрузками с прогнозируемой производительностью и динамическим масштабированием.
Как разработчик баз данных с многолетним опытом по запуску локальных установок MySQL и управлению ими вы хотите понять, каким образом служба базы данных Azure для MySQL поддерживает и масштабирует свои функции.
На этом занятии вы ознакомитесь с ценами, узнаете о поддержке версий, изучите процесс репликации и рассмотрите варианты масштабирования для Базы данных Azure для PostgreSQL.
Преимущества службы базы данных Azure для MySQL
Служба базы данных Azure для MySQL предоставляется как сервер базы данных Azure для MySQL. Сервер службы базы данных Azure для MySQL эквивалентен локальному серверу MySQL и обеспечивает предоставление центральной точки для администрирования нескольких баз данных MySQL.
Чтобы создать службу базы данных Azure для MySQL, необходимо сначала выполнить подготовку к работе сервера базы данных Azure для MySQL. Сервер службы базы данных Azure для MySQL является родительским для одной или нескольких баз данных и обеспечивает предоставление пространства имен для этих баз данных. При удалении сервера удаляются все размещенные на нем базы данных.
Какие возможности предоставляет сервер службы базы данных Azure для MySQL?
Служба "База данных Azure для MySQL" обеспечивает высокую доступность без дополнительных затрат и масштабируемость по мере необходимости. Вы платите только за то, что используете. Предоставляется автоматическое резервное копирование с возможностью восстановления на определенный момент времени.
Сервер обеспечивает безопасность подключения, требуя соблюдения правил брандмауэра и при необходимости запрашивая SSL-соединения. Множество имеющихся параметров сервера позволяют настраивать режимы блокировки, максимальное количество подключений, тайм-ауты и другие возможности. Изменения параметров, помеченных как динамические, вступает в силу немедленно. Для статических параметров требуется перезапуск сервера. Перезапуск сервера выполняется кнопкой Перезапустить, находящейся на портале на странице Обзор.
Серверы службы базы данных Azure для MySQL обладают функциями мониторинга, которые позволят добавлять предупреждения и просматривать метрики и журналы.
Ценовые категории
Ценовые категории обеспечивают предоставление ресурсов с широким спектром производительности и емкости: от одного до 64 виртуальных ядер и от 5 ГБ до 4 ТБ хранилища. Базовая ценовая категория предназначена для небольших по ресурсоемкости рабочих нагрузок и поддерживает до двух виртуальных ядер с 2 ГБ памяти на каждое ядро. Ценовая категория общего назначения подходит для большинства рабочих нагрузок и поддерживает от двух до 64 виртуальных ядер с 5 ГБ памяти на ядро. Ценовая категория "Оптимизированная для памяти" поддерживает от 2 до 32 виртуальных ядер, предусматривает предоставление 10 ГБ памяти на каждое виртуальное ядро и предназначена для высокопроизводительных рабочих нагрузок, включая анализ данных в режиме реального времени. Несмотря на то, что можно переключаться между ценовыми категориями "Общего назначения" и "Оптимизированной для памяти", а также изменять количество виртуальных ядер или объем хранилища всего за несколько секунд, переход на ценовую категорию "Стандартная" или со "Стандартной" категории на другие ценовые категории невозможен.
Для подключений имеются ограничения в соответствии с ценовыми категориями и количеством виртуальных ядер. Дополнительные сведения см. в разделе Ограничения службы базы данных Azure для MySQL.
Управление версиями и обновления
Служба базы данных Azure для MySQL совместима со следующими версиями: 5.6 (выпуск 5.6.42 с исправлением ошибок), 5.7 (выпуск 5.7.24 с исправлением ошибок) и 8.0 (выпуск 8.0.15 с исправлением ошибок).
Примечание.
Сетевой шлюз перенаправляет соединения к экземплярам сервера. Клиенты MySQL отображают версию шлюза, а не версию экземпляра сервера. Чтобы посмотреть версию экземпляра сервера, используйте команду SELECT VERSION();.
Версии с исправлением ошибок применяются автоматически, но обновление версий не поддерживается. Для обновления с одной версии на другую необходимо выполнить операции создания файла резервной копии и восстановления.
Масштабируемость
Как уже отмечалось, переход на базовую ценовую категорию или с нее на другую категорию невозможен. Однако можно изменить количество виртуальных ядер, создание аппаратных ресурсов, объем хранилища и срок хранения резервных копий. Вы также можете переключаться между ценовыми категориями "Общего назначения" и "Оптимизированной для памяти".
Обратите внимание, что хранилище может только увеличиваться, а не уменьшаться, и это увеличение для него можно задать в автоматическом режиме. При включении автоматического увеличения для серверов с объемом хранилища менее 100 ГБ объем хранилища увеличивается на 5 ГБ, если объем доступного хранилища меньше 1 ГБ, или на 10 % от объема тома хранилища (в зависимости от того, какая из этих величин больше). Для серверов с объемом хранилища больше 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, который будет использоваться в качестве узла для реплики, а также создайте все необходимые учетные записи пользователей и привилегии.
- Настройте репликацию на главном сервере.
- Создайте резервную копию и восстановите главный сервер.
- Для настройки целевого сервера используйте сохраненные процедуры репликации входных данных.
Для получения дополнительной информации см. раздел Настройка службы базы данных Azure для MySQL для репликации входных данных.
Реплики чтения
В репликах чтения используется собственная технология репликации MySQL для создания экземпляров асинхронной реплики серверов службы базы данных Azure для MySQL. Серверы реплик доступны только для чтения, и для каждого главного сервера может существовать не более пяти реплик. За каждую реплику чтения вносится ежемесячная стоимость в соответствии с количеством виртуальных ядер и объемом используемого хранилища.
Использование реплик чтения
Серверы отчетов
Создание реплики чтения для главного сервера позволяет перенаправить в реплику все рабочие нагрузки по созданию отчетов, бизнес-аналитике и общей аналитике. Таким образом эти рабочие нагрузки удаляются с главного сервера, и на нем снижается количество конфликтов, при этом главный сервер продолжает обслуживать рабочие нагрузки с интенсивными операциями записи.
Перенос данных ближе к пользователям
Межрегиональные реплики создаются для переноса данных ближе к пользователям и для повышения скорости их чтения. Межрегиональные реплики могут находиться в регионе универсальной реплики или в дополнительном регионе главного сервера. Доступные регионы отображаются при создании сервера-реплики.
Настройка реплик чтения
Реплики чтения настраиваются на портале Azure:
Затем следует указать имя и регион для реплики:
Примечание.
Реплики чтения недоступны в базовой ценовой категории.
Дополнительные сведения о репликах чтения см. в разделе Реплики чтения в службе базы данных Azure для MySQL.
Управление и мониторинг
В состав службы базы данных Azure для MySQL входит широкий набор средств мониторинга, помогающих выполнить оптимизацию сервера, получать уведомления о событиях и проактивно реагировать в соответствии с метриками. Вы также можете использовать привычные средства администрирования MySQL, такие как последние версии MySQL Workbench, PHPMyAdmin и Navicat, чтобы осуществлять управление и мониторинг серверов службы базы данных Azure для MySQL:
Средства Azure для мониторинга службы базы данных Azure для MySQL
Для управления и мониторинга службы базы данных Azure для MySQL на портале Azure имеются следующие средства:
Метрики Azure. Метрики обеспечивают предоставление числовых данных один раз в минуту и сохраняются в течение 30 дней. Существует широкий набор метрик, которые используются для наблюдения за сервером; можно также настроить оповещения, чтобы реагировать на данные метрик.
Дополнительные сведения см. в разделе Платформа данных Azure Monitor.
Журналы сервера и аудита. Включение функции журнала сервера позволяет отслеживать медленные запросы и проводить аудит сервера. Доступ к журналам сервера вне базы данных SQL для MySQL возможен с помощью журналов диагностики 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 Community Edition и обеспечивается совместимость с широким спектром драйверов благодаря поддержке различных языков программирования. Строки подключения предоставляются на портале Azure:
Дополнительные сведения о драйверах MySQL см. в разделе Драйверы и средства управления MySQL, совместимые со службой базы данных Azure для MySQL
Настройка брандмауэра
Проще всего настроить брандмауэр можно с помощью параметров безопасности подключения для службы на портале Azure. Добавьте правило для каждого диапазона IP-адресов клиента. На этой странице можно также указать принудительное использование SSL-соединений для службы.
Чтобы добавить IP-адрес настольного компьютера, щелкните на панели инструментов пункт Добавить IP-адрес клиента.
Если вы настроили реплики только для чтения, для каждой из них необходимо добавить правило брандмауэра, чтобы сделать их доступными для клиентов.
Временные ошибки подключения
При подключении к базе данных через Интернет возникновение временных ошибок подключения является неизбежным, и они должны обрабатываться клиентскими приложениями.
С информацией о временных ошибках подключения можно ознакомиться в разделе Обработка временных ошибок подключения в службе базы данных Azure для MySQL.
Функции MySQL, которые не поддерживаются в службе базы данных Azure для MySQL
Хотя большинство функций MySQL доступно в службе базы данных Azure для MySQL, некоторые из них не поддерживаются. На эти функции следует обратить внимание, чтобы предотвратить возможные проблемы при миграции.
Подсистемы хранилища
Служба базы данных Azure для MySQL поддерживает подсистемы хранилища InnoDB и MEMORY. InnoDB — это подсистема хранилища, используемая для MySQL по умолчанию, она обеспечивает баланс между высокой производительностью и высокой надежностью. Все новые таблицы в MySQL используют подсистему хранилища InnoDB, если не указано иное.
Дополнительные сведения о подсистеме хранилища InnoDB см. в разделе Введение в InnoDB.
Для хранения данных в памяти предназначена подсистема хранилища MEMORY. Такие данные подвергаются риску при любых сбоях или отказах в работе — подсистему хранилища MEMORY следует использовать только как временное высокопроизводительное хранилище.
Дополнительные сведения о подсистеме хранилища MEMORY см. в разделе Подсистема хранилища MEMORY.
В службе базы данных Azure для MySQL не поддерживаются подсистемы хранилища MyISAM, BLACKHOLE, ARCHIVE и FEDERATED. Данные из подсистемы хранилища MyISAM нужно преобразовать в подсистему хранилища InnoDB. Подсистемы хранилища BLACKHOLE, ARCHIVE и FEDERATED имеют специальное предназначение и не используются в качестве типовых хранилищ данных.
Привилегии и роли
Роль администратора баз данных недоступна, так как многие параметры и настройки сервера могут нарушать правила транзакций и снижать производительность. По тем же причинам ограничены права суперпользователя, как и права роли DEFINER ("создатель"), в которой используются привилегии суперпользователя.
Восстановление
В службе базы данных Azure для MySQL имеется две функции восстановления, которые работают по разному:
- При восстановлении до точки во времени создается новый сервер с конфигурацией, идентичной исходному серверу.
- Удаленный сервер восстановить невозможно.