Quel est le principe du basculement Sentinel dans Redis ?

Qu'est-ce que Sentinel ?

Sentinel est une solution à haute disponibilité pour Redis. La réplication maître-esclave dont nous avons parlé plus tôt est la base de la haute disponibilité. Cependant, la réplication maître-esclave pure nécessite une intervention manuelle pour terminer le basculement. Pour résoudre ce problème, dans le cas d'une réplication maître-esclave, lorsque le nœud maître tombe en panne, Sentinel peut détecter automatiquement la panne et terminer le basculement pour obtenir une véritable haute disponibilité Redis. Dans le cluster sentinelle, sentinel surveillera l'état de tous les serveurs Redis et autres nœuds sentinelles, détectera les pannes à temps et terminera le transfert, garantissant ainsi la haute disponibilité de Redis.

Créer un cluster Sentinel

Bien que Sentinel soit essentiellement un service Redis, il fournit des fonctions différentes des services Redis ordinaires. Sentinel est une architecture distribuée, car si vous voulez garantir la haute disponibilité de Redis, vous devez d'abord assurer votre propre haute disponibilité, donc si nous devons construire une sentinelle, nous devons déployer au moins trois instances, de préférence un nombre impair , car lors du basculement ultérieur, un vote sera impliqué.

Nous pouvons télécharger le fichier de configuration sentinel sous le projet redis GitHub. Il existe un fichier appelé sentinel.conf sous le projet. Vous pouvez l'utiliser comme modèle de configuration sentinel. Bien sûr, vous pouvez également utiliser le fichier de configuration redis.conf. . Ajoutez simplement les configurations liées aux sentinelles.

Il n'y a pas beaucoup d'éléments de configuration liés à Sentinel. Il y a principalement les éléments de configuration suivants :

// 端口号，默认是 redis 实例+20000，所以我们沿用这个规则就好了 port 26379  // 是否守护进程运行 daemonize yes // 日志存放的位置，这个非常重要，通过日志可以查看故障转移的过程 logfile "26379.log"  // 监视一个名为 mymaster（自定义） 的 redis 主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， // 最后面的 2 代表着至少有两个哨兵认为主服务器出现故障才会进行故障转移，否则认定主服务未失效 sentinel monitor mymaster 127.0.0.1 6379 2  // 哨兵判断服务器失效的响应时间，超过这个时间未接收到服务器的回应，就认为该服务器失效了 sentinel down-after-milliseconds mymaster 30000  // 完成故障转移之后，最多多少个从服务器可以同时发起数据复制，数字越小，说明完成全部从服务数据复制的时间越长 // 数字越大，对主服务器的压力就变大了 sentinel parallel-syncs mymaster 1  // 故障转移超时时间 sentinel failover-timeout mymaster 180000

Pour chaque configuration d'instance Sentinel, à l'exception des différents ports et fichiers journaux, les autres éléments de configuration sont les mêmes. Après avoir modifié la configuration, nous pouvons utiliser la commande ./redis-sentinel sentinel.conf pour démarrer la sentinelle. La commande est similaire au démarrage de l'instance redis. Parce que la sentinelle est également une instance redis, nous pouvons utiliser la commande ./redis-. Commande cli -p 26379 info sentinel pour l'afficher. Les informations sentinelle actuelles sont telles qu'indiquées dans la figure ci-dessous :

Informations Sentinel

Question : Comment découvrir le serveur esclave et les autres Sentinel lorsque seul le serveur maître est configuré. ?

Pour découvrir le serveur esclave, Sentinel peut demander au serveur maître d'obtenir des informations du serveur. Pour découvrir d'autres nœuds Sentinel, cela est implémenté via les fonctions de publication et d'abonnement, et en envoyant des informations au canal Sentinel : bonjour. se composent principalement des deux étapes suivantes :

1. Chaque Sentinel toutes les 2 secondes Un message sera envoyé au canal sentinel : hello de tous les services maîtres et serveurs esclaves via la fonction de publication et d'abonnement. Le message contient l'adresse IP et le numéro de port de Sentinel. et ID d'exécution (runid)

2. Chaque Sentinelle est abonnée Sentinelle : bonjour les canaux de tous les serveurs maîtres et serveurs esclaves surveillés par celui-ci, à la recherche de sentinelles qui ne sont pas apparues auparavant (à la recherche de sentinelles inconnues). Lorsqu'un Sentinel découvre un nouveau Sentinel, il ajoute le nouveau Sentinel à une liste qui contient tous les autres Sentinels connus du Sentinel qui surveillent le même serveur maître

Principe de basculement de Sentinel

Basculement C'est le travail principal de Sentinel La mise en œuvre. La logique derrière cela est également très compliquée. Veuillez consulter les livres pertinents pour connaître la logique d'implémentation spécifique. J'ai résumé les trois points suivants pour le basculement Sentinel :

1. Serveur d'écoute

