So migrieren Sie Redis-Daten mit Master-Slave-Replikation unter Ubuntu 14.04

Einführung

Redis ist ein speicherinterner NoSQL-Schlüsselwert-Cache und -Speicher, der auch auf der Festplatte gespeichert werden kann. Es erfreut sich wachsender Beliebtheit und wird sowohl in großen als auch in kleinen Projekten als Datenspeicher verwendet. Aus einer Reihe von Gründen, wie beispielsweise dem Übergang zu einem leistungsstärkeren Server, ist es manchmal erforderlich, diese Daten von einem Server auf einen anderen zu migrieren.

Es ist zwar möglich, die Datenbankdateien vom aktuellen auf den neuen Server zu kopieren, die empfohlene Methode zum Migrieren einer Redis-Datenbank besteht jedoch darin, eine Replikationskonfiguration in Master-Slave-Weise zu verwenden. Ein solches Setup ist viel schneller als das Kopieren von Dateien und erfordert nur sehr wenig oder gar keine Ausfallzeiten.

Dieser Artikel zeigt, wie Sie Redis-Daten mithilfe der Master-Slave-Replikation von einem Ubuntu 14.04-Server auf einen ähnlichen Server migrieren können. Dazu muss ein neuer Redis-Server eingerichtet und als Slave des aktuellen Servers konfiguriert werden (d. H. den Master) und befördert dann den Slave zum Master, nachdem die Migration abgeschlossen ist.

Voraussetzungen

Um diesem Artikel zu folgen, benötigen Sie einen Redis-Masterserver mit den Daten, die Sie exportieren oder migrieren möchten, und einen zweiten neuen Redis-Server, der als Slave fungiert.

Insbesondere sind dies die Voraussetzungen für den Redis-Master.

Und das sind die Voraussetzungen für den Redis-Sklaven.

Befolgen Sie unbedingt den Abschnitt zur Nameserver-Konfiguration im IPTables-Lernprogramm für beide Server. Ohne das funktioniert "+ apt +" nicht.

Schritt 1 - Aktualisieren der Redis Master Firewall

Nach der Installation und Konfiguration des Redis-Slaves verfügen Sie über zwei unabhängige Server, die aufgrund der Firewall-Regeln nicht miteinander kommunizieren. In diesem Schritt beheben wir das

Das Update umfasst das Hinzufügen einer Ausnahme zu den TCP-Regeln auf dem Master, um Redis-Datenverkehr auf Port 6379 zuzulassen. Öffnen Sie daher auf dem Master die IPTables-Konfigurationsdatei für IPv4-Regeln.

sudo nano /etc/iptables/rules.v4

Fügen Sie direkt unter der Regel, die SSH-Verkehr zulässt, eine Regel für Redis hinzu, die den Verkehr auf dem Redis-Port nur von der IP-Adresse des Slaves aus zulässt. Stellen Sie sicher, dass "++" auf die IP-Adresse des Slave-Servers aktualisiert wird.

/etc/iptables/rules.v4

. . .
# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT

. . .

Dies ist sehr restriktiv und sicherer. Andernfalls würde der Server Datenverkehr von jedem Host auf dem Redis-Port akzeptieren.

Starten Sie IPTables neu, um die neue Regel anzuwenden.

sudo service iptables-persistent restart

Nachdem das Replikationssystem aktiv ist und die Firewall auf dem Master so konfiguriert wurde, dass Redis-Datenverkehr zugelassen wird, können wir überprüfen, ob beide Server miteinander kommunizieren können. Dies können Sie mit den Anweisungen in Schritt 4 des https://www.digitalocean.com/community/tutorials/how-to-configure-a-redis-cluster-on-ubuntu-14-04 vornehmen ].

Schritt 2 - Überprüfen des Datenimports

Wenn beide Server einen Kontakt hergestellt haben, sollte der Datenimport vom Server zum Slave automatisch starten. Sie müssen jetzt nur noch überprüfen, ob dies der Fall ist und erfolgreich abgeschlossen wurde. Es gibt mehrere Möglichkeiten, dies zu überprüfen.

Das Redis Data Directory

Eine Möglichkeit, einen erfolgreichen Datenimport zu überprüfen, besteht darin, im Redis-Datenverzeichnis nachzuschauen. Die gleichen Dateien, die sich auf dem Master befinden, sollten sich jetzt auf dem Slave befinden. Wenn Sie mit diesem Befehl eine lange Liste der Dateien im Redis-Datenverzeichnis des Slave-Servers erstellen:

ls -lh /var/lib/redis

Sie sollten eine Ausgabe dieser Art erhalten:

Ausgabe

