DbRep - Import von 770MB csv (8.758.319 Datensätze) in mySQL, RasPi 3 stürzt ab.

[Frank_Huber]

Na das ist auf dem 3er beides nicht vorhanden.

45 zu 3,5min?
Da siehst mal wie langsam deine dump Routinen sind. *zwinker*

Ne im ernst, mir so nem Unterschied hätte ich auf der gleichen HW nicht gerechnet.

Gesendet von meinem Doogee S60 mit Tapatalk

[DS_Starter]

Ja, wie gesagt, andere Techniken.
Die eine Routine schreibt nur die history-Tabelle raus und macht das mit Mitteln der DB-Engine. Dafür muss bei einem Restore die DB  und eine history Tabelle schon vorhanden sein.

Die clientSide schreibt alles raus inklusive current, indizes, eventuell angelegten Views usw. und hat auch die Möglichkeit die Tabellen vom Scratch anzulegen wenn sie nicht vorhanden sind.
Wenn du die Dumpfliles dir ansiehst wirst du große Unterschiede feststellen, eins ist ein einfaches Textfile, das andere enthält jede Menge SQL-Statements.

[Frank_Huber]

In der Tat,

client side:

Code Auswählen Erweitern

2019.01.28 21:04:14 3: DbRep DBRep_mySQL - 8586861 records inserted (size of backupfile: 1540.46 MB)
2019.01.28 21:04:14 3: DbRep DBRep_mySQL - Finished backup of database fhem - total time used (hh:mm:ss): 07:49:53

server side:

Code Auswählen Erweitern

2019.01.29 09:32:55 3: DbRep DBRep_mySQL - Number of exported datasets: 8588523
2019.01.29 09:32:55 3: DbRep DBRep_mySQL - Finished backup of database fhem - total time used (hh:mm:ss): 00:04:21

für serverside auf meinem gemounteten Ordner musste ich noch bischen nach Berchtigungen forschen, war dann aber nochmal schneller:

Code Auswählen Erweitern

2019.01.29 10:10:27 3: DbRep DBRep_mySQL - Number of exported datasets: 8588591
2019.01.29 10:10:27 3: DbRep DBRep_mySQL - Size of backupfile: 762.54 MB
2019.01.29 10:10:27 3: DbRep DBRep_mySQL - Finished backup of database fhem - total time used (hh:mm:ss): 00:03:00

damit könnte ich sogar ganz gut leben. denke die Versuche mit dem mySQL auf Windows spare ich mir (erstmal).

[Frank_Huber]

Ein "Problem" besteht aktuell noch.

Den Share mounte ich als mit UID=111 welches für den mysql user steht. nur damit kann mysql dort das backup ablegen.
Will ich aber den dump auch komprimieren schlägt das fehl weil hier wohl fhem als Benutzer greift.

Code Auswählen Erweitern

2019.01.29 10:50:00 3: DbRep DBRep_mySQL - ################################################################
2019.01.29 10:50:00 3: DbRep DBRep_mySQL - ###             New database serverSide dump                 ###
2019.01.29 10:50:00 3: DbRep DBRep_mySQL - ################################################################
2019.01.29 10:50:00 3: DbRep DBRep_mySQL - execute command before dump: 'set logdb reopen 3600'
2019.01.29 10:50:00 2: DbLog logdb: Connection closed until 11:50:00 (3600 seconds).
2019.01.29 10:50:00 3: DbRep DBRep_mySQL - Searching for tables inside database fhem....
2019.01.29 10:50:00 3: DbRep DBRep_mySQL - Starting dump of database 'fhem', table 'history'
2019.01.29 10:53:01 3: DbRep DBRep_mySQL - compress file /Q/backup/rpi/MySQL/fhem_history_2019_01_29_10_50.csv
2019.01.29 10:53:01 2: DbRep DBRep_mySQL - gzip of /Q/backup/rpi/MySQL/fhem_history_2019_01_29_10_50.csv failed: cannot open file '/Q/backup/rpi/MySQL/fhem_history_2019_01_29_10_50.csv.gzip': Permission denied
2019.01.29 10:53:01 3: DbRep DBRep_mySQL - Number of exported datasets: 8588703
2019.01.29 10:53:01 3: DbRep DBRep_mySQL - Finished backup of database fhem - total time used (hh:mm:ss): 00:03:01
2019.01.29 10:53:01 3: DbLog logdb: Reopen requested.
Ich schaffe es irgendwie nicht in der fstab das so einzurichten dass beide Benutzer Rechte haben.
da wirst doch zum Hirsch! unter Windows hätte ich die Rechte schon längst zurecht gebogen...

[Wernieman]

mysql der Gruppe root hinzufügen reicht nicht.

sehr blöde Idee ....

Das Ziel ist ein Windows-Share?

Dann gibt es 2 Möglichkeiten
a) Du liest Dich in ACL ein
b) Du machst ein Backup local und schiebst es im 2. Stepp als User fhem hoch ....

[Frank_Huber]

sehr blöde Idee ....

Das Ziel ist ein Windows-Share?

Dann gibt es 2 Möglichkeiten
a) Du liest Dich in ACL ein
b) Du machst ein Backup local und schiebst es im 2. Stepp als User fhem hoch ....

Ja, ein Windows Share,
Zur Ursachenforschung finde ich das erstmal OK mit den Rechten, dauerhaft bzw auf dem produktiven nicht.

