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


Устранение неполадок с потерей данных в Управляемом 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 и георепликации, чтобы улучшить защиту данных от этих сбоев инфраструктуры.

Дополнительная информация:

В этих статьях содержатся дополнительные сведения о предотвращении потери данных.