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

[Frank_Huber]

Hi,

Will auf einem Testsystem mal mySQL anstelle SQLite versuchen.
Hab dazu eine SQLite DB in csv exportiert, das lief fehlerfrei durch.

Auf der neuen Installation mit mySQL (Installiert nach Wiki) und beim Versuch der Migration (nach dem Link im Wiki) stürz der RPI3 komplett ab.
Die LED der SD Karte leuchtet dauerhaft. (mehrere SD Karten versucht, an denen liegt es nicht)

kann die csv auch nicht mit nano öffnen, auch niccht mit Excel oder Notepad++ unter Windows.
Mit Nano kann ich beobachten dass der benutzte RAM des Systems bis auf knapp 900 MB ansteigt, dann meldet Nano "killed" oder so ähnlich.

Ist die csv defekt? Kann ich die csv irgendwie prüfen?
kann man den export irgendwie aufteilen in Zeitbereiche?
Andere Tipps?

Danke & Grüße
Frank

btw: wäre nicht ein eigenes Unterforum für DbLog / DbRep vorteilhaft?

[DS_Starter]

Morgen Frank,

welche Version DbRep hast du ?
Ich bin der Meinung die RAM Nutzung beim Import in der aktuellen Version begrenzt zu haben.

Mach mir bitte mal ein List deines DbRep.
Die Exporte kann man auch in Zeitteile splitten beim Export, klar.

Eigenes Unterforum würde ich begrüßen.

Grüße,
Heiko

[Wernieman]

Und gebe uns doch mal einige Zeilen vom csv.

Hinweis:
Auf der Kommandozeile kann man große Dateien mit Hilfsprogrammen teilweise Anzeigen lassen.
head -nX : Öffnet die ersten X Zeilen (Head = Kopf der Datei)
tail -nX : Öffnet die letzten X Zeilen (Tail = Schwanz der Datei, zu Deutsch Ende)

[Frank_Huber]

Morgen Frank,

welche Version DbRep hast du ?
Ich bin der Meinung die RAM Nutzung beim Import in der aktuellen Version begrenzt zu haben.

Mach mir bitte mal ein List deines DbRep.
Die Exporte kann man auch in Zeitteile splitten beim Export, klar.

Eigenes Unterforum würde ich begrüßen.

Grüße,
Heiko

Hi Heiko,

FHEM habe ich vor dem Export bzw Import aktualisiert.

Ich starte gerade einen neuen Versuch in dem ich die selbe Installation für den Import nehme anstelle der Neuinstallation.
Damit kann ich den Transfer über Stick als Fehler ausschließen.

