NEWS
Redis in ioBroker - Überblick
-
Ok danke
-
@apollon77
Ich habe eine kurze Frage zur Umstellung von Redis -> File.
Ich betreibe einen Master und zwei Slaves. Beim Master ist mir alles klar. Was muss ich bei den beiden Slaves angeben? File scheint richtig zu sein. Muss ich den Master angeben? Ich habe hier viel zur Umstellung File auf Redis aber wenig zur Rückkehr auf File gerate bei einer Multi-Host Umgebung gefunden.
Vielleicht kannst du mir hierzu eine Hilfestellung geben. -
@martybr Am Ende sollten Die Ausgaben auf dem Screen selbst erklärend sein :-))
Bei so einer Umstellung am besten alle ioBroker hosts stoppen (Also Master und Slaves). Dann den Master auf File umstellen und migrieren. Wenn das durch ist und alles klappt (also Master starten, schauen das alles ok ist) dann die Slaves umstellen - die IP des Masters angeben für die DB IP und dort NICHT migrieren!!
Danach Slaves auch starten. Es kann jetzt sein das Admin die Konfigseiten der Adapter auf den Slaves noch nicht anzeigen kann. Da hilft aber noch ein "iobroker upload all" auf dem Master wenn auch beide Slaves an sind. -
@apollon77 Vielen Dank, das gehe ich dann mal an (natürlich vorher ein Backup machen).
-
@apollon77 Danke für diese super Anleitung! Mein iobroker system wurde deutlich zu langsam. aber mit Deiner Hilfe hat alles super geklappt Master und 1 slave bisher. der 2 Slave für weite Gpios folgt bald. und vor allem hab ich mich damit endlich an redis getraut!
und am wichtigsten er reagiert wieder viel schneller. war vorallem bei objektabfragen und in der Vis aufgefallen. -
@aba320 Aber an alle Pitfalls und so denken und Backup und so!! Und auch die I/O bedenken!
-
Hallo zusammen, passend zum Thema gibts es hier eine Dokumentation eines kompletten HA Setups: https://forum.iobroker.net/topic/47478/dokumentation-einer-proxmox-iobroker-redis-ha-umgebung
-
Ä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.