Рекомендации по архитектуре Azure Database for MySQL

Известные проблемы и ограничения служб, которые могут повлиять на надежность: Гибкий сервер Azure Database for MySQL имеет ограничения, влияющие на надежность. Просмотрите эти ограничения перед подготовкой серверов, чтобы избежать повторного создания сервера. Подтвердите требования высокой доступности с избыточностью между зонами и метод подключения к сети при создании, так как эти параметры невозможно изменить позже.

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

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

Реализуйте избыточность с помощью конфигураций высокого уровня доступности: Используйте конфигурацию высокого уровня доступности для распределения компонентов базы данных между доменами сбоя и устранения отдельных точек сбоя. Развертывание зоны с избыточной высокой доступностью для размещения основных и резервных серверов в разных зонах доступности, использующих зонально-избыточное хранилище (ZRS), которое обеспечивает автоматическое переключение в течение 60–120 секунд и с нулевым RPO для подтвержденных транзакций.

Учитывайте высокую доступность в пределах одной зоны, если рабочая нагрузка допускает риск на уровне зоны или ориентируется на оптимизацию затрат с использованием локально избыточного хранилища (LRS). Этот параметр защищает от сбоев на уровне сервера, но не от сбоев зон.

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

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

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

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

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

Отслеживайте индикаторы насыщенности ресурсов для вычислений, памяти, хранилища и ввода-вывода (I/O) для выявления нагрузки на емкость. Отслеживайте активные подключения относительно ограничений подключения, чтобы предотвратить исчерпание и отслеживать прерывание подключений для обнаружения проблем с подключением.

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

Применение методов настройки и самосохранения для защиты от сбоев: Применение мер по настройке базы данных и защите платформы для повышения устойчивости резервного копирования и предотвращения дрейфа конфигурации.

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

• Настройте логику повторных попыток подключения на уровне доступа к данным для обработки кратких перебоев во время плановой замены на резервные системы, обслуживания и увеличения систем. Учитывайте задержку распространения системы доменных имен (DNS) после переключения на резервный сервер, настраивая приложения для повторной попытки восстановления прерванных подключений.

• Примените блокировки ресурсов Azure и Azure Policy для защиты от смещения конфигурации.

Создайте стратегию аварийного восстановления, которая включает возможности резервного копирования и геоизбыточности: Определите, как резервное копирование, геоизбыточное и межрегионное восстановление используются для соответствия требованиям RPO и времени восстановления (RTO).

• Задайте частоту автоматического резервного копирования и периоды хранения для достижения RPO рабочей нагрузки. Настройте интервалы резервного копирования для ускорения восстановления больших баз данных.

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

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

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

Используйте встроенные определения Azure Policy для применения элементов управления ключами, включая использование частной конечной точки, принудительное применение протокола SSL, шифрование ключей, управляемое клиентом, и проверку подлинности Microsoft Entra. Примените эти политики для проверки соответствия конфигурации в экземплярах сервера.

Сегментирование доступа с помощью управления доступом на основе ролей (RBAC): Настройте многоуровневый контроль доступа на уровне управления и плоскостей данных, чтобы обеспечить минимальный доступ к привилегиям и ограничить доступ администратора.

• Используйте Azure RBAC для управления операциями в области управления и собственными привилегиями MySQL для управления операциями в плоскости данных. Гибкий сервер не поддерживает Azure RBAC для доступа к каналу данных.

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

• Ограничьте конфигурацию администратора Microsoft Entra одной на экземпляр сервера и зарезервируйте учетную запись администратора сервера только для аварийного доступа. Используйте Customer Lockbox для управления доступом службы поддержки Microsoft во время обращений в службу поддержки.

Централизируйте управление удостоверениями с помощью Microsoft Entra ID: Microsoft Entra-идентификация полностью исключает потребность в доступе на основе паролей. Настройте приложения для проверки подлинности с использованием краткосрочных токенов через управляемые удостоверения или служебные принципалы. Назначьте пользовательское управляемое удостоверение и определите администратора Microsoft Entra для каждого экземпляра сервера. Каждый сервер поддерживает только одного администратора.

Используйте объединенную проверку подлинности MySQL и Microsoft Entra для поддержки постепенной миграции с пароля на доступ на основе маркеров. Запланируйте график перехода на режим только для Microsoft Entra после миграции всех подключений, так как аутентификация только MySQL не имеет централизованного управления идентификацией.

