Répertoire d'articles
1. Principe de la réplication maître-esclave
①: Le serveur esclave établit une longue connexion socket avant le serveur maître maître
②: Le serveur esclave esclave envoie une commande PSYNC au serveur maître maître pour demander la réplication des données.
③: Une fois que le maître du serveur maître reçoit la commande PSYNC, il utilisera le sous-thread pour générer le dernier fichier de snapshot rdb via la commande bgsave et l'envoyer au serveur esclave esclave.
Pendant la période de persistance, le maître continuera à recevoir les demandes des clients, et il mettra en cache ces demandes qui peuvent modifier le jeu de données dans la mémoire tampon de
réplication ④: L'esclave efface les données inutiles, et accepte les données du maître à charger dans la mémoire
⑤: maître Envoyez ensuite la commande mise en cache dans la mémoire lors de la persistance précédente à l'esclave.
⑥: L'esclave accepte la nouvelle commande envoyée par le maître et l'exécute.
⑦: À ce moment, les données ont été synchronisées. Lorsque le maître a une nouvelle opération d'écriture, elles seront continuellement envoyées à l'esclave via la connexion longue socket pour assurer la cohérence des données maître-esclave!
Remarque: Si le maître reçoit plusieurs demandes de connexion simultanées de plusieurs esclaves, il ne persistera qu'une seule fois, pas une connexion à la fois, puis enverra cette donnée persistante à plusieurs esclaves connectés simultanément.
1. Que faire si le nœud esclave raccroche pendant la transmission maître-esclave?
Lorsque Salve raccroche lorsqu'il reçoit la moitié des données en raison du réseau et d'autres raisons, et après un certain temps, le nœud esclave Salve est redémarré artificiellement, comment la transmission de données est-elle gérée à ce moment?
Réponse: À partir de la version redis 2.8, redis utilise la commande PSYNC qui prend 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. L'organigramme est le suivant:
①: Tout d'abord, redis ouvrira un pool de tampons par défaut lors de son exécution, qui est utilisé pour mettre en cache les dernières commandes Redis. Vous pouvez configurer
repl-backlog-size 1mb dans 6379.conf #### pool de tampons de commandes redis, la taille par défaut 1Mb
②: Lorsque l'esclave est déconnecté du maître et que la connexion est rétablie, l'esclave enverra une commande PSYNC au maître, et utilisera le décalage d'offset pour localiser la position de la transmission de données lorsque la connexion est déconnectée, et partira de cette position pour continuer le transfert
③: Si le nœud esclave est déconnecté pendant trop longtemps, que le décalage est trop ancien et que la position correspondante est introuvable dans le pool de mémoire tampon de commande du maître, une copie complète des données sera effectuée. Impossible d'utiliser le point d'arrêt pour reprendre le téléchargement!
2. Qu'est-ce qu'une tempête de réplication maître-esclave?
Tempête de réplication maître-esclave: plusieurs nœuds esclaves répliquent le nœud maître en même temps, entraînant une pression excessive sur le nœud maître.
Afin de résoudre le problème de la tempête de réplication maître-esclave, certains nœuds esclaves peuvent synchroniser les données avec les nœuds esclaves. L'architecture est conçue comme suit:
3. Avantages et inconvénients de la réplication maître-esclave
1. Avantages
2. Inconvénients
Deux, déploiement de projet Redis
1. Topologie du projet
2. Environnement
一台主服务器 master ：192.168.1.10
两台备服务器 slave1 ：192.168.1.11
slave2 ：192.168.1.12
1. Installez redis
Les serveurs
actifs et de secours doivent être installés. Transférez le package d'installation de redis via des fichiers xshell
1. Décompressez
[root@master ~]# tar zxvf redis-5.0.4.tar.gz
[root@master ~]# cd redis-5.0.4/
[root@master redis-5.0.4]# make 配置安装
[root@master redis-5.0.4]# make DREFIX=/usr/local/redis install
更改安装路径可以用make PREFIX=安装路径 install
[root@master redis-5.0.4]# cd
2. Créez un lien
[root@master ~]# ln -s /usr/local/redis/bin/* /usr/local/bin/
[root@master ~]# cd redis-5.0.4/utils/
[root@master utils]# ls -lh 查看安装脚本
[root@master utils]# ./install_server.sh 运行脚本
[root@master utils]# netstat -anpt | grep redis 查看端口状态
Une fois l'installation de l'invite réussie, la configuration de base de Redis est terminée
2. Configurer le service de réplication maître-esclave Redis
Sur le serveur maître
[root@master utils]# cd
[root@master ~]# vi /etc/redis/6379.conf
[root@master ~]# /etc/init.d/redis_6379 stop #服务关闭
[root@master ~]# /etc/init.d/redis_6379 start #服务开启
修改添加
bind 0.0.0.0 修改监听地址为0.0.0.0
daemonize yes 开启守护进程
logfile /var/log/redis_6379.log 修改日志文件目录
dir /var/lib/redis/6379 修改工作目录
appendonly yes 开启AOF持久化功能
Modifier la configuration sur l'appareil 1, 2
[root@slave1 utils]# vi /etc/redis/6379.conf
[root@slave1 utils]# /etc/init.d/redis_6379 restart 服务重启
修改添加
bind 0.0.0.0 修改监听地址为0.0.0.0
appendonly yes 开启AOF持久化功能
replicaof 192.168.1.10 6379 增加一个同步master节点IP和端口
Vue sur le serveur maître pour
vérifier l'effet maître-esclave
[root@master ~]# tail -f /var/log/redis_6379.log
Idem que ci-dessus pour le serveur de veille 2
Tester la fonction de réplication des données maître-esclave
sur le serveur maître
[root@master ~]# redis-cli #进入数据库
127.0.0.1:6379> set fa a #设置fa键得值为a
127.0.0.1:6379> get fa #查看fa键得值
127.0.0.1:6379> info replication #信息复制，状态信息
Sur le serveur de secours 1
[root@slave1 ~]# redis-cli #进入数据库
127.0.0.1:6379> get fa #获取fa键得值
127.0.0.1:6379> info replication #信息复制，状态信息
Sur le serveur de secours 2
// An highlighted block
var foo = 'bar';
3. Après le blocage du serveur principal simulé
Sur le serveur maître, désactivez le service
[root@master ~]# /etc/init.d/redis_6379 stop 关闭服务
[root@master ~]# tail -f /var/log/redis_6379.log 查看日志
Vérifiez le phénomène sur le serveur de secours 1
[root@slave1 ~]# tail -f /var/log/redis_6379.log 查看日志
[root@slave1 ~]# redis-cli 进入数据库
127.0.0.1:6379> get k 获取k的键值
"aa"
127.0.0.1:6379> info replication 信息复制，状态信息
# Replication
role:slave 状态：从服务器
master_host:192.168.1.10
Sur le serveur de secours 2,
vous pouvez voir qu'après l'arrêt du serveur principal, l'état du serveur esclave ne sera pas converti en serveur maître, mais les données seront copiées et transférées, et pourront être lues et visualisées.
Solution:
grâce à la fonction sentinelle, l'état du maître et de l'esclave peut basculer automatiquement en cas de défaillance du serveur maître
Première restauration à l'état précédent sur le
maître et
reprise en ligne
[root@master ~]# /etc/init.d/redis_6379 start 服务启动
[root@master ~]# tail -f /var/log/redis_6379.log 查看日志
[root@master ~]# redis-cli 进入数据库
127.0.0.1:6379> info replication 信息复制，状态查看
# Replication
role:master 主服务
connected_slaves:2 连接2个服务器
slave0:ip=192.168.1.11,port=6379,state=online,offset=84,lag=1
slave1:ip=192.168.1.12,port=6379,state=online,offset=84,lag=0
master_replid:087088c1aa398b11c1e4759e93eb8abb6bc277e2
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:84
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:84
127.0.0.1:6379> set nb b 添加nb键值为b
OK
127.0.0.1:6379> get nb 获取nb的键值
"b"
Sur le serveur de secours 1
[root@slave1 ~]# tail -f /var/log/redis_6379.log #查看日志
[root@slave1 ~]# redis-cli
Troisièmement, le principe du mode sentinelle
- La sentinelle sentinelle est un service redis spécial, qui ne fournit pas de services de lecture et d'écriture. Il est principalement utilisé pour surveiller l'état des nœuds d'instance redis!
- Sous l'architecture sentinelle, lorsque le client demande le service redis pour la première fois, il trouve d'abord le nœud maître redis à partir de la sentinelle, puis accède directement au nœud maître redis. Il n'accède pas au nœud maître redis via l'agent sentinelle à chaque fois. Lorsque le nœud maître change, la sentinelle le percevra pour la première fois, et notifiera au client le nouveau nœud maître redis (le côté client redis implémente généralement la fonction d'abonnement et s'abonne au message de changement de nœud publié par sentinel)
1. Le rôle principal de la sentinelle
1. Phénomène
Lorsque le nœud maître raccroche, la console du serveur affiche une erreur de temporisation de connexion. Après un certain temps, il revient à la normale et vous pouvez continuer à écrire des données dans redis!
2. Raison
- La raison en est que la sentinelle surveillera toujours le nœud maître. Lorsque le nœud maître est arrêté, la console du serveur affiche une erreur de temporisation de connexion. Mais en même temps, la sentinelle confirme que le maître est descendu à travers la moitié du mécanisme et élira un esclave comme nouveau maître
- Pendant la période électorale, la console affichera encore des erreurs. Une fois l'élection réussie, la connexion normale sera rétablie. C'est aussi la raison du phénomène ci-dessus! !
- Lorsque le nœud maître initialement suspendu est restauré, il sera automatiquement appelé le nouveau nœud de cluster maître, complétant ainsi l'architecture de haute disponibilité sentinelle!
La sentinelle doit être réglée sur un nombre impair, au moins trois, ce qui implique le vote!
2. Processus de déploiement Sentinel
Editez le fichier de configuration du mode sentinelle sur le serveur maître
[root@master ~]# vi redis-5.0.4/sentinel.conf
修改添加
protected-mode no 关闭安全模式
daemonize yes 指定sentine1为后台启动，开启守护进程
logfile "/var/log/sentinel.log" 指定日志存放路径
dir /var/lib/redis/6379 指定数据库存放路径
sentinel monitor mymaster 192.168.1.10 6379 2
指定几个哨兵（slave）检测主服务器故障，才会进行故障迁移（主服务器ip地址，端口号，slave数）
sentinel down-after-milliseconds mymaster 3000
判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 100000
故障节点的最大超时时间为100000毫秒（100秒）
Copier les fichiers vers slave1 et slave2
[root@master ~]# scp redis-5.0.4/sentinel.conf root@192.168.1.11:/root/redis-5.0.4
[root@master ~]# scp redis-5.0.4/sentinel.conf root@192.168.1.12:/root/redis-5.0.4
Démarrez le mode sentinelle
, démarrez d'abord le serveur maître, puis le serveur esclave
[root@master ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 69742
[root@slave1 ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 62685
[root@slave2 ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 62250
1. Affichez le journal sur le serveur maître
[root@master ~]# tail -f /var/log/sentinel.log
2. Afficher l'état du processus
[root@master ~]# ps aux | grep redis
[root@master ~]# ps aux | grep sentinel
Indique que le service de sentinelle a été démarré
3. Connectez-vous à distance à la base de données pour afficher l'état de la sentinelle
[root@master ~]# redis-cli -h 192.168.1.10 -p 26379 info sentinel
[root@master ~]# redis-cli -h 192.168.1.10 -p 6379 info replication
1. Simulez un problème avec le serveur principal et en panne, vérifiez le changement d'état du serveur secondaire
Sur le serveur maître
[root@master ~]# /etc/init.d/redis_6379 stop 停止服务
[root@master ~]# ps aux | grep redis 查看进程状态
Afficher les journaux sur le serveur esclave
[root@slave1 ~]# tail -f /var/log/sentinel.log
Trouvé que l'état du maître est transféré à l'esclave 1
Afficher la connexion à distance pour afficher les informations de sentinelle dans slave2
[root@slave2 ~]# redis-cli -h 192.168.1.11 -p 26379 info sentinel
2. Affichez l'adresse du serveur principal détecté par la sentinelle précédemment configurée
Sur le serveur de secours 1
[root@slave1 ~]# vi redis-5.0.4/sentinel.conf
Les changements d'adresse de configuration trouvés sur le serveur principal changeront également automatiquement l'adresse de détection lorsque l'état principal est automatiquement commuté
3. Affichez les changements d'état lorsque le serveur maître d'origine revient en ligne
Sur le serveur maître
[root@master ~]# /etc/init.d/redis_6379 start 服务启动
[root@master ~]# ps aux | grep redis 查看进程端口状态
[root@master ~]# tail -f /var/log/sentinel.log 查看日志文件
Afficher le statut de la sentinelle de la base de données sur slave2
[root@slave2 ~]# redis-cli -h 192.168.1.11 -p 26379 info sentinel
Il s'avère qu'après la mise en ligne du serveur maître d'origine, l'état du maître ne reviendra pas à lui-même. Ceci est différent du service vrrp car vrrp a un paramètre de priorité, mais pas le service ici.