Principe de fonctionnement de la réplication maître-esclave Redis et problèmes courants

Je pense que de nombreux amis ont déjà configuré la réplication maître-esclave, mais ils n'ont pas une compréhension approfondie du flux de travail et des problèmes courants de la réplication maître-esclave Redis. Kaka a passé cette fois deux jours à compiler tous les points de connaissances sur la réplication maître-esclave Redis.

L'environnement requis pour implémenter cet article

centos7.0

redis4.0

1. Qu'est-ce que la réplication maître-esclave Redis ?

La réplication maître-esclave signifie qu'il existe désormais deux serveurs Redis et que les données d'un Redis sont synchronisées avec l'autre base de données Redis. Le premier est appelé nœud maître et le second est le nœud esclave. Les données ne peuvent être synchronisées que dans un seul sens, du maître vers l'esclave.

Mais dans le processus réel, il est impossible d'avoir seulement deux serveurs Redis pour la réplication maître-esclave, ce qui signifie que chaque serveur Redis peut être appelé le nœud maître (master )

Dans le cas ci-dessous, notre esclave3 est à la fois le nœud esclave du maître et le nœud maître de l'esclave.

Comprenez d'abord ce concept et continuez à lire ci-dessous pour plus de détails.

2. Pourquoi la réplication maître-esclave Redis est-elle nécessaire ?

Supposons que nous ayons maintenant un serveur Redis, qui est un état autonome.

Le premier problème qui se posera dans ce cas est que le serveur est en panne, ce qui entraîne directement une perte de données. Si le projet est lié au RMB, les conséquences peuvent être imaginées.

La deuxième situation est le problème de mémoire. Lorsqu'il n'y a qu'un seul serveur, la mémoire atteindra certainement son maximum. Il est impossible de mettre à niveau un serveur à l'infini.

Donc, en réponse aux deux problèmes ci-dessus, nous allons préparer quelques serveurs supplémentaires et configurer la réplication maître-esclave. Stockez les données sur plusieurs serveurs. Et assurez-vous que les données de chaque serveur sont synchronisées. Même si un serveur tombe en panne, cela n'affectera pas l'utilisation des utilisateurs. Redis peut continuer à assurer une haute disponibilité et une sauvegarde redondante des données.

Il devrait y avoir beaucoup de questions à ce stade. Comment connecter le maître et l'esclave ? Comment synchroniser les données ? Et si le serveur maître tombe en panne ? Ne vous inquiétez pas, résolvez vos problèmes petit à petit.

3. Le rôle de la réplication maître-esclave Redis

Nous avons expliqué ci-dessus pourquoi nous utilisons la réplication maître-esclave de Redis, donc le rôle de la réplication maître-esclave est d'expliquer pourquoi elle est utilisée.

1. Continuons à utiliser ce diagramme pour parler de
2. Le premier point est la redondance des données, la sauvegarde à chaud des données est réalisée, ce qui est la persistance Une autre façon.
3. Le deuxième point concerne la panne d’une seule machine. Lorsqu'il y a un problème avec le nœud maître, le service peut être fourni par le nœud esclave, qui est l'esclave, permettant une récupération rapide après les pannes, ce qui constitue une redondance du service.
4. Le troisième point est la séparation de la lecture et de l'écriture. Le serveur maître est principalement utilisé pour l'écriture, et l'esclave est principalement utilisé pour la lecture des données, ce qui peut améliorer la capacité de charge du serveur. Dans le même temps, le nombre de nœuds esclaves peut être ajouté en fonction de l'évolution de la demande.
5. Le quatrième point est l'équilibrage de charge. En conjonction avec la séparation de la lecture et de l'écriture, le nœud maître fournit des services d'écriture et les nœuds esclaves fournissent des services de lecture pour partager la charge du serveur. plus de lecture, via plusieurs nœuds esclaves Le partage de la charge de lecture peut considérablement augmenter la concurrence et la charge du serveur Redis.
6. Le cinquième point est la pierre angulaire de la haute disponibilité. La réplication maître-esclave est la base de la mise en œuvre de Sentinel et du cluster, nous pouvons donc dire que la réplication maître-esclave est la pierre angulaire de la haute disponibilité.

4. Configurer la réplication maître-esclave Redis

Voilà, commençons simplement par configurer un cas de réplication maître-esclave, puis parlons des principes de mise en œuvre.

Le chemin de stockage Redis est : usr/local/redis

Les fichiers journaux et de configuration sont stockés dans : usr/local /redis/data

Nous configurons d'abord deux fichiers de configuration, à savoir redis6379.conf et redis6380.conf

