configDB - HA oder Failover der MariaDB Instanz

[Kai-Alfonso]

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

[MadMax-FHEM]

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

[Kai-Alfonso]

Gibt es da nicht ein Attribut für "asynchron" oder so?

Gruß, Joachim

Das kann sein, gefunden hab ich es nicht

Code Auswählen Erweitern

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 output

In der commandref steht auch nichts.

[Beta-User]

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...

[Kai-Alfonso]

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

[Beta-User]

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.

[Kai-Alfonso]

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.

[betateilchen]

configDB hat keinen asynchronen Modus.

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.

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.

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.

Code Auswählen Erweitern

2022.02.21 14:10:24 4: configDB reading file: ./www/gplot/SVG_dbLog_1.gplot

Anderes Beispiel: Ruft man den gplot-Editor auf und speichert die Definition dann wieder ab, wird auch das in die Datenbank geschrieben.

Code Auswählen Erweitern

2022.02.21 14:14:02 4: configDB writing file: ./www/gplot/SVG_dbLog_1.gplot

Es 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, ...)

[Beta-User]

Danke für die Klarstellung, v.a. den lesenden Zugriff für plots usw. hatte ich in der Tat nicht auf dem Schirm.