Redis Sentinel Cluster-Grafik-Tutorial

Sentinel ist eine Hochverfügbarkeitslösung für Redis: Ein Sentinel-System bestehend aus einer oder mehreren Sentinel-Instanzen kann eine beliebige Anzahl von Master-Servern und die Server unter diesen Master-Servern überwachen , und wenn der überwachte Master-Server offline geht, wird automatisch ein Slave-Server unter dem Offline-Master-Server auf den neuen Master-Server aktualisiert. Empfohlen: Redis-Video-Tutorial

Zum Beispiel:

Nachdem Server1 offline geht:

Upgrade von Server2 auf den neuen Master-Server:

2. Redis Master-Slave-Trennung

Bevor wir den Sentinel-Cluster erklären, bauen wir zunächst eine einfache Master-Slave-Trennung (Lese-Schreib-Trennung) auf.

Zuerst hat standardmäßig jeder Redis installiert, dann kopieren wir redis.conf in mehreren Kopien und erstellen mehrere Verzeichnisse, um mehrere Redis-Dienste zu unterscheiden:

Hier hat jedes Verzeichnis seine eigene Konfigurationsdatei redis.conf. Als nächstes legen wir zunächst die Konfigurationsdatei des Hauptservers fest.

1. Master konfigurieren

1. Ändern Sie den Port

# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6380

Der Standardport von Redis ist 6379. Hier stellen wir den Port des Hauptservers auf 6380 ein

2. PID-Datei ändern

# If a pid file is specified, Redis writes it where specified at startup
# and removes it at exit.
#
# When the server runs non daemonized, no pid file is created if none is
# specified in the configuration. When the server is daemonized, the pid file
# is used even if not specified, defaulting to "/var/run/redis.pid".
#
# Creating a pid file is best effort: if Redis is not able to create it
# nothing bad happens, the server will start and run normally.
pidfile /var/run/redis_6380.pid

PID-Datei ist eine PID-Prozessnummer, die uns von Linux zugewiesen wird, wenn wir Redis starten. Wenn sie hier nicht geändert wird, wirkt sie sich auf den nachfolgenden Start des Redis-Dienstes aus

3. Starten Sie Redis

Starten Sie Redis, wir können sehen, dass Redis Port 6380 belegt hat

Geben Sie den Client ein

redis-cli -p 6380
127.0.0.1:6380> info
...
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
...

us Wie Sie sehen können, ist die aktuelle Rolle von Redis ein vom Master gestarteter Dienst.

2. Slave konfigurieren

Wie oben beim Konfigurieren des Masters müssen wir die Portnummer und die PID-Datei ändern. Nach der Änderung haben wir zwei Methoden, um den Slave-Dienst zu konfigurieren

1. Konfigurieren Sie den Slave-Dienst in der Konfigurationsdatei

################################# REPLICATION #################################

# Master-Slave replication. Use slaveof to make a Redis instance a copy of
# another Redis server. A few things to understand ASAP about Redis replication.
#
# 1) Redis replication is asynchronous, but you can configure a master to
#    stop accepting writes if it appears to be not connected with at least
#    a given number of slaves.
# 2) Redis slaves are able to perform a partial resynchronization with the
#    master if the replication link is lost for a relatively small amount of
#    time. You may want to configure the replication backlog size (see the next
#    sections of this file) with a sensible value depending on your needs.
# 3) Replication is automatic and does not need user intervention. After a
#    network partition slaves automatically try to reconnect to masters
#    and resynchronize with them.
#
# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6380

Wir können die IP-Adresse und Portnummer des Hauptservers direkt in der Konfigurationsdatei konfigurieren ein Konfigurationspasswort

Sie können das Link-Passwort festlegen, indem Sie masterauth konfigurieren

# If the master is password protected (using the "requirepass" configuration
# directive below) it is possible to tell the slave to authenticate before
# starting the replication synchronization process, otherwise the master will
# refuse the slave request.
#
# masterauth <master-password>

Starten Sie den Redis-Dienst:

Das können wir dort sehen Jetzt laufen zwei. Wir geben den Client von 6381 ein und sehen uns seinen Status an. Wir können sehen, dass der aktuelle Redis ein Slave-Dienst ist, der mit dem Dienst von 6380 verbunden ist.

2. Nach dem Start des Dienstes einrichten