Modifiez le fichier de configuration, principalement pour modifier le port. Pour faciliter la visualisation, les noms des fichiers journaux et des fichiers persistants sont identifiés avec leurs ports respectifs.

Ensuite, ouvrez deux services Redis, un avec le port 6379 et un avec le port 6380. Exécutez la commande redis-server redis6380.conf, puis utilisez redis-cli -p 6380 pour vous connecter. Étant donné que le port par défaut de redis est 6379, nous pouvons démarrer un autre serveur Redis et utiliser directement redis-server redis6379.conf, puis utiliser redis-cli pour nous connecter directement.

À l'heure actuelle, nous avons configuré avec succès deux services Redis, l'un est 6380 et l'autre est 6379. Ceci est juste à titre de démonstration. Dans la réalité, il doit être configuré sur deux serveurs différents.

1. Utilisez la ligne de commande du client pour démarrer

Il faut d'abord avoir un concept, c'est-à-dire que lors de la configuration de la réplication maître-esclave, toutes les opérations sont effectuées sur le nœud esclave, c'est-à-dire l'esclave.

Ensuite, nous exécutons une commande en tant que slaveof 127.0.0.1 6379 depuis le nœud esclave. Une fois exécuté, cela signifie que nous sommes connectés.

Testons d'abord pour voir si la réplication maître-esclave est implémentée. Exécutez deux set kaka 123 和 set master 127.0.0.1 sur le serveur maître, puis le port slave6380 pourra être obtenu avec succès, ce qui signifie que notre réplication maître-esclave a été configurée. Cependant, la mise en œuvre de l'environnement de production n'est pas la fin du monde. Plus tard, la réplication maître-esclave sera encore optimisée jusqu'à atteindre une haute disponibilité.

2. Utilisez le fichier de configuration pour activer

Avant d'utiliser le fichier de configuration pour démarrer la réplication maître-esclave ! Tout d'abord, vous devez déconnecter la connexion précédente à l'aide de la ligne de commande client et exécuter slaveof no one sur l'hôte esclave pour déconnecter la réplication maître-esclave.

Où puis-je vérifier que le nœud esclave s'est déconnecté du nœud maître ? Entrez la ligne de commande info sur le client du nœud maître pour afficher

Cette image montre les informations imprimées en saisissant info sur le client du nœud maître après avoir utilisé le nœud esclave pour vous connecter au nœud maître à l'aide de la ligne de commande client. Vous pouvez voir qu'il y a une information sur slave0. .

Cette image est imprimée sur le nœud maître après que slaveof no one soit exécuté sur le nœud esclave, indiquant que le nœud esclave a communiqué avec le maître nœud Déconnecté. info

démarre le service Redis selon le fichier de configuration,

redis-server redis6380.conf

Après le nœud redémarre, vous pouvez visualiser directement les informations de connexion du nœud esclave sur le nœud maître.

Données de test, les éléments écrits par le nœud maître seront toujours automatiquement synchronisés par le nœud esclave.

3. Démarrer au démarrage du serveur Redis

Cette méthode de configuration est également très simple. Lors du démarrage du serveur redis, démarrez directement la réplication maître-esclave et exécutez la commande : redis-server --slaveof host port.

4. Afficher les informations du journal après le démarrage de la réplication maître-esclave

Ceci sont les informations du journal du nœud maître

Il s'agit des informations du nœud esclave, y compris les informations de connexion du nœud maître et la sauvegarde de l'instantané RDB.

5. Principe de fonctionnement de la réplication maître-esclave

1. Trois étapes de réplication maître-esclave

Le flux de travail complet de la réplication maître-esclave est divisé en trois étapes suivantes. Chaque segment a son propre flux de travail interne, nous parlerons donc de trois processus de processus.

• Processus d'établissement de connexion : Ce processus est le processus de connexion de l'esclave au maître
• Processus de synchronisation des données : C'est le processus de synchronisation des données du maître à l'esclave
• Processus de propagation des commandes : il s'agit de données de synchronisation répétées
  

Phase 1 : Processus d'établissement de la connexion

<.>

L'image ci-dessus est un workflow complet d'établissement de connexion de réplication maître-esclave. Utilisez ensuite des mots courts pour décrire le flux de travail ci-dessus.

Définissez l'adresse et le port du maître, enregistrez les informations du maître
1. Établissez une connexion socket (le rôle de cette connexion sera décrit ci-dessous)
2. Envoyer en continu la commande ping
3. Authentification
4. Envoyer les informations du port esclave

