Introduction à la persistance Redis et au mécanisme de réplication maître-esclave

Le contenu de cet article est de présenter le mécanisme de persistance et de réplication maître-esclave de redis. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Persistance Redis

Redis fournit une variété de méthodes de persistance à différents niveaux :

La persistance RDB peut être Générer un point instantané de l'ensemble de données dans l'intervalle de temps spécifié

AOF enregistre de manière persistante toutes les commandes d'opération d'écriture exécutées par le serveur et réexécute ces commandes lorsque le serveur démarre. Toutes les commandes du fichier AOF sont enregistrées au format de protocole Redis et les nouvelles commandes seront ajoutées à la fin du fichier. Redis peut également réécrire le fichier AOF en arrière-plan afin que la taille du fichier AOF ne dépasse pas la taille réelle requise pour enregistrer l'état de l'ensemble de données.

Redis peut également utiliser la persistance AOF et la persistance RDB en même temps. Dans ce cas, au redémarrage de Redis, il donnera la priorité à l'utilisation du fichier AOF pour restaurer l'ensemble de données, car l'ensemble de données enregistré par le fichier AOF est généralement plus complet que l'ensemble de données enregistré par le fichier RDB.
Vous pouvez même désactiver la persistance afin que les données n'existent que pendant l'exécution du serveur.

RDB (Redis DataBase)

Rdb : écrit un instantané de l'ensemble de données en mémoire sur le disque dans un intervalle de temps spécifié, qui est Dans le jargon, un instantané est un instantané. Lorsqu'il est restauré, le fichier d'instantané est lu directement dans la mémoire.

Redis créera (fork) un sous-processus distinct pour la persistance. Il écrira d'abord les données dans un fichier temporaire lorsque le processus de persistance sera terminé, ce fichier temporaire sera utilisé pour remplacer la dernière persistance. Documents retournés. Tout au long du processus, le processus principal n'effectue aucune opération d'E/S, ce qui garantit des performances extrêmement élevées. Si une récupération de données à grande échelle est requise et que l'intégrité de la récupération des données n'est pas très sensible, la méthode RDB est plus efficace que la méthode AOF. .de haute efficacité. L'inconvénient de RDB est que les données après la dernière persistance peuvent être perdues.

