Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
База данных Azure для MySQL выполняет периодическое обслуживание, чтобы обеспечить безопасность, стабильность и актуальность управляемой базы данных. В процессе обслуживания сервер получает новые возможности, обновления и исправления.
Внимание
Избегайте всех операций сервера (изменений, изменений конфигурации, запуска и остановки) во время обслуживания Базы данных Azure для MySQL. Участие в этих действиях может привести к непредсказуемым результатам, которые могут повлиять на производительность сервера и стабильность. Дождитесь завершения обслуживания перед выполнением операций сервера.
Цикл обслуживания
В следующих разделах описаны типы обслуживания. Дополнительные сведения о том, что влечет за собой каждое обновление обслуживания, см. в заметках о выпуске. Эти заметки предоставляют исчерпывающую информацию об обновлениях, применяемых во время обслуживания, чтобы вы могли понять и подготовиться к любым изменениям, влияющим на вашу среду.
Примечание.
Не все серверы обязательно проходят обслуживание во время запланированных обновлений, будь то стандартные или критически важные. Команда Azure MySQL использует определенные критерии, чтобы определить, какие серверы требуют обслуживания. Этот выборочный подход гарантирует, что обслуживание является эффективным и важным, адаптировано к уникальным потребностям каждой серверной среды и сводит к минимуму время простоя в рабочей среде.
Плановое обслуживание
Наш стандартный цикл обслуживания проводится не реже, чем каждые 30 дней. Этот период помогает обеспечить стабильность системы и производительность при минимизации нарушений работы служб.
Критическое обслуживание
В некоторых сценариях, таких как необходимость развертывания срочных исправлений безопасности или обновлений, критически важных для поддержания доступности и целостности данных, мы можем проводить обслуживание чаще. Эти исключения помогают защитить данные и обеспечить непрерывную работу служб.
Обслуживание виртуальной канарейки
Virtual Canary — это экспериментальная программа обслуживания, которая предлагает ранний доступ к обновлениям. Он позволяет клиентам тестировать совместимость рабочей нагрузки с новыми версиями Базы данных Azure для MySQL и предоставлять отзывы о новых функциях.
В отличие от планового обслуживания, Виртуальный канарий не следует минимальному интервалу в 30 дней или 7-дневному периоду уведомления. Эта программа помогает клиентам заранее проверять новые функции и вносить ранние отзывы о улучшениях продукта. Высокоуровневые серверы, часто используемые для непроизводственных сред, автоматически регистрируются в программе Virtual Canary.
Регистрация виртуальных канарий
База данных Azure для MySQL обеспечивает гибкость для клиентов для управления их участием в программе Virtual Canary. Клиенты могут присоединяться к программе или выходить из нее по мере необходимости в соответствии с их операционными требованиями.
Чтобы проверить, зарегистрирован ли сервер в программе Virtual Canary, выполните следующую команду. Если результат включает в себя "patchStrategy": "VirtualCanary"
, сервер регистрируется в программе.
az mysql flexible-server show --resource-group {resourcegroupname} --name {servername} --query "maintenancePolicy"
Чтобы зарегистрировать сервер в программе Virtual Canary, выполните следующую команду:
az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy VirtualCanary
Чтобы оставить программу Virtual Canary и вернуться к стандартной политике обслуживания, используйте следующую команду:
az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy Regular
Окна обслуживания
Вы можете запланировать техническое обслуживание на определенный день недели и временное окно в течение этого дня. Кроме того, вы можете позволить системе автоматически выбирать день и период. В любом случае система оповещает вас семь дней до запуска любого обслуживания. Система также сообщает вам, когда начинается обслуживание и когда оно успешно завершается.
Уведомления о предстоящем плановом техническом обслуживании можно передавать следующими способами:
- Отправлено по электронной почте на определенный адрес.
- Отправлено по электронной почте роли Azure Resource Manager.
- Отправляется в текстовое сообщение (SMS) на мобильные устройства.
- Отправлено в качестве уведомления в приложение Azure.
- Доставлено в виде голосового сообщения.
При указании параметров расписания обслуживания можно выбрать день недели и период времени. Если вы не указываете параметры, система выбирает время от 11 вечера до 7 утра в регионе сервера. Вы можете определить разные расписания для каждого гибкого сервера в подписке Azure.
Вы можете обновить настройки расписания в любое время. Если обслуживание запланировано на гибкий сервер и вы обновляете параметры планирования, текущий выпуск выполняется по расписанию. Изменение параметров планирования становится эффективным после успешного завершения следующего запланированного обслуживания.
Вы можете определить управляемое системой расписание или пользовательское расписание для каждого гибкого сервера в подписке Azure:
- С помощью настраиваемого расписания можно указать период обслуживания сервера, выбрав день недели и одночасовое время.
- При использовании управляемого системой расписания система выбирает любое одночасовое окно с 11 вечера до 7 утра по времени региона вашего сервера.
Внимание
По состоянию на 31 августа 2024 г. База данных Azure для MySQL больше не поддерживает настройку окон обслуживания для Burstable-экземпляров. Это изменение помогает упростить процессы обслуживания и обеспечить оптимальную производительность. Кроме того, наш анализ показал, что количество пользователей, использующих пользовательские окна обслуживания на уровнях с функцией повышения производительности, минимально.
Существующие экземпляры Burstable-уровня с пользовательскими окнами обслуживания не затрагиваются. Однако пользователи больше не могут изменять эти параметры для пользовательских окон обслуживания.
Для клиентов, которым требуется пользовательское обслуживание, рекомендуется обновить до уровня "Общего назначения" или "Критически важный для бизнеса".
В редких случаях событие обслуживания может быть отменено системой или может не завершиться успешно. Если событие обслуживания завершается неудачей, обновление отменяется, а предыдущая версия двоичных файлов восстанавливается. В сценариях неудачных обновлений может по-прежнему возникать перезагрузка сервера во время периода обслуживания.
Если событие обслуживания отменено или завершается сбоем, система отправляет уведомление. Следующая попытка выполнить обслуживание запланирована в соответствии с текущими параметрами. Вы получите уведомление о следующей попытке пять дней заранее.
Техническое обслуживание с минимальным простоем (предварительная версия)
Функция обслуживания с минимальным простоем в базе данных Azure для MySQL — это передовое новшество для серверов высокой доступности. Эта функция предназначена для существенного снижения простоя обслуживания. Эта возможность является ключевой для предприятий, требующих высокой доступности и минимального прерывания работы с базами данных.
Точные ожидания простоя
- Длительность простоя: в большинстве случаев время простоя во время обслуживания составляет от 10 до 30 секунд.
- Дополнительные рекомендации: После события переключения на резервный режим существует встроенный период времени жизни DNS (TTL) примерно в 30 секунд. Этот период не контролируется непосредственно процессом обслуживания, но является стандартной частью поведения DNS. Таким образом, с точки зрения клиента, общее время простоя во время обслуживания может составлять 40–60 секунд.
Условия и ограничения
Чтобы обеспечить оптимальную производительность, которую предлагает эта функция, обратите внимание на следующие условия и ограничения:
- Первичные ключи во всех таблицах: убедитесь, что каждая таблица имеет первичный ключ. Отсутствие первичных ключей может значительно увеличить задержку репликации и повлиять на время простоя.
- Низкая рабочая нагрузка во время обслуживания: периоды обслуживания должны совпадать с временем низкой рабочей нагрузки на сервере, чтобы свести к минимуму время простоя. Мы рекомендуем использовать настраиваемое время обслуживания для планирования обслуживания в нерабочие часы.
- Гарантии простоя: хотя мы стремимся сохранить время простоя обслуживания как можно меньше, мы не гарантируем, что это будет менее 60 секунд во всех обстоятельствах. Различные факторы, такие как высокая рабочая нагрузка или определенные конфигурации сервера, могут увеличить время простоя. В худшем случае простой может быть похож на автономный сервер.
Планирование обслуживания
Функция планирования обслуживания обеспечивает больший контроль над временем обслуживания на гибком сервере Базы данных Azure для MySQL. Получив уведомление об обслуживании, вы можете перепланировать его на более удобное время, независимо от того, было ли оно управляемым системой или пользовательским управляемым.
Используйте эту функцию, чтобы избежать сбоев во время критически важных операций базы данных. Мы рекомендуем вам поделиться своими отзывами, так как мы продолжаем разрабатывать эту функцию.
Перенос параметров и уведомлений
Перепланирование не ограничивается фиксированными интервалами времени. Это зависит от самых ранних и последних допустимых времен в текущем цикле обслуживания. Цикл обычно охватывает от первого дня до последнего дня периода обслуживания для региона. При повторном планировании вы получите уведомление для подтверждения изменений в соответствии со стандартными политиками уведомлений.
Рекомендации и ограничения
Помните о следующих аспектах функции:
- Доступность уровня: Планирование обслуживания недоступно для уровня Burstable compute. Эта функция предназначена для серверов в рабочей среде, тогда как Burstable уровень предназначен для нене производственных целей.
- Ограничения спроса: возможно отмена перепланированного обслуживания, если большое количество действий по обслуживанию происходит одновременно в одном регионе.
- Период блокировки: перепланировка недоступна за 15 минут до первоначально запланированного времени обслуживания, чтобы обеспечить надежность услуги.
- Регулирование перепланировки: если слишком много серверов в одном регионе запланировано на обслуживание в одно и то же время, запросы на перепланировку могут не удаваться. Если эта ошибка возникает, вы получите уведомление об ошибке, которое советует выбрать альтернативный интервал времени. Успешное перепланированное обслуживание вряд ли будет отменено.
Нет ограничений на то, сколько раз может быть перепланировано событие обслуживания. Если событие обслуживания не перешло в состояние подготовки, вы всегда можете перепланировать его на другое время.
Примечание.
Мы рекомендуем внимательно отслеживать уведомления на этапе предварительного просмотра, чтобы учесть потенциальные изменения.
Вопросы и ответы
Почему некоторые из моих серверов получили уведомления об обслуживании, а другие — нет?
Время начала обслуживания отличается от регионов. Серверы в разных регионах могут получать уведомления об обслуживании в разное время.
Почему некоторые серверы в том же регионе получили уведомления об обслуживании, а другие — нет?
Возможно, что серверы, которые не получили уведомления, были созданы в последнее время, и система определила, что они еще не нуждаются в обслуживании.
Можно ли отказаться от планового обслуживания?
Нет, отказ от запланированного обслуживания не допускается. Однако для настройки времени можно использовать функцию перепланирования обслуживания. Кроме того, можно включить функцию высокой доступности, чтобы свести к минимуму время простоя. Так как база данных Azure для MySQL — это платформа как услуга (PaaS), своевременное обслуживание помогает обеспечить безопасность и надежность базы данных.