Ограничить доступ к сети с помощью элементов управления подключениями: Используйте интеграцию виртуальной сети, чтобы внедрить сервер в управляемую клиентом виртуальную сеть с частным IP-адресом в делегированной подсети, что устраняет уязвимость к общедоступному Интернету. Настройте необходимое делегирование подсети перед развертыванием и примените правила группы безопасности сети (NSG) для управления потоком трафика.

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

Шифрование неактивных и передаваемых данных: Защита хранимых данных и сетевого трафика с помощью механизмов шифрования как для неактивных, так и для транзитных сценариев.

• Шифрование неактивных данных использует ключи, управляемые платформой, по умолчанию для всех сохраненных данных, резервных копий и журналов транзакций. Используйте управляемые клиентом ключи с помощью Azure Key Vault или Azure Key Vault управляемого устройства HSM для дополнительного контроля над жизненным циклом ключа.

• Применение протокола TLS 1.2 по умолчанию и использование TLS 1.3 в MySQL 8.0 и более поздних версий для более надежной безопасности. Задайте параметр для управления принудительным применением TLS. Наборы шифров, совместимые с федеральными стандартами обработки информации (FIPS), применяются автоматически.

• Доверять только корневым центрам сертификации (ЦС) в конфигурациях клиентов, чтобы избежать сбоев подключения. Azure управляет сертификатами сервера с помощью корневого ЦС DigiCert Global Root G2 и корневого ЦС Microsoft RSA Root CA 2017. Промежуточные обновления центров сертификации обычно выполняются без объявления.

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

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

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

• Используйте проверку удостоверения личности с помощью удостоверений управляемых Microsoft Entra ID, чтобы заменить статические пароли краткосрочными токенами. Задайте строки подключения, используя проверку подлинности Microsoft Entra, чтобы избежать использования встроенных паролей.

• Сохраните оставшиеся пароли собственной проверки подлинности MySQL, включая пароль администратора сервера от подготовки, в Key Vault и примените ограниченный доступ.

• Внимательно отслеживайте Key Vault доступ при использовании шифрования ключей, управляемых клиентом, так как потеря доступа делает сервер недоступным в течение 10 минут. Создайте оповещения для Key Vault сбоев доступа или событий удаления ключей и сохраняйте резервные копии ключей с помощью документированных процедур восстановления.

Включите ведение журнала мониторинга безопасности и аудита: Используйте журналы аудита для отслеживания событий подключения, операций администрирования, языка определения данных (DDL) и инструкций языка обработки данных (DML) и доступа к таблицам. Включите параметр сервера и выберите типы событий в зависимости от требований безопасности.

Маршрутизация журналов аудита в Azure Monitor с помощью параметров диагностики для назначений Log Analytics, Azure Event Hubs или Azure Storage. Используйте встроенную книгу аудита для визуализации событий безопасности и создайте оповещения для необычных шаблонов подключений и неудачных попыток проверки подлинности.

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

• Сравните цены на оплату по мере использования, которые почасово взимается за вычислительные ресурсы и за гигабайт (ГБ) для хранения с зарезервированными экземплярами, которые предлагают скидки на более длительные сроки. Учет затрат на вычисления, которые значительно различаются на разных уровнях. Наиболее экономичный вариант — это облачные вычисления с возможностью временного увеличения производительности, а оптимизированный для памяти вариант — самый дорогой.

• Следует понимать, что плата за хранение взимается за ГБ в месяц и может увеличиваться в объеме только после создания ресурсов. Первоначальные решения по размеру влияют на долгосрочные затраты.

• Ожидается, что HA удвоит затраты на вычисления, так как он развертывает резервную реплику с выделенным хранилищем и вычислениями. При чтении реплики взимается независимая плата за те же тарифы, что и сервер-источник.

• Вычислите затраты на хранилище резервных копий. Хранилище резервных копий предоставляется бесплатно до 100% выделенного объема хранилища сервера, но стоимость геоизбыточного резервного копирования вдвое выше по сравнению с локально избыточным. Учтите дополнительные затраты на функции, которые варьируются в зависимости от уровня и конфигурации HA (высокой доступности).

Метрики затрат базы данных и тенденции расходов с использованием Azure Monitor: Используйте метрики Azure Monitor для получения видимости использования вычислительных ресурсов, потребления хранения, использования операций ввода-вывода в секунду и хранилища резервных копий, которые напрямую связаны с затратами на обслуживание.

Отслеживайте процент загрузки ЦП и использование памяти, чтобы определить избыточно снабженные серверы, которые последовательно работают ниже полной загрузки. Просмотрите метрики использования операций ввода-вывода, чтобы оценить, соответствует ли текущая модель операций ввода-вывода фактическим шаблонам потребления. Анализ шаблонов использования с течением времени, чтобы определить кандидатов для покупок зарезервированных экземпляров или изменений уровня.

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

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

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

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

