Redis Cluster est une version avancée de Redis qui est distribuée et autorise des points de défaillance uniques. Le cluster Redis n'a pas de nœud le plus important ou central. L'un des principaux objectifs de cette version est de concevoir une fonction évolutive linéaire (des nœuds peuvent être ajoutés et supprimés à volonté).
Cet article présente principalement le contenu pertinent de l'analyse détaillée des échecs du cluster Redis. J'espère qu'il pourra aider tout le monde.
Symptômes de panne :
L'affichage au niveau de l'entreprise indique que la requête Redis a échoué
Composition du cluster :
3 maîtres et 3 esclaves, chaque nœud dispose de 8 Go de données
Distribution machine :
Dans le même rack,
xx.x.xxx.199
xx.x.xxx.200
xx.x.xxx.201
État du processus redis-server :
Par la commande ps -eo pid,lstart | grep $pid,
a constaté que le processus a été fonctionnant en continu 3 mois
L'état du nœud du cluster avant la panne :
xx.x.xxx.200:8371(bedab2c537fe94f8c0363ac4ae97d56832316e65) maître
xx.x.xxx.199:8373(792020fe66c00ae56e27cd7a048ba6bb2b67adb6) esclave
xx.x.xxx.201:8375(5ab4f85306da6d633e4834b4d3327f45af02171b) maître
xx.x.xxx.201:8372(826607654f5ec81c3756a4a21f357e644efe605a) esclave
xx.x.xxx.199:8370(462cadcb41e635d460425430d318f2fe464665c5) maître
xx.x.xxx.200:8374(1238085b578390f3c8efa30824fd9a4baba10ddf) esclave
------- -- --------------Ce qui suit est l'analyse du journal------------------ ---- ----------------
Étape 1 :
Le nœud maître 8371 perd la connexion avec nœud esclave 8373 :
46590:M 09 Sep 18:57:51.379 # Connexion avec l'esclave xx.x.xxx.199:8373 perdue.
Étape 2 :
Le nœud maître 8370/8375 détermine que 8371 est perdu :
42645:M 09 Sep 18:57:50.117 * Marquage du nœud bedab2c537fe94f8c0363ac4ae97d56832316e65 comme étant en échec (quorum atteint).
Étape 3 :
Le nœud esclave 8372/8373/8374 a reçu le nœud maître 8375 indiquant que 8371 a perdu le contact :
46986:S 09 septembre 18:57:50.120 * Message FAIL reçu de 5ab4f85306da6d633e4834b4d3327f45af02 171b à propos de bedab2c 537fe94f8c0363ac4ae97d56832316e65
Étape 4 :
Le nœud maître 8370/8375 autorise 8373 à passer au transfert de nœud maître :
42645:M 09 septembre 18:57:51.055 # Authentification de basculement accordée à 792020fe66c00ae56e27cd7a048ba6bb2b67adb6 pour l'époque 16
Étape 5 :
Le nœud maître d'origine 8371 modifie sa configuration et devient le nœud esclave de 8373 :
46590:M 09 septembre 18:57:51.488 # Changement de configuration détecté. Me reconfigurer en tant que réplique de 792020fe66c00ae56e27cd7a048ba6bb2b67adb6
Étape 6 :
Le nœud maître 8370/8375/8373 efface 8371. statut :
42645:M 09 Sep 18:57:51.522 * Effacer l'état FAIL pour le nœud bedab2c537fe94f8c0363ac4ae97d56832316e65 : le maître sans slots est à nouveau accessible, les premières données de synchronisation complète :
8373 log ::
4255:M 09 septembre 18:57:51.906 * Démarrage de BGSAVE pour SYNC avec la cible : disque4255:M 09 septembre 18:57:51.941 * Sauvegarde en arrière-plan lancée par le pid 52308371 Journal ::
46590:S 9 septembre 18:57:51.948 * Resynchronisation complète à partir du maître : d7751c4ebf1e63d3baebea1ed409e0e7243a4423:44072182699 3
Étape 8 :
Nœud maître 8370/8375 décision 8 373 (nouveau propriétaire) contact perdu :
42645:M 09 septembre 18:58:00.320 * Marquage du nœud 792020fe66c00ae56e27cd7a048ba6bb2b67adb6 comme défaillant ( quorum atteint) .
Étape 9 :
Nœud maître 837 0/8375jugement 8373 (nouveau maître) restauré :
60295:M 09 septembre 18:58:18.181 * Effacer État FAIL pour le nœud 792020fe66c00ae56e27cd7a048ba6bb2b67adb6 : est à nouveau accessible et personne ne dessert ses emplacements après un certain temps.
Étape 10 :
L'opération BGSAVE requise pour que le nœud maître 8373 se termine synchronisation complète :
5230:C 09 septembre 18:59:01.474 * DB enregistrée sur le disque
4255:M 09 septembre 18:59:01.877 * L'enregistrement en arrière-plan s'est terminé avec succès
Étape 11 :
Le nœud esclave 8371 commence à recevoir des données du nœud maître 8373 :
46590:S 09 Sep 18:59:02.263 * Synchronisation MASTER <-> SLAVE : réception de 2657606930 octets du maître
Étape 12 :
Nœud maître 8373 constate que le nœud esclave 8371 a restreint le tampon de sortie :
4255:M 09 Sep 19:00:19.014 # Client id =14259015 addr=xx.x.xxx.200:21772 fd=844 name= age=148 inactif =148 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl= 16349 oll=4103 omem=95944066 events=rw cmd=psync doit être fermé dès que possible pour surmonter la sortie limites de tampon.
Étape 13 : Étape 14 : Étape 15 : Étape 16 : Étape 17 : Cluster revient à la normale : 8371 Raison de la perte de contact Analyse : Comme plusieurs machines sont dans le même rack, il est peu probable qu'une interruption du réseau se produise, j'ai donc vérifié la requête lente connectez-vous via la commande SLOWLOG GET et constatez qu'il y a un La commande KEYS a été exécutée, ce qui a pris 8,3 secondes. Après avoir vérifié le paramètre de délai d'expiration du nœud de cluster, il a été constaté qu'il était de 5 secondes (cluster-node-timeout 5000)<.> 9/9/2016 18:57:43 Démarrer l'exécution de la commande KEYS 9/9/2016 18:57:50 8371 a été jugé déconnecté (journal Redis) En résumé, il y a les problèmes suivants : 3. En raison de la limitation de la configuration du client-output-buffer-limit, la première synchronisation complète a échoué
Passer à l'action : 1. Coupez l'instance unique à moins de 4G, sinon le commutateur maître-esclave prendra beaucoup de temps 2 Ajustez le paramètre client-output-buffer-limit, empêchez la synchronisation d'échouer. le milieu Explication détaillée des connaissances sur la spécification du cluster Redis
Le nœud esclave 8371 n'a pas réussi à synchroniser les données du nœud maître 8373, la connexion a été interrompue et la première synchronisation complète a échoué :
46590:S 09 septembre 19h00 :19.018 # Erreur d'E/S lors de la tentative de synchronisation avec MASTER : connexion perdue
46590:S 09 Sep 19:00:20.102 * Connexion à MASTER xx.x.xxx.199:8373
46590:S 09 Sep 19 :00 :20.102 * La synchronisation MASTER <-> SLAVE a démarré
Redémarrez la synchronisation à partir du nœud 8371, la connexion a échoué et le nombre de connexions du nœud maître 8373 est plein :
46590:S 09 septembre 19:00:21.103 * Connexion au MASTER xx.x.xxx.199:8373
46590:S 09 septembre 19:00:21.103 * MASTER < ;-> La synchronisation SLAVE a démarré
46590:S 09 septembre 19:00:21.104 * La connexion non bloquante pour SYNC a déclenché l'événement.
46590:S 09 septembre 19:00:21.104 # Réponse d'erreur au PING du maître : '-ERR nombre maximum de clients atteint'
Le nœud esclave 8371 se reconnecte au nœud maître 8373 et démarre la synchronisation complète pour la deuxième fois :
8371 log :
46590:S 09 septembre 19:00:49.175 * Connexion à MASTER xx.x.xxx.199:8373
46590:S 09 septembre 19:00:49.175 * MASTER <-> ; La synchronisation SLAVE a démarré
46590:S 09 septembre 19:00:49.175 * La connexion non bloquante pour SYNC a déclenché l'événement.
46590:S 09 septembre 19:00:49.176 * Le maître a répondu au PING, la réplication peut continuer. ..
46590 : S 09 septembre 19:00:49.179 * Resynchronisation partielle impossible (pas de maître en cache)
46590 : S 09 septembre 19:00:49.501 * Resynchronisation complète à partir du maître : d7751c4ebf1e63d3baebea1ed409e0e7243a4423:4 40780763454
8373 journal :
4255 :M 09 septembre 19:00:49.176 * L'esclave xx.x.xxx.200:8371 demande une synchronisation
4255:M 09 septembre 19:00:49.176 * Resynchronisation complète demandée par l'esclave xx.x.xxx.200 : 8371
4255:M 9 septembre 19:00:49.176 * Démarrage de BGSAVE pour SYNC avec la cible : disque
4255:M 9 septembre 19:00:49.498 * Sauvegarde en arrière-plan lancée par pid 18413
18413:C 09 septembre 19:01:52.466 * DB enregistrée sur le disque
18413:C 09 septembre 19:01:52.620 * RDB : 2 124 Mo de mémoire utilisée par copie sur écriture
4255 :M 09 septembre 19:01 : 53.186 * L'enregistrement en arrière-plan s'est terminé avec succès
Synchronisation réussie des données du nœud 8371 et démarrage du chargement de la mémoire :
46590:S 09 septembre 19 : 01:53.190 * Synchronisation MAÎTRE <-> data
46590:S 09 Sep 19:05:58.695 * Synchronisation MASTER <-> : Chargement de la base de données en mémoire
42645 ; Cela a pris 7 minutes :
46590:S 09 septembre 19:08:19.303 * Synchronisation MASTER <-> : terminée avec succès
, raison pour laquelle le nœud a perdu le contact :
9/2016 /9 18:57:51 Commande KEYS terminée
1. Paramètre de délai d'attente du nœud de cluster, l'interrogation lente de KEYS a entraîné la perte du contact du nœud de jugement du cluster 8371
À propos du paramètre client-output-buffer-limit :
# The syntax of every client-output-buffer-limit directive is the following:
#
# client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
#
# A client is immediately disconnected once the hard limit is reached, or if
# the soft limit is reached and remains reached for the specified number of
# seconds (continuously).
# So for instance if the hard limit is 32 megabytes and the soft limit is
# 16 megabytes / 10 seconds, the client will get disconnected immediately
# if the size of the output buffers reach 32 megabytes, but will also get
# disconnected if the client reaches 16 megabytes and continuously overcomes
# the limit for 10 seconds.
#
# By default normal clients are not limited because they don't receive data
# without asking (in a push way), but just after a request, so only
# asynchronous clients may create a scenario where data is requested faster
# than it can read.
#
# Instead there is a default limit for pubsub and slave clients, since
# subscribers and slaves receive data in a push fashion.
#
# Both the hard or the soft limit can be disabled by setting them to zero.
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
3. Ajustez le délai d'expiration du nœud de cluster, qui ne peut pas être inférieur à 15 secondes
Recommandations associées :
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!
Quels sont les quatre outils d'analyse du Big Data ?
analyses statistiques
Logiciel de base de données couramment utilisé
Que sont les bases de données en mémoire ?
Lequel a une vitesse de lecture plus rapide, mongodb ou redis ?
Comment utiliser Redis comme serveur de cache
Comment Redis résout la cohérence des données
Comment MySQL et Redis assurent-ils la cohérence des doubles écritures ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
