Heim >Datenbank >Redis >Detaillierte Erläuterung der Redis-Master-Slave-Replikation

Detaillierte Erläuterung der Redis-Master-Slave-Replikation

尚
nach vorne
2019-11-26 16:56:142131Durchsuche

Detaillierte Erläuterung der Redis-Master-Slave-Replikation

In diesem Kapitel wird eine leistungsstarke Funktion von Redis vorgestellt – die Master-Slave-Replikation. Ein Master-Host kann mehrere Slave-Maschinen haben. Und ein Sklavensklave kann mehrere Sklavensklaven haben. Dadurch entsteht weiterhin eine leistungsstarke mehrstufige Server-Cluster-Architektur (hohe Skalierbarkeit). Dadurch kann ein Redis-Single-Point-of-Failure vermieden und ein Disaster-Recovery-Effekt (hohe Verfügbarkeit) erzielt werden. Die Architektur der Trennung von Lesen und Schreiben erfüllt gleichzeitige Anwendungsszenarien mit mehr Lesen und weniger Schreiben. Empfohlen: Redis-Video-Tutorial

Die Rolle der Master-Slave-Replikation

Master-Slave-Replikation, Lese-/Schreibzugriff Trennung, Disaster Recovery, Wiederherstellung. Ein Host ist für das Schreiben von Daten verantwortlich und mehrere Slave-Maschinen sind für die Datensicherung verantwortlich. In Szenarien mit hoher Parallelität kann, selbst wenn der Host-Rechner hängen bleibt, der Slave-Rechner anstelle des Host-Rechners weiterarbeiten, um Systemleistungsprobleme zu vermeiden, die durch Single Points of Failure verursacht werden. Die Trennung von Lesen und Schreiben ermöglicht eine bessere Leistung für Anwendungen, die mehr lesen und weniger schreiben.

Master-Slave-Replikationsarchitektur

Die Basis der Redis-Replikation ist eine sehr einfach zu verwendende und zu konfigurierende Master-Slave-Replikation, die dies ermöglicht Slave-Redis-Server sollen exakte Kopien von Master-Servern sein.

Es ist wirklich einfach: Ein Befehl: Slaveof Host IP Host-Port kann die Master-Slave-Beziehung bestimmen: ./redis-sentinel sentinel.conf Sentinel Die Überwachung kann eingeschaltet werden.

Das Bauen ist einfach, aber die Wartung ist mühsam. In Szenarien mit hoher Parallelität können viele unerwartete Probleme auftreten. Wir haben lediglich ein klares Verständnis des Replikationsprinzips, der Vertrautheit mit der Host-Maschine und den Änderungen nach dem Ausfall der Slave-Maschine. Nur dann können wir diese Fallstricke gut überwinden. Jeder Schritt unten ist ein kleiner Wissenspunkt und eine kleine Szene. Jedes Mal, wenn Sie einen Schritt abschließen, gewinnen Sie Wissen.

Architekturdiagramm: ein Meister, zwei Diener und ein Soldat (Sie können auch mehrere Herren, mehrere Diener und mehrere Soldaten haben)

Detaillierte Erläuterung der Redis-Master-Slave-Replikation

Vorbereitung vor der Bauarbeit

Da ich arm war, entschied ich mich dafür, einen Server zu verwenden, um drei Hosts zu simulieren. Der einzige Unterschied zur Produktionsumgebung besteht in der IP-Adresse und dem Port.

Schritt 1: Kopieren Sie drei Kopien von redis.conf, die Namen sind redis6379.conf, redis6380.conf, redis6381.conf

Schritt 2: Ändern Sie die Ports der drei Dateien, PID-Datei Name, Name der Protokolldatei, Name der RDB-Datei

Schritt 3: Öffnen Sie drei Fenster, um drei Server zu simulieren und den Redis-Dienst zu starten.

[root@itdragon bin]# cp redis.conf redis6379.conf
[root@itdragon bin]# cp redis.conf redis6380.conf
[root@itdragon bin]# cp redis.conf redis6381.conf
[root@itdragon bin]# vim redis6379.conf
logfile "6379.log"
dbfilename dump_6379.rdb
[root@itdragon bin]# vim redis6380.conf
pidfile /var/run/redis_6380.pid
port 6380
logfile "6380.log"
dbfilename dump_6380.rdb
[root@itdragon bin]# vim redis6381.conf
port 6381
pidfile /var/run/redis_6381.pid
logfile "6381.log"
dbfilename dump_6381.rdb
[root@itdragon bin]# ./redis-server redis6379.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
[root@itdragon bin]# ./redis-server redis6380.conf 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6380
127.0.0.1:6380> keys *
(empty list or set)
[root@itdragon bin]# ./redis-server redis6381.conf 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6381
127.0.0.1:6381> keys *
(empty list or set)

Einrichtungsschritte für die Master-Slave-Replikation

Grundlegende Einrichtung

Schritt 1: Fragen Sie ab master Wählen Sie aus den Replikationsinformationen jeweils drei Ports aus und führen Sie den Befehl aus: info replication.

