Sql-Adapter und meherer ioBroker Installationen
-
Moin!
Kurze Frage:
Kann ich von mehreren ioBroker Installationen mittels sql-Adapter die selbe Datenbank verwenden?
Erzeugt jeder ioBroker dann eigene Daten oder können Datenpunkte die nur die eine Instanz loggt auch von der anderen ausgelesen werden?
Danke im vorraus
Mr.Lee
-
Hey,
das sollte bei MySQL und MSSQL kein Problem sein, da der DB-Name pro Instanz angegeben werden kann. Damit kannst Du ach mit einem DB-Server jede Instanz in eine getrennte DB schreiben lassen. Die kommen sich nicht in die quere (also mal mind. bei MySQL und MSSQL). Bei Postgres und SQLite geht das glaube ich nicht so ohne weiteres.
Sogar das "gegenseitig lesen" müste gehen indem Du eine zweite Instanz anlegst wo Du den anderen DB-namen einträgst und sicherstellst das keine Datenpunkte da rein geloggt werden. Dann könnte getHistory und in jedem Fall query gehen
Warum eigentlich mehrere Installationen? Multi-Host geht nicht?
-
Moin!
Danke fürs Feedback.
Ich wollte eigentlich beide Systeme jeweils in die SELBE Datenbank auf dem selben Server schreiben/lesen lassen.
Warum…nunja...eigentlich..Spieltrieb.
Ich habe eine Liv-e und eine Fallback/Test-System die ich zyklisch gleichhalte.
Per nginx-Frontend-Server kommt man auf das Live-System und im Aufalls-Fall aus Fallback...
P.S.: Eins der Systeme ist ein MultiHost mit 4 RasPis..
-
Wenn Du sicherstellen kannst das das Fallback-System keine Datenpunkte loggt/Daten erhält die vom anderen System auch geschrieben werden, sollte das passen. Dann kommen die sich nicht ins Gehege
-
…ich weiß ich nerve...
Aber doch: beide sollen identisch sein...eben auch bez. der LogDaten...HotStandby halt...
-
Nervst nicht
Finde das eher ein sehr interessantes Thema …Wenn aber alles aktuell live läuft, dann fallen auch bei beiden die Daten an. Da es zwei getrennte Instanzen sind laufen alle Log-Checks doppelt - ergo du loggst Daten doppelt was ggf zu Duplicate-keys (Timestamp) u.ä, führen müsste (vermutung).
Hot Standby ist auf der "History-Datenlogging"-Ebene an der stelle schwierig.
Das Thema geht ja aber weiter: Wenn Du Logik(Skripte, Szenen u.ä.) hast die ausgeführt werden, willst Du ja auch nicht das das doppelt läuft.
Bedeutet für mich: Das "aktuelle Hot-Standy-Fallback-System" darf gern alle Daten erhalten, aber darf nichts tun. Bedeutet an sich: History-Logging müsste aus sein, alle "Logik-Skripte" u.ä. Adapter müssten auch aus sein. Bist also am Ende eher bei einem "Warm Standby", weil Du im Notfall neben dem "umswitchen" noch Dinge Aktivieren musst ( und im alten System deaktivieren).
Oder ?!
-
Ok, also im schlimmsten Fall einfach nur Datenverdopplung.
Könnte der SQL-Adapter nicht vorm schreiben prüfen ob der Wert (Timestamp, Datenpunkt, value) schon da ist?
Thema Hot/Warm:
Touché..aber ich habe bis auf Alex (Cloud-Adapter) nix was Logik macht und steuert.
Meine Gesamte Ablauflogik liegt auf der CCU (yahm). Da habe ich noch ne echte CCU, die ist dann aber cold (IP-Adresse, Funkschnittstelle, Ablauflogik).
Fange gerade erst an ein wenig mit JScript zu spielen und werde das dann über sync der config und deaktivieren des Adapters auf dem Testsystem lösen…
Am liebsten wäre mir, wenn bei einer MultiHost-Umgebung mehrere Master existieren könnten.
Dann hätte man zumindest eine Warm-Standby-Umgebung, sprich man könnte Adapter oder eben auch die Masterfunktion per Admin-Konsole auf einen anderen Host verschieben...
Aber bis dahin halt zwei Systeme...
-
Könnte der SQL-Adapter nicht vorm schreiben prüfen ob der Wert (Timestamp, Datenpunkt, value) schon da ist? `
Aus Performancegründen würde ich das nicht einbauen wollen …Also ich habe es so gelöst das ich ein Warm-Standby System habe. Für die States nehme ich Redis und da ist auf dem Warm-Standy ein Redis-Slave. Damit sind mal alle State-Daten da. Der Redis ist mit einer Zeile in der Konfig zum Master gemacht.
ioBroker-Daten(also das Verzeichnis) an sich wird regelmäßig per rsync auf den Warm-Standby Rechner gesynct der hat HW- und OS-mäßig identisch ist zum Hauptsystem. Da ändert sich aber im Normalfall nur das objects.json. Heisst im Notfall reicht dort ein fixen des Hostnamens in der iobroker-Konfig und der Master läuft wieder. Für die Slaves hab ich nen DNS-Eintrag der auf den Master zeigt mit dem die Verbunden sind (ebenso für Redis). Also mit Ändern des DNS-Eintrags ist es auch gefixt.
Sind also ein paar Handgriffe leider, und auch welche die blöd zu automatisieren sind.
Die "Multi-Master"-Idee ist schon in einigen Köpfen, aber hier ist meiner Meinung nach ganz wichtig nicht zu wenig zu machen, weil man sonst zu schnell in komische Situationen kommt. Theoretisch müsste man eine Quorum-Logik bauen und das heisst das mindestens 3 Rechner nötig sind um zu sagen ob der aktuelle Master wirklich tod ist und sich auf einen neuen zu einigen falls man das automatisieren will. Das kann alles beliebig komplex werden.
Mal schauen.