Pendant le processus d'établissement d'une connexion, le nœud esclave enregistrera l'adresse et le port du maître, et le nœud maître enregistrera le port du nœud esclave.

3. Phase 2 : Processus de synchronisation des données

Cette image décrit en détail le processus de synchronisation des données lorsque le nœud esclave se connecte au nœud maître pour la première fois.

Lorsque le nœud esclave se connecte au nœud maître pour la première fois, il effectuera d'abord une copie complète. Cette copie complète est inévitable.

Une fois la réplication complète terminée, le nœud maître enverra les données dans le tampon du backlog de réplication, puis le nœud esclave exécutera bgrewriteaof pour restaurer les données, ce qui est réplication partielle.

Trois nouveaux points sont évoqués à ce stade, la copie complète, la copie partielle et le retard du tampon de copie. Ces points seront expliqués en détail dans la FAQ ci-dessous.

4. La troisième étape : étape de propagation des commandes

Lorsque la base de données maître est modifiée et que les données sur les serveurs maître et esclave sont incohérentes, les données maître et esclave seront synchronisées pour être cohérentes. Ce processus est appelé propagation de commandes.

Le maître enverra la commande de modification des données reçue à l'esclave, et l'esclave exécutera la commande après avoir reçu la commande pour rendre les données maître-esclave cohérentes.

Une copie partielle pendant la phase de propagation des commandes

• se produit pendant la phase de propagation des commandes Une déconnexion ou une gigue du réseau entraînera la perte de la connexion (connexion perdue)
• À ce moment, le nœud maître continuera à écrire des données dans le replbackbuffer (zone de backlog du tampon de réplication)
• Esclave node Continuera à essayer de se connecter au maître
• Lorsque le nœud esclave envoie son runid et son décalage de réplication au nœud maître, et exécute la commande pysnc pour synchroniser
• Si le maître détermine le décalage se trouve dans la plage du tampon de copie, la commande continue sera renvoyée. Et envoyez les données dans le tampon de copie au nœud esclave.
• Le nœud esclave reçoit des données et exécute bgrewriteaof pour restaurer les données

Introduction détaillée au principe de la réplication maître-esclave (complète). réplication + réplication partielle)

Ce processus est l'explication la plus complète du processus de réplication maître-esclave. Alors présentons brièvement chaque étape du processus

1. Envoyez la commande depuis le nœud psync ? 1 psync runid offset pour trouver le runid correspondant pour demander des données. Mais ici vous pouvez considérer que lorsque le nœud esclave se connecte pour la première fois, il ne connaît pas du tout le runid 和 offset du nœud maître. Donc la commande envoyée pour la première fois est psync ？ 1, ce qui signifie que je veux toutes les données du nœud maître.
2. Le nœud maître commence à exécuter bgsave pour générer le fichier RDB et enregistrer le décalage de réplication actuel
3. À ce moment, le nœud maître enverra son propre runid et son décalage via le runid +FULLRESYNC Commande offset pour envoyer le RDB via le fichier socket au nœud esclave.
4. Le nœud esclave reçoit +FULLRESYNC, enregistre le runid et le décalage du nœud maître, puis efface toutes les données actuelles, reçoit le fichier RDB via le socket et commence à restaurer les données RDB.
5. Après la réplication complète, le nœud esclave a obtenu le runid et le décalage du nœud maître, et commence à envoyer des instructions. psync runid offset
6. Le nœud maître reçoit les instructions, détermine si le runid correspond, et détermine si le décalage est copié dans le tampon.
7. Le nœud maître détermine que l'un des runid et offset n'est pas satisfait et reviendra à l'étape 2 pour continuer à effectuer la réplication complète. L'inadéquation du runid ici peut être uniquement due au redémarrage du nœud esclave. Ce problème sera résolu plus tard. L'inadéquation du décalage (offset) est le dépassement du tampon du retard de réplication. Si la vérification runid ou offset réussit, si le décalage du nœud esclave est le même que celui du nœud maître, il sera ignoré. Si la vérification runid ou offset réussit et que le décalage du nœud esclave est différent du décalage, +CONTINUE offset (ce décalage appartient au nœud maître) sera envoyé, et les données du décalage du nœud esclave vers le décalage du nœud maître dans le tampon de réplication sera envoyé via le socket.
8. Recevez +CONTINUE du nœud et enregistrez le décalage du maître Après avoir reçu les informations via le socket, exécutez bgrewriteaof pour restaurer les données.

1-4 sont des copies complètes 5-8 sont des copies partielles

À l'étape 3 du nœud maître, le nœud maître a reçu des données client pendant la période de réplication maître-esclave et le décalage du nœud maître a changé. Seules les modifications seront envoyées à chaque esclave. Ce processus d'envoi est appelé mécanisme de battement de cœur

