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

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для MySQL — гибкий сервер

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

Внимание

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

Примечание.

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

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

Следующие шаги