# 6379 端口
[root@itdragon bin]# ./redis-server redis6379.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
......

# 6380 端口
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
......

# 6381 端口
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
......

Alle drei Ports geben die gleichen Informationen aus: Role:master Die Rolle ist Master, connected_slaves:0 Die Anzahl der verbundenen Slaves ist Null. Um mehr über die Bedeutung von Parametern zu erfahren, besuchen Sie bitte den Link: http://redisdoc.com/server/info.html

Schritt 2: Wählen Sie Port 6379 und führen Sie den Befehl aus: set k1 v1

127.0.0.1:6379> set k1 v1
OK

Schritt 3: Stellen Sie die Master-Slave-Beziehung ein, wählen Sie Port 6380 bzw. Port 6381 aus, führen Sie den Befehl aus: SLAVEOF 127.0.0.1 6379

# 6380 端口
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

# 6381 端口
127.0.0.1:6381> SLAVEOF 127.0.0.1 6379
OK
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

# 6379 端口
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=98,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=98,lag=1
......

Die Master-Slave-Beziehung hat sich geändert:

6380-Port- und 6381-Port-Druckinformationen: Rolle: Master-Host: 127.0.0.1 IP-Adresse des Master-Ports: 6379 Port des Hosts.

Auf Port 6379 gedruckte Informationen: Rolle:Master-Host; verbundene_Slaves:2 mit zwei Slaves verbunden: ID, IP-Adresse, Portnummer, Verbindungsstatus, Slave-Datenbankinformationen

Nr 4: Vollständig kopieren, Port 6380 bzw. Port 6381 auswählen und den Befehl ausführen: get k1

# 6380 端口
127.0.0.1:6380> get k1
"v1"

# 6381 端口
127.0.0.1:6381> get k1
"v1"

Beide Ports können den Wert von k1 drucken, was darauf hinweist, dass der Slave beim Aufbau einer Master-Slave-Beziehung über den verfügt Stammdaten.

Schritt 5: Inkrementelles Kopieren, Port 6379 auswählen und den Befehl ausführen: set k2 v2. Wählen Sie dann Port 6380 bzw. Port 6381 aus und führen Sie den Befehl aus: get k2

# 6379 端口
127.0.0.1:6379> set k2 v2
OK

# 6380 端口
127.0.0.1:6380> get k2
"v2"

# 6381 端口
127.0.0.1:6381> get k2
"v2"

Beide Ports können den Wert von k2 drucken, was bedeutet, dass nach dem Herstellen der Master-Slave-Beziehung die neuen Daten hinzugefügt werden Der Host wird auf den Slave kopiert.

Schritt 6: Master-Slave-Lese-/Schreibtrennung, Port 6380 auswählen, Befehl ausführen: set k3 v3

# 6380 端口
127.0.0.1:6380> set k3 v3
(error) READONLY You can't write against a read only slave.

# 6379 端口
127.0.0.1:6379> set k3 v3
OK

Slave 6380 konnte aufgrund des Lese-/Schreibtrennungsmechanismus nicht schreiben.

Schritt 7: Wenn der Host ausgefallen ist, wählen Sie Port 6379 und führen Sie den Befehl aus: Shutdown

# 6379 端口
127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380 端口
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

# 6381 端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......

Aus den gedruckten Ergebnissen wissen wir, dass der Slave im Standby-Modus ist

Nein. Acht Schritte: Stellen Sie den Host nach einem Absturz wieder her. Wählen Sie Port 6379 aus, starten Sie den Redis-Dienst neu und führen Sie den Befehl aus: set k4 v4. Wählen Sie Port 6380 bzw. Port 6381 aus und führen Sie den Befehl aus: get k4

# 6379 端口
[root@itdragon bin]# ./redis-server redis6379.conf 
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> set k4 v4
OK

# 6380 端口
127.0.0.1:6380> get k4
"v4"

# 6381 端口
127.0.0.1:6381> get k4
"v4"

Nach dem Neustart des Hosts ist alles normal.

Schritt 9: Stellen Sie die Maschine wieder her, wählen Sie Port 6380 aus und führen Sie den Befehl aus: Herunterfahren. Wählen Sie Port 6379 und führen Sie den Befehl aus: set k5 v5. Wählen Sie Port 6380 aus, starten Sie den Redis-Dienst neu und führen Sie den Befehl aus: get k5

# 6380 端口
127.0.0.1:6380> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# ./redis-server redis6380.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6380
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......
127.0.0.1:6380> get k5
"v5"

# 6379 端口
127.0.0.1:6379> set k5 v5
OK

从机宕机后,一切正常。笔者用的是redis.4.0.2版本的。看过其他教程,从机宕机恢复后,只能同步主机新增数据,也就是k5是没有值的,可是笔者反复试过,均有值。留着备忘!

第十步:去中性化思想,选择6380端口,执行命令:SLAVEOF 127.0.0.1 6381。选择6381端口,执行命令:info replication

# 6380 端口
127.0.0.1:6380> SLAVEOF 127.0.0.1 6381
OK

# 6381 端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=1677,lag=1
......

