Что проверить, если scale-down долго остаётся в Scaling и блокирует обновления: data plane против management plane, Resource Health, Activity Log, допустимое время и пакет Azure Support.
Разделите data plane и management plane
Статус Scaling относится к управляющей операции изменения ресурса. Microsoft отмечает, что сообщение о предыдущем update блокирует другие management operations, при этом cache может оставаться полностью доступным для client operations. Поэтому отдельно запишите результаты обычного health-check приложения, latency, error rate и состояние ресурса в портале. Не делайте вывод «Redis не работает» только по заблокированной кнопке Scale; и наоборот, успешный GET не доказывает завершение изменения инфраструктуры.
Не запускайте конкурирующие изменения
Пока масштабирование активно, не повторяйте scale, не меняйте networking, patch schedule, persistence и не инициируйте reboot в попытке разблокировать ресурс. Официальная документация указывает, что последующие management operations блокируются до завершения текущей. Параллельные действия не ускоряют перераспределение данных и усложняют Activity Log. Сохраните исходный SKU, целевой SKU, число shards, объём данных и время принятия первой операции, затем наблюдайте без новых мутаций.
Оцените ожидаемое время и риск данных
Microsoft пишет, что масштабирование зависит от объёма данных, интенсивности записи, загрузки и числа shards и может занимать часы. При scale-down Standard или Premium возможна потеря ключей, если данные не помещаются в меньший размер, поэтому до операции нужен запас ёмкости и понимание eviction policy. Не пытайтесь ускорить процесс удалением случайных ключей во время зависшего изменения. Сопоставьте метрики memory usage, server load и writes до начала с текущим состоянием, не раскрывая содержимое ключей.
Используйте порог Microsoft
Monitoring and troubleshooting FAQ указывает: текущая операция обычно завершается за несколько часов, а если сообщение о предыдущем update сохраняется более 12 часов, следует обращаться в Azure Support. До порога проверяйте Activity Log, Resource Health и Diagnose and solve problems. После порога не продолжайте ждать без обращения и не создавайте серию одинаковых запросов. Зафиксируйте, менялся ли provisioning state, но не трактуйте отсутствие нового Activity Log как доказательство потери данных.
Соберите пакет и план возврата
Закрытый запрос должен содержать timestamp UTC, регион, исходный и целевой SKU, shards, approximate used memory, нагрузку записи, operation ID, Activity Log, Resource Health, provisioning state и подтверждение клиентского health-check. Скрывайте keys, hostnames и access credentials. Критерий решения — статус Running, возможность выполнить read-only management query и стабильные клиентские метрики. После разблокировки сначала проверьте размер и данные, а уже затем планируйте следующее изменение. Отдельно учтите объявленный Microsoft переход с Azure Cache for Redis на Azure Managed Redis.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 29 июля 2026 года по обезличенному сигналу Microsoft Q&A и официальной документации Azure; ключи, хосты и данные кэша не использовались.
Источники и проверка
- Microsoft Learn — масштабирование Azure Cache for Redis проверено 2026-07-29
- Microsoft Learn — monitoring и troubleshooting Redis проверено 2026-07-29
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.