.

7. Mécanisme Heartbeat

Pendant l'étape de propagation des commandes, le nœud maître et le nœud esclave doivent toujours échanger des informations. Basculez et utilisez le mécanisme de battement de cœur pour la maintenance afin de maintenir la connexion entre le nœud maître et le nœud esclave en ligne.

• battement de coeur principal

• Commande : ping
• par défaut toutes les 10 secondes, il est déterminé par le paramètre repl-ping-slave-period
• La principale chose qu'il fait est de déterminer si le nœud esclave est en ligne
• Vous pouvez utiliser la réplication des informations pour vérifier l'intervalle de temps de connexion après la location du nœud esclave. Si le décalage est de 0 ou 1, c'est un état normal.

• tâche de battement de coeur esclave

• Commande : replconf ack {offset}
• Exécuter une fois par seconde
• La principale chose qu'il fait est d'envoyer son propre décalage de réplication au nœud maître, d'obtenir la dernière commande de modification de données du nœud maître et de déterminer également si le nœud maître est en ligne.

Précautions pendant la phase de battement de cœur

Afin d'assurer la stabilité des données, le nœud maître Lorsque le nombre de chutes ou le délai est trop élevé. Toute synchronisation des informations sera refusée.

Il existe deux paramètres pour le réglage de la configuration :

min-esclaves-à-écrire 2

min-esclaves-max-lag 8

ce Les deux paramètres indiquent qu'il ne reste que 2 nœuds esclaves, ou lorsque le délai du nœud esclave est supérieur à 8 secondes, le nœud maître désactivera de force la fonction maître et arrêtera la synchronisation des données.

Et si le nœud maître connaît les données et le délai du nœud esclave qui raccroche ! Dans le mécanisme de battement de cœur, l'esclave enverra la commande perlconf ack toutes les secondes. Cette commande peut transporter le décalage, le temps de retard du nœud esclave et le nombre de nœuds esclaves.

8. Trois éléments essentiels de la réplication partielle

1. ID d'exécution du serveur (ID d'exécution)

Voyons d'abord ce qu'est cet identifiant d'exécution. Vous pouvez le voir en exécutant la commande info. Nous pouvons également le voir lorsque nous examinons les informations du journal de démarrage ci-dessus.