Nachdem wir die Serverkonfigurationsdatei von Port 6382 geändert haben, starten Sie den Dienst

Eingabe Überprüfen Sie den Status des aktuellen Servers:

# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:71
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Wir können sehen, dass der Status des aktuellen Servers als Hauptdienst ausgeführt wird:

# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

3. Zusammenfassung

Werfen wir zunächst einen Blick auf den aktuellen Status des Masters:

127.0.0.1:6382> slaveof 127.0.0.1 6380

//修改后状态
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:617
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Wir können sehen, dass die beiden Slave-Dienste bereits mit dem Master-Server verbunden sind. Der Unterschied zwischen den beiden oben genannten Konfigurationen ist das, wenn die Salve getrennt wird Nachdem die Leitung wieder verbunden ist,

Wenn wir die Klassenkonfigurationsdatei ändern, stellen wir nach der erneuten Verbindung eine Verbindung zum Master her und synchronisieren die Daten auf dem Master.

Wenn Wir stellen manuell eine Verbindung zum Hauptserver her. Nach der erneuten Verbindung liest der Slave-Server seine eigenen lokalen RDB-Antwortdaten und stellt keine automatische Verbindung zum Hauptdienst her.

Wenn wir eine Lese-/Schreibtrennung einrichten müssen, tun wir dies nur muss im Hauptserver eingestellt werden:

# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=785,lag=0
slave1:ip=127.0.0.1,port=6382,state=online,offset=785,lag=0
master_repl_offset:785
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:784

3. Konfigurationsport In der Konfigurationsdatei sentinel.conf finden wir das Portattribut, das zum Festlegen des Sentinel-Ports verwendet wird. Unter normalen Umständen sind mindestens drei Sentinels erforderlich, um Redis zu überwachen. Durch Ändern des Ports können wir mehrere Sentinel-Dienste starten.

# Note: read only slaves are not designed to be exposed to untrusted clients
# on the internet. It's just a protection layer against misuse of the instance.
# Still a read only slave exports by default all the administrative commands
# such as CONFIG, DEBUG, and so forth. To a limited extent you can improve
# security of read only slaves using 'rename-command' to shadow all the
# administrative / dangerous commands.
slave-read-only yes

2. Konfigurieren Sie die IP und den Port des Hauptservers

Wir ändern den Abhörport auf 6380 und fügen eine Gewichtung von 2 hinzu. Die Gewichtung hier wird verwendet, um zu berechnen, was wir brauchen Server zum Upgrade auf den Hauptserver

# port <sentinel-port># The port that this sentinel instance will run on
port 26379

3. Sentinel starten

Nach dem Start von Sentinel wird überwacht, dass es jetzt einen Hauptserver gibt Slave-Server

当我们把其中一个从服务器器关闭之后，我们可以看到日志：

10894:X 30 Dec 16:27:03.670 # +sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380

日志表示，6381这个从服务器已经从主服务器中脱离了出来，我们重新把6381 接回去。

10894:X 30 Dec 16:28:43.288 * +reboot slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 638010894:X 30 Dec
16:28:43.365 # -sdown slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380

4、关闭Master

我们手动关闭Master 之后，sentinel 在监听master 确实是断线了之后，将会开始计算权值，然后重新分配主服务器

我们可以看到，6380主服务器断了之后，sentinel 帮我们选了6382作为新的主服务器

我们进到6382的客户端，查看他的状态：

# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=13751,lag=0
master_repl_offset:13751
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:13750

我们可以看到 6382，重slave 荣升为master

127.0.0.1:6382> set name jaycekon
OK

原本的没有权限写，也得到了相应的权限

5、重连Master

大家可能会好奇，如果master 重连之后，会不会抢回属于他的位置，答案是否定的，就比如你被一个小弟抢了你老大的位置，他肯给回你这个位置吗。因此当master 回来之后，他也只能当个小弟　　

4、Sentinel 总结

一、Sentinel的作用：

A、Master 状态监测

B、如果Master 异常，则会进行Master-slave 转换，将其中一个Slave作为Master，将之前的Master作为Slave 

C、Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换 

二、Sentinel的工作方式:

1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 

2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。 

3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。 

4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 

5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 

6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 

7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。 

若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

更多redis相关文章请关注redis数据库教程栏目。

Das obige ist der detaillierte Inhalt vonRedis Sentinel Cluster-Grafik-Tutorial. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!