Moin,
ich habe die DB für configDB auf einer MariaDB Instanz auf der Synology laufen. Da liegen auch andere Datenbanken von mir und ich wollte gerne eine zu starke Fragmentierung der Datenbanken im Netz vermeiden, um das Thema Backup/Sicherheit ein wenig zu vereinfachen. Nachteil ist natürlich, das bei einem Reboot der Nas auch die DB steht und in der Folge Fhem.
Hat schon jemand ein HA bzw. Failover Szenario realisiert mit lokaler MariaDB Instanz als Master und Slave auf der Synology oder ggf. umgekehrt?
Vielen Dank
Grüße
Kai
Zitat von: Kai-Alfonso am 21 Februar 2022, 11:42:26
Nachteil ist natürlich, das bei einem Reboot der Nas auch die DB steht und in der Folge Fhem.
Gibt es da nicht ein Attribut für "asynchron" oder so?
Gruß, Joachim
Zitat von: MadMax-FHEM am 21 Februar 2022, 11:43:58
Gibt es da nicht ein Attribut für "asynchron" oder so?
Gruß, Joachim
Das kann sein, gefunden hab ich es nicht
deleteimported : (0|1) delete file from filesystem after import
dumpPath : (valid path) define path for database dump
maxversions : (number) define maximum number of configurations stored in database
mysqldump : (valid parameter string) define additional parameters used for dump in mysql environment
private : (0|1) show or supress userdata in info outputIn der commandref steht auch nichts.
configDB liest die Daten eigentlich nur zum Start aus der DB und braucht dann eben beim Schreiben (save) wieder Zugriff. Für mich klingt das eher nach einer DBLog-Thematik, und da gibt es einen asynchronen Modus.
Die Daten in der configDB sind in der Regel auch nicht allzu viele, von daher weiß ich nicht, ob das "Fragmentierungsargument" so schlagkräftig ist...
Zitat von: Beta-User am 21 Februar 2022, 11:52:20
configDB liest die Daten eigentlich nur zum Start aus der DB und braucht dann eben beim Schreiben (save) wieder Zugriff. Für mich klingt das eher nach einer DBLog-Thematik, und da gibt es einen asynchronen Modus.
Die Daten in der configDB sind in der Regel auch nicht allzu viele, von daher weiß ich nicht, ob das "Fragmentierungsargument" so schlagkräftig ist...
also DBLog läuft bei mir schon seit immer im asynchronen Modus. Mit Fragmentation meinte ich eher, das ich alle DBs zu Hause gerne auf einem Host laufen habe
Na ja, wie dem auch sei: FHEM dürfte nicht stehen bleiben, nur weil der DB-Server _zwischendurch_ weg ist; wenn, dann kann es nur eine Rolle spielen, wenn entweder ein FHEM-Start stattfindet oder was gespeichert werden soll.
Zitat von: Beta-User am 21 Februar 2022, 12:46:21
Na ja, wie dem auch sei: FHEM dürfte nicht stehen bleiben, nur weil der DB-Server _zwischendurch_ weg ist; wenn, dann kann es nur eine Rolle spielen, wenn entweder ein FHEM-Start stattfindet oder was gespeichert werden soll.
Danke dir - unabhängig von der DB Geschichte schaue ich mal, wieso Fhem dann einfach stehenbleibt. Gibt eigentlich sonst keine anderen Ressourcen auf der NAS, wo Fhem drauf zugreifen müsste. Aber irgendwas muss da sein.
configDB hat keinen asynchronen Modus.
Zitat von: Kai-Alfonso am 21 Februar 2022, 12:31:14
Mit Fragmentation meinte ich eher, das ich alle DBs zu Hause gerne auf einem Host laufen habe
Das kannst Du ja machen. Aber wenn möglich, die Daten von DBLog und configDB nicht in die gleiche Datenbank schreiben.
Ein DB-Host kann ja problemlos mehrere Datenbanken verwalten.
Zitat von: Beta-User am 21 Februar 2022, 11:52:20
configDB liest die Daten eigentlich nur zum Start aus der DB und braucht dann eben beim Schreiben (save) wieder Zugriff.
Vorsicht, so einfach ist das nicht! Die Datenbank muss nicht nur zum Start und zum "save config" verfügbar sein.
Zitat von: Beta-User am 21 Februar 2022, 12:46:21
wenn, dann kann es nur eine Rolle spielen, wenn entweder ein FHEM-Start stattfindet oder was gespeichert werden soll.
FHEM braucht auch zur Laufzeit zuverlässigen Zugriff auf die Konfigurationsdatenbank. Beispielsweise werden die gplot Dateien bei der Anzeige von SVG plots jedesmal aus der Datenbank gelesen.
2022.02.21 14:10:24 4: configDB reading file: ./www/gplot/SVG_dbLog_1.gplotAnderes Beispiel: Ruft man den gplot-Editor auf und speichert die Definition dann wieder ab, wird auch das in die Datenbank geschrieben.
2022.02.21 14:14:02 4: configDB writing file: ./www/gplot/SVG_dbLog_1.gplotEs gibt noch eine ganze Reihe andere Module, die ihre Daten regelmäßig in die Datenbank schreiben und/oder aus ihr lesen. (eventTypes, RSS, InfoPanel, DbLog, ...)
Danke für die Klarstellung, v.a. den lesenden Zugriff für plots usw. hatte ich in der Tat nicht auf dem Schirm.