Redis générera automatiquement un identifiant aléatoire au démarrage (il convient de noter ici que l'ID sera différent à chaque démarrage), composé de 40 chaînes hexadécimales aléatoires et utilisé pour identifier de manière unique un nœud Redis. .

Lorsque la réplication maître-esclave est démarrée pour la première fois, le maître enverra son runid à l'esclave, et l'esclave enregistrera l'identifiant du maître. Nous pouvons utiliser la commande info. pour le visualiser

Lorsqu'il est déconnecté et reconnecté, l'esclave envoie cet ID au maître, si le runid enregistré par l'esclave est le même que le runid actuel du maître, le maître essaiera d'utiliser la réplication partielle (un autre facteur pour savoir si ce bloc peut être copié avec succès est le décalage). Si le runid enregistré par l'esclave est différent du runid actuel du maître, la copie complète sera effectuée directement.

2. Tampon de retard de copie

Le retard de tampon de copie est une file d'attente premier entré, premier sorti, stockage utilisateur Enregistrements de commandes principales pour la collecte de données. L'espace de stockage par défaut du tampon de copie est de 1 Mo.

Vous pouvez modifier repl-backlog-size 1mb dans le fichier de configuration pour contrôler la taille du tampon. Ce ratio peut être modifié en fonction de la mémoire de votre propre serveur que Kaka a réservée 30 % environ.

Que stocke exactement le tampon de copie ?

Lors de l'exécution d'une commande en tant que set name kaka, nous pouvons afficher le fichier de persistance pour afficher

Ensuite, le tampon du backlog de copie est la quantité stockée de données persistantes, séparées par des octets, et chaque octet a son propre décalage. Ce décalage est également le décalage de copie (offset)

Alors pourquoi dit-on que le retard du tampon de copie peut provoquer une copie complète

Pendant la phase de propagation des commandes, le nœud maître stockera les données collectées dans le tampon de réplication puis les enverra au nœud esclave. C'est là que le problème se pose. Lorsque la quantité de données sur le nœud maître est extrêmement importante en un instant et dépasse la mémoire du tampon de réplication, certaines données seront supprimées, entraînant une incohérence des données entre le nœud maître et l'esclave. nœud. Pour en faire une copie complète. Si la taille du tampon n'est pas définie de manière appropriée, cela peut provoquer une boucle infinie. Le nœud esclave copiera toujours intégralement, effacera les données et copiera intégralement.

3. Copie offset (offset)

Le décalage de réplication du nœud maître consiste à envoyer un enregistrement une fois au nœud esclave, et le nœud esclave doit recevoir un enregistrement une fois.

est utilisé pour synchroniser les informations, comparer les différences entre le nœud maître et le nœud esclave et restaurer l'utilisation des données lorsque l'esclave est déconnecté.

Cette valeur est le décalage par rapport au retard du tampon de copie.

9. Problèmes courants avec la réplication maître-esclave

1. Problème de redémarrage du nœud maître (optimisation interne)

Lorsque le nœud maître redémarre, la valeur de runid changera, ce qui entraînera une réplication complète de tous les nœuds esclaves.

Nous n'avons pas besoin de considérer cette question, tant que nous savons comment le système est optimisé.

Une fois la réplication maître-esclave établie, le nœud maître créera la variable maître-réplid. La stratégie générée est la même que celle du runid, avec une longueur de 41. bits et une longueur runid de 40 bits. Puis envoyé au nœud esclave.

Lorsque la commande shutdown save est exécutée sur le nœud maître, une persistance RDB est effectuée et le runid et le offset sont enregistrés dans le fichier RDB. Vous pouvez utiliser la commande redis-check-rdb pour afficher ces informations.

Chargez le fichier RDB après le redémarrage du nœud maître, puis chargez le repl-id et le repl-offset dans le fichier en mémoire. Même si tous les nœuds esclaves sont considérés comme les nœuds maîtres précédents.

2. Le décalage d'interruption du réseau du nœud esclave traverse la limite, provoquant une réplication complète

En raison d'un mauvais environnement réseau. , la panne du réseau du nœud esclave. La mémoire tampon du retard de réplication est trop petite, ce qui entraîne un débordement de données. Parallèlement au décalage du nœud esclave dépassant la limite, une réplication complète se produit. Cela peut entraîner des copies complètes répétées.

Solution : Modifier la taille du tampon du backlog de réplication : repl-backlog-size

Recommandation de configuration : Tester l'heure de connexion du maître du nœud esclave, obtenez le nombre total moyen de commandes générées par le nœud maître par seconde write_size_per_second

Réglage de l'espace tampon de copie = 2 Temps de connexion maître-esclave Maître La quantité totale de données générées par le nœud par seconde

3 Interruptions fréquentes du réseau

dues. au processeur du nœud maître L'occupation est trop élevée ou le nœud esclave est fréquemment connecté. Le résultat de cette situation est que diverses ressources du nœud maître sont sérieusement occupées, notamment, mais sans s'y limiter, les tampons, la bande passante, les connexions, etc.

Pourquoi les ressources du nœud maître sont-elles fortement occupées ?

Dans le mécanisme de battement de cœur, le nœud esclave enverra une commande replconf ack au nœud maître toutes les secondes.

Le nœud esclave a exécuté une requête lente, occupant beaucoup de CPU

Le nœud maître a appelé la fonction de synchronisation de réplication replicationCron toutes les secondes, puis le nœud esclave n'a pas répondu pendant longtemps.

Solution :

Définir la libération du délai d'expiration du nœud esclave

Définir les paramètres : repl-timeout

Ce paramètre est par défaut de 60 secondes . Après 60 secondes, relâchez l'esclave.

4. Problème d'incohérence des données

En raison de facteurs de réseau, les données de plusieurs nœuds esclaves seront incohérentes. Il n'y a aucun moyen d'éviter ce facteur.

Il existe deux solutions à ce problème :

Les premières données nécessitent une configuration très cohérente. utilise un seul serveur pour la lecture et l'écriture. Cette méthode est limitée à une petite quantité de données et les données doivent être très cohérentes.

Le second surveille le décalage des nœuds maître et esclave. Si le délai du nœud esclave est trop important, l'accès du client au nœud esclave est temporairement bloqué. Définissez le paramètre sur slave-serve-stale-data yes|no. Une fois ce paramètre défini, il ne peut répondre qu'à quelques commandes telles que info slaveof.

10. Résumé

Cet article explique principalement ce qu'est la réplication maître-esclave et les trois aspects majeurs du maître. -réplication esclave Étapes, flux de travail et trois composants principaux de la réplication partielle. Mécanisme de battement de coeur pendant la phase de propagation des commandes. Enfin, les problèmes courants liés à la réplication maître-esclave sont expliqués.

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!