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


Рекомендации по работе с серверами на База данных 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 таблиц или более.