Chacun Le nœud Sentinel envoie la commande ping au serveur. le nœud maître, le nœud esclave et les autres nœuds Sentinel toutes les secondes pour la détection des battements de cœur afin de déterminer l'état du serveur.

Le nœud répondra également en conséquence à Sentinel Parmi ces réponses, les trois réponses suivantes sont des réponses valides :

• Return+PONG

• Return-LOADING

• Return-MASTERDOWN

If a. Le nœud n'a pas reçu ne serait-ce qu'une seule réponse valide dans la valeur de l'option master-down-after-milliseconds définie dans le fichier de configuration Sentinel, Sentinel marquera le serveur comme hors ligne. Nous appelons cela hors ligne subjectif. seule cette sentinelle pense que le serveur est hors ligne.

Si le serveur subjectivement hors ligne est le serveur principal, afin de confirmer si le serveur principal est réellement hors ligne, le Sentinel demandera aux autres Sentinels qui surveillent également le serveur principal de voir s'ils pensent également que le serveur principal a Lorsque le serveur principal est hors ligne, lorsqu'un nombre suffisant de Sentinels pensent que le serveur principal est hors ligne, le Sentinel jugera le serveur principal comme étant objectivement hors ligne, qui est véritablement hors ligne, et effectuera une opération de basculement sur celui-ci.

2. Élire les nœuds sentinelles pour terminer la tâche de transfert

Le basculement n'est pas terminé par toutes les sentinelles, mais un nœud sentinelle est élu comme leader pour terminer le basculement, donc lorsque le serveur principal est marqué comme objectif lorsqu'il est en ligne, les sentinelles éliront un leader via l'algorithme Raft pour terminer le travail de basculement. Les règles et méthodes générales sont les suivantes. Redis procède à l'élection des chefs sentinelles

• Toutes les sentinelles en ligne sont éligibles pour être élues dirigeants, ce qui signifie que chaque sentinelle a la possibilité de devenir un leader

• Lorsque Sentinel marque le serveur maître comme subjectivement hors ligne, il enverra la commande Sentinel is-master-down-by-addr à d'autres nœuds Sentinel, leur demandant de se définir comme leader

• Le nœud Sentinel qui reçoit le commande, en adoptant la règle du premier arrivé, premier servi, si la commande sentinel is-master-down-by-addr des autres nœuds Sentinel n'a pas été acceptée, la demande sera approuvée, sinon elle sera rejetée

• Si le nœud Sentinelle constate que son nombre de voix a dépassé la moitié, alors il deviendra le leader

• Si le chef sentinelle n'est pas élu dans le délai spécifié, il sera réélu après un certain temps jusqu'à ce que le chef sentinelle soit élu. élu.

3. Élire le nouveau serveur maître pour terminer le basculement

Le chef sentinelle élu terminera le travail de basculement restant. Le basculement comprend principalement les trois étapes suivantes :

(1) Sélectionnez un nouveau maître. serveur

Sélectionnez un serveur esclave parmi tous les serveurs esclaves du serveur maître hors ligne et convertissez-le en serveur maître Les règles de sélection d'un nouveau serveur maître sont les suivantes :

• Dans le cas du serveur maître défaillant. Parmi les serveurs esclaves sous le serveur maître, les serveurs esclaves marqués comme subjectifs hors ligne, déconnectés ou dont la dernière réponse à la commande PING date de plus de cinq secondes seront éliminés

• Parmi les serveurs esclaves sous le serveur maître défaillant , les serveurs esclaves qui sont déconnectés du serveur maître défaillant pendant plus de dix fois le temps spécifié par l'option down-after seront éliminés

• Après les deux tours d'élimination ci-dessus, les serveurs esclaves restants seront sélectionnés. le serveur esclave avec le décalage de réplication le plus grand devient le nouveau serveur maître ; si le décalage de réplication n'est pas disponible ou si les décalages de réplication des serveurs esclaves sont les mêmes, alors le serveur esclave avec le plus petit ID en cours d'exécution devient le nouveau serveur maître

.

Exécutez la commande slaveof no one sur le serveur esclave sélectionné pour en faire le nœud maître.

(2) Modifier les cibles de réplication des autres serveurs esclaves

Lorsque le nouveau serveur maître apparaît, la prochaine étape que le chef sentinelle doit faire est de laisser d'autres serveurs esclaves répliquer le nouveau serveur maître en envoyant des messages à d'autres esclaves. serveurs. Le serveur envoie la commande slaveof new_master port pour terminer. Les règles de réplication sont liées au paramètre parallel-syncs du fichier de configuration. (3) Transformer l'ancien serveur maître en serveur esclave. L'opération consiste à mettre le serveur hors ligne hors ligne. Définissez le serveur maître comme serveur esclave du nouveau service maître, gardez-le à l'œil et commandez-lui de répliquer le nouveau nœud maître après sa récupération.

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!