[Modul LogDB] neuer Befehl "close" für Backups

Begonnen von Elektrofreak, 25 Januar 2017, 07:32:26

Vorheriges Thema - Nächstes Thema

Elektrofreak

Hallo,

ich möchte gerne jede Nacht das Dateisystem von FHEM inkl. Datenbank in SQLite sichern. Zur Zeit beende ich FHEM jedes mal, was jedoch zu Problemen führen kann, da in diesem Zeitraum z.B. die Heizung abgeschaltet wird.

Mein Vorschlag wäre, dass das LogDB-Modul nur die Verbindung zur Datenbank trennt, bevor ein Backup angestoßen wird. Dann können alle Komponenten weiterhin aktiv sein und gesteuert / geregelt werden, es werden nur keine aktuellen Messwerte gespeichert.

Da ich eine RAM-Disk für die Datenbank verwende, die ich alle x Stunden automatisch sichere, würde das sogar bedeuten, dass ich nur für die Sicherungsvorgang aus dem RAM auf die SD-Karte die Datenbankverbindung trennen müsste und da die Kopie dann auf der SD-Karte liegt, die Verbindung mit LogDB wiederherstellen kann, obwohl das Backup im Hintergrund noch läuft.

Aktuell mache ich auch oft ein Backup der SQLite-Datenbank, wenn diese geöffnet ist. Das funktioniert zwar, kann aber korrumpierte Datensätze verursachen. Daher versuche ich eine bessere Methode zu finden  :).

Ich freue mich über eure Rückmeldungen.


PS: PN an den Developer vom LogDB-Modul mit Verweis auf diesen Thread ist raus  ;)

Tobias

reicht da nicht ein "set <dblog> disable 1" aus??? Dann sollten doch alle connection geschlossen werden..??
@DS_Starter, ist dem auch so bei deinen Erweiterungen?
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Elektrofreak

#2
Hallo.

Zitat von: Tobias am 25 Januar 2017, 07:44:03
reicht da nicht ein "set <dblog> disable 1" aus???

Den disable-Befehl konnte ich in der Doku nicht finden. Daher bin ich davon ausgegangen, dass es ihn nicht gibt. Meinst du ggf.

setreading <dblog> disable 1?

Das wäre natürlich machbar  ;) (wobei ich das disable lieber für dauerhaftes deaktivieren nehme wie für kurzzeitiges. Da wäre ein "close" und ein "reopen" besser)

marvin78


Elektrofreak

Zitat von: marvin78 am 25 Januar 2017, 08:17:03
Es ist ein Attribut, also

attr <name> disable 1

Ich Idiot, bin wohl noch nicht ganz wach  ;D ;D ;D

marvin78

Eigentlich lag hier auch jemand anderes falsch.

betateilchen

Könnte man auch als optionalen Parameter in das reopen einbauen:


set <name> reopen 60


sorgte dafür, dass die Datenbankverbindung geschlossen und nach 60 Sekunden wieder hergestellt wird.
In dieser Zeit kann die Datenbank problemlos kopiert werden, beispielsweise per notify, das auf den Event <name>:closed triggert.

Dann wäre das Ganze mit einem einzigen Kommando erledigt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Amenophis86

Das mit reopen fände ich auch gut. Vor allem, wenn ich meine NAS aktualisiere und die DB dann kurzzeitig nicht erreichbar ist.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

DS_Starter

Hallo zusammen,

interessantes Feature was betateilchen vorgeschlagen hat. Das würde ich bei einem Update mal mit vorsehen.
Die Version zum Test würde ich in diesem Thread https://forum.fhem.de/index.php/topic,62998.msg542539.html#msg542539 zur Verfügung stellen.

Allerdings müßte ich das "reopen" etwas weiter fassen. Im Gegensatz zum normalen synchronen Modus wird im asynchronen Modus die DB-Verbindung  nur für den Moment des Schreibens in die DB aufgebaut und danach wieder geschlossen. Ich müßte also solange die "Reopen-Zeit" läuft das Schreiben im asynchronen Modus ebenfalls verbieten, aber das ist machbar.

Ich schau mal ...

viele Grüße

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Hallo zusammen,

eine Version mit der Erweiterung für "set ... reopen" habe ich hier https://forum.fhem.de/index.php/topic,62998.msg571997.html#msg571997
bereitgestellt.

viele Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

mkriegl

Ich bin momentan auch am überlegen in das Thema Ramdisk einzusteigen. Bin aber noch nicht so fit, was das ganze Thema MariaDB und Ramdisk betrifft.
Soweit ich verstanden habe beinhaltet die Current Tabelle die aktuellen Daten und die History Tabelle Daten für Plots.
Ist es nicht irgendwie möglich diese beiden Tabellen in einer Ramdisk zu haben und eine weitere Backup Tabelle, die sich auf einem Stick befindet, in die regelmäßig (wöchentlich z.b.) gebackuped wird? Somit wäre der Zugriff entlastet, man hat noch Zugriff auf die letzte Woche und zur Not auf das Backup.
Nur mal so ein Idee, wei´aber nicht ob das irgendwie möglich ist.