Redis in ioBroker - Überblick
-
Ändert sich durch die Umstellung der Datenbank von "file" auf "jsonl" etwas an den Pro/Contra Argumenten im vergleich zu Redis?
-
@kla960 Hm ... Effektiv nicht.
Warum: Der höhere generelle Durchsatz von Redis (als native C Anwendung) gegenüber einer JavaScript DB-Implementierung bleibt bestehen und hat mit der verwendeten Persistenzänderung bei JSONL nichts wirklich zu tun.
Das was sich ändert wäre I/O, wobei es hier von den Redis Einstellungen abhängt. "File-DB" ist quasi vergleichbar mit der "RDB Persistenz" vom Redis, und JSONL ist vergleichbar mit der "AOF Persistenz".
Ob sich da was ändert liegt also an der Konfig - und dann ändert es sich auch nur weil ggf vorher suboptimale Redis-EInstellungen genutzt wurden
-
Hallo Zusammen!
Mein ioBroker Master läuft mit 5 Slaves jetzt schon lange stabil auf einer lokalen Redis-Installation. Das ganze System ist dadurch deutlich performanter geworden.
Jetzt wollte ich meinen Redis-Host als Docker-Container auf einem anderen Host laufen lassen, ist ja einfach zu installieren. Eventuell auch auf Redis-Sentinel, aber das dann später.
Nun, jetzt kommt mein Problem: wie stelle ich einen bereits auf lokalem Redis laufenden ioBroker auf einen anderen Redis-Host um? Ein einfaches
iobroker stop - iobroker setup custom (dann die IP des neuen Redis Hosts vergeben) und iobroker start
führte jedenfalls zu einer völlig verkorksten ioBroker Installation. Alle States und Instanzen waren weg! Zum Glück hat ein erneutes "iobroker setup custom" mit Auswahl von 127.0.0.1 die vorhandene, lokale Redis-DB gefunden und verwendet. Jetzt läuft mein ioBroker erst mal wieder normal.
Aber: mit welcher Strategie mache ich eine Sicherung der lokalen Redis-DB (mit redis-cli BGSAVE?), kopiere die Sicherung auf den neuen Redis-Host und spiele dann dort die Sicherung ein? Danach sollte es doch funktionieren, wenn ich die IP des neuen Hosts angebe?!
Hat das schon einmal jemand durchgespielt? Das wäre ja auch wichtig für eine Umstellung von laufendem Redis auf Redis-Sentinel, denn dazu sind ja wahrscheinlich ähnliche Schritte notwendig.
Danke für Tips!
Viele Grüße
Dirk -
@higginsd sagte in Redis in ioBroker - Überblick:
Ein einfaches
iobroker stop - iobroker setup custom (dann die IP des neuen Redis Hosts vergeben) und iobroker start
führte jedenfalls zu einer völlig verkorksten ioBroker Installation. Alle States und Instanzen waren weg!
Aber: mit welcher Strategie mache ich eine Sicherung der lokalen Redis-DB (mit redis-cli BGSAVE?), kopiere die Sicherung auf den neuen Redis-Host und spiele dann dort die Sicherung ein? Danach sollte es doch funktionieren, wenn ich die IP des neuen Hosts angebe?!Der neue Redis muss extern erreichbar sein, also hier die Konfig richtig machen.
Was hast Du denn genau eingegeben? Am Ende alles bestätigen mit enter quasi ausser der "neuen" IP und dann eine migration machen.
Falls das nicht geht (weiss nicht mehr wie wir das hatten) dann am besten
- iobroker stoppen, redis stoppen (alt und neu)
- dann vom alten redis das dump.db nehmen und beim neuen hinkopieren
- dann den neuen redis starten (alten am besten aus lassen)
- dann setup custom und die IP des neuen Redis eintragen und KEINE Migration machen
Da sollte tun.
Hat das schon einmal jemand durchgespielt? Das wäre ja auch wichtig für eine Umstellung von laufendem Redis auf Redis-Sentinel, denn dazu sind ja wahrscheinlich ähnliche Schritte notwendig.
Bei Redis sentinel ists anders. Du hast von oben dann einen Redis Master. Der läuft ja schon und hat alles. Jetzt hängst Du an den erstmal zwei Redis-Slaves dran. Die bekommen dadurch automatisch die Daten vom Master und werden aktuell gehalten.
DANACH dann den Sentinel dazu (einen Sentinel pro Host wo auch der Redis läuft). Denen sagst Du die 3 Redis hosts und sich unterienander, den Rest erkennen die an sich automatisch
-
Genau so hatte ich es gemacht, aber die Migration wurde nicht ausgeführt.
Redis stoppen in einem Redis Docker Container geht nicht, zumindest nicht mit service, systemctl oder /etc/init.d/redis-server stop
Daher funktioniert das mit dem Kopieren der dump.rdb nicht.
Ich versuche es nachher noch mal und schreibe die Fehlermeldung bei der missglückten Migration auf.
-
@higginsd ja gern. Aber sonst musst du halt bei gestopptem Container die Datei in das Volume kopieren (oder volume exposen und auf ein Verzeichnis Mappen. Brauchst ja ggf eh was für Backup oder?! )
-
Danke für den entscheidenden Tip!
Manchmal sieht man vor lauter Bäumen den Wald nicht mehr...
Ich habe verzweifelt versucht, die Redis DB in meinem Docker Container zu stoppen - und dabei völlig vergessen, daß man ja auch in einen gestoppten Container Dateien kopieren kann. Bin wohl noch zu neu mit Docker und zu stark in der Denke einer VM verankert.Jedenfalls ein Redis SAVE und Redis Stop auf meinem Master, dann ein Kopieren der dump.rdb in den gestoppten Redis Container und ein Neustart des Containers haben die ganze Magie geliefert. Nach einem ssh-Umzug - mit jeweiligem "iobroker setup custom" und Umstellen auf die IP des Containers - durch die Gemeinde meiner ioBroker-Slaves läuft mein ioBroker nun auf Redis unter Docker.
Jetzt sehe ich mir mal Redis Sentinel an.
Eine Frage noch zum ioBroker Backup mit einer Redis-Basis: der ioBroker Backup-Adapter protokolliert ja beim Backup auch, daß er States und Objects sichert. Würde ein Restore von so einem Backup im Zweifel reichen, um nach einem Total-Crash zumindest einigermaßen zeitnah wieder Aufzusetzen? Oder sollte ich lieber zusätzlich regelmäßig ein SAVE des Redis Clients auslösen und die dump.rdb auch irgendwo sichern?
-
@higginsd Ein normales ioBroker Backup enthält ebenso alle States und Objekte und User-spezifische Files ... also das reicht auch
-
Nachdem ich heute den halben Tag an Redis für ioBroker rumprobiert habe noch ein paar Hinweise von mir. Kann ja sein, daß da noch jemand drüber stolpert.
a) Wenn man Redis im Docker Container nutzen will und (u.a. wegen der Sicherung) die dump.rdb über ein lokales Verzeichnis vom/auf Docker Host mounten will, dann unbedingt nur das Container-Verzeichnis (normalerweise /var/lib/redis, steht im Parameter "dir" der redis.conf) mit der darin befindlichen dump.rdb beim Docker-Aufruf (run oder create) mounten und niemals die dump.rdb Datei selber! Sonst schlägt der SAVE/BGSAVE von Redis fehl mit einem "file-busy" Fehler.
b) Docker verwendet Stand heute (4.1.2023) in redis:latest die Version 7.0.7 von Redis. Auf einem raspberry/Raspbian wird aber aktuell die Redis Version 6.0.16 verwendet bzw. von apt ausgeliefert. Dies führt in folgender Konstellation zu einem Fehler beim Sync eines Redis-Replica Slaves:
- der Redis-Master (v7.0.7) wird in einem Docker-Container gestartet
- ein Redis-Replica Slave auf einem Raspberry/Raspbian wird mit dem Master verbunden
Denn Redis 7 verwendet die dump.rdb Version 10 (steht ganz zu Anfang in der Datei) und Redis 6 kann nur die dump.rdb Version 9.
Da apt auf Raspbian derzeit nur Redis 6 als aktuell ausliefert, muss man notgedrungen auf Raspbian Redis 7 aus der Source selber compilieren. Und weil Redis standardmäßig in systemctl mit Daemon-Control eingebunden ist, muss für den Compile auch noch die libsystemd-dev installiert sein. Die liefert (zum Glück) apt aus.
sudo apt install libsystemd-dev
wget http://download.redis.io/releases/redis-7.0.7.tar.gz
tar xzf redis-7.0.7.tar.gz
cd redis-7.0.7
make USE_SYSTEMD=yes
sudo make installDer make mit dem Parameter USE_SYSTEMD=yes ist wichtig, da Redis sonst ohne Systemd-Control compiliert wird und von systemctl ständig neu gestartet wird.
Nach make und make install muss dann zum Schluss noch die /lib/systemd/system/redis-server.service angepasst werden, denn "make install" installiert Redis 7 auf /usr/local/bin, in redis-server.service wird aber /usr/bin/redis-server aufgerufen. Also den Aufruf einfach ändern auf /usr/local/bin/redis-server
Danach sollte ein "sudo systemctl daemon-reload" und ein "sudo systemctl restart redis" zu einem funktionierenden Sync des Redis-Slaves führen.
Vielleicht hilft es ja dem ein oder anderen!
-
@higginsd sagte in Redis in ioBroker - Überblick:
Denn Redis 7 verwendet die dump.rdb Version 10 (steht ganz zu Anfang in der Datei) und Redis 6 kann nur die dump.rdb Version 9.
Ja also wenn man Redis Cluster baut dann sollten die die gleiche version haben. Korrekt!
-
Zwei Frage noch zur Sentinel Config:
"Ansonsten fehlt nur die Anpassung der IP des Redis-Masters in der Konfiguration sentinel monitor mymaster 127.0.0.1 6379 2. "
Also das ist ja der Default. Da trage ich die IP meines aktuellen Redis-Masters ein, richtig?
Und: die Sentinel Clients müssen zwangsläufig jeweils auf dem System mit dem Redis-Server laufen? Abstimmen und umschalten können die doch auch, wenn sie auf völlig anderen Hosts laufen.
-
@higginsd sagte in Redis in ioBroker - Überblick:
Also das ist ja der Default. Da trage ich die IP meines aktuellen Redis-Masters ein, richtig?
Genau
Und: die Sentinel Clients müssen zwangsläufig jeweils auf dem System mit dem Redis-Server laufen? Abstimmen und umschalten können die doch auch, wenn sie auf völlig anderen Hosts laufen.
Ja natürlich können die auch woanders laufen, aber das redis-sentinel das redis-server binary in nem anderen Modus startet hast Du halt auf den hosts mit Redis alles da und also why not
Aber Formal können das andere sein, korrekt. Sentinel brauchst Du mindestes 3 -
Ja, ich habe nur das Problem, daß mein Redis Master im redis:latest Docker Container läuft. Und da wird es schwierig, auch noch Sentinel in den Container zu bringen und vor allem, es zu starten. Docker Container sind ja streng genommen nur für einen Prozess/Anwendung ausgelegt.
Klar könnte ich per apt auch noch systemctl und redis-sentinel im Container installieren und Sentinel dann ganz normal mit systemctl starten/stoppen. Aber das "verbiegt" den Container doch sehr.
Ich schaue einfach mal, ob ich das nicht mit einem zusätzlichen Sentinel-Container hinbekomme. Die anderen 2 Slaves mit Sentinel laufen bei mir auf anderen physikalischen Rechnern mit Debian/Raspbian.
Man sollte übrigens beim Start von einem Sentinel Cluster darauf achten, Sentinel zuerst auf dem aktuellen Master zu starten. Sonst sind die 2 Slaves sich in 20 Sekunden einig, daß der Master tot ist und schalten um. Danach wird es dann schwierig, den Master zu starten, zumindest musste ich die Geschichte erst wieder stoppen und eine Sicherung einspielen, denn die "Master-DB" war defekt.
Kann aber sein, daß ich falsch liege. Zumindest schadet es nicht, so vorzugehen.
-
@higginsd ja klar wenn du Docker hast dann mach nen zweiten sentinel Container auf dem gleiche Host. Ist doch faktisch das gleiche was ich oben geschrieben hab ;-))
-
Redis und Redis-Sentinel mit Docker - etwas tricky! Das Problem ist das NATing im Container. Sentinel sucht sich IP-Adressen über HELOs zusammen und das geht schief, wenn man wie bei Docker NATing hat. Denn dann wird die interne IP des Netzes im Container (irgendwas mit 17.0.x.x) an Sentinel geliefert.
Ok, die einfache Lösung ist es, den Container mit "--net=host" zu starten/bauen. Das funktioniert aber NICHT mit Docker auf MacOS, denn dann sind die Ports außerhalb des Macs (Docker Host) nicht mehr zugreifbar. Irgendein bekanntes, aber ungelöstes Problem mit dem dahinter liegendem NATing der Docker Linux-VM auf MacOS.
Abhilfe: für jeden Sentinel Host in der sentinel.conf die Parameter "sentinel announce-ip X.X.X.X" und "sentinel announce-port 26379" setzen, dabei X.X.X.X auf die eigene IP setzen. Also insbesondere im Sentinel Container auf dem Docker Host!
Ferner: damit ein Redis Master in einem Docker Container die IPs seiner verbundenen Slaves richtig erkennt, muss man in jedem Slave (besser auch im Master, wenn man Sentinel später verwenden will) die Parameter "replica-announce-ip X.X.X.X" und "replica-announce-port 6379" setzen. Dabei ist X.X.X.X wieder die eigene IP. Danach erkennt ein Redis Mster in einem Docker Container auch korrekt, mit welchen IPs seine Slaves verbunden sind.
Bisher läuft es bei mir mit 3 Redis Hosts und Sentinel.
-
@higginsd wow Puhh. Interessant. Danke für deine Infos. Hilft bestimmt anderen. Läuft bei mir in lxc Containern im proxmox Cluster.
-
Was mich ja jetzt umtreibt, ich mir aber nicht selber beantworten kann, weil ich mich noch zu wenig mit der Datenhaltung in iobroker befasst habe.
Ich nutze iobroker mit einem Master (auf Raspi mit SSD) und 6 Slaves. Wenn jetzt ein Slave ausfällt, verteile ich vom Master einfach die Adapter-Instanzen per Hand schnell auf andere Slaves und alles läuft wieder.
Mein persönlicher Worst-case: der Master fällt aus.
Frage: alle meine iobroker Daten (states und objects) sind ja sicher in meinem Redis Sentinel. Wenn jetzt der Master-Pi ausfällt, reicht es dann, einfach eine weitere iobroker Instanz als Master zu konfigurieren und mit dem Redis Sentinel zu verbinden? Sind dann alle installierten Adapter-Instanzen wieder auf dem neuen Master vorhanden und laufen? Alle meine JS-Scripte wieder da und laufen?
-
Ok, laaaangsam
Die Daten sind nicht im Redis-Sentinel!! Der Sentinel ist ein Zusatzprozess der alle deine Redis Hosts überwacht. Den Master und den Slave. Wenn jetzt der Redis Master ausfällt erkennt der Sentinel das und alle Sentinels stimmen für einen neuen Redis-master ab und das wird dann umgesetzt. Die Redis-Sentinels sorgen dann dafür das einer der Redis-Slaves zum neuen Master wird. Das heisst aus reiner DB Sicht hast Du jetzt eine hochverfügbare DB (so lange >50% der Sentinels da sind),
Daher bitte wenn Du das nutzt auch über iob Custom bei jedem ioBroker Host die Konfig der DB ändern: Als IP kommt die (komma getrennte) Liste aller (!!) Sentinel IPs rein. Bei Port der Sentinel port. Dann verbinden sich ab dann die Hots und Adapter zuerst zu irgendeinem Sentry und erfahren so welcher Redis gerade der Master ist und verbinden sich dann dorthin.
Ab jetzt sind alle ioBroker gleichberechtigt weil sie alle zum "richtigen" Redis Server verbinden können mit der Hilfe der Sentinels.
Wenn dir jetzt ein Host ausfällt wo auch ioBroker drauf läuft sind erstmal nur die Instanzen weg die dort waren. Du kannst also jetzt auf einen der anderen Hosts einloggen und die instanzen auf die anderen iobroker hosts verschieben (geht per CLI, oder auch indem du einfach pro iobroker host ne admin instanz machst die du dann bei bedarf einschaltest, dann haste auf der IP deine UI).
probleme mit dem "instanzen verschieben" machen nur adapter die ggf lokal extra Daten liegen haben - also zB "history" weil da die ganzen Datenfiles auf dem Host liegen oder andere Fälle oder falls es um USB sticks geht oder sowas.
-
Ja, schon klar daß die Daten im Redis liegen und die Sentinel clients nur die Redis Master/Slaves überwachen.
Und natürlich habe ich auf allen iobroker auch das custom setup mit der Liste der Sentinel Hosts durchgeführt.
Mein Punkt ist: ich habe die iobroker Adapter Installs nur auf dem Master gemacht, auf den Slaves nur jeweils den Backup Adapter und den JS Adapter. Instanzen verschieben auf Slaves mache ich über den Master.
Wenn ich mich auf 8081 zu einem Slave verbinde, sehe ich dort in der Oberfläche auch nur die Instanzen von Backup und JS.
Ich muss also einfach mal versuchen, den Master abzuschalten und einen weiteren iobroker als Master zu konfigurieren und dann zu starten. In der Hoffnung, dass er mir dann alle meine Adapter Instanzen anzeigt.
Das wäre dann ein einfaches Fail over für den Ausfall des Masters.
-
@higginsd Achtung Wording!! KEINER der ioBroker "hots" ist jetztnich der Master weil die Datenbank der Master ist wenn Objekte und States im Redis liegen.
und in jedem Admin kannst Du unter Adapter oben im Header den Host umschalten ... jeder Admin kann immer alle Hosts verwalten. Und unter "Instanzen" solltest Du alle Instanzen von allen Hosts sehen
