Рекомендации по созданию приложения с помощью Базы данных Azure для MySQL

Статья
12/01/2023

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

Важно!

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

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

Настройка ресурсов приложения и базы данных

Сохранение приложения и базы данных в одном регионе

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

Обеспечение безопасности сервера MySQL

Настройте безопасность сервера MySQL и запрет на открытый доступ. Используйте один из следующих параметров для настройки безопасности сервера.

В целях безопасности необходимо всегда подключаться к серверу MySQL по протоколу SSL и настраивать сервер и приложение для использования TLS 1.2. См. раздел Настройка SSL/TLS.

Расширенное сетевое взаимодействие и AKS

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

Настройка параметров сервера

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

Чтобы вычислить максимально возможный размер tmp_table_size и max_heap_table_size, используйте следующую формулу.

(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections

Примечание.

Параметр "общая память" указывает общий объем памяти, которую сервер использует в подготовленных виртуальных ядрах. Например, в параметре "База данных Azure общего назначения с двумя виртуальными ядрами для сервера MуSQL" общий объем памяти составит 5 ГБ * 2. Дополнительные сведения об объеме памяти для каждого уровня можно найти в документации по конкретной ценовой категории.

Базовая память указывает на переменные памяти, такие как query_cache_size и innodb_buffer_pool_size, что MySQL инициализирует и выделяется на начальном сервере. Память для каждого подключения, например sort_buffer_size и join_buffer_size, — это память, выделенная только в том случае, если запрос нуждается в нем.

Создание пользователей, не являющихся администраторами

Создание пользователей , не являющихся администраторами для каждой базы данных. Как правило, имена пользователей определяются как имена баз данных.

Сбросьте пароль

Вы можете сбросить пароль для сервера MySQL с помощью портал Azure.

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

Производительность и устойчивость

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

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

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

Журналы аудита также доступны посредством журналов диагностики Azure в Azure Monitor, Центрах событий Azure и учетной записи хранения. См. раздел Решение проблем с производительностью запросов.

Использование пула соединений

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

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

Логика повторных попыток для обработки временных ошибок

В приложении могут возникнуть временные ошибки, при которых подключения к базе данных периодически разрываются или теряются. В таких ситуациях сервер запускается и работает после одной-двух повторных попыток через 5–10 секунд.

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

Включение репликации чтения для устранения сбоев при отработке отказа

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

Вы заметите задержку между источником и реплика, так как реплика tion является асинхронной. Задержка сети может влиять на множество факторов, таких как размер рабочей нагрузки, выполняемой на исходном сервере, и задержка между центрами обработки данных. В большинстве случаев реплика задержка составляет от нескольких секунд до нескольких минут.

Развертывание баз данных

Настройка задачи базы данных Azure для MySQL в конвейере развертывания непрерывной поставки и непрерывной интеграции

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

Использование эффективного процесса развертывания базы данных вручную

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

Создайте копию рабочей базы данных в новой базе данных, используя для этого mysqldump или MySQL Workbench.
Обновите новую базу данных, добавив изменения схемы или обновления, требуемые для базы данных.
Переведите рабочую базу данных в состояние "только для чтения". Лучше всего было бы, если у вас не было операций записи в рабочей базе данных до завершения развертывания.
Протестируйте приложение, используя обновленную базу данных, созданную в шаге 1.
Разверните изменения приложения и убедитесь, что приложение теперь использует новую базу данных с последними обновлениями.
Сохраните старую рабочую базу данных, чтобы откатить изменения. Затем можно оценить удаление старой рабочей базы данных или экспортировать ее в служба хранилища Azure при необходимости.

Примечание.

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

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

Используйте собственные метрики MySQL, чтобы узнать, превышает ли рабочая нагрузка размеры временных таблиц в памяти.

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

show global status like 'created_tmp_disk_tables';
show global status like 'created_tmp_tables';

Метрика created_tmp_disk_tables показывает, сколько таблиц было создано на диске. Учитывая рабочую нагрузку, created_tmp_table метрика сообщает, сколько временных таблиц должно быть сформировано в памяти. Чтобы определить, использует ли конкретный запрос временные таблицы, выполните инструкцию EXPLAIN в запросе. Подробные сведения в столбце extra указывают, Using temporary выполняется ли запрос с помощью временных таблиц.

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

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

В идеале этот процент должен быть меньше 25 %. Если процент равен 25% или больше, рекомендуется изменить два параметра сервера, tmp_table_size и max_heap_table_size.

Схема базы данных и запросы

Ниже приведены несколько советов, которые следует помнить при создании схемы базы данных и запросов.

Использование правильного типа данных для столбцов таблицы

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

Использование индексов

Во избежание снижения производительности при обработке запросов можно использовать индексы. Индексы позволяют быстро находить строки с конкретными столбцами. См. статью Использование индексов в MySQL.

Использование инструкции EXPAIN для запросов SELECT

Используйте инструкцию EXPLAIN, чтобы получить подробные сведения о том, какие операции MySQL выполняет в ходе обработки запроса. Это позволит выявить узкие места и определить проблемы с обработкой запроса. См. раздел Использование инструкции EXPLAIN для профилирования производительности запросов.

Share via