虽然6381 是6380的主机,是6379的从机。在Redis眼中,6381依旧是从机。一台主机配多台从机,一台从机在配多台从机,从而实现了庞大的集群架构。同时也减轻了一台主机的压力,缺点是增加了服务器间的延迟。

从机上位 

模拟主机宕机,人为手动怂恿从机上位的场景。先将三个端口恢复成6379是主机,6380和6381是从机的架构。

从机上位步骤:

第一步:模拟主机宕机,选择6379端口,执行命令:shutdown

第二步:断开主从关系,选择6380端口,执行命令:SLAVEOF no one

第三步:重新搭建主从,选择6381端口,执行命令:info replication,SLAVEOF 127.0.0.1 6380

第四步:之前主机恢复,选择6379端口,重启Redis服务,执行命令:info replication

在6379主机宕机后,6380从机断开主从关系,6381开始还在原地待命,后来投靠6380主机后,6379主机回来了当它已是孤寡老人,空头司令。

# 6379端口

127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380端口
127.0.0.1:6380> SLAVEOF no one
OK
127.0.0.1:6380> set k6 v6
OK

# 6381端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
......
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380
OK
127.0.0.1:6381> get k6
"v6"

哨兵监控 

从机上位是需要人为控制,在生产环境中是不可取的,不可能有人实时盯着它,也不可能大半夜起床重新搭建主从关系。在这样的需求促使下,哨兵模式来了!!!

哨兵有三大任务:

1 监控:哨兵会不断地检查你的Master和Slave是否运作正常

2 提醒:当被监控的某个Redis出现问题时, 哨兵可以通过API向管理员或者其他应用程序发送通知

3 故障迁移:若一台主机出现问题时,哨兵会自动将该主机下的某一个从机设置为新的主机,并让其他从机和新主机建立主从关系。

哨兵搭建步骤:

第一步:新开一个窗口,取名sentinel,方便观察哨兵日志信息

第二步:创建sentinel.conf文件,也可以从redis的解压文件夹中拷贝一份。

第三步:设置监控的主机和上位的规则,编辑sentinel.conf,输入 sentinel monitor itdragon-redis 127.0.0.1 6379 1 保存退出。解说:指定监控主机的ip地址,port端口,得票数。

第四步:前端启动哨兵,执行命令:./redis-sentinel sentinel.conf。

第五步:模拟主机宕机,选择6379窗口,执行命令:shutdown。

第六步:等待从机投票,在sentinel窗口中查看打印信息。

第七步:启动6379服务器,

语法结构:sentinel monitor 自定义数据库名 主机ip 主机port 得票数

若从机得票数大于设置值,则成为新的主机。若之前的主机恢复后,

如果哨兵也宕机了???那就多配几个哨兵并且相互监控。

# sentinel窗口
[root@itdragon bin]# vim sentinel.conf
sentinel monitor itdragon-redis 127.0.0.1 6379 1
[root@itdragon bin]# ./redis-sentinel sentinel.conf
......
21401:X 29 Nov 15:39:15.052 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ itdragon-redis 127.0.0.1 6380
21401:X 29 Nov 15:39:15.052 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380
21401:X 29 Nov 15:39:45.081 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380

21401:X 29 Nov 16:40:52.055 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380
21401:X 29 Nov 16:41:02.028 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ itdragon-redis 127.0.0.1 6380
......

# 6379端口
127.0.0.1:6379> SHUTDOWN
not connected> QUIT

# 6380端口
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=72590,lag=0
......

# 6381端口
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
......

+slave :一个新的从服务器已经被 Sentinel 识别并关联。

+sdown :给定的实例现在处于主观下线状态。

-sdown :给定的实例已经不再处于主观下线状态。

Detaillierte Erläuterung der Redis-Master-Slave-Replikation

Detaillierte Erläuterung der Redis-Master-Slave-Replikation

主从复制的原理

全量复制

实现原理:建立主从关系时,从机会给主机发送sync命令,主机接收命令,后台启动的存盘进程,同时收集所有用于修改命令,传送给从机。

增量复制

实现原理:主机会继续将新收集到的修改命令依次传给从机,实现数据的同步效果。

主从复制的缺点

Redis的主从复制最大的缺点就是延迟,主机负责写,从机负责备份,这个过程有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,从机器数量的增加也会使这个问题更加严重。

Zusammenfassung

1 Anzeigen des Befehls für die Master-Slave-Replikationsbeziehung: Info-Replikation

2 Festlegen des Befehls für die Master-Slave-Beziehung: Slaveof Host IP Host Port

3 Aktivieren Sie den Sentinel-Modus-Befehl: ./redis-sentinel sentinel.conf

4 Prinzip der Master-Slave-Replikation: vollständige Zuweisung zu Beginn, gefolgt von inkrementeller Zuweisung

5 Drei Hauptaufgaben des Sentinel-Modus: Überwachung, Erinnerung, automatische Fehlermigration

Weitere Redis-Kenntnisse finden Sie in der Spalte Redis-Datenbank-Tutorial.

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung der Redis-Master-Slave-Replikation. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:cnblogs.com. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen