Cet article explore les méthodes de sauvegarde et de restauration Redis (Save, BGSAVE, AOF), mettant l'accent sur les meilleures pratiques pour minimiser les temps d'arrêt. Il compare les instantanés RDB et la journalisation AOF, préconisant une approche hybride pour la production. Stratégies pour un grand D

Comment effectuer des sauvegardes et des restaurations dans Redis?
Redis propose plusieurs façons d'effectuer des sauvegardes et des restaurations, selon vos besoins et la taille de votre ensemble de données. Les méthodes les plus courantes consistent à utiliser SAVE
, BGSAVE
et AOF
(Ajout uniquement du fichier).
-
SAVE
: Cette commande effectue un instantané ponctuel de l'ensemble de données Redis et l'enregistre sur le disque. Il s'agit d'une opération de blocage, ce qui signifie qu'elle arrêtera toutes les autres opérations Redis pendant la création de l'instantané. Cela le rend inapproprié pour les environnements de production avec un trafic élevé, car cela entraînera des temps d'arrêt importants. Le fichier enregistré est un seul fichier RDB (base de données redis).
-
BGSAVE
: Cette commande est une alternative non bloquante à SAVE
. Il alimente un processus d'enfant pour gérer la sauvegarde, permettant au processus Redis principal de continuer les demandes de service. Cela minimise les temps d'arrêt par rapport à SAVE
, mais implique toujours une quantité importante de ressources système pendant les opérations de fourche et d'écriture. Le résultat est également un fichier RDB.
- Ajouter le fichier uniquement (AOF): Il s'agit d'une approche basée sur les journaux. Chaque opération d'écriture à Redis est annexée au fichier AOF. Cela fournit une histoire détaillée de tous les changements. Bien que plus lent que RDB pour les écritures, AOF offre une récupération de données plus robuste car elle peut être rejouée pour reconstruire l'ensemble de données à partir de la dernière écriture réussie. L'AOF peut être configuré avec différentes stratégies d'ajout (toujours, tout ce, non) affectant la vitesse d'écriture et la cohérence des données.
Restaurer: Pour restaurer à partir d'un fichier RDB, vous arrosez simplement Redis, remplacez le fichier RDB existant par votre sauvegarde et redémarrez Redis. Pour restaurer à partir d'un fichier AOF, vous commencez Redis avec le fichier AOF spécifié. Redis rejouera automatiquement le journal et reconstruisa l'ensemble de données.
Quelles sont les meilleures pratiques pour les sauvegardes redis pour minimiser les temps d'arrêt?
La minimisation des temps d'arrêt pendant les sauvegardes redis nécessite une approche stratégique combinant différentes techniques:
-
BGSAVE
OUT SAVE
: Priorisez toujours BGSAVE
sur SAVE
dans la production. La nature non bloquante de BGSAVE
assure un minimum de perturbation des services.
- AOF avec paramètres appropriés: configurer AOF avec la stratégie
everysec
. Cela fournit un bon équilibre entre la sécurité des données et les performances. L'utilisation peut always
avoir un impact significatif sur les performances de l'écriture, tandis que no
est risqué et peut entraîner une perte de données.
- Sauvegardes régulières: implémentez un calendrier pour les sauvegardes régulières, en fonction de votre fréquence de changement de données. Des changements plus fréquents nécessitent des sauvegardes plus fréquentes. Envisagez d'utiliser un travail CRON ou un mécanisme de planification similaire.
- Sauvegarde dans un stockage séparé: stockez vos sauvegardes sur un périphérique de stockage ou un serveur séparé pour éviter la perte de données en cas de défaillance de stockage primaire.
- Tests Restores: Testez régulièrement votre processus de sauvegarde et de restauration pour vous assurer qu'il fonctionne comme prévu et identifier tous les problèmes potentiels avant une véritable catastrophe.
- Instantané et réplication: envisagez d'utiliser les fonctionnalités de réplication de Redis pour créer des répliques de lecture. Des instantanés réguliers des répliques peuvent être pris avec un impact minimal sur la base de données principale.
Comment puis-je restaurer efficacement un grand ensemble de données Redis?
La restauration d'un grand ensemble de données Redis peut prendre du temps. L'efficacité dépend de la méthode de sauvegarde utilisée et des ressources disponibles.
- Optimisation de restauration RDB: assurez une capacité d'E / S de disque suffisante pour gérer le transfert de fichiers grand pendant le processus de restauration. L'utilisation de SSDS accélère considérablement le processus.
- Optimisation de la restauration AOF: Bien que AOF offre de meilleures capacités de récupération, la restauration d'un très grand fichier AOF peut prendre plus de temps que la restauration d'un fichier RDB. L'optimisation de la stratégie d'ajout AOF (
everysec
est un bon équilibre) peut aider à réduire la taille du fichier.
- Sauvegarde incrémentielle: envisagez d'utiliser des sauvegardes incrémentielles, ce qui ne fait que des changements depuis la dernière sauvegarde complète. Cela réduit considérablement la taille des sauvegardes ultérieures et accélère la restauration. Bien que Redis ne prenne pas en charge nativement les sauvegardes incrémentielles, vous pouvez obtenir un effet similaire à travers des outils ou des scripts qui comparent et ne transfèrent que les différences.
- Traitement parallèle (si possible): si votre instance redis est distribuée sur plusieurs nœuds, envisagez d'utiliser un traitement parallèle pour accélérer le processus de restauration.
- Bande passante du réseau: Si vous restaurez à partir d'une sauvegarde distante, assurez-vous une bande passante réseau suffisante pour gérer le transfert de données important.
Quelles sont les différentes stratégies de sauvegarde disponibles pour Redis, et laquelle convient le mieux à mon cas d'utilisation?
Redis propose plusieurs stratégies de sauvegarde, chacune avec des compromis:
- RDB (instantanée): simple, rapide pour la création de sauvegardes, mais entraîne potentiellement une perte de données si une défaillance se produit pendant le processus de sauvegarde. Le mieux adapté aux situations où la tolérance à la perte de données est élevée et les temps d'arrêt minimaux sont essentiels pendant la sauvegarde.
- AOF (Ajouter uniquement le fichier): fournit une meilleure durabilité et cohérence des données, mais des performances d'écriture plus lentes. Le mieux adapté aux situations où la perte de données est inacceptable et les données cohérentes sont primordiales.
- Approche hybride: la combinaison de RDB et AOF fournit une stratégie robuste. RDB fournit des instantanés fréquents pour des restaurations rapides, tandis que l'AOF assure la durabilité des données. Il s'agit souvent de l'approche recommandée pour les environnements de production.
- Outils externes: plusieurs outils tiers offrent des fonctionnalités de sauvegarde et de restauration plus avancées, y compris des fonctionnalités telles que les sauvegardes incrémentielles, la compression et le chiffrement.
Choisir la meilleure stratégie: la meilleure stratégie dépend de vos besoins et priorités spécifiques:
- Haute disponibilité et temps d'arrêt faible: l'approche hybride (RDB AOF avec la stratégie
everysec
) est recommandée.
- La tolérance à la perte de données est élevée: RDB avec
BGSAVE
- La perte de données est inacceptable: AOF avec la stratégie
everysec
- De très grands ensembles de données et des performances sont essentiels: une approche hybride bien planifiée avec des techniques de sauvegarde incrémentielles et éventuellement des outils externes.
N'oubliez pas de toujours tester la stratégie choisie pour vous assurer qu'elle répond à vos besoins et à vos objectifs de récupération.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!