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

Устранение неполадок, связанных с потерей данных в Кэше Azure для Redis

  • Применяется к: ✅ Azure Cache for Redis

В этой статье описывается, как диагностировать частичные или полные потери данных, возникающие в кэше Azure для Redis.

Частичная утеря ключа

Кэш Azure для Redis не случайно удаляет ключи после их хранения в памяти, но удаляет ключи в ответ на политики истечения срока действия, политики вытеснения и явные команды удаления ключей. Эти команды можно выполнять в консоли или с помощью интерфейса командной строки Redis.

Ключи, записанные на основной узел в экземпляре Redis уровня "Премиум" или "Стандартный" Azure, могут быть недоступны сразу на реплике. Данные реплицируются из первичной в реплику асинхронным и неблокируемым способом.

Если некоторые ключи исчезают из кэша, проверьте следующие возможные причины:

Причина Описание
Окончание срока действия ключей Ключи были удалены из-за времени ожидания, установленного на них.
Удаление ключей Ключи были удалены из-за недостатка памяти.
Удаление ключей Ключи были удалены явными командами удаления.
Асинхронная репликация Ключи не были доступны в реплике из-за задержек репликации данных.

Окончание срока действия ключей

Кэш Azure для Redis автоматически удаляет ключ, если ему назначено время ожидания, и этот период истекает. Дополнительные сведения об истечении срока действия ключа Redis см. в документации по команде Redis EXPIRE . Значения времени ожидания также можно задать с помощью команд SET, SETEX, GETSET и других *STORE команд.

Чтобы получить статистику о том, сколько ключей истекло, используйте команду INFO . В разделе Stats отображается общее число ключей с истекшим сроком действия. В Keyspace разделе содержатся дополнительные сведения о количестве ключей с тайм-аутами и средним значением времени ожидания.

# Stats

expired_keys:46583

# Keyspace

db0:keys=3450,expires=2,avg_ttl=91861015336

Удаление ключей

Для кэша Azure для Redis требуется пространство памяти для хранения данных и очистки ключей, чтобы освободить доступную память при необходимости. Когда значения used_memory или used_memory_rss приближаются к настроенной maxmemory, Azure Redis начинает удаление ключей из памяти в соответствии с политикой кэша.

Вы можете отслеживать количество удалённых ключей с помощью команды INFO.

# Stats

evicted_keys:13224

Удаление ключей

Клиенты 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 Cache для Redis стандартного или премиального уровня настраиваются с основным узлом и как минимум одной репликой. Данные копируются с первичного узла в реплику асинхронно с помощью фонового процесса.

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

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

Полная потеря ключа

Если большинство или все ключи исчезают из кэша, проверьте следующие возможные причины:

Причина Описание
Очистка ключей Ключи были удалены вручную.
Неправильный выбор базы данных Для Azure Redis установлено использование нестандартной базы данных.
Сбой экземпляра Redis Сервер Redis недоступен.

Очистка ключей

Клиенты Redis Azure могут вызвать команду 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 не находит их. Используйте команду Redis SELECT для поиска ключей в других доступных базах данных.

Сбой экземпляра Redis

Redis хранит данные в памяти на физических или виртуальных машинах, на которых размещен кэш Redis. Экземпляр Redis Azure Cache уровня Basic выполняется только на одной виртуальной машине. Если эта виртуальная машина исчезнет, все данные, хранящиеся в кэше, будут потеряны.

Кэши на уровнях "Стандартный" и "Премиум" обеспечивают более высокую устойчивость к потере данных с помощью двух виртуальных машин в реплицированной конфигурации. При сбое первичного узла в таком кэше задача обработки данных автоматически переходит на узел реплики.

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

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