En savoir plus sur la réplication maître-esclave dans Redis

Cet article vous présentera la réplication maître-esclave dans Redis, présentera la configuration maître-esclave de base, ainsi que les fonctions et principes de la configuration maître-esclave. J'espère qu'il vous sera utile !

Redis prend en charge la fonction de réplication maître-esclave. Vous pouvez activer la fonction de réplication en exécutant slaveof (changé en réplicaof après la version Redis5) ou en définissant slaveof dans le fichier de configuration (changé en réplicaof après la version Redis5). [Recommandations associées : Tutoriel vidéo Redis]

• Un maître et deux clusters

• Un maître et plusieurs esclaves

Configuration de base maître-esclave

Configuration maître Redis

Configuration principale de Re dis Il n'est fondamentalement pas nécessaire de modifier. L'élément clé est de configurer à partir de Redis

Configurer à partir de Redis

1 Copier un fichier redis.conf

2.

3. Configurez la réplication maître-esclave

# salve的端口号
port 6380 

#把pid进程号写入pidfile配置的文件
pidfile /var/run/redis_6380.pid 

logfile "6380.log"  

#指定数据存放目录
dir /usr/local/redis‐5.0.3/data/6380 

#需要注释掉bind
#bind127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）

4. Démarrez le nœud esclave

#从本机master6379的redis实例复制数据，Redis5.0之前使用slaveof
replicaof 192.168.0.60 6379

#配置从节点只读
replica‐read‐only yes

5. Connectez le nœud esclave

redis‐server redis.conf

6. l'instance peut synchroniser les données nouvellement modifiées dans le temps

redis‐cli ‐p 6380

Configuration maître-esclave Le rôle de

Séparation de la lecture et de l'écriture

Un maître et plusieurs esclaves, synchronisation maître-esclave

• Le maître est responsable de l'écriture , et l'esclave est responsable de la lecture
• Améliorer les performances et le débit de Redis
• Problème de cohérence des données maître-esclave

Tolérance aux catastrophes de données

L'esclave est la sauvegarde de l'hôte

• L'hôte est en panne , l'esclave peut lire mais pas écrire
• Par défaut, une fois l'hôte en panne, l'esclave ne peut pas être utilisé par l'hôte
• Sentinel peut réaliser une commutation maître-esclave, pour atteindre une haute disponibilité
• Principe de fonctionnement du maître Redis- esclave

Copie complète de la réplication maître-esclave

Ce n'est que la première fois que le Redis esclave se connecte au Redis maître que la copie complète se produit. S'il s'agit d'un CV à court terme, il peut s'agir d'une copie complète. peut-être une copie partielle.

Organigramme

1. Établissez une longue connexion Socker avec le maître Redis

l'esclave établit une connexion socket avec le maître

processeur d'événements de fichiers associé à l'esclave

Ce processeur reçoit R Base de données fichiers (Copie complète), recevez la commande d'écriture transmise par le Maître (copie incrémentielle)

Après que le serveur maître ait accepté la connexion Socket du serveur esclave, il crée l'état client correspondant. Cela équivaut à ce que le serveur esclave soit le client du serveur maître.

Envoyer la commande ping

• L'esclave envoie la commande ping au maître

  • 1. Vérifiez l'état de lecture et d'écriture du socket
    2. Vérifiez si le maître peut le gérer normalement.

  Réponse du Maître :

  • 1. Envoyez "pong", indiquant un délai d'attente normal
    2.

    Vérification des autorisations
Une fois que le maître et l'esclave sont connectés normalement, effectuez la vérification des autorisations

Le maître n'a pas défini de mot de passe (requirepass="") et il n'est pas nécessaire de définir un mot de passe (masterauth="")

Le maître définit un mot de passe (requirepass! =""), de la nécessité de définir un mot de passe (masterauth=la valeur du requirepass du maître)

• ou de l'envoi du mot de passe au maître via le commande auth

2. Le maître Redis reçoit la commande PSYNC

Le maître Redis reçoit L'exécution de la commande bgsave après que la commande PSYNC génère le dernier instantané rdb

3. instantané au Redis esclave.

Lorsque le maître Redis envoie l'instantané rdb au Redis esclave, le maître continuera à recevoir les requêtes du client. Il mettra en cache ces requêtes susceptibles de modifier l'ensemble de données en mémoire et les stockera dans le. cache tampon relp

• Phase d'instantané de synchronisation : le maître crée et envoie l'instantané RDB à l'esclave, et l'esclave charge et analyse l'instantané. Le Maître stocke également dans le tampon les nouvelles commandes d'écriture générées lors de cette phase.

4. Le nœud esclave reçoit l'instantané rdb

Une fois que le nœud esclave a reçu l'instantané rdb, il efface les anciennes données et charge le fichier rdb

5 Le maître Redis envoie le fichier de cache tampon au. slave Redis

Synchroniser le tampon d'écriture Étape : Le maître synchronise la commande d'opération d'écriture stockée dans le tampon avec l'esclave.

6. Le nœud esclave reçoit le fichier cache tampon

Le nœud esclave reçoit le fichier cache tampon et charge le fichier cache tampon dans la mémoire

7 Le Redis maître envoie en continu des commandes au nœud esclave via le. Connexion longue Socker

Recevez la commande envoyée par le maître Redis depuis Redis et exécutez la commande actuelle

