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?
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
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)
Zitat von: DS_Starter am 18 Januar 2019, 10:17:51
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:
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
Zitat von: DS_Starter am 18 Januar 2019, 10:17:51
Eigenes Unterforum würde ich begrüßen.
Dann müsste man mal einen Forums-Admin darum bitten. :-)
Zitat von: Wernieman am 18 Januar 2019, 10:31:12
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
"","","","","","",""
"","","","","","",""
"","","","","","",""
"","","","","","",""
"","","","","","",""
"","","","","","",""
"","","","","","",""
"","","","","","",""
"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
"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?
Import läuft. Die Speichernuitzung steigt an.
Im Log habe ich das:
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.
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.
Zitat von: DS_Starter am 18 Januar 2019, 11:59:56
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?
Na dann lass mal laufen. Die Änderung wäre nur für die Importphase zur möglichen Problemlösung.
Grüße,
Heiko
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?
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 ?
Zitat von: DS_Starter am 18 Januar 2019, 12:58:37
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.
mit vi kann man sogar wirklich große Textdateien editieren
Dachte ein Kollege auch mal ;o)
(War allerdings ein mehrere GByte Großer mySQL-Dump ...)
Zitat von: Wernieman am 18 Januar 2019, 13:27:05
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
Und es braucht Zeit zum laden, die wir eigentlich nicht hatten ....
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.
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
Konnte die Warnungen beseitigen und habe einen Fix eingecheckt.
Zitat von: DS_Starter am 18 Januar 2019, 23:22:30
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
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
Kam jetzt doch drauf...
aus dem Import dbRep deice:
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?
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.
melde mich dann Montag wie es läuft.
danke!
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 ...
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.
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
Nachtrag:
die Importierten Daten haben bei der EInheit Fehler:
alte DB SQLite:
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:
| 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?
Hallo Frank,
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
Zitat von: DS_Starter am 22 Januar 2019, 13:28:22
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.
Die Crux dabei ist die Behandlung von Sonderzeichen bzw. der Umgang mit Zeichensätzen. °C ist ein typisches Beispiel dafür.
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.
Zitat von: DS_Starter am 22 Januar 2019, 13:28:22
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
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:
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:
| 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 |
|
Ganz am Anfang hattest du gepostet.
"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
sqlCmd update history set TIMESTAMP=TIMESTAMP,UNIT='°C' WHERE UNIT like '%C'
Zitat von: DS_Starter am 22 Januar 2019, 15:12:57
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. :)
Möglicherweise ist das aber nur ein Darstellungsproblem.
Mal mit fetchrows im DbRep anschauen wenn du fertig bist.
Zitat von: DS_Starter am 22 Januar 2019, 15:26:15
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.
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.
Zitat von: Frank_Huber am 22 Januar 2019, 16:09:29
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
Wie sicherst Du denn?
Zitat von: Wernieman am 22 Januar 2019, 20:05:49
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
Hast du dir schon mal
set ... dumpMySQL serverSide (oder clientSide)
für das Backup der MySQL-DB angeschaut ?
Zitat von: DS_Starter am 22 Januar 2019, 22:24:15
Hast du dir schon mal
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
ZitatRestore Tests mit MySQL stehen noch aus.
Es gibt natürlich auch einen integrierten Restorebefehl mit einer Dropdown-Liste
set <DbRep> restoreMySQL <File>
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 ....
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.
Hatte gestern noch eine Version eingecheckt bei der der Export/Import von "°C" out-of-the-box funktioniert.
Zitat von: DS_Starter am 23 Januar 2019, 08:37:29
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.
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
Zitat von: DS_Starter am 23 Januar 2019, 23:39:49
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
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. :-)
Gern geschehen :)
Edit: Und ich danke dir , habe mich gefreut :) :) :)
Zitat von: Wernieman am 23 Januar 2019, 08:04:10
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
Wenn Du MySQL runter fährst und dann sicherst, DANN sollte es funktionieren. Aber eben nicht im laufendem System ...
Hi Frank,
ZitatAlso 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.
Hier mal ein Beispiel. Die hier gedumpte DB ist knapp 3GB groß und enthält rund 20Mio Sätze.
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.
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
ZitatDenk 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 :D
Bin gespannt auf deine weiteren Ergebnisse ...
Ich bin vor allen gespannt wie lang der Client side noch lief. [emoji23][emoji23][emoji23][emoji23]
Gesendet von meinem Doogee S60 mit Tapatalk
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.
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
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.
In der Tat,
client side:
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:
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:
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).
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.
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...
Zitatmysql 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 ....
Zitat von: Wernieman am 29 Januar 2019, 11:41:09
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.
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).
Zitat von: DS_Starter am 29 Januar 2019, 12:53:12
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.
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.
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.
Zitat von: DS_Starter am 29 Januar 2019, 14:40:50
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.
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
Zitat von: DS_Starter am 29 Januar 2019, 14:40:50
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.
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.
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...
Zitat von: Wernieman
Zitat von: DS_Starter