Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Si une défaillance du cache Azure pour Redis se produit, la perte de données est possible lorsque les nœuds sont arrêtés. La persistance Redis vous permet de conserver les données stockées dans les instances de cache. En cas de défaillance matérielle, l'instance de cache se recharge avec les données du fichier de persistance lorsqu'elle revient en ligne.
Cet article décrit la persistance Redis et explique comment configurer et gérer la persistance des données dans vos instances de cache Azure Redis de niveau Premium et Entreprise. La fonctionnalité de persistance des données n’est pas disponible dans les niveaux De base ou Standard et est en préversion dans les niveaux Enterprise et Enterprise Flash.
La possibilité de conserver des données est un moyen important d’améliorer la durabilité d’une instance de cache, car elle stocke toutes les données de cache en mémoire. La persistance doit être une partie clé de votre stratégie de haute disponibilité et de récupération d’urgence Azure Redis.
Important
La fonctionnalité de persistance des données offre une résilience aux pannes inattendues des nœuds Redis. La persistance des données n’est pas une fonctionnalité de sauvegarde des données ou de récupération à un moment donné (PITR). Si les données endommagées sont écrites dans l’instance Redis, les données endommagées sont également conservées. Pour effectuer des sauvegardes de votre instance Redis, utilisez la fonctionnalité Exporter .
Étendue de la disponibilité
Niveau | De base, Standard | Haute qualité | Enterprise, Enterprise Flash |
---|---|---|---|
Disponible | Non | Oui | Oui (préversion) |
Types de persistance des données Redis
Azure Redis offre deux types de persistance des données, le format de base de données Redis (RDB) et le format AOF ( Append-only File ).
La persistance RDB conserve un instantané de votre cache dans un format binaire et l’enregistre dans un compte de stockage Azure. Vous configurez la fréquence de sauvegarde pour déterminer la fréquence à laquelle conserver l’instantané. Si un événement catastrophique se produit qui désactive le cache principal et le cache de réplica, le cache se reconstruit automatiquement à l’aide de l’instantané le plus récent. Pour plus d’informations, consultez avantages RDB et inconvénients RDB.
La persistance AOF enregistre chaque opération d’écriture dans un journal et enregistre le journal une fois par seconde dans un compte de stockage Azure. Si un événement catastrophique se produit qui désactive les caches principaux et réplicas, le cache se reconstruit automatiquement à l’aide des opérations d’écriture stockées. Pour plus d’informations, consultez avantages AOF et inconvénients AOF.
Conditions requises et limitations :
La fonctionnalité de persistance des données offre une résilience pour les défaillances inattendues des nœuds Redis. La persistance des données n’est pas une fonctionnalité de sauvegarde de données ou PITR. Si les données endommagées sont écrites dans l’instance Redis, les données endommagées sont également conservées. Pour sauvegarder votre instance Redis, utilisez la fonctionnalité Exporter .
Les fonctionnalités de persistance du Cache Azure pour Redis sont destinées à restaurer automatiquement les données dans le même cache après une perte de données. Vous ne pouvez pas importer de fichiers de données persistants dans un cache nouveau ou existant.
Pour déplacer des données entre des caches, utilisez les fonctionnalités d’importation et d’exportation des données .
Pour générer des sauvegardes de données qui peuvent être ajoutées à un nouveau cache, vous pouvez utiliser des scripts automatisés à l’aide de PowerShell ou d’Azure CLI qui exportent régulièrement des données.
La persistance n’est pas prise en charge avec les caches qui utilisent la géoréplication passive ou la géoréplication active.
Chiffrement des données
Étant donné que la persistance Redis crée des données au repos, il est important de chiffrer ces données. Les options de chiffrement varient en fonction du niveau Redis Azure que vous utilisez.
Configurer la persistance des données
Vous pouvez utiliser le portail Azure, les modèles Azure Resource Manager (ARM), PowerShell ou Azure CLI pour créer et configurer la persistance des données pour les caches Azure Redis de niveau Premium ou Entreprise.
Conditions préalables
- Pour créer et ajouter la persistance aux caches Redis Azure, vous avez besoin d’un accès en écriture et d’autorisations pour créer des caches Premium ou Enterprise dans un abonnement Azure.
- Pour les caches de niveau Premium, vous avez besoin d’un compte de stockage Azure dans la même région que votre cache pour stocker les données du cache. Si vous utilisez l’identité managée comme méthode d’authentification, vous pouvez utiliser un compte de stockage dans un autre abonnement que votre cache.
- Pour les procédures Azure PowerShell, vous avez besoin d’Azure PowerShell installé ou utilisez Azure Cloud Shell avec l’environnement PowerShell dans le portail Azure.
- Pour les procédures Azure CLI, vous avez besoin d’Azure CLI installé ou d’utiliser Azure Cloud Shell avec l’environnement Bash dans le portail Azure.
Configurer la persistance des données dans le portail Azure
Dans le portail Azure, vous pouvez configurer la persistance des données lorsque vous créez votre instance de cache Azure Redis Premium ou Enterprise.
Configurer la persistance des données à l’aide d’Azure PowerShell
Vous pouvez utiliser Azure PowerShell pour configurer la persistance des données lorsque vous créez un cache de niveau Premium ou Entreprise Azure Redis, ou pour ajouter la persistance à un cache créé précédemment.
Configurer la persistance des données à l’aide d’Azure CLI
Vous pouvez utiliser Azure CLI pour configurer la persistance des données lorsque vous créez un cache De niveau Entreprise ou Premium Redis Azure, ou pour ajouter la persistance à un cache créé précédemment.
Forum aux questions sur la persistance
Cette section contient des réponses aux questions fréquemment posées sur la persistance du cache Redis Azure.
- Puis-je activer la persistance sur un cache existant ?
- Puis-je activer la persistance AOF et RDB ?
- La persistance fonctionne-t-elle avec la géoréplication ?
- Quel modèle de persistance dois-je choisir ?
- Que se passe-t-il si j’effectue une mise à l’échelle vers une autre taille et une sauvegarde avant la restauration de l’opération de mise à l’échelle ?
- Puis-je utiliser le même compte de stockage pour la persistance entre deux caches différents ?
- Est-ce que je suis facturé pour les utilisations de persistance des données de stockage ?
- À quelle fréquence la persistance RDB et la persistance AOF écrivent-elles dans le stockage ? Dois-je activer la suppression réversible ?
- Les exceptions de pare-feu sur le compte de stockage affectent-elles la persistance ?
- Comment vérifier si la suppression réversible est activée sur mon compte de stockage ?
- Puis-je utiliser un compte de stockage dans un autre abonnement que celui où se trouve mon cache ?
Persistance RDB
- Puis-je modifier la fréquence de sauvegarde RDB après avoir créé le cache ?
- Pourquoi y a-t-il plus de 60 minutes entre les sauvegardes lorsque j’ai une fréquence de sauvegarde RDB de 60 minutes ?
- Que se passe-t-il pour les anciennes sauvegardes RDB lorsqu’une nouvelle sauvegarde est effectuée ?
Persistance AOF
- Quand dois-je utiliser un deuxième compte de stockage ?
- La persistance AOF affecte-t-elle le débit du cache, la latence ou les performances ?
- Comment puis-je supprimer le deuxième compte de stockage ?
- Qu’est-ce qu’une réécriture et comment cela affecte-t-il mon cache ?
- Que dois-je attendre lors de la mise à l’échelle d’un cache avec AOF activé ?
- Comment mes données AOF sont-elles organisées dans le stockage ?
- Puis-je activer la persistance AOF si j’ai plusieurs réplicas ?
Puis-je activer la persistance sur un cache créé précédemment ?
Oui, vous pouvez configurer la persistance lors de la création du cache et sur les caches Premium, Entreprise ou Enterprise Flash existants.
Puis-je activer la persistance AOF et RDB en même temps ?
Non, vous pouvez activer RDB ou AOF, mais pas les deux en même temps.
Comment la persistance fonctionne-t-elle avec la géoréplication ?
La persistance des données ne fonctionne pas avec la géoréplication activée.
Quel modèle de persistance dois-je choisir ?
La persistance AOF écrit dans un journal une fois par seconde, tandis que la persistance RDB enregistre les sauvegardes en fonction de l’intervalle de sauvegarde configuré. La persistance RDB a moins d’effet sur le débit et les performances que la persistance AOF.
Choisissez la persistance AOF si votre objectif principal est de réduire la perte de données et de gérer un débit inférieur pour votre cache. Choisissez la persistance RDB si vous souhaitez conserver un débit optimal sur votre cache, mais souhaitez toujours un mécanisme de récupération des données.
Pour plus d'informations, consultez avantages RDB, inconvénients RDB, avantages AOF, et inconvénients AOF.
La persistance AOF affecte-t-elle le débit, la latence ou les performances de mon cache ?
La persistance AOF affecte le débit. Étant donné que AOF s’exécute à la fois sur le processus principal et le processus de réplica, vous voyez une charge processeur et serveur plus élevée pour un cache avec persistance AOF que sur un cache identique sans persistance AOF. AOF offre la meilleure cohérence avec les données en mémoire, car chaque écriture et chaque suppression sont conservées avec seulement quelques secondes de retard. Le compromis est que L’AOF est plus gourmand en calcul.
Tant que le processeur et la charge du serveur sont à la fois inférieurs à 90%, il existe une pénalité sur le débit, mais le cache fonctionne normalement. Au-dessus de 90 % de charge du CPU et du serveur, la pénalité de débit peut devenir plus élevée et la latence de toutes les commandes traitées par le cache augmente. En effet, la latence augmente car la persistance AOF s’exécute à la fois sur le processus principal et le réplica, augmentant la charge sur le nœud utilisé et plaçant la persistance sur le chemin critique des données.
Que se passe-t-il si j’effectue une mise à l’échelle à une autre taille et qu’une sauvegarde est restaurée avant l’opération de mise à l’échelle ?
- Si vous passez à une taille plus grande, il n'y a aucun effet.
- Si vous avez mis à l’échelle une taille plus petite et que vous disposez d’un paramètre de bases de données personnalisé supérieur à la limite des bases de données pour votre nouvelle taille, les données de ces bases de données ne sont pas restaurées. Pour plus d’informations, consultez Le paramètre de mes bases de données personnalisées est-il affecté lors de la mise à l’échelle ?
- Si vous avez réduit l'échelle à une taille plus petite et qu'il n'y a pas assez de place dans cette taille réduite pour contenir toutes les données de la dernière sauvegarde, les clés sont supprimées pendant le processus de restauration. En général, les clés sont éliminées en utilisant la stratégie d’éviction allkeys-lru.
Puis-je utiliser le même compte de stockage pour la persistance dans deux caches différents ?
Non, vous devez utiliser différents comptes de stockage. Chaque cache doit avoir son propre compte de stockage à configurer pour la persistance.
Important
Utilisez également des comptes de stockage distincts pour la persistance et l’exécution d’opérations d’exportation périodiques sur un cache.
Est-ce que je suis facturé pour le stockage utilisé dans la persistance des données ?
- Pour les caches Premium, vous êtes facturé pour le stockage utilisé par le modèle tarifaire du compte de stockage.
- Pour les caches Flash Entreprise et Entreprise, le stockage sur disque managé est inclus dans le prix et n’entraîne pas de frais supplémentaires.
Quelle est la fréquence d’écriture de la persistance RDB et AOF dans mes objets blob et dois-je activer la suppression réversible ?
La persistance RDB et AOF peut écrire dans vos objets blobs de stockage à une fréquence de quelques heures, de quelques minutes ou d’une seconde. La suppression réversible peut rapidement s’avérer coûteuse avec les tailles de données typiques d’un cache qui effectue également les opérations d’écriture chaque seconde. L’activation de la suppression réversible sur un compte de stockage signifie également qu’Azure Redis ne peut pas réduire les coûts de stockage en supprimant les anciennes données de sauvegarde.
Il est préférable d’éviter d’activer la suppression réversible sur les comptes de stockage que vous utilisez pour la persistance des données de niveau Premium Azure Redis. Pour plus d’informations sur les coûts de suppression réversible, consultez Tarification et facturation.
Puis-je modifier la fréquence de sauvegarde RDB après avoir créé le cache ?
Oui, vous pouvez modifier la fréquence de sauvegarde pour la persistance RDB à l’aide du portail Azure, d’Azure CLI ou d’Azure PowerShell.
Pourquoi, si la fréquence de sauvegarde RDB est de 60 minutes, y a-t-il un délai supérieur à 60 minutes entre les sauvegardes ?
L'intervalle de fréquence de sauvegarde de persistance RDB ne démarre pas tant que le processus de sauvegarde précédent n'est pas terminé avec succès. Si la fréquence de sauvegarde est de 60 minutes et qu’un processus de sauvegarde prend 15 minutes, la sauvegarde suivante ne démarre pas jusqu’à 75 minutes après l’heure de début de la sauvegarde précédente.
Qu’advient-il des anciennes sauvegardes RDB quand une nouvelle sauvegarde est effectuée ?
Toutes les sauvegardes avec la persistance RDB à l’exception de la plus récente sont supprimées automatiquement. Cette suppression peut ne pas avoir lieu immédiatement, mais les anciennes sauvegardes ne sont pas conservées indéfiniment. Si vous utilisez le niveau Premium pour la persistance et que la suppression réversible est activée pour votre compte de stockage, les sauvegardes existantes continuent de résider dans l’état de suppression réversible.
Quand dois-je utiliser un deuxième compte de stockage ?
Utilisez un deuxième compte de stockage pour la persistance AOF lorsque vous prévoyez d’avoir des opérations SET plus élevées que d’habitude sur le cache. L’utilisation du compte de stockage secondaire permet de s’assurer que votre cache n’atteint pas les limites de bande passante de stockage. Cette option est disponible uniquement pour les caches de niveau Premium.
Comment puis-je supprimer le deuxième compte de stockage ?
Vous pouvez supprimer le compte de stockage secondaire pour la persistance AOF en définissant le deuxième compte de stockage de manière à ce qu’il soit identique au premier compte de stockage. Pour modifier les paramètres des caches existants, sélectionnez Persistance des données sous Paramètres dans le menu de navigation de gauche de votre page de cache. Pour désactiver entièrement la persistance, sélectionnez Désactivé dans la page persistance des données .
Qu’est-ce qu’une réécriture et comment affecte-t-elle mon cache ?
Lorsqu’un fichier AOF devient suffisamment volumineux, une réécriture est automatiquement mise en file d’attente sur le cache. La réécriture redimensionne le fichier AOF avec l’ensemble minimal d’opérations nécessaires pour créer le jeu de données en cours.
Durant les réécritures, vous pouvez vous attendre à atteindre plus rapidement les limites de performances, en particulier lors du traitement de grands jeux de données. Les réécritures se produisent moins souvent que le fichier AOF devient plus volumineux, mais prennent beaucoup de temps lorsqu’ils se produisent.
À quoi dois-je attendre lors de la mise à l’échelle d’un cache avec la persistance AOF activée ?
Si le fichier AOF au moment de la mise à l’échelle est volumineux, attendez-vous que l’opération de mise à l’échelle prenne plus de temps que d’habitude, car elle recharge le fichier une fois la mise à l’échelle terminée. Voir également Que se passe-t-il si j’effectue une mise à l’échelle vers une autre taille et qu’une sauvegarde est restaurée avant l’opération de mise à l’échelle ?
Comment sont organisées mes données AOF dans le stockage ?
Lorsque vous utilisez le niveau Premium, les données stockées dans des fichiers AOF sont divisées en plusieurs objets blob de pages par partition. Par défaut, la moitié des objets blob sont enregistrés dans le compte de stockage principal et la moitié sont enregistrés dans le compte de stockage secondaire. Le fractionnement des données entre plusieurs objets blob de pages et deux comptes de stockage différents améliore les performances.
Si le taux maximal d’écritures dans le cache n’est pas élevé, ces performances supplémentaires peuvent ne pas être nécessaires. Dans ce cas, la configuration du compte de stockage secondaire peut être supprimée et tous les fichiers AOF stockés dans le compte de stockage principal unique. Le tableau suivant montre le nombre total d’objets blob de pages utilisés pour chaque niveau tarifaire :
Niveau Premium | Objets blob |
---|---|
P1 | 8 par partition |
P2 | 16 par partition |
P3 | 32 par partition |
P4 | 40 par partition |
Quand le clustering est activé, chaque partition dans le cache a son propre ensemble d’objets blob de pages, comme indiqué dans le tableau précédent. Par exemple, un cache P2 avec trois fragments distribue son fichier AOF sur 48 blobs de pages : seize blobs par fragment, avec trois fragments.
Après une réécriture, deux jeux de fichiers AOF se trouvent dans le stockage. Les réécritures se produisent en arrière-plan et s’ajoutent au premier jeu de fichiers. Opérations SET envoyées au cache pendant la réécriture sont ajoutées au deuxième ensemble de fichiers.
En cas de défaillance lors d’une réécriture, une sauvegarde est temporairement stockée. La sauvegarde est rapidement supprimée une fois la réécriture terminée. Si la suppression réversible est activée pour votre compte de stockage, le paramètre de suppression réversible s’applique et les sauvegardes existantes continuent d’y résider à l’état de suppression réversible.
Le fait d’avoir des exceptions de pare-feu sur le compte de stockage affecte-t-il la persistance ?
Oui. Pour la persistance dans le niveau Premium, l’utilisation des paramètres de pare-feu sur le compte de stockage peut empêcher le fonctionnement de la fonctionnalité de persistance.
Vous pouvez rechercher des erreurs dans les données persistantes en affichant la métrique Erreurs. Cette métrique indique si le cache ne parvient pas à conserver les données en raison de restrictions de pare-feu sur le compte de stockage ou d’autres problèmes.
Pour utiliser la persistance des données avec un compte de stockage configuré par un pare-feu, utilisez l’authentification basée sur l’identité managée pour vous connecter au stockage. L’utilisation de l’identité managée ajoute l’instance de cache à la liste des services approuvés, ce qui facilite l’application des exceptions de pare-feu. Si vous autorisez le compte de stockage à l’aide d’une clé au lieu d’une identité managée, le fait d’avoir des exceptions de pare-feu sur le compte de stockage tend à interrompre le processus de persistance.
Puis-je activer la persistance AOF si j’ai plusieurs réplicas ?
Avec le niveau Premium, vous ne pouvez pas utiliser la persistance AOF avec plusieurs répliques. Dans les niveaux Enterprise et Enterprise Flash, l’architecture de réplica est plus complexe, mais la persistance AOF est prise en charge lorsque les caches Enterprise sont utilisés dans les déploiements en zone redondante.
Comment savoir si la suppression réversible est activée sur mon compte de stockage ?
Dans le portail Azure, sélectionnez le compte de stockage que votre cache utilise pour la persistance, puis sélectionnez Protection des données sous Gestion des données dans son menu de navigation gauche. Dans la page Protection des données , vérifiez si l’option Activer la suppression réversible pour les objets blob est activée. Pour plus d’informations sur la suppression réversible dans les comptes de stockage Azure, consultez Activer la suppression réversible pour les objets blob.
Puis-je utiliser un compte de stockage dans un autre abonnement que celui où se trouve mon cache ?
Vous pouvez choisir un compte de stockage dans un autre abonnement uniquement si vous utilisez l’identité managée comme méthode d’authentification du compte de stockage.
Contenu connexe
En savoir plus sur les fonctionnalités d’Azure Cache pour Redis.