Рекомендации по работе с серверами на База данных Azure для MySQL — гибкий сервер
Узнайте о рекомендациях по работе с гибким сервером База данных Azure для MySQL. При добавлении новых возможностей на платформу мы продолжаем сосредоточиться на уточнении рекомендаций, описанных в этом разделе.
База данных Azure для MySQL рекомендации по работе гибкого сервера
Ниже приведены операционные рекомендации, которые следует соблюдать при работе с База данных Azure для MySQL гибким сервером для повышения производительности базы данных:
Совместное расположение. Чтобы уменьшить задержку в сети, разместите клиент и сервер базы данных в одном регионе Azure.
Отслеживайте использование памяти, ЦП и хранилища. Вы можете настроить оповещения, чтобы уведомить вас об изменении шаблонов использования или при подходе к емкости развертывания, чтобы обеспечить производительность системы и доступность.
Ускоренные журналы для повышения производительности. Включение функции ускорения журналов оптимизирует операции, связанные с транзакциями, повышая пропускную способность сервера и производительность. Эта функция, доступная без дополнительных затрат, является значительным дополнением к операционным рекомендациям для пользователей уровня служб критически важный для бизнеса.
Увеличение масштаба экземпляра базы данных. Вы можете увеличить масштаб при приближении ограничений емкости хранилища. У вас должен быть определенный буфер в хранилище и памяти, чтобы адаптироваться к непредвиденному увеличению спроса со стороны ваших приложений. Можно также включить функцию автоувеличения размера хранилища, чтобы служба автоматически масштабировала хранилище по мере приближения к его ограничениям.
Настройка резервного копирования: включите локальные или геоизбыточные резервные копии в зависимости от требований бизнеса. Кроме того, вы можете изменить период хранения резервных копий, чтобы обеспечить непрерывность бизнес-процессов.
Оптимизация емкости ввода-вывода с помощью автомасштабирования операций ввода-вывода. Если для рабочей нагрузки базы данных требуется больше операций ввода-вывода, чем подготовлено, восстановление или другие операции транзакций для базы данных будут медленными. Чтобы увеличить емкость ввода-вывода экземпляра сервера, сделайте следующее:
Используйте функцию автомасштабирования операций ввода-вывода: автомасштабирование операций ввода-вывода в секунду устраняет необходимость предварительной подготовки определенного количества операций ввода-вывода в секунду. Вместо этого сервер позволяет серверу автоматически настраивать операции ввода-вывода в секунду на основе требований рабочей нагрузки1. Это означает, что сервер может автоматически увеличивать или уменьшать число операций ввода-вывода в секунду в зависимости от потребностей рабочей нагрузки.
База данных Azure для MySQL Гибкий сервер обеспечивает масштабирование операций ввода-вывода в секунду в секунду с частотой трех операций ввода-вывода в секунду на подготовленное хранилище в ГБ. Увеличьте подготовленное хранилище, чтобы масштабировать операции ввода-вывода для повышения производительности.
Если вы уже используете подготовленное хранилище операций ввода-вывода в секунду, подготовьте дополнительную пропускную способность.
Масштабирование вычислительных ресурсов: рабочая нагрузка базы данных также может быть ограничена из-за ЦП или памяти, и это может серьезно повлиять на обработку транзакций. Вычислительные ресурсы (ценовая категория) можно масштабировать только между уровнями общего назначения или оптимизированной для памяти.
Тестирование для отработки отказа: вручную протестируйте отработку отказа для экземпляра сервера, чтобы понять, как долго длится процесс в случае вашего варианта использования, и убедитесь, что приложение, которое обращается к экземпляру сервера, может автоматически подключаться к новому экземпляру сервера после отработки отказа.
Используйте первичный ключ: убедитесь, что таблицы имеют первичный или уникальный ключ при работе с экземпляром гибкого сервера База данных Azure для MySQL. Это очень помогает создавать резервные копии, реплики и т. д., а также повышать производительность.
Настройка значения TTL: если клиентское приложение кэширует данные службы доменных имен (DNS) экземпляров сервера, выберите значение срока жизни (TTL) менее 30 секунд. Поскольку базовый IP-адрес экземпляра сервера может измениться после отработки отказа, длительное кэширование данных DNS может привести к сбоям подключения, если приложение попытается подключиться к IP-адресу, который больше не работает.
Используйте пул соединений во избежание превышения максимального числа подключений, и используйте логику повторных попыток во избежание периодических проблем с подключением.
При использовании реплики используйте ProxySQL для балансировки нагрузки между основным сервером и сервером вторичной реплики. Здесь см. этапы настройки.
При подготовке ресурса убедитесь, что вы включили автоматическое увеличение для экземпляра База данных Azure для MySQL гибкого сервера. Это не добавляет никаких дополнительных затрат и защищает базу данных от каких-либо узких мест хранилища, с которыми вы можете столкнуться.
Использование InnoDB с гибким сервером База данных Azure для MySQL
Если используется
ibdata1
функция, то это системный файл данных табличного пространства не может сжиматься или очищаться путем удаления данных из таблицы или перемещения таблицы в файл для каждой таблицыtablespaces
.Если размер базы данных составляет более 1 ТБ, следует создать таблицу в табличном пространстве innodb_file_per_table
tablespace
. Если размер одной таблицы превышает 1 ТБ, следует создать таблицу разделов.Для сервера, имеющего большое количество
tablespace
, запуск подсистемы очень медленный из-за последовательной проверки пространства таблиц во время запуска или отработки отказа гибкого сервера База данных Azure для MySQL.Присвойте "innodb_file_per_table" значение "ON" перед созданием таблицы, если общее число таблиц меньше 500.
Если в базе данных более 500 таблиц, проверьте размер каждой отдельной таблицы. Если таблица большая, следует рассмотреть возможность использования табличного пространства "file-per-table", чтобы избежать превышения максимального размера файла хранилища для системных табличных пространств.
Примечание.
В случае таблиц, размер которых меньше 5 ГБ, можно использовать системное табличное пространство.
CREATE TABLE tbl_name ... *TABLESPACE* = *innodb_system*;
Секционирование таблицы при создании таблицы, если у вас может быть большая таблица, возможно, превысит 1 ТБ.
Используйте несколько экземпляров гибкого сервера База данных Azure для MySQL и распределяйте таблицы между этими серверами. Избегайте размещения слишком большого количества таблиц на одном сервере, если у вас есть около 10 000 таблиц или более.