List (vor dem Import Start:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DATABASE   fhem
   DEF        logdb_mysql
   LASTCMD     
   MODEL      Client
   NAME       dblog_import
   NOTIFYDEV  global,dblog_import
   NR         796
   NTFY_ORDER 50-dblog_import
   ROLE       Client
   STATE      connected
   TYPE       DbRep
   UTF8       1
   VERSION    8.9.9
   .attraggr:
   .attrminint:
   HELPER:
     DBLOGDEVICE logdb_mysql
     IDRETRIES  3
     MINTS      2019-01-18 10:45:20
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         logdb_mysql:
           TIME       1547804750.35491
           VALUE      connected
   READINGS:
     2019-01-18 10:45:50   state           connected
   dbloghash:
     CFGFN     
     COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
     CONFIGURATION ./db_mysql.conf
     DEF        ./db_mysql.conf .*:.*
     MODE       asynchronous
     MODEL      MYSQL
     NAME       logdb_mysql
     NR         727
     NTFY_ORDER 50-logdb_mysql
     PID        559
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     UTF8       1
     VERSION    3.13.0
     dbconn     mysql:database=fhem;host=localhost;port=3306
     dbuser     fhemuser
     .attraggr:
     .attrminint:
     HELPER:
       COLSET     1
       DEVICECOL  64
       EVENTCOL   512
       OLDSTATE   connected
       READINGCOL 64
       TYPECOL    64
       UNITCOL    32
       VALUECOL   128
       .RUNNING_PID:
         abortFn    DbLog_PushAsyncAborted
         arg        logdb_mysql|Mxyz--gekürzt--zyx
         bc_pid     407
         finishFn   DbLog_PushAsyncDone
         fn         DbLog_PushAsync
         loglevel   4
         pid        5958
         telnet     telnetForBlockingFn_1547800880_127.0.0.1_42520
         timeout    86400
         abortArg:
     READINGS:
       2019-01-18 10:45:50   CacheUsage      2
       2019-01-18 10:45:50   NextSync        2019-01-18 10:46:20 or if CacheUsage 500 reached
       2019-01-18 10:45:50   state           connected
     cache:
       index      3
       .memcache:
Attributes:
   expimpfile /tmp/dbexport.csv

[Frank_Huber]

Eigenes Unterforum würde ich begrüßen.

Dann müsste man mal einen Forums-Admin darum bitten.

[Frank_Huber]

Und gebe uns doch mal einige Zeilen vom csv.

Hinweis:
Auf der Kommandozeile kann man große Dateien mit Hilfsprogrammen teilweise Anzeigen lassen.
head -nX : Öffnet die ersten X Zeilen (Head = Kopf der Datei)
tail -nX : Öffnet die letzten X Zeilen (Tail = Schwanz der Datei, zu Deutsch Ende)

gerne:
root@FHEM-PI-KG:/tmp# head -n10 dbexport.csv

Code Auswählen Erweitern

"","","","","","",""
"","","","","","",""
"","","","","","",""
"","","","","","",""
"","","","","","",""
"","","","","","",""
"","","","","","",""
"","","","","","",""
"2016-11-16 13:14:39","Flur_KG_Ost_Temp","OWTHERM","temperature: 10.4375","temperature","10.4375","�C"
"2016-11-16 13:14:45","Flur_KG_Ost_rH","OWMULTI","rH: 93.25","rH","93.25",""


root@FHEM-PI-KG:/tmp# tail -n10 dbexport.csv

Code Auswählen Erweitern

"2019-01-17 03:03:19","Aussen_rH","OWMULTI","absFeuchte: 5.8","absFeuchte","5.8",""
"2019-01-17 03:03:19","Aussen_rH","OWMULTI","taupunkt: 2.7","taupunkt","2.7",""
"2019-01-17 03:03:20","ETA_Puffer_6_geforderte_Leistung","HTTPMOD","Puffer_6_geforderte_Leistung: 0.0","Puffer_6_geforderte_Leistung","0.0",""
"2019-01-17 03:03:20","Flur_KG_Ost_rH","OWMULTI","rH: 38.43","rH","38.43",""
"2019-01-17 03:03:20","Flur_KG_Ost_rH","OWMULTI","VDD: 5.12","VDD","5.12",""
"2019-01-17 03:03:20","Flur_KG_Ost_rH","OWMULTI","absFeuchte: 7.1","absFeuchte","7.1",""
"2019-01-17 03:03:20","Flur_KG_Ost_rH","OWMULTI","taupunkt: 6.4","taupunkt","6.4",""
"2019-01-17 03:03:20","ETA_FBH_3_Heizkurve","HTTPMOD","FBH_3_Heizkurve: 33","FBH_3_Heizkurve","33",""
"2019-01-17 03:03:20","Flur_KG_Ost_Temp","OWTHERM","temperature: 21.875","temperature","21.875","�C"
"2019-01-17 03:03:20","ETA_FBH_4_Vorlauf","HTTPMOD","FBH_4_Vorlauf: 33","FBH_4_Vorlauf","33",""


Konnte ich aber nur durch deinen Tipp mit head und tail. das kannte ich nicht, danke!

da er das Anfang und das Ende lesen kann gehe ich fast davon aus dass die Datei i.O. ist oder?

[Frank_Huber]

Import läuft. Die Speichernuitzung steigt an.

Im Log habe ich das:

Code Auswählen Erweitern

root@FHEM-PI-KG:/opt/fhem/log# tail -n20 fhem-2019-02.log
2019.01.18 11:14:33 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 108492.
2019.01.18 11:14:33 1: PERL WARNING: utf8 "\xC2" does not map to Unicode at ./FHEM/93_DbRep.pm line 5443, <FH> line 108493.
2019.01.18 11:14:33 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 108493.
2019.01.18 11:14:33 1: PERL WARNING: utf8 "\xC2" does not map to Unicode at ./FHEM/93_DbRep.pm line 5443, <FH> line 108494.
2019.01.18 11:14:33 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 108494.
2019.01.18 11:14:33 1: PERL WARNING: utf8 "\xC2" does not map to Unicode at ./FHEM/93_DbRep.pm line 5443, <FH> line 108495.
2019.01.18 11:14:33 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 108495.
2019.01.18 11:14:33 1: PERL WARNING: utf8 "\xC2" does not map to Unicode at ./FHEM/93_DbRep.pm line 5443, <FH> line 108496.
2019.01.18 11:14:33 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 108496.
2019.01.18 11:14:33 1: PERL WARNING: utf8 "\xC2" does not map to Unicode at ./FHEM/93_DbRep.pm line 5443, <FH> line 108497.
2019.01.18 11:14:33 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 108497.
2019.01.18 11:14:33 1: PERL WARNING: utf8 "\xC2" does not map to Unicode at ./FHEM/93_DbRep.pm line 5443, <FH> line 108498.
2019.01.18 11:14:33 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 108498.
2019.01.18 11:14:33 1: PERL WARNING: utf8 "\xC2" does not map to Unicode at ./FHEM/93_DbRep.pm line 5443, <FH> line 108502.
2019.01.18 11:14:33 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 108502.
2019.01.18 11:14:33 1: PERL WARNING: utf8 "\xC2" does not map to Unicode at ./FHEM/93_DbRep.pm line 5443, <FH> line 108506.
2019.01.18 11:14:33 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 108506.
2019.01.18 11:14:33 1: PERL WARNING: utf8 "\xC2" does not map to Unicode at ./FHEM/93_DbRep.pm line 5443, <FH> line 108507.
2019.01.18 11:14:33 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 108507.
2019.01.18 11:14:33 1: PERL WARNING: utf8 "\xC2" does not map to Unicode at ./FHEM/93_DbRep.pm line 5443, <FH> line 108508.


[DS_Starter]

Setzt dir mal bitte im DbLog cfg-File UTF = 0 oder auskommentieren. Danach Konfig neu einlesen und den Import restarten. Vorübergehend die MySQL auf synchron umschalten damit der Speicher nicht ansteigt. So erstmal die Theorie.

[Frank_Huber]

Setzt dir mal bitte im DbLog cfg-File UTF = 0 oder auskommentieren. Danach Konfig neu einlesen und den Import restarten. Vorübergehend die MySQL auf synchron umschalten damit der Speicher nicht ansteigt. So erstmal die Theorie.

der vorhin gestartete Import läuft noch. gestern war er nach ca 30min stehen geblieben.
Ich denke daher fast dass die Datei was hat(te)

Mal schauen wie lange es noch läuft. ich melde mich dann wieder.

Heiko,
sollte ich das im cfg generell ändern oder nur wegen dem Import?

[DS_Starter]

Na dann lass mal laufen. Die Änderung wäre nur für die Importphase zur möglichen Problemlösung.

Grüße,
Heiko

[Frank_Huber]

OK, danke. wie lange läuft das ca? kannst Du das abschätzen?

muss dann auch hinterher mal schauen ob alles korrekt importiert ist.
irgend etwas kann er ja nicht sauber interpretieren. das sagen ja die Log Einträge oder?

btw: Die "line" am Ende der Log Einträge, ist das die Zeile vom Import file?

[DS_Starter]

Ich bin grad nicht in Lage nachzuschauen aber bin der Meinung mit verbose 4 Ausgaben zum Importverlauf zu machen, d.h. wieviel Sätze wurden schon importiert usw.
Wie lange es dauert weiß nur die Db allein 

Das ist erstmal nur eine Warnung. Aber wenn alles durch ist wird die Anzahl der importierten Sätze ausgegeben und sollte mit der exportierten Zahl übereinstimmen.
Eventuell die Ziel Db nochmal droppen, beim Quell DbLog das Attribut useCharfilter setzen, neu expotieren und wieder importieren. In der IT macht man bei solchen Migrationen auch Testläufe vor der Produktiven Übernahme

Ähhh.... dabei fällt mir ein ... wie genau hast du den Export gemacht ? Mit DbRep oder anders ?

[Frank_Huber]

Ich bin grad nicht in Lage nachzuschauen aber bin der Meinung mit verbose 4 Ausgaben zum Importverlauf zu machen, d.h. wieviel Sätze wurden schon importiert usw.
Wie lange es dauert weiß nur die Db allein 

Das ist erstmal nur eine Warnung. Aber wenn alles durch ist wird die Anzahl der importierten Sätze ausgegeben und sollte mit der exportierten Zahl übereinstimmen.
Eventuell die Ziel Db nochmal droppen, beim Quell DbLog das Attribut useCharfilter setzen, neu expotieren und wieder importieren. In der IT macht man bei solchen Migrationen auch Testläufe vor der Produktiven Übernahme

Mach ich gern.
Das ist alles noch Test hier aufm Schreibtisch.
aber erstmal muss er fertig laufen.

Bin ja schon mal happy dass er nicht abschmiert.

[Wuppi68]

mit vi kann man sogar wirklich große Textdateien editieren

[Wernieman]

Dachte ein Kollege auch mal ;o)
(War allerdings ein mehrere GByte Großer mySQL-Dump ...)

