Hallo zusammen,
aus aktuellen Anlass, wollte ich mal fragen wie oft und wie ihr eure DBlog sichert.
GrüßeSwen
configDB und dbLog werden täglich gesichert
Ich benutze MariaDB und sichere ebenfalls täglich mit Hilfe der dump-Funktion im DbRep. Da ist gleich eine Versionsverwaltung mit dabei.
SQLite dump ist dort noch nicht integriert, aber das File kann man auch per Script o.ä. sichern.
SQLite Dump ist inzwischen ebenfalls integriert.
Ich würde dazu das DbLog-Device auf jeden Fall mit "set .... reopen xxxx" für die Zeit des Backups von der DB trennen damit das SQLite File in einem konsistenten Zustand gesichert wird. Im asynchronen Modus gehen dabei keine Events verloren.
danke für die antworten, ich hab mal noch eine frage. meine DB ist 1,2 GB groß. Jetzt habe ich den dump gemacht, der ist ca. 70 MB groß. Danach eine neue DB erstellt, import der erstellten sql Datei.
Die neu erstellte DB ist jetzt auch nur 86 MB groß. Ist das normal?
Grüße
Swen
ZitatDie neu erstellte DB ist jetzt auch nur 86 MB groß. Ist das normal?
Die Frage kann so pauschal nicht beantwortet werden.
Es ist so, dass wenn Datensätze in der DB gelöscht werden dadurch das File nicht automatisch kleiner wird. Es gibt zwar bei SQLite ein Auto-Vacuum, aber das ist normalerweise nicht eingeschaltet.
Demzufolge wird das Datenbankfile erst kleiner wenn ein Vacuum-Befehl durchgeführt wurde. Es kann also durchaus sein, dass sich in deiner DB jede Menge Freiplatz vorhanden war der durch den Export/Import-Vorgang freigegeben wurde, obwohl die von dir dargestellte Größenordnung doch erstaunlich ist.
Du müsstest dir also mal die Daten genauer anschauen ob alles da ist was du erwartest.
Hallo Zusammen,
um mein System etwas performanter zu haben teste ich seit einigen Tagen die Umstellung auf DbLog.
Im Prinzip habe ich nun alles soweit am Laufen, dass ich kurz vor der Umstellung bin.
Was ich allerdings noch nicht ganz verstanden habe ist wie es "normalerweise" mit dem Backup läuft.
Ich habe das DbRep installiert und kann nun so schon mal manuell ein Backup starten,
aber wie macht ihr das automatisch?
Gibt es da eine Einstellung in DbRep?
Nutzt ihr at oder DOIF?
Danke im Voraus und Grüße
Knut
## make fhem DbLog Databasedump
mysqldump --user= --password= -Q fhemLogHistory | gzip > $SOURCEPATH/backup/logDbHistory_"`date +%d-%m-%Y`".sql.gz
mysqldump --user= --password= -Q fhemLog | gzip > $SOURCEPATH/backup/logDb_"`date +%d-%m-%Y`".sql.gz
Der Code ist Teil eines Backupskriptes
Das Backup mit DbRep startet man automatisch einfach mit einem AT, z.B.:
defmod At.Fhem.Dump at *23:52:00 set Rep.Fhem.Dump dumpMySQL clientSide
attr At.Fhem.Dump icon clock
attr At.Fhem.Dump room DbLog
Oder
defmod At.Fhem.Dump at *23:52:00 set Rep.Fhem.Dump dumpMySQL serverSide
attr At.Fhem.Dump icon clock
attr At.Fhem.Dump room DbLog
Im DbRep kann nach dem Backup ein komprimieren des Files eingestellt werden (dumpCompress), eine Versionsverwaltung aktiviert werden (dumpFilesKeep) oder die Übertragung zu einem FTP-Server aktiviert werden (ftp*-Attribute).
Weiterhin können vor und nach dem Backup FHEM-Kommandos oder Perl-Script ausgeführt werden (executeBeforeProc, executeAfterProc).
Grüße,
Heiko
Alles klar, dachte ich hab da was übersehen.
Danke und Grüße
Knut
Ich mach backups auf netzlaufwerk wie hier beschrieben:
http://www.meintechblog.de/2015/05/fhem-howto-automatisches-backup-auf-externem-nas/
Eine Minute vor dem Backup mach ich auf dem dblog device ein "Reopen 600", damit ist die DB 10 Minuten geschlossen und kann problemlos gesichert werden.
Auf dem Weg hab ich jede Nacht die ganze Installation inkl dblog gesichert.
Mit dem Handy online, daher kurz gefasst...
Zitat von: DS_Starter am 24 März 2018, 17:21:20
Das Backup mit DbRep startet man automatisch einfach mit einem AT, z.B.:
defmod At.Fhem.Dump at *23:52:00 set Rep.Fhem.Dump dumpMySQL clientSide
attr At.Fhem.Dump icon clock
attr At.Fhem.Dump room DbLog
Oder
defmod At.Fhem.Dump at *23:52:00 set Rep.Fhem.Dump dumpMySQL serverSide
attr At.Fhem.Dump icon clock
attr At.Fhem.Dump room DbLog
Im DbRep kann nach dem Backup ein komprimieren des Files eingestellt werden (dumpCompress), eine Versionsverwaltung aktiviert werden (dumpFilesKeep) oder die Übertragung zu einem FTP-Server aktiviert werden (ftp*-Attribute).
Weiterhin können vor und nach dem Backup FHEM-Kommandos oder Perl-Script ausgeführt werden (executeBeforeProc, executeAfterProc).
Grüße,
Heiko
Guten Morgen
ich habe dazu eine Frage. Wenn du täglich ein Dump machst, machst du es von der gesamten Datenbank oder lediglich vom aktuellen Tag?
Ich überlege mir grad wie ich die dumps am Besten organisiere. Da ich von FHEM immer um 1 Uhr früh ein Backup auf mein NAS mache (mittels script von meintechblog.de / Otto123), dumpe ich die Datenbank um 0:30 Uhr und lege den Dump in das Verzeichnis /opt/fhem/log/ (clientSide). Das klappt soweit auch problemlos.
Doch nun meine Problemstellung. Ich möchte nicht täglich die ganze Datenbank dumpen, weil sonst das Backup immer grösser wird, sondern ich möcht irgendwie nur den aktuellen Tag dumpen, und einmal im Monat den gesamten Monat. Dabei sollen die Tagesdumps gelöscht werden. Irgendwie so.. Wie organisiert Ihr das?
Ich beschränke heute meine Datenbank mit d:30 auf die letzten 30 Tage, damit sie nicht zu gross wird. Die aktuelle d:30-Grösse ist 39mb (data length) und 133mb (data index length), komprimiert ist der dump dann 3.9mb. Ist das Ok?
Und wenn ich schon blöd am Fragen bin ;), kann mir jemand folgendes noch erklären?
- Unterschied data length und data index length?
- Unterschied delEntries im LogRep und deleteOldDays im Log?
Herzlichen Dank.
Lg c
Hallo choetzu,
ZitatWenn du täglich ein Dump machst, machst du es von der gesamten Datenbank oder lediglich vom aktuellen Tag?
Es wird die gesamte DB gedumpt. Die ca. 2,6GB werden nach Komprimierung ca. 140M groß. Geht recht schnell und 3 Generationen mit 140M vorzuhalten sind bei mir kein Problem.
ZitatIch beschränke heute meine Datenbank mit d:30 auf die letzten 30 Tage, damit sie nicht zu gross wird. Die aktuelle d:30-Grösse ist 39mb (data length) und 133mb (data index length), komprimiert ist der dump dann 3.9mb. Ist das Ok?
Die Größe ist sicher ok. ABER beim Dump die zu sichernden Daten mit den timestamp-Attributen zu begrenzen geht nicht. Diese Funktion ignoriert die timestamp-Attribute und berücksichtigt nur die in der Commandref zu dieser Funktion "dumpMySQL ..." angegebenen Attribute.
D.h. du dumpst immer die komplette DB.
ZitatIch möchte nicht täglich die ganze Datenbank dumpen, weil sonst das Backup immer grösser wird, sondern ich möcht irgendwie nur den aktuellen Tag dumpen, und einmal im Monat den gesamten Monat. Dabei sollen die Tagesdumps gelöscht werden. Irgendwie so..
Vorschlag: Einmal in der Woche oder im Monat machst du dir einen Dump mit der dumpMySQL-Funktion. Ansonsten legst du dir ein oder mehrere DbRep-Device an mit dem du täglich (z.B. 00:15) einen Export vom Vortag mit "exportToFile" an (timestamp_begin/end = previous_day_begin/end).
Im Attr expimpfile kannnst du mit Platzhaltern geschickt die Zieldatei definieren.
Bei einem Restore brauchst du dann nur das letzte Backup zurückspielen zzgl. der gesicherten Tagesdateien (importFromFile).
ZitatUnterschied data length und data index length?
Größe der Daten bzw. Größe Daten UND Indizes. Die Differenz zwischen beiden Werten sagt dir wieviel Platz deine Indizes verbrauchen.
ZitatUnterschied delEntries im LogRep und deleteOldDays im Log
deleteOldDays im DbLog löscht einfach nur Daten die älter sind als x Tage.
Die DbRep Funktion lässt sich viel feiner einstellen. Die zu löschenden Daten lassen sich bzgl. des Device/Readings eingrenzen, es können Daten gelöscht werden die älter als oder auch jünger als sind. siehe Commandref->
"timestamp_begin" gesetzt -> gelöscht werden DB-Einträge ab diesem Zeitpunkt bis zum aktuellen Datum/Zeit
"timestamp_end" gesetzt -> gelöscht werden DB-Einträge bis bis zu diesem Zeitpunkt
beide Timestamps gesetzt -> gelöscht werden DB-Einträge zwischen diesen Zeitpunkten
"timeOlderThan" gesetzt -> gelöscht werden DB-Einträge älter als aktuelle Zeit minus "timeOlderThan"
"timeDiffToNow" gesetzt -> gelöscht werden DB-Einträge ab aktueller Zeit minus "timeDiffToNow" bis jetzt
Weiterhin können FHEM/Perl-Befehle vor- und nach der Löschfunktion ausgeführt werden. Z.B. schließen der DB damit nichts "dazwischenfunkt" usw.
Grüße
Heiko
Hallo Heiko
danke für deine rasche Antwort. Das weiss ich sehr zu schätzen. Ich komme der Sache schon näher und verstehe auch das Meiste. Doch bei folgenden 2 Punkten hab ich etwas Mühe. Danke für die Erläuterung.
Zitat..und 3 Generationen mit 140M vorzuhalten...
das versteh ich nicht ganz. 3 Generationen von was?
ZitatGröße Daten UND Indizes.
Daten ist mir klar. Doch was sind Indizes?
Lg c
Zitatdas versteh ich nicht ganz. 3 Generationen von was?
Sorry für das Fachchinesisch. Wenn man Backups macht und für sich festlegt, dass man die neuesten 3 Sicherungen aufheben will und die vierte = älteste löschen möchte, dann spricht man davon 3 Generationen (von Backups) aufzuheben.
DbRep hat eine integrierte Versionsverwaltung wo du einstellen kannst wieviel Backups (Generationen) du aufheben möchtest.
ZitatDaten ist mir klar. Doch was sind Indizes?
Einen Index legst du z.B. an mit "CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP)".
Hast du bestimmt bei der Einrichtung von DbLog gesehen und hast es gemacht ?
Ein Index ist für die DB quasi wie ein Telefonbuch damit die Daten schnell gefunden werden können. Sehr wichtig für die Performance !
Und ein Index braucht Platz !!
Auf deiner DB kannst du es mit DbLog checken -> set ... configCheck
LG
Heiko
Super Heiko, herzlichen Dank, dass du dir die Zeit genommen hast. jetzt ist alles klar und ich habe meine Dumps entsprechend eingerichtet.
Darf ich noch eine letzte Frage stellen?
Ich habe einen Raspi 2. Darauf läuft lediglich FHEM mit CUL, EnOcean und Zwave. Gibt es eine Regel, wie gross die Datenbank sein darf, damit sie die Performance von Raspi nicht beeinträchtigt? Wenn ich die Datenbank mit Sequel Pro für Mac öffne, dann dauert es aktuell schon beim sortieren der Datensätze nach Zeit relativ lange.
Danke für die Antwort, dann lass ich dich in Ruhe, vorerst ;)
Hallo choetzu,
ZitatGibt es eine Regel, wie gross die Datenbank sein darf, damit sie die Performance von Raspi nicht beeinträchtigt?
Also ich habe keinen Raspi und kann die Frage nicht wirklich beantworten. Eine Regel gibt es da wahrscheinlich nicht, eher Erfahrungswerte. Meiner Meinung nach ist es dann eher die Frage ob der Suchindex angelegt wurde. Wenn nicht leidet die Lesepeformance für SVG,DbRep usw. sehr.
Weiterhin wären Engpässe bzgl. des Speichers zu vermeiden, also wenn für Auswertungen, Graphen etc. zuviele Daten in den RAM geladen werden müssen und das Betriebssystem anfängt zu swappen (Verwendung von SWAP -> MODUL SYSMON).
Das sind Gesichtspunkte die mir dazu so einfallen, gibt sicherlich noch mehr.
LG ! :)
Heiko