Устранение неполадок с потерей данных в Управляемом Redis Azure (предварительная версия)
В этой статье описывается, как диагностировать фактические или предполагаемые потери данных, которые могут возникнуть в Управляемом Redis Azure (предварительная версия).
Примечание.
Шаги по устранению проблем в этой статье также включают в себя указания по выполнению команд Redis и мониторингу различных метрик производительности. Дополнительные сведения и указания см. в разделе Дополнительные сведения.
Частичная утрата ключей
Управляемый Redis Azure не случайно удаляет ключи после их хранения в памяти. Но может удалить ключи согласно политикам истечения срока действия, а также при получении явной команды удаления ключа. Эти команды можно выполнить с помощью интерфейса командной строки.
Ключи, записанные на основной узел в экземпляре Управляемого Redis в Azure, также могут быть недоступны сразу на реплике. Данные реплицируются с первичного узла в реплику в асинхронном режиме и без блокировки.
Если вы обнаружите, что ключи исчезли из кэша, проверьте следующие возможные причины.
Причина | Описание |
---|---|
Окончание срока действия ключей | Ключи удалены, так как для них задано истечение времени ожидания. |
Вытеснение ключей | Ключи удалены из-за нехватки памяти. |
Удаление ключей | Ключи удалены с помощью явных команд удаления. |
Асинхронная репликация | Ключи недоступны в реплике из-за задержек репликации данных. |
Окончание срока действия ключей
Управляемый Redis Azure автоматически удаляет ключ, если ключ назначен тайм-аут, и этот период прошел. Дополнительные сведения об окончании срока действия ключа Redis см. в документации по команде EXPIRE. Значения времени ожидания также можно задать с помощью SET, SETEX, GETSET и других команд *STORE.
Чтобы получить данные статистики о числе ключей с истекшим сроком действия, используйте команду INFO. В разделе Stats
отображается общее число ключей с истекшим сроком действия. В разделе Keyspace
содержатся дополнительные сведения о числе ключей с истекшим временем ожидания и средним значением времени ожидания.
# Stats
expired_keys:46583
# Keyspace
db0:keys=3450,expires=2,avg_ttl=91861015336
Вы также можете просмотреть метрики диагностики для кэша, чтобы определить, существует ли корреляция между моментом, когда пропал ключ, и увеличением числа ключей с истекшим сроком действия. Сведения об использовании уведомлений keyspace
или команды для отладки проблем такого вида см. в приложении Отладка отсутствия данных в пространстве ключей RedisMONITOR
.
Вытеснение ключей
Для хранения данных в Управляемом Redis в Azure требуется пространство памяти. Он очищает ключи, если нужно освободить память. Когда значения used_memory или used_memory_rss в команде INFO подходили к настроенной параметру maxmemory, Управляемый Redis Azure начинает вытеснение ключей из памяти на основе политики кэша.
Количество вытесненных ключей можно отслеживать с помощью команды INFO.
# Stats
evicted_keys:13224
Вы также можете просмотреть метрики диагностики для кэша, чтобы определить, существует ли корреляция между моментом, когда пропал ключ, и увеличением числа вытесненных ключей. Сведения об использовании уведомлений пространства ключей или команды MONITOR для отладки проблем такого вида см. в приложении Отладка отсутствия данных в пространстве ключей Redis.
Удаление ключей
Клиенты Redis могут выдавать команду DEL или HDEL для явного удаления ключей из Управляемого Redis в Azure. Число операций удаления можно узнать с помощью команды 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
Асинхронная репликация
Любой экземпляр Управляемого Redis Azure с поддержкой высокой доступности настроен с основным узлом и по крайней мере одной репликой. Данные копируются с первичного узла в реплику асинхронно с помощью фонового процесса. На веб-сайте redis.io описано, как работает репликация данных Redis в целом. Если клиенты часто записывают данные в 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
Сбой экземпляра Redis
Redis — это хранилище данных в памяти. Данные хранятся на физических или виртуальных машинах, на которых размещен кэш Redis. Кэши Управляемого Redis azure обеспечивают высокую устойчивость к потере данных, предоставляя по умолчанию отказоустойчивые кэши зоны. Если основной сегмент в таком кэше завершается ошибкой, сегмент реплики берет на себя автоматическое обслуживание данных. Эти виртуальные машины размещаются в отдельных доменах на случай неисправностей и обновлений, что позволяет избежать одновременной недоступности обеих этих виртуальных машин. Однако если происходит основной сбой центра обработки данных, виртуальные машины могут по-прежнему уменьшаться. В таких редких случаях ваши данные будут утеряны.
Рассмотрите возможность использования сохраняемости данных Redis и георепликации, чтобы улучшить защиту данных от этих сбоев инфраструктуры.
Дополнительная информация:
В этих статьях содержатся дополнительные сведения о предотвращении потери данных.