[Wuppi68]

Dachte ein Kollege auch mal ;o)
(War allerdings ein mehrere GByte Großer mySQL-Dump ...)

naja, es geht .... muss aber genug Platz im SWAP/TMP vorhanden sein

[Wernieman]

Und es braucht Zeit zum laden, die wir eigentlich nicht hatten ....

[DS_Starter]

Hallo Frank,

wie seiht es bei dir aus ?

Ich habe mal bei mir getestet. Habe rund 28Mio Datensätze exportiert und in etwa 2 Stunden in die MySQL importiert.
Die Warnungen habe ich auch festgestellt. Schau mal woran das liegt. Ist mir früher nie aufgefallen.

Code Auswählen Erweitern


2019.01.18 19:00:22.169 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 28085845.
2019.01.18 19:00:22.803 1: PERL WARNING: utf8 "\xC2" does not map to Unicode at ./FHEM/93_DbRep.pm line 5443, <FH> line 28089041.
2019.01.18 19:00:22.804 1: PERL WARNING: Malformed UTF-8 character (unexpected non-continuation byte 0x43, immediately after start byte 0xc2) in transliteration (tr///) at ./FHEM/93_DbRep.pm line 5410, <FH> line 28089041.
2019.01.18 19:00:22.827 4: DbRep Rep.MariaVM.Import - execute command after import: 'set LogMariaVM reopen'
2019.01.18 19:00:22.831 3: DbLog LogMariaVM: Reopen requested.
2019.01.18 19:00:22.832 3: DbLog LogMariaVM - Creating Push-Handle to database mysql:database=fhemtest;host=192.168.2.44;port=3306 with user fhemtest
2019.01.18 19:00:22.833 3: DbLog LogMariaVM - Push-Handle to db mysql:database=fhemtest;host=192.168.2.44;port=3306 created
2019.01.18 19:00:22.834 3: DbLog LogMariaVM - UTF8 support enabled
2019.01.18 19:00:22.948 2: DbRep Rep.MariaVM.Import - command message after import: "Reopen executed."
2019.01.18 19:00:22.995 3: DbRep Rep.MariaVM.Import - Number of imported datasets to fhemtest from file /sds1/backup/export.txt: 28089090


[DS_Starter]

Konnte die Warnungen beseitigen und habe einen Fix eingecheckt.

[Frank_Huber]

Konnte die Warnungen beseitigen und habe einen Fix eingecheckt.

Ja, habs gesehen.
Meiner schafft noch. (seit 11.08)
Ich geb bescheid.

Gesendet von meinem Doogee S60 mit Tapatalk

[Frank_Huber]

So wie es aussieht ist er abgeschmiert.
Komme nicht mehr drauf. Nicht per Browser auf FHEM, nicht per SSH und nicht per VNC.
Auf ping reagiert er aber.

Kann ich wohl erst Montag weitermachen.
(RasPi steht im Büro)

Gesendet von meinem Doogee S60 mit Tapatalk

[Frank_Huber]

Kam jetzt doch drauf...

aus dem Import dbRep deice:

Code Auswählen Erweitern

state   Process died prematurely   2019-01-19 08:57:38
im Log hab ich "cannot fork cannot allocate memory" Meldungen.

War wohl zuviel.
Werd das am Montag nochmal starten. im 4 Teilen zu je ca 2 Mio Datensätzen.

Nach dem Fix, sollte ich die oben geschriebenen Änderungen trotzdem vorher machen?

[DS_Starter]

Nein, brauchst nichts ändern. RAM Verbrauch bleibt auch stabil. Habe ich gerade nochmal nachgeschaut mit einem laufenden Test.
Eine Teilung der Importmenge ist wahrscheinlich gut. Ich mache es auf einer VM mit 1GB Speicher und konnte die 28Mio in einem File importieren, allerdings ist ein NUC drunter.

[Frank_Huber]

melde mich dann Montag wie es läuft.
danke!

[Wernieman]

Würde es bringen, eventuell mysql für den Import vorher "zu tunen"? z.B. keine BinLogs schreiben etc.?

Es ist ja jederzeit möglich, dieses tunen zurückzunehmen ...

[DS_Starter]

Man kann bestimmt noch tunen, keine Frage. Der Import ist nur so einfach gehalten dass es problemlos zwischen SQLite, MySQL und Postgre hin und her funktioniert ohne auf Spezifika der jeweiligen DB einzugehen oder diese auszureizen.
Vielleicht stelle ich mir dieser Aufgabe nochmal, aber das braucht wie üblich viel Zeit für die Ausarbeitung und Testen.

[Frank_Huber]

So, in vier Teilen konnte ich alles erfolgreich importieren. Jetzt mal die Performance beobachten und mit den Plots spielen...

Hab auch schmerzlich lernen müssen dass Linux den gesamten Inhalt des /tmp Ordner bei jedem booten löscht.
dachte gestern ich mach nen Reboot nach den ersten zwei Import files. war ne blöde Idee. musste dannach die Hälfte nochmal exportieren...

Wo wir gerade beim export sind. ´Hier hätte ich noch einen Verbesserungsvorschlag.
Ein Attribut z.B. "maxlinesperfile".
Setzt man das aus z.B. 1.000.000 wird mit der 1.000.001en Zeile automatisch eine neue Datei angelegt. z.B. mit automatischen Endungen _part1 _part2.......

So etwas würde einen größeren Export auf kleinen Systemen erleichtern. Das Limitieren auf einen Zeitbereich sagt ja nichts über die Datenmenge aus.

Danke & Grüße

[Frank_Huber]

Nachtrag:
die Importierten Daten haben bei der EInheit Fehler:

alte DB SQLite:

Code Auswählen Erweitern

2016-11-16 13:14:39|Flur_KG_Ost_Temp|OWTHERM|temperature: 10.4375|temperature|10.4375|°C
2016-11-16 14:04:39|Flur_KG_Ost_Temp|OWTHERM|temperature: 10.5|temperature|10.5|°C
2016-11-16 15:04:39|Flur_KG_Ost_Temp|OWTHERM|temperature: 10.6875|temperature|10.6875|°C
2016-11-16 16:04:39|Flur_KG_Ost_Temp|OWTHERM|temperature: 10.6875|temperature|10.6875|°C
2016-11-16 17:04:39|Flur_KG_Ost_Temp|OWTHERM|temperature: 10.75|temperature|10.75|°C


die gleichen Datensätze nach dem Import in mySQL:

Code Auswählen Erweitern

| 2016-11-16 13:14:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.4375 | temperature | 10.4375 | ?C   |
| 2016-11-16 14:04:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.5    | temperature | 10.5    | ?C   |
| 2016-11-16 15:04:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.6875 | temperature | 10.6875 | ?C   |
| 2016-11-16 16:04:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.6875 | temperature | 10.6875 | ?C   |
| 2016-11-16 17:04:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.75   | temperature | 10.75   | ?C   |


Ne Idee wie sich das beheben lässt?

[DS_Starter]

Hallo Frank,

Code Auswählen Erweitern


sqlCmd update history set TIMESTAMP=TIMESTAMP,UNIT='°C' WHERE UNIT='?C'


sollte es bringen.

Den Vorschlag setzte ich mal auf meine ToDo.

Grüße
Heiko

[Frank_Huber]

Code Auswählen Erweitern


sqlCmd update history set TIMESTAMP=TIMESTAMP,UNIT='°C' WHERE UNIT='?C'

sollte es bringen.

Danke werde ich versuchen, aber sollte es nicht nach dem Import unverändert sein?
Wenn ich es richtig sehe wurde es im Export schon "verhagelt".

Auf jeden Fall hat aber die Migration SQLite zu mySQL am Ende gut funktioniert.

[DS_Starter]

Die Crux dabei ist die Behandlung von Sonderzeichen bzw. der Umgang mit Zeichensätzen. °C ist ein typisches Beispiel dafür.

[Frank_Huber]

solange es sich einfach lösen lässt....

Im Idealfall müsste man wohl erst den Zichensatz der DB abfragen, dann entsprechend exportieren.
Problem kommt dann wohl beim Import, der müsste den Zeichensatz dann am File erkennen.
oder man bräuchte ne Steuerzeile am Anfang des csv.
Alles nicht so einfach und irgendwie auch unnötig wenns nur um die EInheit geht.

[Frank_Huber]

Code Auswählen Erweitern


sqlCmd update history set TIMESTAMP=TIMESTAMP,UNIT='°C' WHERE UNIT='?C'

sollte es bringen.

Hallo Heiko,

Das hat leider nicht funktioniert.
Es lief eine Weile mit

Code Auswählen Erweitern

SqlResultRow_1   2249828   2019-01-22 14:52:23
sqlCmd   update history set TIMESTAMP=TIMESTAMP,UNIT='� C' WHERE UNIT='?C'   2019-01-22 14:52:23
sqlResultNumRows   2249828   2019-01-22 14:52:23
state   done   2019-01-22 14:52:23

Aber dannach immer noch:

Code Auswählen Erweitern

MariaDB [fhem]> select * from history where reading = "temperature" and timestamp < "2016-11-17 00:00:00";
+---------------------+------------------+---------+----------------------+-------------+---------+------+
| TIMESTAMP           | DEVICE           | TYPE    | EVENT                | READING     | VALUE   | UNIT |
+---------------------+------------------+---------+----------------------+-------------+---------+------+
| 2016-11-16 13:14:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.4375 | temperature | 10.4375 | ? C  |
| 2016-11-16 14:04:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.5    | temperature | 10.5    | ? C  |
| 2016-11-16 15:04:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.6875 | temperature | 10.6875 | ? C  |
| 2016-11-16 16:04:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.6875 | temperature | 10.6875 | ? C  |
| 2016-11-16 17:04:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.75   | temperature | 10.75   | ? C  |
| 2016-11-16 18:04:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.6875 | temperature | 10.6875 | ? C  |
| 2016-11-16 19:04:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.75   | temperature | 10.75   | ? C  |
| 2016-11-16 20:04:39 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.875  | temperature | 10.875  | ? C  |
| 2016-11-16 21:04:41 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.75   | temperature | 10.75   | ? C  |
| 2016-11-16 22:04:41 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.8125 | temperature | 10.8125 | ? C  |
| 2016-11-16 23:04:41 | Flur_KG_Ost_Temp | OWTHERM | temperature: 10.8125 | temperature | 10.8125 | ? C  |
+---------------------+------------------+---------+----------------------+-------------+---------+------+


Mach Dir aber deswegen keinen Kopf. Die Einheit brauch ich nicht wirklich.
Neu geloggte Daten sind korrekt:

Code Auswählen Erweitern

| 2019-01-22 14:57:30 | OWX_10_6D0CD6020800 | OWTHERM | state: T: 25.25 °C ↓    | data        | state: T: 25.25 °C ↓    | 25.25 °C ↓    |
| 2019-01-22 15:02:30 | OWX_10_6D0CD6020800 | OWTHERM | state: T: 25.38 °C ↓    | data        | state: T: 25.38 °C ↓    | 25.38 °C ↓    |
| 2019-01-22 14:02:19 | OWX_10_6D0CD6020800 | OWTHERM | state: defined          | state       | defined                 |               |
| 2019-01-22 14:02:29 | OWX_10_6D0CD6020800 | OWTHERM | state: initialized      | state       | initialized             |               |
| 2019-01-22 14:02:30 | OWX_10_6D0CD6020800 | OWTHERM | temperature: 24.6875    | temperature | 24.6875                 | °C            |
|

[DS_Starter]

Ganz am Anfang hattest du gepostet.

Code Auswählen Erweitern


"2016-11-16 13:14:39","Flur_KG_Ost_Temp","OWTHERM","temperature: 10.4375","temperature","10.4375","�C"

Da steht nicht °C   
Aber das Problem kenne ich schon vom Logging her. Kann man im DbLog mit dem charFilter Attribut für die zukünftigen Datensätze umgehen. Ist auch der einzige Fall der immer mal wieder aufpoppt.

Da ist ein Leerzeichen zwischen ? und C. Musst die where Bedingung anpassen und neu laufen lassen.

Oder so

Code Auswählen Erweitern


sqlCmd update history set TIMESTAMP=TIMESTAMP,UNIT='°C' WHERE UNIT like '%C'


[Frank_Huber]

Da ist ein Leerzeichen zwischen ? und C. Musst die where Bedingung anpassen und neu laufen lassen.

genau das ist mir auch gerade beim vergleichen aufgefallen.
neuer Lauf läuft.

[DS_Starter]

Möglicherweise ist das aber nur ein Darstellungsproblem.

Mal mit fetchrows im DbRep anschauen wenn du fertig bist.

[Frank_Huber]

Möglicherweise ist das aber nur ein Darstellungsproblem.

Mal mit fetchrows im DbRep anschauen wenn du fertig bist.

Wenn alles korrekt läuft sollte ja jetzt nach dem Lauf alles in der DB korrekt sein.
Ich melde dann das Ergebnis.

[Frank_Huber]

fetchrows zeigt auch nur "C" an.
Ist mir aber jetzt egal. das passt so.

weiter geht es mit dem testen:
- loggen anderer Instanzen in die mySQL
- einbinden ins Backup Script.
- Anpassen User Reading für DB Größe.

[Frank_Huber]

fetchrows zeigt auch nur "C" an.
Ist mir aber jetzt egal. das passt so.

weiter geht es mit dem testen:
- loggen anderer Instanzen in die mySQL
- einbinden ins Backup Script.
- Anpassen User Reading für DB Größe.

Das scheint alles problemlos zu funktionieren.
Nur das Backup ist bei MySQL doch um einiges größer als bei sqlite. Bei gleicher datenmenge.

Werd mal noch kucken wie sich remote Plots verhalten, denke aber dass auch das OK sein wird.

Der Umstellung der Produktivsysteme scheint nichts im Weg zu stehen.

Danke Heiko nochmal für deine allzeit kompetente Hilfe!

Gesendet von meinem Doogee S60 mit Tapatalk

[Wernieman]

Wie sicherst Du denn?

[Frank_Huber]

Wie sicherst Du denn?

Ich mach ein reopen 900 auf die DB, gefolgt von nem shell Script welches auf meinen fileserver sichert.
Hab ich vor langen von nem Blog gemopst.
Das script hat Initial nur /opt/fhem drin, das hab ich um den DB Ordner ergänzt.

Edit:
https://www.meintechblog.de/2015/05/fhem-howto-automatisches-backup-auf-externem-nas/

Zusätzlich gibt es wöchentlich einen Klon der SD Karte.
Da hast mir ja im anderen Thread zur Seite gestanden. [emoji6]



Gesendet von meinem Doogee S60 mit Tapatalk

[DS_Starter]

Hast du dir schon mal

Code Auswählen Erweitern


set ... dumpMySQL serverSide  (oder clientSide)


für das Backup der MySQL-DB angeschaut ?

[Frank_Huber]

Hast du dir schon mal

Code Auswählen Erweitern


set ... dumpMySQL serverSide  (oder clientSide)


für das Backup der MySQL-DB angeschaut ?

Nein, noch nicht.
Bei sqlite hat das mit der DB Datei immer gut funktioniert.
Hab so mehrfach eine aktive Instanz auf eine Test Instanz wiederhergestellt.

Restore Tests mit MySQL stehen noch aus. [emoji6]
Werd mit das mit dem dump mal reinziehen.

Gesendet von meinem Doogee S60 mit Tapatalk

[DS_Starter]

Restore Tests mit MySQL stehen noch aus.

Es gibt natürlich auch einen integrierten Restorebefehl mit einer Dropdown-Liste

Code Auswählen Erweitern


set <DbRep> restoreMySQL <File>


[Wernieman]

Du könntest eine "richtige" DB sichern wie Du auch sql-light sicherst, nur wird dann ein restore nicht funktionieren. Eine DB cacht immr, bevor sie in die Datei schreibt, d.h. im laufenden Zustand sie die DB-Files mit großer Wahrscheinlichkeit inkonsistent.

Dafür gibt es eigene backup/restore-Befehle ....

[Frank_Huber]

Danke für den Tip!
Deswegen ist das alles noch auf dem Testsystem.
Heiko hat ja oben ja schon den eleganten Weg dargestellt.

diesen werd ich dann als nächstes angehen und dann die File-Sicherung wieder abstellen.

[DS_Starter]

Hatte gestern noch eine Version eingecheckt bei der der Export/Import von "°C" out-of-the-box funktioniert.

[Frank_Huber]

Hatte gestern noch eine Version eingecheckt bei der der Export/Import von "°C" out-of-the-box funktioniert.

dann werd ich das nochmal checken. danke.

[DS_Starter]

Hallo Frank,

ich habe DbRep noch erweitert dass man beim Export die Filegröße begenzen kann:

* exportToFile [</Pfad/File>] [MAXLINES=<lines>] - exportiert DB-Einträge im CSV-Format in den gegebenen Zeitgrenzen.

Der Dateiname wird durch das Attribut "expimpfile" bestimmt. Alternativ kann "/Pfad/File" als Kommando-Option angegeben werden und übersteuert ein eventuell gesetztes Attribut "expimpfile". Optional kann über den Parameter "MAXLINES" die maximale Anzahl von Datensätzen angegeben werden, die in ein File exportiert werden. In diesem Fall werden mehrere Files mit den Extensions "_part1", "_part2", "_part3" usw. erstellt (beim Import berücksichtigen !).
.........

Man kann die MAXLINES-Option sowohl im Kommando als auch im Attribut expimpfile verwenden.

Grüße
Heiko

[Frank_Huber]

Hallo Frank,

ich habe DbRep noch erweitert dass man beim Export die Filegröße begenzen kann:

* exportToFile [</Pfad/File>] [MAXLINES=<lines>] - exportiert DB-Einträge im CSV-Format in den gegebenen Zeitgrenzen.

Der Dateiname wird durch das Attribut "expimpfile" bestimmt. Alternativ kann "/Pfad/File" als Kommando-Option angegeben werden und übersteuert ein eventuell gesetztes Attribut "expimpfile". Optional kann über den Parameter "MAXLINES" die maximale Anzahl von Datensätzen angegeben werden, die in ein File exportiert werden. In diesem Fall werden mehrere Files mit den Extensions "_part1", "_part2", "_part3" usw. erstellt (beim Import berücksichtigen !).
.........

Man kann die MAXLINES-Option sowohl im Kommando als auch im Attribut expimpfile verwenden.

Grüße
Heiko

Na das ging ja schnell.
Hat meine Idee ja eingeschlagen. [emoji6]

Wird heute zusammen mit den Sonderzeichen getestet.

Gesendet von meinem Doogee S60 mit Tapatalk

[Frank_Huber]

Hallo Heiko,

--> "Problem" mit dem "° C" istr behoben. nach Exp/Imp alles wie es in der alten DB war.
--> MAXLINES fonktioniert super!
--> Export sowie Import ist sehr viel schneller. gefühlt Faktor 3 bis 4. kann aber auch am kompletten Raspbian Update liegen.

Danke wiedermals.

[DS_Starter]

Gern geschehen 

Edit: Und ich danke dir , habe mich gefreut     

[Frank_Huber]

Du könntest eine "richtige" DB sichern wie Du auch sql-light sicherst, nur wird dann ein restore nicht funktionieren. Eine DB cacht immr, bevor sie in die Datei schreibt, d.h. im laufenden Zustand sie die DB-Files mit großer Wahrscheinlichkeit inkonsistent.

Dafür gibt es eigene backup/restore-Befehle ....

Hi Werner,

Ich wollte es nicht glauben, aber du hast Recht behalten.
Eine File Kopie lässt sich nicht wiederherstellen.
- FHEM gestoppt
- MySQL gestoppt
- Backup gemacht
- 3 Tage alten SD Klon rein
- Datenbank files gelöscht und aus dem Backup wiederhergestellt.
Ergebnis: 3 Tage Ereignisse fehlen.
Der Restore geht wohl, aber beim Backup reicht es nicht den SQL zu stoppen.

Also das dumpen versucht...
Anstelle 6min file Backup waren es 63min Datenbank optimieren und nach 5 Std läuft der dump (Client side) noch immer.

Das taugt so nix.

Hab jetzt einen MySQL auf Windows installiert und werde damit  Versuche starten.
Zuhause läuft eh nen Barebone mit 4xSSD im RAID5 als exchange / fileserver.
Der bekommt den MySQL dann dazu.

Und das alles nur weil ich dachte die Datenbanken der 4 Instanzen Vereinen zu können. *lach*

Schönen Abend, ich muss dann los zur FW...

Gesendet von meinem Doogee S60 mit Tapatalk

[Wernieman]

Wenn Du MySQL runter fährst und dann sicherst, DANN sollte es funktionieren. Aber eben nicht im laufendem System ...

[DS_Starter]

Hi Frank,

Also das dumpen versucht...
Anstelle 6min file Backup waren es 63min Datenbank optimieren und nach 5 Std läuft der dump (Client side) noch immer.

Dann nutze die Kraft der DB und führe ein Dump "serverSide" aus. Geht wahrscheinlich deutlich flotter. Und optimieren musst du ja nicht immer, sondern getrennt vom Dump ab und zu über Nacht zum Beispiel.

Edit: Hinweis .... den clientSide Dump kannst du in Abhängigkeit deiner Rechnerressourcen über Attribute optimieren.

[DS_Starter]

Hier mal ein Beispiel. Die hier gedumpte DB ist knapp 3GB groß und enthält rund 20Mio Sätze.

Code Auswählen Erweitern


2019.01.28 20:06:12.543 3: DbRep Rep.Fhem.Dump.ServerSide - ################################################################
2019.01.28 20:06:12.544 3: DbRep Rep.Fhem.Dump.ServerSide - ###             New database serverSide dump                 ###
2019.01.28 20:06:12.544 3: DbRep Rep.Fhem.Dump.ServerSide - ################################################################
2019.01.28 20:06:12.628 3: DbRep Rep.Fhem.Dump.ServerSide - Searching for tables inside database fhem....
2019.01.28 20:06:13.130 3: DbRep Rep.Fhem.Dump.ServerSide - Starting dump of database 'fhem', table 'history'
2019.01.28 20:08:45.027 3: DbRep Rep.Fhem.Dump.ServerSide - compress file /sds1/backup/dumps_FHEM/fhem_history_2019_01_28_20_06.csv
2019.01.28 20:09:50.027 3: DbRep Rep.Fhem.Dump.ServerSide - file compressed to output file: /sds1/backup/dumps_FHEM/fhem_history_2019_01_28_20_06.csv.gzip
2019.01.28 20:09:50.561 3: DbRep Rep.Fhem.Dump.ServerSide - input file deleted: /sds1/backup/dumps_FHEM/fhem_history_2019_01_28_20_06.csv
2019.01.28 20:09:50.568 3: DbRep Rep.Fhem.Dump.ServerSide - Number of exported datasets: 20133145
2019.01.28 20:09:50.569 3: DbRep Rep.Fhem.Dump.ServerSide - Size of backupfile: 165.89 MB
2019.01.28 20:09:50.576 3: DbRep Rep.Fhem.Dump.ServerSide - Deleting old dumpfile 'fhem_history_2019_01_28_00_29.csv.gzip'
2019.01.28 20:09:50.647 3: DbRep Rep.Fhem.Dump.ServerSide - Finished backup of database fhem - total time used (hh:mm:ss): 00:03:38
2019.01.28 20:09:50.694 3: DbRep Rep.Fhem.Dump.ServerSide - Database dump finished successfully.


Inklusive Kompression nach dem Dump ist der Lauf nach 3,5 Minuten durch. Die DB läuft auf einer Synology.

[Frank_Huber]

Danke Werner für die Info, dann teste ich da mal noch weiter.
Evtl braucht er mehr Zeit zum schließen / Speichern.
Ein sleep in der Backup.sh ist schnell eingebaut und getestet. [emoji16]

Heiko, das ist noch alles noch auf der Spielweise. MySQL ist aktuell auf nem rpi3 mit FHEM und ein rpi2 schreibt mit rein.
Denk client oder Server side macht nicht viel Unterschied. [emoji6]

Werde aber auch Server side mal anchecken. Alles mal ausprobieren... Bin von DbLog / DbRep immer mehr begeistert.

Finde aber so generell den Gedanken das mit auf den Exchange zu packen ganz sympathisch.
Entlastet die PIs und vor allen die SD Karten.

Werde hier weiter berichten. [emoji16]

Gesendet von meinem Doogee S60 mit Tapatalk

[DS_Starter]

Denk client oder Server side macht nicht viel Unterschied.

Naja, dahinter stecken jeweils andere Technologien (mit jeweils anderem Funktionsumfang). Macht wahrscheinlich doch einen Unterschied 
Allergings geht Leistung eben nur mit leistungsfähiger Hardware, so oder so.

Aber probieren ist immer gut   
Bin gespannt auf deine weiteren Ergebnisse ...

[Frank_Huber]

Ich bin vor allen gespannt wie lang der Client side noch lief. [emoji23][emoji23][emoji23][emoji23]

Gesendet von meinem Doogee S60 mit Tapatalk

[DS_Starter]

Nur mal zum Vergleich, die gleiche DB im Beispiel in #55 läuft als clientSide Backup auf dem NUC rund 45 Minuten (statt 3,5).

Die Performance kann man allerdings tunen mit den Attributen:

dumpMemlimit
dumpSpeed

Vorausgesetzt man hat RAM und CPU-Power frei.

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