• Задайте для хранения резервных копий минимальный период, соответствующий требованиям восстановления. Этот параметр сводит к минимуму затраты на хранилище резервных копий за пределы бесплатного пособия. Используйте локально избыточное хранилище резервных копий для рабочих нагрузок, которым не требуется гео-катастрофическое восстановление. Географически резервируемое хранилище удваивает затраты.

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

• Сравните цены на создание оборудования в разных регионах. Один и тот же уровень может иметь разные затраты в зависимости от того, какие поколения доступны в каждом регионе.

Установите контроль расходов для ресурсов базы данных: Используйте Azure Policy, RBAC и управление бюджетом, чтобы внедрить механизмы контроля, которые предотвращают дорогостоящие конфигурации баз данных и несанкционированные изменения ресурсов.

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

Следите за событиями автоматического расширения хранилища и автоматическим масштабированием операций ввода-вывода в секунду (IOPS), которые могут привести к увеличению затрат без явного действия пользователя. Отслеживайте создание и настройку реплик чтения и изменения в конфигурации, которые вводят независимое выставление счетов за вычислительные ресурсы и хранилище.

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

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

• Используйте бесплатный уровень для проверки концепции и начальной разработки. Уменьшите срок хранения резервных копий до 1–7 дней и выберите локально избыточное хранилище резервных копий для непроизводственных сред.

• Разверните серверы разработки в экономически эффективных регионах, если требования к размещению данных позволяют.

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

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

Разверните реплики для чтения для аналитических и отчетных рабочих нагрузок вместо создания отдельных серверов. Размер вычислений реплики чтения независимо от сервера-источника для соответствия фактическим требованиям к рабочей нагрузке чтения. Уровень с возможностью скачкообразного увеличения не поддерживает реплики чтения, поэтому используйте уровни "Общего назначения" или "Оптимизированные для памяти". Чтение реплик тарифицируется отдельно как за вычисления, так и за хранение.

Определите инфраструктуру сервера с помощью шаблонов кода: Используйте инфраструктуру как код (IaC) через шаблоны Azure Resource Manager (шаблоны ARM), Bicep, Terraform или Azure CLI для декларативного гибкого предоставления сервера.

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

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

• Разверните сетевые ресурсы перед созданием сервера при использовании интеграции виртуальной сети, затем настройте параметры диагностики и RBAC на последующих этапах.

• Настройте обнаружение смещения, чтобы определить параметры, измененные вручную через портал, а не через рабочие процессы IaC.

Автоматизация развертываний схемы базы данных в конвейерах: Интеграция изменений схемы базы данных в конвейеры развертывания с помощью скриптов миграции с возможностями проверки и отката. Используйте такие средства, как Flyway, Liquibase или пользовательские скрипты для изменений схемы управления версиями и применяйте их с помощью этапов конвейера CI/CD.

Включите проверку предварительной подготовки для проверки несовместимых операций GTID при выборе серверов с поддержкой высокого уровня доступности. Серверы с поддержкой высокой доступности не поддерживают такие инструкции. Тестирование изменений схемы на тестовых серверах с использованием уровня "Burstable" чтобы снизить затраты и проверить совместимость.

Настройка мониторинга и ведения журнала: настройка интеграции Azure Monitor для сбора метрик, журналов ресурсов, параметров диагностики и шаблонов книг для оперативной видимости. Собирать метрики платформы для ЦП, памяти, хранилища, операций ввода-вывода, подключений и задержки репликации с частотой в одну минуту и хранением данных в течение 30 дней.

Сбалансируйте уровень детализации журналов с воздействием на производительность, так как подробное ведение журнала влияет на пропускную способность сервера. Настройте функцию журналов сервера для краткосрочного файлового доступа вместе с диагностическими параметрами для долгосрочного анализа данных. Планирование маршрутизации журналов в Центры событий для интеграции сведений о безопасности и управлении событиями (SIEM) или Azure Storage для архивации соответствия требованиям.

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

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

• Перепланируйте события обслуживания, когда они конфликтуют с критическими бизнес-периодами. Поддержку этого функционала обеспечивают только уровни общего назначения и оптимизированные для памяти. Настройте Azure Service Health оповещения для получения уведомлений о событиях обслуживания и инцидентах службы.

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

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

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

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

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

