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

Запланированное обслуживание в База данных Azure для MySQL — гибкий сервер

  • Статья

База данных Azure для MySQL Гибкий сервер выполняет периодическое обслуживание для обеспечения безопасности, стабильной и актуальности управляемой базы данных. В процессе обслуживания сервер получает новые возможности, обновления и исправления.

Внимание

Избегайте всех операций сервера (изменений, изменений конфигурации, запуска и остановки сервера) во время обслуживания гибкого сервера База данных Azure для MySQL. Участие в этих действиях может привести к непредсказуемым результатам, что может повлиять на производительность сервера и стабильность. Дождитесь завершения обслуживания перед выполнением операций сервера.

Цикл обслуживания

Плановое обслуживание

Наш стандартный цикл обслуживания планируется не менее часто, чем каждые 30 дней. Этот период позволяет обеспечить стабильность системы и производительность при минимизации нарушений работы служб.

Критическое обслуживание

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

Обслуживание виртуальных канарий (общедоступная предварительная версия)

Virtual Canary — это экспериментальная программа обслуживания, предлагающая ранний доступ к обновлениям, что позволяет клиентам тестировать совместимость рабочей нагрузки с новыми версиями Azure MySQL. В отличие от планового обслуживания, Виртуальный канарий не соответствует минимальному интервалу в 30 дней или 7-дневному периоду уведомлений. Эта программа помогает клиентам заранее проверять новые функции и вносить ранние отзывы о улучшениях продукта. Серверы SKU, которые обычно используются для непроизводственных сред, автоматически регистрируются в программе Virtual Canary.

Управление регистрацией виртуальных канарий

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

  • Проверка регистрации виртуальных канарий

Чтобы проверить, зарегистрирован ли сервер в программе Virtual Canary, выполните следующую команду:

az mysql flexible-server show --resource-group {resourcegroupname} --name {servername} --query "maintenancePolicy"

Если результат включает в себя "patchStrategy": "VirtualCanary", сервер регистрируется в программе Virtual Canary.

  • Регистрация в Виртуальном канарии

Чтобы зарегистрировать сервер в программе 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 MySQL использует определенные критерии, чтобы определить, какие серверы требуют обслуживания. Этот выборочный подход гарантирует, что обслуживание является эффективным и важным, адаптированным к уникальным потребностям каждой среды сервера, и свести к минимуму время простоя рабочей среды.

Выбор периода обслуживания

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

Уведомления о предстоящем плановом техническом обслуживании можно передавать следующими способами:

  • по электронной почте на определенный адрес;
  • электронного письма, отправляемого роли Azure Resource Manager;
  • текстового сообщения (SMS), отправляемого на мобильные устройства;
  • уведомления в приложении Azure;
  • голосового сообщения.

При настройке расписания обслуживания можно выбрать день недели и временной интервал. Если этого не сделать, система будет выбирать время с 23:00 до 7:00 в регионе сервера. Вы можете определить разные расписания для каждого гибкого сервера в подписке Azure.

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

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

  • С помощью пользовательского расписания можно указать период обслуживания для сервера, выбрав день недели и временное окно длительностью один час.
  • При использовании расписания, управляемого системой, система выберет любое временное окно между 23:00 и 7:00 в регионе сервера.

Внимание

Начиная с 31 августа 2024 г. База данных Azure для MySQL больше не будет поддерживать пользовательские периоды обслуживания для экземпляров SKU с возможностью ускорения. Это изменение обусловлено необходимостью упрощения процессов обслуживания, обеспечения оптимальной производительности и нашего анализа, указывающего, что количество пользователей, использующих пользовательские окна обслуживания на пикируемых номерах SKU, минимально. Существующие экземпляры СKU с настраиваемыми конфигурациями периода обслуживания останутся не затронутыми; однако пользователи не смогут изменять эти параметры пользовательского периода обслуживания вперед.

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

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

Почти нулевое обслуживание простоя (общедоступная предварительная версия)

функция База данных Azure для MySQL гибкого сервера "Почти нулевое время простоя" — это неразрывная разработка для разработкиСерверы с поддержкой высокого уровня доступности. Эта функция предназначена для существенного уменьшения времени простоя обслуживания, что в большинстве случаев время простоя обслуживания, как ожидается, составляет от 40 до 60 секунд. Эта возможность является ключевой для предприятий, требующих высокой доступности и минимального прерывания работы с базами данных.

Точные ожидания простоя

  • Длительность простоя: в большинстве случаев время простоя во время обслуживания составляет от 10 до 30 секунд.
  • Дополнительные рекомендации. После события отработки отказа существует встроенный период времени жизни DNS (TTL) примерно в 30 секунд. Этот период не контролируется непосредственно процессом обслуживания, но является стандартной частью поведения DNS. Таким образом, с точки зрения клиента, общее время простоя, переживаемое во время обслуживания, может находиться в диапазоне от 40 до 60 секунд.

Ограничения и предварительные требования

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

  • Первичные ключи во всех таблицах: убедитесь, что каждая таблица имеет первичный ключ. Отсутствие первичных ключей может значительно увеличить задержку репликации, влияя на время простоя.
  • Низкая рабочая нагрузка во время обслуживания: периоды обслуживания должны совпадать с временем низкой рабочей нагрузки на сервере, чтобы обеспечить минимальное время простоя. Мы рекомендуем использовать настраиваемую функцию периода обслуживания для планирования обслуживания в нерабочие часы.
  • Гарантии простоя: хотя мы стремимся сохранить время простоя обслуживания как можно меньше, мы не гарантируем, что это всегда будет менее 60 секунд во всех обстоятельствах. Различные факторы, такие как высокая рабочая нагрузка или определенные конфигурации сервера, могут привести к длительному простою. В худшем случае простой может быть похож на автономный сервер.

Перепланируйте обслуживание

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

Перепланируйте параметры и уведомления

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

Рекомендации и ограничения

При использовании этой функции следует учитывать следующее:

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

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

Примечание.

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

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

Вопросы и ответы

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

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

Вопрос. Почему некоторые серверы в том же регионе получают уведомления об обслуживании, а другие не?

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

Вопрос. Можно ли отказаться от планового обслуживания?

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

Связанный контент