dump und FHEM Backup laufen wieder zusammen. da war noch nen anderer Wurm drin für den Zielordner.
a) Danke für den Hinweis. werd ich machen. kannte ich noch nicht.
b) da DbRep das Backup macht hab ich selbst da wenig chancen.

[DS_Starter]

Bezüglich DbRep Backup kannst du auch FTP verwenden falls ein FTP Server auf dem Zielrechner vorhanden ist.
Geht auch mit Versionsverwaltung im DbRep out-of-the-box. Nur so als Hinweis falls du es noch nicht gesehen hast.

Das wäre quasi b).

[Frank_Huber]

Bezüglich DbRep Backup kannst du auch FTP verwenden falls ein FTP Server auf dem Zielrechner vorhanden ist.
Geht auch mit Versionsverwaltung im DbRep out-of-the-box. Nur so als Hinweis falls du es noch nicht gesehen hast.

Das wäre quasi b).

müsste ich erst nen FTP aufsetzen. eleganter wäre es wenn der SQL User auch das zippen machen würde.
In meinem Fall hätte ich dann FHEM backups und SQL dumps im gleichen share.
Alternativ lass ich einfach die Kompression aus. das ist wohl für uns alle die einfachste Lösung. *lach*

Bin übrigens auf ein Limit mit dem MySQL auf Windows gestossen:
- loggen und auslesen der history geht problemlos.
- dump restore oder dump serverside schlägt fehl. "secure-file-priv" wäre angeblich aktiv. --> ist es aber nicht.

Code Auswählen Erweitern

2019.01.29 13:52:35 2: DbRep DBRep_mySQL_win - DBD::mysql::st execute failed: The MySQL server is running with the --secure-file-priv option so it cannot execute this statement at ./FHEM/93_DbRep.pm line 6877.
da gaukelt der Windows MySQL wohl falsche Tatsachen vor.

[DS_Starter]

Da habe ich im Netz Hinweise gefunden. In der my.cnf setzen:

secure-file-priv= "<Pfad>"

Wenn die Variable leer ist, hätte sie keinen Effekt. Ich denke dass lässt sich lösen.
Mir fällt noch die Variante mit dem Attr usrExitFn ein. Hier hinterlegst du eine Perl Routine in myUtils die bei jedem erstellten Reading von DbRep durchlaufen wird. Richtig ausgewertet, startest du nach dem erledigten Kompresslauf die Übertragung mit einem shellscricpt oder qx erc.

Wäre vllt. auch etwas.

[Frank_Huber]

Da habe ich im Netz Hinweise gefunden. In der my.cnf setzen:

secure-file-priv= "<Pfad>"

Wenn die Variable leer ist, hätte sie keinen Effekt. Ich denke dass lässt sich lösen.
Mir fällt noch die Variante mit dem Attr usrExitFn ein. Hier hinterlegst du eine Perl Routine in myUtils die bei jedem erstellten Reading von DbRep durchlaufen wird. Richtig ausgewertet, startest du nach dem erledigten Kompresslauf die Übertragung mit einem shellscricpt oder qx erc.

Wäre vllt. auch etwas.

leere variable ja, wenn sie aber auskommentiert ist sollte sie nicht greifen.
Kann aber versuchen den Pfad explizit dort zu erlauben.

Das mit der Routine klingt interessant.  werd ich mir für später notieren.

[Frank_Huber]

Morgähn,

dachte ich lasse einfach erstmal die Komprimierung weg, ...
ABER, fhem kann auch keine älteren dumps löschen. Egal was ich bei dumpFilesKeep einstelle.

muss mich also mit den ACLs beschäftigen. Gestern habe ich das nach ein paar Versuchen aufgegeben...
Für heute werde ich noch etwas den auf Windows installierten MySQL quälen.

/Frank

[Frank_Huber]

Da habe ich im Netz Hinweise gefunden. In der my.cnf setzen:
secure-file-priv= "<Pfad>"
Wenn die Variable leer ist, hätte sie keinen Effekt. Ich denke dass lässt sich lösen.

Ja, die Variable gezielt auf den Pfad setzen hat funktioniert.
Musste nur bei den Pfaden für das Windows System die "\" doppeln, die einfachen hat er einfach weggelassen.

Code Auswählen Erweitern

attr DBRep_mySQL_win dumpDirLocal /Q/backup/pi/MySQL
attr DBRep_mySQL_win dumpDirRemote D:\\pi\\MySQL

Wenn ich den Mount mit dem User fhem mounte ",uid=999" kann FHEM auch das Verzeichnis bereinigen (dumpFilesKeep) und die csv zippen.

War wohl gestern zu arg darauf fixiert das Attribut zu löschen anstatt es "richtig" zu setzen.

Danke (mal wieder)

Denke der Weg über den Windows MySQL wird es dann werden.
Zieh mir jetzt dann mal von zuhause alle Daten der vier Instanzen.

[Frank_Huber]

So, Gestern die Migration auf den Windows basierten MySQL abgeschlossen.
In Summe hostet er jetzt 14,5 Mio Datensätze aus vier Instanzen und benötigt für die Sicherung (ServerSide dump) knapp 67 Sec.
mit Komprimierung sind es 4,5 Minuten. hier merkt man dass der RPI3 nicht so die gzip Leistung hat.
Werde also die Komprimierung aus lassen um den RPI zu entlasten. das dump file hat ca 1,5 GB.

Werner, Heiko, habt vielen Dank für eure unendliche Gedult und Unterstützung hier.
somit ist dieser dann doch etwas ausgeartete Thread beendet...