Устранение неполадок, связанных с потерей данных, в Кэше Azure для Redis
В этой статье описывается, как диагностировать фактические и предполагаемые потери данных, которые могут возникнуть в Кэше Azure для Redis.
Примечание
Шаги по устранению проблем в этой статье также включают в себя указания по выполнению команд Redis и мониторингу различных метрик производительности. Дополнительные сведения и указания см. в разделе Дополнительные сведения.
Частичная утрата ключей
Кэш Azure для Redis не удаляет ключи случайным образом, если они сохранены в памяти, Но может удалить ключи согласно политикам истечения срока действия, а также при получении явной команды удаления ключа. Эти команды можно выполнить в консоли или с помощью интерфейса командной строки.
Ключи, которые были записаны в первичный узел в экземпляре Кэша Azure для Redis ценовой категории "Премиум" или "Стандартный", также могут быть не сразу доступны в реплике. Данные реплицируются с первичного узла в реплику в асинхронном режиме и без блокировки.
Если вы обнаружите, что ключи исчезли из кэша, проверьте следующие возможные причины.
| Причина | Описание |
|---|---|
| Окончание срока действия ключей | Ключи удалены, так как для них задано истечение времени ожидания. |
| Вытеснение ключей | Ключи удалены из-за нехватки памяти. |
| Удаление ключей | Ключи удалены с помощью явных команд удаления. |
| Асинхронная репликация | Ключи недоступны в реплике из-за задержек репликации данных. |
Окончание срока действия ключа
Кэш Azure для Redis удаляет ключ автоматически, если этому ключу назначено время ожидания и этот период истек. Дополнительные сведения об окончании срока действия ключа Redis см. в документации по команде EXPIRE. Значения времени ожидания также можно задать с помощью SET, SETEX, GETSET и других команд *STORE.
Чтобы получить данные статистики о числе ключей с истекшим сроком действия, используйте команду INFO. В разделе Stats отображается общее число ключей с истекшим сроком действия. В разделе Keyspace содержатся дополнительные сведения о числе ключей с истекшим временем ожидания и средним значением времени ожидания.
# Stats
expired_keys:46583
# Keyspace
db0:keys=3450,expires=2,avg_ttl=91861015336
Вы также можете просмотреть метрики диагностики для кэша, чтобы определить, существует ли корреляция между моментом, когда пропал ключ, и увеличением числа ключей с истекшим сроком действия. Сведения об использовании уведомлений keyspace или команды для отладки проблем такого вида см. в приложении Отладка отсутствия данных в пространстве ключей RedisMONITOR.
Вытеснение ключей
Для хранения данных Кэшу Azure для Redis требуется определенный объем памяти. Он очищает ключи, если нужно освободить память. Когда значения used_memory или used_memory_rss в команде INFO приближаются к заданному значению параметра maxmemory, Кэш Azure для Redis начинает вытеснять ключи из памяти на основе политики кэша.
Количество вытесненных ключей можно отслеживать с помощью команды INFO.
# Stats
evicted_keys:13224
Вы также можете просмотреть метрики диагностики для кэша, чтобы определить, существует ли корреляция между моментом, когда пропал ключ, и увеличением числа вытесненных ключей. Сведения об использовании уведомлений пространства ключей или команды MONITOR для отладки проблем такого вида см. в приложении Отладка отсутствия данных в пространстве ключей Redis.
Удаление ключей
Клиенты Redis могут использовать команду DEL или HDEL, чтобы явно удалить ключи из Кэша Azure для Redis. Число операций удаления можно узнать с помощью команды INFO. Если были вызваны команды DEL или HDEL, они будут указаны в разделе Commandstats.
# Commandstats
cmdstat_del:calls=2,usec=90,usec_per_call=45.00
cmdstat_hdel:calls=1,usec=47,usec_per_call=47.00
Асинхронная репликация
Любой экземпляр Кэша Azure для Redis ценовой категории "Стандартный" или "Премиум" настраивается с первичным узлом и по крайней мере одной репликой. Данные копируются с первичного узла в реплику асинхронно с помощью фонового процесса. На веб-сайте redis.io описано, как работает репликация данных Redis в целом. Если клиенты часто записывают данные в Redis, может произойти частичная утрата данных, так как мгновенное выполнение репликации не гарантируется. Например, если первичный узел отключается после того, как клиент записывает в него ключ, но до того, как фоновый процесс отправит этот ключ в реплику, ключ будет потерян в момент, когда реплика станет новым первичным узлом.
Значительная или полная утрата ключей
Если вы обнаружите, что большинство ключей или все ключи исчезли из кэша, проверьте следующие возможные причины.
| Причина | Описание |
|---|---|
| Очистка ключей | Ключи были очищены вручную. |
| Неправильный выбор базы данных | Кэш Azure для Redis настроен на использование базы данных, отличной от используемой по умолчанию. |
| Сбой экземпляра Redis | Сервер Redis недоступен. |
Очистка ключей
Клиенты могут использовать команду FLUSHDB, чтобы удалить все ключи в одной базе данных или FLUSHALL, чтобы удалить все ключи из всех баз данных в кэше Redis. Чтобы узнать, очищены ли ключи, используйте команду INFO. В разделе Commandstats показано, была ли вызвана команда FLUSH:
# Commandstats
cmdstat_flushall:calls=2,usec=112,usec_per_call=56.00
cmdstat_flushdb:calls=1,usec=110,usec_per_call=52.00
Неправильный выбор базы данных
Кэш Azure для Redis использует базу данных db0 по умолчанию. Если переключиться на другую базу данных (например, db1) и попытаться считать ключи из нее, то Кэш Azure для Redis не обнаружит их там. Каждая база данных является логически отдельной единицей и содержит разный набор данных. Примените команду SELECT, чтобы использовать другие доступные базы данных и искать в них ключи.
Сбой экземпляра Redis
Redis — это хранилище данных в памяти. Данные хранятся на физических компьютерах или виртуальных машинах, где размещен кэш Redis. Экземпляр Кэша Azure для Redis ценовой категории "Базовый" работает только на отдельной виртуальной машине. Если эта виртуальная машина перестанет работать, все сохраненные в кэше данные будут утеряны.
Кэши ценовой категории "Стандартный" и "Премиум" обеспечивают более высокую устойчивость к потере данных за счет использования двух виртуальных машин в реплицированной конфигурации. При сбое первичного узла в таком кэше задача обработки данных автоматически переходит на узел реплики. Эти виртуальные машины размещаются в отдельных доменах на случай неисправностей и обновлений, что позволяет избежать одновременной недоступности обеих этих виртуальных машин. Однако крупный сбой центра обработки данных может привести к недоступности обеих виртуальных машин. В таких редких случаях ваши данные будут утеряны.
Рассмотрите возможность использования сохраняемости данных Redis и георепликации, чтобы улучшить защиту данных от этих сбоев инфраструктуры.
Дополнительные сведения
В этих статьях содержатся дополнительные сведения о предотвращении потери данных.