total 32M
-rw-r----- 1 redis redis 19M Oct  6 22:53 appendonly.aof
-rw-rw---- 1 redis redis 13M Oct  6 22:53 dump.rdb

Die Redis-Befehlszeile

Eine andere Methode zum Überprüfen des Datenimports ist die Redis-Befehlszeile. Geben Sie die Befehlszeile auf dem Slave-Server ein.

redis-cli

Dann authentifizieren Sie sich und geben Sie den Befehl "+ info +" ein

auth

info

In der Ausgabe sollte die Anzahl der Schlüssel im * # Keyspace * auf beiden Servern gleich sein. Die folgende Ausgabe wurde vom Slave-Server übernommen, der genau der Ausgabe auf dem Master-Server entspricht.

Ausgabe

# Keyspace
db0:keys=26378,expires=0,avg_ttl=0

Scannen Sie die Schlüssel

Eine weitere Methode, um zu überprüfen, ob der Slave die gleichen Daten wie der Master hat, ist die Verwendung des Befehls "+ scan +" in der Redis-Befehlszeile. Obwohl die Ausgabe dieses Befehls auf beiden Servern nicht immer gleich ist, können Sie bei der Ausgabe auf dem Slave zumindest bestätigen, dass auf dem Slave die Daten vorhanden sind, die Sie voraussichtlich finden werden.

Eine Beispielausgabe des für diesen Artikel verwendeten Testservers ist unten dargestellt. Beachten Sie, dass das Argument für den Befehl "+ scan +" eine beliebige Zahl ist und als Cursor fungiert:

scan 0

Die Ausgabe sollte ungefähr so ​​aussehen:

Ausgabe

1) "17408"
2)  1) "uid:5358:ip"
   2) "nodebbpostsearch:object:422"
   3) "uid:4163:ip"
   4) "user:15682"
   5) "user:1635"
   6) "nodebbpostsearch:word:HRT"
   7) "uid:6970:ip"
   8) "user:15641"
   9) "tid:10:posts"
  10) "nodebbpostsearch:word:AKL"
  11) "user:4648"
127.0.0.1:6379>

Schritt 3 - Beförderung des Slaves zum Master

Sobald Sie bestätigt haben, dass der Slave über alle Daten verfügt, können Sie ihn zum Master hochstufen. Dies wird auch in https://www.digitalocean.com/community/tutorials/how-to-configure-a-redis-cluster-on-ubuntu-14-04#step-5-%E2%80%94- behandelt. switch-to-the-slave [Schritt 5 des Redis-Cluster-Tutorials], aber der Einfachheit halber finden Sie hier auch die Anweisungen.

Geben Sie zuerst die Redis-Befehlszeile auf dem Slave ein.

redis-cli

Geben Sie nach der Authentifizierung den Befehl "+ slaveof noone +" ein, um ihn zum Master zu befördern.

auth
slaveof no one

Sie sollten diese Ausgabe erhalten:

Ausgabe

OK

Verwenden Sie dann den Befehl "+ info +", um zu überprüfen.

info

Die relevante Ausgabe im Abschnitt "* Replication *" sollte folgendermaßen aussehen. Insbesondere zeigt die Zeile * role: master *, dass der Slave jetzt der Master ist.

Ausgabe

# Replication

connected_slaves:0
master_repl_offset:11705
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Danach sollte ein einzelner Eintrag in der Protokolldatei des früheren Masters dies ebenfalls bestätigen.

/var/log/redis/redis-server.log

14613:M 07 Oct 14:03:44.159 # Connection with slave 192.168.1.8:6379 lost.

Und auf dem neuen Meister (früher der Sklave) solltest du sehen:

/var/log/redis/redis-server.log

14573:M 07 Oct 14:03:44.150 # Connection with master lost.
14573:M 07 Oct 14:03:44.150 * Caching the disconnected master state.
14573:M 07 Oct 14:03:44.151 * Discarding previously cached master state.
14573:M 07 Oct 14:03:44.151 * MASTER MODE enabled (user request from 'id=4 addr=127.0.0.1:52055 fd=6 name= age=2225 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')

Jetzt können Sie die Anwendungen mit der Datenbank verbinden und den ursprünglichen Master löschen oder zerstören.

Fazit

Bei korrekter Ausführung ist die Migration von Redis-Daten auf diese Weise eine unkomplizierte Aufgabe. Die Hauptfehlerquelle ist in der Regel das Vergessen, die Firewall des Masterservers so zu ändern, dass Redis-Datenverkehr zugelassen wird.

Weitere Informationen zu Redis finden Sie unter mehr Redis-Tutorials.