Redis Sentinel ist ein verteiltes System. Sie können mehrere Sentinel-Prozesse (Progress) in einer Architektur ausführen. Diese Prozesse verwenden Gossip-Protokolle, um Informationen darüber zu erhalten, ob der Hauptserver offline ist verwendet Vereinbarungsprotokolle, um zu entscheiden, ob ein automatisches Failover durchgeführt werden soll und welcher Slave-Server als neuer Master-Server ausgewählt werden soll.
Obwohl Redis Sentinel als separate ausführbare Datei redis-sentinel veröffentlicht wird, handelt es sich eigentlich nur um einen Redis-Server, der in einem speziellen Modus läuft. Sie können einen normalen Redis-Server starten, indem Sie die Option - -sentinel angeben, um Redis Sentinel zu starten .
Das Sentinel-System wird zur Verwaltung mehrerer Redis-Server (Instanzen) verwendet. Das System führt die folgenden drei Aufgaben aus:
1. Überwachung: Sentinel überprüft kontinuierlich Ihren Hauptserver und ob der Slave-Server funktioniert normal.
2. Benachrichtigung: Wenn ein Problem mit einem überwachten Redis-Server auftritt, kann Sentinel über die API Benachrichtigungen an den Administrator oder andere Anwendungen senden.
3. Automatisches Failover: Wenn ein Master-Server nicht ordnungsgemäß funktioniert, startet Sentinel einen automatischen Failover-Vorgang. Es aktualisiert einen der Slave-Server des ausgefallenen Master-Servers und lässt den anderen zu Slave-Server des ausgefallenen Master-Servers ändern sich, um den neuen Master-Server zu replizieren. Wenn der Client versucht, eine Verbindung zum ausgefallenen Master-Server herzustellen, gibt der Cluster auch die Adresse des neuen Master-Servers an den Client zurück, sodass der Cluster diese verwenden kann Neuer Master-Server Ersetzt einen ausgefallenen Server.
Konfiguration
Wenn der Master ausfällt, übernimmt der Slave und wird nach dem Start automatisch zum Slave ist ein Dual-Master mit MySQL. Der Modus ist derselbe wie beim gegenseitigen Master-Slave. Redis Sentinel muss das Redis-Sentinel-Programm und die Sentinel.conf-Konfigurationsdatei verwenden.
mkdir -p /usr/local/redis mkdir -p /usr/local/redis/6379 mkdir -p /usr/local/redis/6380 mkdir -p /usr/local/redis/redis_cluster
Hauptkonfiguration
vim redis_6379.conf
daemonize yes pidfile /usr/local/redis/6379/redis_6379.pid port 6379 tcp-backlog 128 timeout 0 tcp-keepalive 0 loglevel notice logfile "" databases 16 save 900 1 ###save save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb ###dbfile dir "/usr/local/redis/6379" masterauth "123456" requirepass "123456" slave-serve-stale-data yes slave-read-only yes repl-diskless-sync no repl-diskless-sync-delay 5 repl-disable-tcp-nodelay no slave-priority 100 appendonly yes appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes lua-time-limit 5000 slowlog-log-slower-than 10000 slowlog-max-len 128 latency-monitor-threshold 0 notify-keyspace-events "" hash-max-ziplist-entries 512 hash-max-ziplist-value 64 list-max-ziplist-entries 512 list-max-ziplist-value 64 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 activerehashing yes client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 hz 10 aof-rewrite-incremental-fsync yes
vim sentinel_1.conf
Sentinel-Dateikonfiguration
port 6000 dir "/usr/local/redis/sentinel" # 守护进程模式 daemonize yes protected-mode no logfile "/usr/local/sentinel/sentinel.log"
Slave-Konfiguration
vim redis_6380.conf
daemonize yes pidfile "/usr/local/redis/6380/redis_6380.pid" port 6380 tcp-backlog 128 timeout 0 tcp-keepalive 0 loglevel notice logfile "" databases 16 save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename "dump.rdb" dir "/usr/local/redis/6380" masterauth "123456" requirepass "123456" slave-serve-stale-data yes slave-read-only yes repl-diskless-sync no repl-diskless-sync-delay 5 repl-disable-tcp-nodelay no slave-priority 100 appendonly yes appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes lua-time-limit 5000 slowlog-log-slower-than 10000 slowlog-max-len 128 latency-monitor-threshold 0 notify-keyspace-events "" hash-max-ziplist-entries 512 hash-max-ziplist-value 64 list-max-ziplist-entries 512 list-max-ziplist-value 64 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 activerehashing yes client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 hz 10 aof-rewrite-incremental-fsync yes
vim sentinel_2.conf
#sentinel端口 port 6000 #工作路径,注意路径不要和主重复 dir "/usr/local/sentinel" # 守护进程模式 daemonize yes protected-mode no # 指明日志文件名 logfile "/usr/local/sentinel/sentinel.log"
Hinweis:
1. Die Anwendung stellt eine Verbindung zu Sentinel her Port: Stellen Sie eine Verbindung zu einem bestimmten Masterreplikat her, indem Sie einen anderen Masternamen angeben.
2. In der Sentinel-Konfigurationsdatei müssen Sie nur die Master-Replikat-IP und den Port in der Master-Slave-Replikation konfigurieren. Wenn die Master-Slave-Replikation wechselt, ändert Sentinel automatisch die Master-Replikat-IP im Sentinel Konfigurationsdatei auf die neue Master-IP.
3. Eine Sentinel-Konfigurationsdatei kann so konfiguriert werden, dass mehrere Master-Slave-Replikationen gleichzeitig überwacht werden.
4. Ein einzelner Sentinel kann für die Master-Slave-Fehlerüberwachung verwendet werden, aber wenn es nur einen Sentinel-Prozess gibt, dieser Prozess fehlerhaft läuft oder das Netzwerk blockiert ist, dann ist die Master-Slave-Umschaltung des Der Redis-Cluster ist nicht möglich (einzelne Frage);
nicht verfügbar sein. (Jeder Sentinel im Sentinel-Cluster kommuniziert auch miteinander über das Gossip-Protokoll.) Daher sollte eine sinnvolle Konfiguration darin bestehen, mehrere Sentinel-Prozesse gleichzeitig zu starten, und es ist am besten, sie auf verschiedenen Servern zu starten. 5. Beachten Sie, dass „mymaster“ in der gesamten Netzwerkumgebung eindeutig sein muss, solange die Netzwerkumgebung verbunden ist.
Redis starten
1. Sowohl Master als auch Slave sollten gestartet werden
src/redis-server redis.conf
2. Melden Sie sich bei 6380 an, um eine Master-Slave-Beziehung herzustellen
redis-cli -p 6380 slaveof 192.168.137.40 6379
Sentry konfigurieren
Beide Sentinels, Master und Slave, müssen gestartet werden. Sie können auch über den Redis-Server gestartet werden, z. B. „redis-server sentinel.conf --sentinel“
1. Starten Sie den Sentinel >
src/redis-sentinel sentinel.conf
Fehlerverarbeitung starten
WARNUNG overcommit_memory ist auf 0 gesetzt! Um dieses Problem zu beheben, fügen Sie „vm. overcommit_memory = 1' in /etc/sysctl.conf und starten Sie dann neu oder führen Sie den Befehl „sysctl vm.overcommit_memory=1“ aus, damit dies wirksam wird.
1. echo "vm.overcommit_memory=1" > ; /etc/sysctl.conf und dann die Maschine neu starten
2. echo 1 > /overcommit_memory Es wird wirksam, ohne die Maschine zu starten
Overcommit_memory-Parameterbeschreibung:
Legen Sie die Speicherzuweisungsrichtlinie fest (optional, entsprechend der tatsächlichen Situation des Servers festlegen). /proc/sys/vm/overcommit_memory
Optionale Werte: 0, 1, 2.
0 gibt an, dass der Kernel prüft, ob genügend Speicher für den Anwendungsprozess vorhanden ist. Andernfalls schlägt die Speicheranwendung fehl und es wird ein Fehler zurückgegeben den Bewerbungsprozess. 1 gibt an, dass der Kernel die Zuweisung des gesamten physischen Speichers unabhängig vom aktuellen Speicherstatus zulässt. 2, was anzeigt, dass der Kernel mehr Speicher zuweisen darf als die Summe des gesamten physischen Speichers und des Auslagerungsspeichers注意:redis在dump数据的时候,会fork出一个子进程,理论上child进程所占用的内存和parent是一样的,比如parent占用 的内存为8G,这个时候也要同样分配8G的内存给child,如果内存无法负担,往往会造成redis服务器的down机或者IO负载过高,效率下降。所 以这里比较优化的内存分配策略应该设置为 1(表示内核允许分配所有的物理内存,而不管当前的内存状态如何)。
这里又涉及到Overcommit和OOM。
什么是Overcommit和OOM
在Unix中,当一个用户进程使用malloc()函数申请内存时,假如返回值是NULL,则这个进程知道当前没有可用内存空间,就会做相应的处理工作。许多进程会打印错误信息并退出。
Linux使用另外一种处理方式,它对大部分申请内存的请求都回复"yes",以便能跑更多更大的程序。因为申请内存后,并不会马上使用内存。这种技术叫做Overcommit。
当内存不足时,会发生OOM killer(OOM=out-of-memory)。它会选择杀死一些进程(用户态进程,不是内核线程),以便释放内存。
Overcommit的策略
Linux下overcommit有三种策略(Documentation/vm/overcommit-accounting):
0. 启发式策略。合理的overcommit会被接受,不合理的overcommit会被拒绝。
1. 任何overcommit都会被接受。
2. 当系统分配的内存超过swap+N%*物理RAM(N%由vm.overcommit_ratio决定)时,会拒绝commit。
overcommit的策略通过vm.overcommit_memory设置。
overcommit的百分比由vm.overcommit_ratio设置。
# echo 2 > /proc/sys/vm/overcommit_memory
# echo 80 > /proc/sys/vm/overcommit_ratio
当oom-killer发生时,linux会选择杀死哪些进程
选择进程的函数是oom_badness函数(在mm/oom_kill.c中),该函数会计算每个进程的点数(0~1000)。
点数越高,这个进程越有可能被杀死。
每个进程的点数跟oom_score_adj有关,而且oom_score_adj可以被设置(-1000最低,1000最高)。
错误2:
WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
echo 511 > /proc/sys/net/core/somaxconn
错误3:
16433:X 12 Jun 14:52:37.734 * Increased maximum number of open files to 10032 (it was originally set to 1024).
新装的linux默认只有1024,当负载较大时,会经常出现error: too many open files
ulimit -a:使用可以查看当前系统的所有限制值
vim /etc/security/limits.conf
在文件的末尾加上
* soft nofile 65535 * hard nofile 65535
执行su或者重新关闭连接用户再执行ulimit -a就可以查看修改后的结果。
故障切换机制
1. 启动群集后,群集程序默认会在从库的redis文件中加入连接主的配置
# Generated by CONFIG REWRITE slaveof 192.168.137.40 6379
2.启动群集之后,群集程序默认会在主从的sentinel.conf文件中加入群集信息
主:
port 26379 dir "/usr/local/redis-6379" # 守护进程模式 daemonize yes # 指明日志文件名 logfile "./sentinel.log" sentinel monitor mymaster 192.168.137.40 6379 1 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 18000 sentinel auth-pass mymaster 123456 # Generated by CONFIG REWRITE sentinel config-epoch mymaster 0 sentinel leader-epoch mymaster 1 sentinel known-slave mymaster 192.168.137.40 6380 sentinel known-sentinel mymaster 192.168.137.40 26380 c77c5f64aaad0137a228875e531c7127ceeb5c3f sentinel current-epoch 1
从:
#sentinel端口 port 26380 #工作路径 dir "/usr/local/redis-6380" # 守护进程模式 daemonize yes # 指明日志文件名 logfile "./sentinel.log" #哨兵监控的master,主从配置一样,在进行主从切换时6379会变成当前的master端口, sentinel monitor mymaster 192.168.137.40 6379 1 # master或slave多长时间(默认30秒)不能使用后标记为s_down状态。 sentinel down-after-milliseconds mymaster 5000 #若sentinel在该配置值内未能完成failover操作(即故障时master/slave自动切换),则认为本次failover失败。 sentinel failover-timeout mymaster 18000 #设置master和slaves验证密码 sentinel auth-pass mymaster 123456 #哨兵程序自动添加的部分 # Generated by CONFIG REWRITE sentinel config-epoch mymaster 0 sentinel leader-epoch mymaster 1 ###指明了当前群集的从库的ip和端口,在主从切换时该值会改变 sentinel known-slave mymaster 192.168.137.40 6380 ###除了当前的哨兵还有哪些监控的哨兵 sentinel known-sentinel mymaster 192.168.137.40 26379 7a88891a6147e202a53601ca16a3d438e9d55c9d sentinel current-epoch 1
模拟主故障
[root@monitor redis-6380]# ps -ef|grep redis root 4171 1 0 14:20 ? 00:00:15 /usr/local/redis-6379/src/redis-server *:6379 root 4175 1 0 14:20 ? 00:00:15 /usr/local/redis-6380/src/redis-server *:6380 root 4305 1 0 15:28 ? 00:00:05 /usr/local/redis-6379/src/redis-sentinel *:26379 [sentinel] root 4306 1 0 15:28 ? 00:00:05 /usr/local/redis-6380/src/redis-sentinel *:26380 [sentinel] root 4337 4144 0 15:56 pts/1 00:00:00 grep redis [root@monitor redis-6380]# kill -9 4171 [root@monitor redis-6380]# ps -ef|grep redis root 4175 1 0 14:20 ? 00:00:15 /usr/local/redis-6380/src/redis-server *:6380 root 4305 1 0 15:28 ? 00:00:05 /usr/local/redis-6379/src/redis-sentinel *:26379 [sentinel] root 4306 1 0 15:28 ? 00:00:05 /usr/local/redis-6380/src/redis-sentinel *:26380 [sentinel] root 4339 4144 0 15:56 pts/1 00:00:00 grep redis [root@monitor redis-6380]#
从哨兵配置文件中可以看到当前的主库的已经发生了改变
总结
redis的哨兵端口26379、26380使用客户端软件无法连接,使用程序可以连接,客户端软件只能直接连接6379和6380端口。使用哨兵监控当主故障后会自动切换从为主,当主启动后就变成了从。有看到别人只配置单哨兵26379的这种情况,这种情况无法保证哨兵程序自身的高可用。
更多redis知识请关注redis数据库教程栏目。
Das obige ist der detaillierte Inhalt vonSo implementieren Sie Master-Slave-Failover im Redis-Sentry-Modus. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!