Aperçu

Si vous configurez un esclave pour le maître, que l'esclave soit connecté ou non au maître pour la première fois temps, il enverra une commande PSYNC au maître demande de copier les données. Après avoir reçu la commande PSYNC, le maître effectuera la persistance des données en arrière-plan et générera le dernier fichier d'instantané RDB via bgsave. Pendant la période de persistance, le maître continuera à recevoir les demandes des clients et mettra en cache ces demandes susceptibles de modifier les données. mis en mémoire. Lorsque la persistance est terminée, le maître enverra l'ensemble de données du fichier RDB à l'esclave, et l'esclave conservera les données reçues pour générer du RDB, puis les chargera dans la mémoire. Ensuite, le maître envoie la commande préalablement mise en cache en mémoire à l'esclave. Lorsque la connexion entre le maître et l'esclave est déconnectée pour une raison quelconque, l'esclave peut se reconnecter automatiquement au maître. Si le maître reçoit plusieurs demandes de connexion simultanées à l'esclave, elle ne persistera qu'une fois, pas une fois pour chaque connexion, puis enverra. ces données persistantes à plusieurs esclaves connectés simultanément.

Copie partielle de la copie maître-esclave

Le processus général est similaire à la copie complète, je ne l'expliquerai donc pas en détail

Brève description

Lorsque le maître et l'esclave sont déconnectés et reconnecté, toutes les données seront généralement faites une copie. Cependant, à partir de la version 2.8 de Redis, Redis utilise la commande PSYNC qui peut prendre en charge la réplication partielle des données pour synchroniser les données avec le maître. L'esclave et le maître ne peuvent effectuer une réplication partielle des données (reprise de la transmission) qu'une fois la connexion réseau déconnectée et reconnectée. Le maître créera une file d'attente de cache pour copier les données dans sa mémoire afin de mettre en cache les données de la période la plus récente. Le maître et tous ses esclaves conservent le décalage d'indice des données copiées et l'identifiant de processus du maître. Par conséquent, lorsque la connexion réseau est déconnectée, Ensuite, l'esclave demandera au maître de poursuivre la réplication inachevée, à partir de l'index des données enregistrées. Si l'ID du processus maître change ou si le décalage des données du nœud esclave est trop ancien et ne se trouve plus dans la file d'attente du cache du maître, une copie complète des données sera effectuée. Organigramme de la réplication maître-esclave (réplication partielle, reprise du point d'arrêt) :

Synchronisation incrémentielle de la réplication maître-esclave

• La synchronisation incrémentielle Redis fait principalement référence aux opérations d'écriture qui se produisent sur le maître lorsque l'esclave termine l'initialisation et démarre pour fonctionner normalement. Le processus de synchronisation avec l'esclave.

• Normalement, chaque fois que le maître exécute une commande d'écriture, il enverra la même commande d'écriture à l'esclave, puis l'esclave la recevra et l'exécutera.

Détection du rythme cardiaque de la réplication maître-esclave

1. Détectez l'état de connexion du serveur maître-esclave

Détectez l'état de la connexion réseau du serveur maître-esclave en envoyant la commande de réplication INFO à. le serveur maître, vous pouvez lister la liste des serveurs esclaves. Vous pouvez voir combien de secondes se sont écoulées depuis que la dernière commande a été envoyée au maître. La valeur de lag doit sauter entre 0 et 1. Si elle dépasse 1, cela signifie que la connexion entre le maître et l'esclave est défectueuse.

2. Implémentation auxiliaire de min-slaves

Redis peut être configuré pour empêcher le serveur principal d'exécuter la commande d'écriture min-slaves-to-write 3 (min-replicas-to-write 3) sous conditions dangereuses -max-lag 10 (min-replicas-max-lag 10) La configuration ci-dessus signifie : lorsque le nombre de serveurs esclaves est inférieur à 3, ou que la valeur du délai (lag) des trois serveurs esclaves est supérieure ou égale à 10 secondes, le serveur maître L'exécution de la commande d'écriture sera refusée. La valeur du délai ici est la valeur de décalage de la commande INForeplication ci-dessus.

3. Détecter la perte de commande

Si la commande d'écriture transmise du serveur maître au serveur esclave est perdue à mi-chemin en raison d'une panne de réseau, alors lorsque le serveur esclave envoie la commande REPLCONF ACK au serveur maître, le maître Le serveur remarquera l'état actuel du serveur esclave. Si le décalage de réplication est inférieur à son propre décalage de réplication, le serveur maître trouvera les données manquantes du serveur esclave dans le tampon du backlog de réplication en fonction du décalage de réplication soumis par l'esclave. serveur et renvoyer les données au serveur esclave. (Réédition) Le réseau est continuellement synchronisé de manière incrémentale : le réseau est déconnecté, et lorsqu'il est reconnecté

Comment juger une copie complète ou partielle

Une fois que le client a envoyé la sauvegarde, le nœud maître jugera s'il est copié pour la première fois. Si tel est le cas, il effectuera une copie complète si elle n'est pas cohérente. , il sera jugé par le décalage runid. S'ils sont cohérents, une copie partielle est effectuée, sinon une copie complète est effectuée.

Pour plus de connaissances sur la programmation, veuillez visiter : Vidéos de programmation ! !

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!