Analyse de l'échec du cluster Redis

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 Sep. 18:57:51.906 * Resynchronisation complète demandée par l'esclave xx.x.xxx.200:8371

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

5230:C 09 septembre 18:59:01.491 * RDB : 7 112 Mo de mémoire utilisée par copie sur écriture

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 e09be6022d700e04aeaa85a5f42fdcb2 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.

4255:M 09 Sep 19:00:19.015 # Connexion avec l'esclave xx.x.xxx.200 : 8371 perdue.

Étape 13 :
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 e09be6022d700e04aeaa85a5f42fdcb2 SLAVE a démarré

Étape 14 :
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'

Étape 15 :
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

Étape 16 :
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 e09be6022d700e04aeaa85a5f42fdcb2 data
46590:S 09 Sep 19:05:58.695 * Synchronisation MASTER e09be6022d700e04aeaa85a5f42fdcb2 : Chargement de la base de données en mémoire

Étape 17 : Cluster revient à la normale :
42645 ; Cela a pris 7 minutes :
46590:S 09 septembre 19:08:19.303 * Synchronisation MASTER e09be6022d700e04aeaa85a5f42fdcb2 : terminée avec succès

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)<.>
, raison pour laquelle le nœud a perdu le contact :

Le client a exécuté une commande qui a pris 8,3 secondes. >

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)
9/2016 /9 18:57:51 Commande KEYS terminée

En résumé, il y a les problèmes suivants :

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

2 En raison de la perte de contact du 8371, le 8373 a été mis à niveau vers le maître et a démarré la synchronisation maître-esclave

3. En raison de la limitation de la configuration du client-output-buffer-limit, la première synchronisation complète a échoué

4. le client PHP, le serveur s'est connecté frénétiquement au serveur, ce qui a entraîné un effet similaire à une attaque SYN

5 Premier Après l'échec de la première synchronisation complète, il a fallu 30 secondes au nœud esclave. reconnectez-vous au nœud maître (en dépassant le nombre maximum de connexions de 1w)

À propos du paramètre client-output-buffer-limit :

Passer à l'action :

# 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&#39;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

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
3. Ajustez le délai d'expiration du nœud de cluster, qui ne peut pas être inférieur à 15 secondes

4. Interdisez tout ce qui prend plus de temps que le délai d'expiration du nœud de cluster. Requête lente. , car cela entraînera une commutation maître-esclave

5. Corrigez la méthode de connexion folle du client similaire à l'attaque SYN

Recommandations associées :

Enregistrement complet de la construction du cluster Redis

Explication détaillée des connaissances sur la spécification du cluster Redis

Pratique du cluster Redis

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!