La fonction de Fork est de copier un processus qui est le même que le processus actuel. Toutes les données (variables, variables d'environnement, compteurs de programme, etc.) du nouveau processus ont les mêmes valeurs que. le processus d'origine, mais il s'agit d'un tout nouveau processus et sert de sous-processus du processus d'origine

Dangers cachés : si le processus actuel contient une grande quantité de données, alors la quantité de données après le fork * 2 , ce qui entraînera une forte pression sur le serveur et réduira les performances de fonctionnement.

Rdb enregistre le fichier dump.rdb

Dans le test : exécutez la commande flushAll, utilisez shutdown Quand le processus est fermé directement, redis lira automatiquement le fichier dump.rdb lors de sa deuxième ouverture, mais lorsqu'il sera restauré, il sera tout vide. (La raison en est : au moment de l'arrêt, le système Redis enregistrera le dump.rdb vide pour remplacer le fichier cache d'origine. Par conséquent, lorsque le système Redis est ouvert pour la deuxième fois, le fichier de valeurs vide est automatiquement lu)

Opération de sauvegarde RDB

Rdb est un instantané compressé de la mémoire entière. La structure de données de RDB peut être configurée pour répondre au déclenchement de l'instantané. conditions. La valeur par défaut est 1 changement en 1 minute. Dix mille fois, ou 10 changements en 5 minutes, ou une fois en 15 minutes ;
Enregistrement désactivé : si vous souhaitez désactiver la stratégie de persistance RDB, ne définissez aucune sauvegarde ; instructions, ou transmettez un paramètre de chaîne vide pour enregistrer. C'est ok aussi.

-----> commande save : enregistrez l'objet d'opération immédiatement

Comment déclencher un instantané RDB

Enregistrer : lors de l'enregistrement, enregistrez simplement, ignorez les autres éléments et bloquez tout.

Bgsave : redis effectuera des opérations d'instantané en arrière-plan, pendant l'opération d'instantané, il peut également répondre aux demandes du client. Vous pouvez obtenir l'heure de la dernière exécution réussie de l'instantané via la commande lastsave.

L'exécution de la commande fluhall générera également un fichier dump.rdb, mais il sera vide.

Comment restaurer :

Déplacez le fichier de sauvegarde (dump.rdb) vers le répertoire d'installation Redis et démarrez le service
La commande Config get dir peut obtenir le directory

Comment arrêter

Méthode pour arrêter dynamiquement les règles de sauvegarde RDB : redis -cli config set save ""

AOF (Append Only File)

Enregistrez chaque opération d'écriture sous la forme d'un journal et enregistrez toutes les instructions d'écriture exécutées par redis (les opérations de lecture ne sont pas enregistrées). Seuls les fichiers peuvent être ajoutés mais pas réécrits. Lorsque Redis démarre, il lira le fichier et reconstruira les données. En d'autres termes, lorsque Redis redémarrera, il exécutera les instructions d'écriture d'avant en arrière en fonction du contenu du fichier journal. terminer le travail de récupération des données.
======MODE AJOUTER UNIQUEMENT=====

Activer aof : ajouter uniquement oui (la valeur par défaut est non)

Remarque :

Dans le travail et la production réels, une corruption de fichiers se produit souvent (une corruption de fichiers causée par une transmission réseau ou d'autres problèmes)

Une erreur se produit au démarrage du serveur (mais le fichier dump.rdb est complet), indiquant que le fichier aof est chargé en premier au démarrage

Solution : exécuter le commande redis-check-aof --fix aof file [vérifier et supprimer automatiquement les champs qui ne sont pas cohérents avec la syntaxe aof]

Politique Aof

Paramètres Appendfsync :

Toujours La persistance synchrone sera immédiatement enregistrée sur le disque à chaque fois qu'un changement de données se produit, avec des performances médiocres mais une meilleure intégrité des données.
Everysec : recommandation d'usine par défaut, fonctionnement asynchrone, enregistrement toutes les secondes, temps d'arrêt après une seconde, perte de données
Non : jamais fsync : transmettez les données au système d'exploitation pour traitement. Option plus rapide et moins sécurisée.

Réécriture

Concept : AOF utilise la méthode d'ajout de fichier, et les fichiers deviendront de plus en plus gros. Pour éviter cette situation, une nouvelle. Mécanisme de réécriture, lorsque la taille du fichier aof dépasse le seuil défini, redis compressera automatiquement le contenu du fichier aof et la valeur conservera le jeu d'instructions minimum pouvant restaurer les données. Vous pouvez utiliser la commande bgrewirteaof.

Principe de réécriture : lorsque le fichier aof continue de croître et devient volumineux, un nouveau processus sera lancé pour réécrire le fichier (c'est-à-dire que
écrit d'abord le fichier temporaire puis le renomme), en parcourant la mémoire du nouveau processus Chaque enregistrement a une instruction définie. L'opération de réécriture du fichier aof ne lit pas l'ancien fichier aof, mais l'intégralité du contenu de la base de données mémoire est réécrite dans un nouveau fichier aof à l'aide de commandes. instantanés.

Mécanisme de déclenchement : redis enregistrera la taille de l'aof de la dernière réécriture. La configuration par défaut est déclenchée lorsque la taille du fichier aof est doublée après la dernière réécriture et que le fichier est supérieur à 64 Mo (3G)

no-appendfsync-on-rewrite no : indique si Appendfsync peut être utilisé pendant la réécriture. Utilisez simplement le no par défaut pour garantir la sécurité des données
base de paramètres multiples auto-aof-rewrite-percentage. value
auto-aof-rewrite-min-size Définir la taille de la valeur de base

Avantages d'AOF

L'utilisation de la persistance AOF rendra Redis très durable : vous pouvez définir différentes stratégies fsync, telles que pas de fsync, fsync chaque seconde ou fsync à chaque fois qu'une commande d'écriture est exécutée. La politique par défaut d'AOF est de fsync une fois par seconde. Dans cette configuration, Redis peut toujours maintenir de bonnes performances, et même en cas de panne, une seule seconde de données sera perdue au maximum (fsync sera exécuté dans un thread en arrière-plan). donc le thread principal peut continuer à travailler dur pour traiter les demandes de commandes).

Le fichier AOF est un fichier journal à ajout uniquement, donc l'écriture dans le fichier AOF ne nécessite pas de recherche, même si le journal contient des commandes incomplètes pour certaines raisons (par exemple, le disque est plein lors de l'écriture, le. l'écriture s'arrête à mi-chemin, etc.), l'outil redis-check-aof peut également résoudre facilement ce problème.

Redis peut réécrire automatiquement l'AOF en arrière-plan lorsque la taille du fichier AOF devient trop grande : le nouveau fichier AOF réécrit contient l'ensemble minimum de commandes requis pour restaurer l'ensemble de données actuel. L'ensemble de l'opération de réécriture est absolument sûr, car Redis continuera à ajouter des commandes au fichier AOF existant pendant le processus de création d'un nouveau fichier AOF. Même en cas d'arrêt pendant le processus de réécriture, le fichier AOF existant ne sera pas perdu. . Une fois le nouveau fichier AOF créé, Redis passera de l'ancien fichier AOF au nouveau fichier AOF et commencera à l'ajouter au nouveau fichier AOF.

Le fichier AOF enregistre toutes les opérations d'écriture effectuées sur la base de données de manière ordonnée. Ces opérations d'écriture sont enregistrées au format du protocole Redis, le contenu du fichier AOF est donc très facile à lire et à analyser. file (analyser) est également très simple. Exporter (exporter) des fichiers AOF est également très simple : par exemple, si vous exécutez accidentellement la commande FLUSHALL, mais tant que le fichier AOF n'a pas été écrasé, alors arrêtez simplement le serveur, supprimez la commande FLUSHALL à la fin de l'AOF et redémarrez Redis. Vous pouvez restaurer l'ensemble de données à l'état avant l'exécution de FLUSHALL.

Inconvénients AOF

Pour un même ensemble de données, la taille des fichiers AOF est généralement plus grande que celle des fichiers RDB.

AOF peut être plus lent que RDB selon la stratégie fsync utilisée. Dans des circonstances normales, les performances de fsync par seconde sont toujours très élevées, et la désactivation de fsync peut rendre AOF aussi rapide que RDB, même sous une charge importante. Cependant, RDB peut fournir une latence maximale plus garantie lors de la gestion d'énormes charges d'écriture.

AOF a eu un tel bug dans le passé : en raison de certaines commandes, lorsque le fichier AOF est rechargé, l'ensemble de données ne peut pas être restauré à l'état d'origine lors de sa sauvegarde. (Par exemple, la commande de blocage BRPOPLPUSH a déjà provoqué un tel bug.)

Des tests ont été ajoutés à la suite de tests pour cette situation : ils génèrent automatiquement des ensembles de données aléatoires et complexes et les rechargent pour s'assurer que tout fonctionne. Bien que ce type de bug ne soit pas courant dans les fichiers AOF, en comparaison, il est presque impossible pour RDB d'avoir ce genre de bug.

Sauvegarder les données Redis

Assurez-vous de sauvegarder votre base de données !

Une panne de disque, une panne de nœud et d'autres problèmes peuvent entraîner la disparition de vos données. L'échec de la sauvegarde est très dangereux.

Redis est très convivial pour la sauvegarde des données, car vous pouvez copier le fichier RDB pendant que le serveur est en cours d'exécution : une fois le fichier RDB créé, aucune modification ne sera apportée. Lorsque le serveur souhaite créer un nouveau fichier RDB, il enregistre d'abord le contenu du fichier dans un fichier temporaire. Lorsque le fichier temporaire est écrit, le programme utilise rename(2) pour remplacer atomiquement le fichier RDB d'origine par le fichier temporaire.

Cela signifie qu'il est absolument sûr de copier des fichiers RDB à tout moment.

Recommandation :

Créez une tâche régulière (tâche cron), sauvegardez un fichier RDB dans un dossier toutes les heures et sauvegardez-le toutes les heures. jour Sauvegardez un fichier RDB dans un autre dossier.

Assurez-vous que les sauvegardes d'instantanés contiennent les informations de date et d'heure correspondantes. Chaque fois que vous exécutez le script de tâche standard, utilisez la commande find pour supprimer les instantanés expirés : par exemple, vous pouvez conserver toutes les heures des 48 dernières heures. Instantanés, vous pouvez également conserver des instantanés quotidiens du ou des deux derniers mois.

Au moins une fois par jour, sauvegardez le RDB en dehors de votre centre de données, ou au moins en dehors de la machine physique sur laquelle vous exécutez le serveur Redis.

Sauvegarde de récupération après sinistre

La sauvegarde de récupération après sinistre de Redis signifie essentiellement la sauvegarde des données et le transfert de ces sauvegardes vers plusieurs serveurs externes différents.

La sauvegarde de récupération après sinistre peut conserver les données dans un état sûr même si un problème grave survient dans le centre de données principal où Redis s'exécute et génère des instantanés.

Certains utilisateurs de Redis sont des entrepreneurs. Ils n'ont pas beaucoup d'argent à gaspiller, voici donc quelques méthodes de sauvegarde de récupération après sinistre pratiques et bon marché :

Amazon S3 et d'autres services comme S3 est un bon endroit pour créer un système de sauvegarde en cas de sinistre. Le moyen le plus simple consiste à chiffrer et à transférer vos sauvegardes RDB horaires ou quotidiennes vers S3. Le cryptage des données peut être réalisé avec la commande gpg -c (mode de cryptage symétrique). N'oubliez pas de conserver vos mots de passe dans plusieurs endroits différents et sécurisés (vous pouvez par exemple les copier auprès des personnes les plus importantes de votre organisation). L'utilisation de plusieurs services de stockage pour enregistrer des fichiers de données en même temps peut améliorer la sécurité des données.

La transmission d'instantanés peut être effectuée à l'aide de SCP (composant de SSH). Voici une méthode de transfert simple et sécurisée : Achetez un VPS (Virtual Private Server) loin de votre centre de données, installez SSH, créez une clé client SSH sans mot de passe et ajoutez cette clé au fichier Authorized_keys du VPS, afin que la sauvegarde de l'instantané Le fichier peut être transféré sur ce VPS. Pour une sécurité optimale des données, achetez un VPS auprès d'au moins deux fournisseurs différents pour la reprise après sinistre.

Il convient de noter que ce type de système de reprise après sinistre peut facilement échouer s'il n'est pas géré avec soin.

Au minimum, une fois le transfert de fichier terminé, vous devez vérifier si la taille du fichier de sauvegarde transféré est la même que la taille du fichier instantané d'origine. Si vous utilisez un VPS, vous pouvez également confirmer si le fichier est complètement transféré en comparant la somme de contrôle SHA1 du fichier.

De plus, vous avez également besoin d'un système d'alarme indépendant pour vous avertir lorsque le transfert (transfert) responsable du transfert des fichiers de sauvegarde échoue.

Réplication maître-esclave Redis

Redis prend en charge la fonction de réplication maître-esclave simple et facile à utiliser, qui permet au serveur esclave devient une réplique exacte du serveur maître.

Voici quelques aspects importants concernant la fonctionnalité de réplication de Redis :

Redis utilise la réplication asynchrone. À partir de Redis 2.8, le serveur esclave signalera la progression du traitement du flux de réplication au serveur maître une fois par seconde.

Un serveur maître peut avoir plusieurs serveurs esclaves.

Non seulement le serveur maître peut avoir des serveurs esclaves, mais le serveur esclave peut également avoir son propre serveur esclave. Plusieurs serveurs esclaves peuvent former une structure graphique.

La fonction de réplication ne bloque pas le serveur maître : même si un ou plusieurs serveurs esclaves sont en cours de synchronisation initiale, le serveur maître peut continuer à traiter les requêtes de commandes.

La fonction de réplication ne bloquera pas le serveur esclave : tant que les paramètres correspondants sont définis dans le fichier redis.conf, le serveur peut utiliser l'ancienne version de l'ensemble de données pour traiter les requêtes de commande même si l'esclave le serveur est en cours de synchronisation initiale.

Cependant, la demande de connexion sera bloquée pendant le temps où l'ancienne version de l'ensemble de données est supprimée du serveur et la nouvelle version de l'ensemble de données est chargée.

Vous pouvez également configurer le serveur esclave pour envoyer une erreur au client lorsque la connexion au serveur maître est perdue.

La fonction de réplication peut être utilisée uniquement pour la redondance des données, ou elle peut améliorer l'évolutivité en permettant à plusieurs serveurs esclaves de gérer les demandes de commande en lecture seule : par exemple, la commande lourde SORT peut laisser le soin au nœud subordonné de s'exécuter. .
Vous pouvez utiliser la fonction de réplication pour empêcher le serveur maître d'effectuer des opérations de persistance : désactivez simplement la fonction de persistance du serveur maître, puis laissez le serveur esclave effectuer les opérations de persistance.

Sécurité des données de la fonction de réplication lorsque la persistance du serveur principal est désactivée.

Lors de la configuration de la fonction de réplication Redis, il est fortement recommandé d'activer la fonction de persistance du serveur principal. Sinon, le service déployé doit éviter d’être automatiquement extrait en raison de la latence et d’autres problèmes.

Cas :

1. Supposons que le nœud A soit le serveur principal et que la persistance soit désactivée. Et le nœud B et le nœud C copient les données du nœud A

2. Le nœud A plante, puis redémarre le nœud A en activant automatiquement le service. Puisque la persistance du nœud A est désactivée, redémarrez. Il n'y aura plus de données par la suite

3. Le nœud B et le nœud C copieront les données du nœud A, mais les données de A sont vides, donc les copies de données qu'ils enregistrent seront supprimées.

Lorsque la persistance sur le serveur principal est désactivée et que le processus d'extraction automatique est activé en même temps, cela est très dangereux même si Sentinel est utilisé pour obtenir une haute disponibilité de Redis. Étant donné que le serveur principal peut être activé si rapidement que Sentinel ne détecte pas que le serveur principal a été redémarré dans l'intervalle de pulsation configuré, le processus de perte de données ci-dessus sera alors toujours exécuté.

La sécurité des données est extrêmement importante à tout moment, il devrait donc être interdit au serveur principal d'extraire automatiquement la persistance lorsqu'il est éteint.

Configuration du serveur esclave

Configurer un serveur esclave est très simple, il suffit d'ajouter la ligne suivante au fichier de configuration :
slaveof 192.168 .1.1 6379
Une autre méthode consiste à appeler la commande SLAVEOF, à saisir l'adresse IP et le port du serveur principal, puis la synchronisation démarrera
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK

Serveur esclave en lecture seule

À partir de Redis 2.6, le serveur esclave prend en charge le mode lecture seule, et ce mode est le mode par défaut de le serveur esclave.
Le mode lecture seule est contrôlé par l'option slave-read-only dans le fichier redis.conf. Ce mode peut également être activé ou désactivé via la commande CONFIG SET.

Le serveur esclave en lecture seule refusera d'exécuter des commandes d'écriture, de sorte que les données ne seront pas accidentellement écrites sur le serveur esclave en raison d'erreurs opérationnelles.

De plus, l'exécution de la commande SLAVEOF NO ONE sur un serveur esclave entraînera la désactivation de la fonction de réplication du serveur esclave et la transition du serveur esclave vers le serveur maître. L'ensemble de données synchronisées d'origine ne sera pas. écarté.

En utilisant la fonctionnalité « SLAVEOF NO ONE ne supprimera pas l'ensemble de données synchronisées », lorsque le serveur maître tombe en panne, le serveur esclave peut être utilisé comme nouveau serveur maître, permettant ainsi un fonctionnement ininterrompu.

Configuration liée au serveur esclave :

Si le serveur maître définit un mot de passe via l'option requirepass, alors afin de permettre l'opération de synchronisation de Pour que le serveur esclave se déroule sans problème, nous devons également définir les paramètres d'authentification correspondants pour le serveur esclave.

Pour un serveur en cours d'exécution, vous pouvez utiliser le client pour saisir la commande suivante :
config set masterauth
Pour définir ce mot de passe de manière permanente, vous pouvez l'ajouter au fichier de configuration :
masterauth

Le serveur maître n'effectuera les opérations d'écriture que lorsqu'il y a au moins N serveurs esclaves

À partir de Redis 2.8, afin d'assurer la sécurité des données, vous pouvez configurez le serveur maître pour qu'il exécute la commande d'écriture uniquement lorsqu'il y a au moins N serveurs esclaves actuellement connectés.

Cependant, comme Redis utilise la réplication asynchrone, les données d'écriture envoyées par le serveur maître peuvent ne pas être reçues par le serveur esclave. Par conséquent, la possibilité de perte de données existe toujours.

Voici comment fonctionne cette fonctionnalité :

L'esclave envoie un ping au maître une fois par seconde et signale le flux de réplication. Gérez la situation.
Le serveur maître enregistrera la dernière fois que chaque serveur esclave lui a envoyé un PING.

Les utilisateurs peuvent configurer la valeur maximale de la latence du réseau min-slaves-max-lag et le nombre minimum de serveurs esclaves requis pour effectuer les opérations d'écriture min-slaves-to-write .

S'il y a au moins des serveurs esclaves min-slaves-to-write et que les valeurs de latence de ces serveurs sont inférieures à min-slaves-max-lag secondes, alors le serveur maître effectuera l'écriture opération demandée par le client.

En revanche, si les conditions ne remplissent pas les conditions spécifiées par min-slaves-to-write et min-slaves-max-lag, alors l'opération d'écriture ne sera pas exécutée et le serveur principal effectuer la requête vers Le client pour l'opération d'écriture a renvoyé une erreur.

Voici les deux options de cette fonctionnalité et leurs paramètres requis :

min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>

Ce qui précède est l'intégralité du contenu de cet article, j'espère qu'il sera utile à l'apprentissage de chacun. Pour un contenu plus passionnant, vous pouvez prêter attention aux colonnes de didacticiels pertinentes du site Web PHP chinois ! ! !

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!