Résoudre les problèmes de perte de données dans Azure Managed Redis (préversion)
Cet article explique comment diagnostiquer les pertes de données réelles ou perçues qui peuvent se produire dans Azure Managed Redis (préversion).
Notes
Dans ce guide, plusieurs procédures de résolution de problèmes comprennent des instructions pour exécuter des commandes Redis et surveiller diverses mesures de performances. Pour plus d’informations et d’instructions, consultez les articles dans la section Informations supplémentaires .
Perte partielle des clés
Azure Managed Redis ne supprime pas de façon aléatoire les clés lorsqu’elles sont stockées en mémoire. Toutefois, il les supprime en réponse à des stratégies d’expiration ou d’éviction et à la suite de commandes de suppression de clé explicites. Vous pouvez exécuter ces commandes via l’interface de ligne de commande.
Les clés écrites dans le nœud principal d’une instance Azure Managed Redis peuvent également ne pas être disponibles immédiatement sur un réplica. Les données sont répliquées du nœud principal vers le réplica de manière asynchrone et non bloquante.
Si vous constatez que des clés ont disparu de votre cache, passez en revue les causes possibles suivantes :
| Cause | Description |
|---|---|
| Expiration des clés | Les clés sont supprimées en raison des délais d’attente définis pour elles. |
| Éviction des clés | Les clés sont supprimées pour cause de sollicitation de la mémoire. |
| Suppression des clés | Les clés sont supprimées par des commandes de suppression explicites. |
| Réplication asynchrone | Les clés ne sont pas disponibles sur un réplica en raison de délais affectant la réplication des données. |
Expiration des clés
Le cache Azure Managed Redis supprime automatiquement une clé si un délai d’attente est affecté à la clé et que la période est passée. Pour en savoir plus sur l’expiration des clés Redis, consultez la documentation relative à la commande EXPIRE. Vous pouvez également définir des valeurs de délai d’expiration à l’aide des commandes SET, SETEX et GETSET et d’autres commandes *STORE.
Vous pouvez utiliser la commande INFO pour obtenir des statistiques sur le nombre de clés arrivées à expiration. La section Stats montre le nombre total de clés arrivées à expiration. La section Keyspace fournit des informations supplémentaires sur le nombre de clés avec des délais d’expiration, et la valeur moyenne du délai d’expiration.
# Stats
expired_keys:46583
# Keyspace
db0:keys=3450,expires=2,avg_ttl=91861015336
Vous pouvez également examiner les indicateurs de performance de diagnostic de votre cache pour voir s’il existe une corrélation entre le moment où la clé a disparu et un pic d’expiration des clés. Consultez l’annexe de la rubrique relative au débogage des échecs de l’espace de clés Redis pour plus d’informations sur l’utilisation des notifications keyspace ou de MONITOR pour corriger ces erreurs.
Éviction des clés
Azure Managed Redis a besoin d’espace mémoire pour stocker les données. Il vide donc des clés pour libérer de la mémoire, si nécessaire. Lorsque les valeurs used_memory ou used_memory_rss dans la commande INFO s’approchent du paramètre maxmemory configuré, Azure Managed Redis commence à supprimer des clés de la mémoire en fonction de la stratégie de cache.
Utilisez la commande INFO pour surveiller le nombre de clés supprimées :
# Stats
evicted_keys:13224
Vous pouvez également examiner les indicateurs de performance de diagnostic de votre cache pour voir s’il existe une corrélation entre le moment où la clé a disparu et un pic d’éviction des clés. Consultez l’annexe de la rubrique relative au débogage des échecs de l’espace de clés Redis pour en savoir plus sur les notifications relatives à l’espace de clés ou à MONITOR pour corriger ces erreurs.
Suppression des clés
Les clients Redis peuvent émettre la commande DEL ou HDEL pour supprimer explicitement des clés d’Azure Managed Redis. Utilisez la commande INFO pour effectuer le suivi du nombre d’opérations de suppression. Si des commandes DEL ou HDEL ont été appelées, elles sont répertoriées dans la section Commandstats.
# Commandstats
cmdstat_del:calls=2,usec=90,usec_per_call=45.00
cmdstat_hdel:calls=1,usec=47,usec_per_call=47.00
Réplication asynchrone
Toute instance Azure Managed Redis avec haute disponibilité activée est configurée avec un nœud principal et au moins un réplica. Les données sont copiées de façon asynchrone du nœud principal vers un réplica à l’aide d’un processus en arrière-plan. Le site web redis.io décrit le fonctionnement général de la réplication des données dans Redis. Dans les scénarios où les clients écrivent fréquemment dans Redis, vous pouvez subir une perte partielle de données, car l’instantanéité de la réplication n’est pas garantie. Par exemple, si le nœud principal subit une défaillance après qu’un client a écrit une clé sur celui-ci, mais avant que le processus en arrière-plan ait eu la l’occasion d’envoyer cette clé au réplica, cette clé est perdue quand le réplica prend le relais en tant que nouveau nœud principal.
Perte majeure ou totale des clés
Si vous constatez que tout ou partie des clés ont disparu de votre cache, passez en revue les causes possibles suivantes :
| Cause | Description |
|---|---|
| Vidage des clés | Les clés ont été vidées manuellement. |
| Échec de l’instance de Redis | Le serveur Redis n’est pas disponible. |
Vidage des clés
Les clients peuvent appeler la commande FLUSHDB ou FLUSHALL pour supprimer toutes les clés de l’instance Redis. Utilisez la commande INFO pour déterminer si les clés ont été vidées. La section Commandstats indique si la commande FLUSH a été appelée :
# Commandstats
cmdstat_flushall:calls=2,usec=112,usec_per_call=56.00
cmdstat_flushdb:calls=1,usec=110,usec_per_call=52.00
Échec de l’instance de Redis
Redis est un magasin de données en mémoire. Les données sont conservées sur les machines physiques ou virtuelles qui hébergent le cache Redis. Les caches Azure Managed Redis offrent une résilience élevée contre la perte de données en fournissant par défaut des caches résilients à la zone. Quand l’étendue principale d’un tel cache échoue, l’étendue de réplica prend le relais pour traiter automatiquement les données. Ces machines virtuelles se trouvent sur des domaines d’erreur et de mise à jour distincts, afin de réduire le risque qu’elles ne soient pas disponibles en même temps. Toutefois, en cas de défaillance majeure du centre de données, il se peut que les machines virtuelles tombent en panne simultanément. Dans ces rares cas, vos données sont perdues.
Songez à utiliser la persistance des données Redis et la géoréplication pour renforcer la protection de vos données contre ces défaillances d’infrastructure.
Informations supplémentaires
Ces articles fournissent des informations supplémentaires pour éviter la perte de données :