Автоматизируйте задачи управления и мониторинга: Используйте встроенные функции автоматизации и интеграцию с Azure Monitor для уменьшения операционных затрат. Настройте автоматические резервные копии с настраиваемыми интервалами и периодами хранения для обслуживания RPOS. Периодически проверяйте рекомендации Azure Advisor по оптимизации производительности, надежности и стоимости.

Автоматизация управления конфигурацией с помощью скриптов Azure CLI или REST API для применения согласованных конфигураций параметров сервера между парками серверов. Настройте автоматические проверки соответствия для сравнения текущих параметров с базовыми конфигурациями и обнаружения смещения. Планирование резервных копий по запросу с помощью автоматизации до запланированных операций обслуживания или изменений.

Планирование емкости: Ваши решения по вычислительным ресурсам, хранению и IOPS (операциям ввода-вывода в секунду) определяют максимальную производительность. Запустите планирование емкости для оценки потребностей виртуальных ядер и памяти на основе сложности запросов, одновременных подключений и типа рабочей нагрузки. Учитывайте распределение памяти в буферном пуле InnoDB, которое зависит от размера вычислительных ресурсов и определяет эффективность кэширования. Кроме того, учитывайте пределы, зависящие от объёма доступной памяти.

Оценка роста хранилища. Вы можете масштабировать только выделение, а не уменьшить его. Вычисляйте требования к операциям ввода-вывода в секунду на основе соотношения операций чтения и записи, объема транзакций и пиковых требований. Используйте метрики "Процент операций ввода-вывода в хранилище " и "Число операций ввода-вывода в хранилище ", чтобы определить базовые шаблоны использования.

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

Выберите уровни вычислительных ресурсов и номера SKU на основе требований к производительности: В Azure Database for MySQL предлагается три уровня вычислительных ресурсов, которые имеют различные особенности производительности и функций. Соответствие выбора уровня требованиям к производительности рабочей нагрузки, требованиям к масштабируемости и зависимостям компонентов.

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

• Выберите оптимизированный для памяти уровень, если рабочие нагрузки требуют более высоких соотношений памяти к vCore для сценариев, зависящих от кэша, и сценариев с высокой степенью параллелизма. Этот уровень обеспечивает наименьшую задержку и самые высокие запросы в секунду (QPS). Используйте этот уровень для рабочих нагрузок с интенсивным объемом памяти, имеющих большие рабочие наборы или требования с высоким параллелизмом.

• Ограничьте уровень "Ускорение" средам разработки и тестирования, так как модель кредита ЦП регулируется при устойчивой нагрузке. Этот уровень не поддерживает HA, реплики чтения или ускоренные журналы, что соответствует требованиям непроизводственной среды.

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

Определите стратегию масштабирования: Планирование изменений уровня вычислений для периодов низкого трафика. Для этих изменений требуется перезапуск сервера, который занимает 60–120 секунд, что приводит к краткому нарушению рабочей нагрузки. Подключите увеличение хранилища онлайн, но помните, что уменьшить его выделение невозможно. Используйте автомасштабирование операций ввода-вывода для автоматического масштабирования операций ввода-вывода в зависимости от спроса без вмешательства вручную.

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

Мониторинг метрик производительности базы данных: Отслеживайте процент ЦП, процент памяти и процент операций ввода-вывода в хранилище , чтобы определить насыщенность ресурсов, прежде чем он влияет на производительность запросов. Отслеживайте метрики буферного пула InnoDB, например , и коэффициенты запросов чтения для измерения эффективности кэша и давления памяти.

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

Используйте метрики Azure Monitor, журналы медленных запросов и рабочую тетрадь Query Performance Insight для анализа на уровне запросов. Используйте Log Analytics для анализа исторических тенденций с помощью запросов Kusto.

Выполните тестирование производительности: Создайте рабочие нагрузки нагрузочного теста, которые отражают рабочие шаблоны запросов, включая коэффициенты чтения и записи, сложности транзакций и уровни параллелизма. Включите имитацию пиковых периодов, чтобы проверить поведение IOPS автоматического масштабирования и запас вычислительных ресурсов. Используйте объемы данных, представляющие рабочие среды, в тестах, поскольку производительность буферного пула InnoDB и планы запросов зависят от размера данных.

Тестирование масштабирования уровней вычислений для измерения длительности перезапуска и поведения повторного подключения приложений. Имитация задержки реплики чтения при загрузке и проверка активации автоматического увеличения хранилища. Сбор основных метрик по задержке запросов, пропускной способности, потреблению операций ввода-вывода в секунду (IOPS) и количеству подключений для сравнения настроек IOPS и выявления проблем с оценкой размера кэша во время роста.

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

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

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

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