Re: [vz-users] Datenbank-Umzug auf neuen Raspi schlägt fehl
Hallo zusammen, hier kurz für alle, die dasselbe Problem haben (und als Remider für mich): Der Fehler ist, die sqlite.db3 vor dem Erstellen der Zieldatenbank in den Pfad aus der dbcopy.yaml zu kopieren. Kopiert man diese nach dem Erstellen der Ziel-DB, kopiert die sqlite.db3 danach und stößt dann den restore (aka. copy) an. läuft alles wie gewünscht. Grüße JD. Sent: Tuesday, August 17, 2021 at 6:04 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Datenbank-Umzug auf neuen Raspi schlägt fehl Hallo Thomas, auf Demo-Daten hatte ich nicht geachtet, werde ich zeitnah nachholen. Die DB sollte intakt sein, da ich zuerst ein älteres Backup der sqlite.db3 auf dem RPi 3 auf einer frischen Karte wieder eingespielt und einige Tage laufen gelassen habe. Bis hierher sieht alles einwandfrei aus. Die nun von mir verwendete sqlite.db3 ist ein tagesaktuelles Backup von heute. Grüße JD. Sent: Tuesday, August 17, 2021 at 5:17 PM From: "Thomas Höpfner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Datenbank-Umzug auf neuen Raspi schlägt fehl Hi, sorry so weit habe ich nicht gelesen. Bei der Installation werden meiner Meinung nach Demo-Daten angeboten. Hast du diese probiert? Dbcopy braucht sehr lange, aber ein Fortschritt sollte erkennbar sein.. Eventuell ist DB auch kaputter wie du denkst. Thomas Am 17.08.2021 um 14:38 schrieb John Doe : Hallo Thomas, wie ich unter 7. schrieb hatte ich source und target in der dbcopy.yaml vor dem copy getauscht. Aber nochmal zur Eindeutigkeit: Mit dieser dbcopy.yaml pi@raspberrypi:~ $ cat /etc/dbcopy.yaml # DATABASE DEFINITION target: driver: pdo_mysql host: localhost user: root password: demo dbname: volkszaehler source: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: /home/pi/sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: entire table will be truncated on target and copied from source # pk: selective copy by primary key. only data not present on target # will be copied from source. tables: entities: copy properties: copy entities_in_aggregator: copy data: pk aggregate: skip ergibt sich das genannte Symptom. Grüße JD. Sent: Tuesday, August 17, 2021 at 2:29 PM From: "Thomas Höpfner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Datenbank-Umzug auf neuen Raspi schlägt fehl deine dbcopy.yaml ist noch vom Backup Thomas Am 17.08.2021 um 14:18 schrieb John Doe : dbcopy.yaml
Re: [vz-users] Datenbank-Umzug auf neuen Raspi schlägt fehl
Hallo Thomas, auf Demo-Daten hatte ich nicht geachtet, werde ich zeitnah nachholen. Die DB sollte intakt sein, da ich zuerst ein älteres Backup der sqlite.db3 auf dem RPi 3 auf einer frischen Karte wieder eingespielt und einige Tage laufen gelassen habe. Bis hierher sieht alles einwandfrei aus. Die nun von mir verwendete sqlite.db3 ist ein tagesaktuelles Backup von heute. Grüße JD. Sent: Tuesday, August 17, 2021 at 5:17 PM From: "Thomas Höpfner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Datenbank-Umzug auf neuen Raspi schlägt fehl Hi, sorry so weit habe ich nicht gelesen. Bei der Installation werden meiner Meinung nach Demo-Daten angeboten. Hast du diese probiert? Dbcopy braucht sehr lange, aber ein Fortschritt sollte erkennbar sein.. Eventuell ist DB auch kaputter wie du denkst. Thomas Am 17.08.2021 um 14:38 schrieb John Doe : Hallo Thomas, wie ich unter 7. schrieb hatte ich source und target in der dbcopy.yaml vor dem copy getauscht. Aber nochmal zur Eindeutigkeit: Mit dieser dbcopy.yaml pi@raspberrypi:~ $ cat /etc/dbcopy.yaml # DATABASE DEFINITION target: driver: pdo_mysql host: localhost user: root password: demo dbname: volkszaehler source: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: /home/pi/sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: entire table will be truncated on target and copied from source # pk: selective copy by primary key. only data not present on target # will be copied from source. tables: entities: copy properties: copy entities_in_aggregator: copy data: pk aggregate: skip ergibt sich das genannte Symptom. Grüße JD. Sent: Tuesday, August 17, 2021 at 2:29 PM From: "Thomas Höpfner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Datenbank-Umzug auf neuen Raspi schlägt fehl deine dbcopy.yaml ist noch vom Backup Thomas Am 17.08.2021 um 14:18 schrieb John Doe : dbcopy.yaml
Re: [vz-users] Datenbank-Umzug auf neuen Raspi schlägt fehl
Hallo Thomas, wie ich unter 7. schrieb hatte ich source und target in der dbcopy.yaml vor dem copy getauscht. Aber nochmal zur Eindeutigkeit: Mit dieser dbcopy.yaml pi@raspberrypi:~ $ cat /etc/dbcopy.yaml # DATABASE DEFINITION target: driver: pdo_mysql host: localhost user: root password: demo dbname: volkszaehler source: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: /home/pi/sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: entire table will be truncated on target and copied from source # pk: selective copy by primary key. only data not present on target # will be copied from source. tables: entities: copy properties: copy entities_in_aggregator: copy data: pk aggregate: skip ergibt sich das genannte Symptom. Grüße JD. Sent: Tuesday, August 17, 2021 at 2:29 PM From: "Thomas Höpfner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Datenbank-Umzug auf neuen Raspi schlägt fehl deine dbcopy.yaml ist noch vom Backup Thomas Am 17.08.2021 um 14:18 schrieb John Doe : dbcopy.yaml
[vz-users] Datenbank-Umzug auf neuen Raspi schlägt fehl
Hallo zusammen, nach einigen Kartencrashs möchte ich mein System auf etwas stabilere Füße in Form eines RPi 4, der von SSD bootet, stellen. Was ich bisher getan habe: 1. Aktuelles Image installiert (der Fehler beim Booten lag tatsächlich an einem zu schwachen Netzteil, mit 18W läuft alles). 2. Ein sqlite.db3 (Backup) ins home-Verzeichnis des RPi4 kopiert. 3. dbcopy.yaml und vzlogger.conf kopiert: dbcopy.yaml: # DATABASE DEFINITION source: driver: pdo_mysql host: localhost user: root password: demo dbname: volkszaehler target: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: /home/pi/sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: entire table will be truncated on target and copied from source # pk: selective copy by primary key. only data not present on target # will be copied from source. tables: entities: copy properties: copy entities_in_aggregator: copy data: pk aggregate: skip vzlogger.conf: { "retry": 0, "daemon": true, "verbosity": 0, "log": "/var/log/vzlogger.log", "local": { "enabled": false, "port": 8080, "index": false, "timeout": 0, "buffer": 0 }, "meters": [ { "enabled": true, "allowskip": false, "interval": -1, "aggtime": -1, "aggfixedinterval": false, "channels": [ { "uuid": "36743eb0-8518-11e9-a32c-2f8e238be491", "identifier": "1-0:1.8.1*255", "api": "volkszaehler", "middleware": "http://localhost/middleware.php", "secretKey": "", "type": "device", "scaler": 1, "aggmode": "none", "duplicates": 0 } ], "protocol": "d0", "device": "/dev/ttyUSB0", "baudrate": 9600, "parity": "7e1", }, { "enabled": true, "allowskip": false, "interval": -1, "aggtime": -1, "aggfixedinterval": false, "channels": [ { "uuid": "d28a7a20-8518-11e9-8699-198afa78ae1b", "identifier": "1-0:1.8.1*255", "api": "volkszaehler", "middleware": "http://localhost/middleware.php", "secretKey": "", "type": "device", "scaler": 1, "aggmode": "none", "duplicates": 0 } ], "protocol": "d0", "device": "/dev/ttyUSB1", "baudrate": 9600, "parity": "7e1", } ] } 4. Auf dem neuen RPi 4: pi@raspberrypi:~ $ sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml In AbstractMySQLDriver.php line 112: An exception occurred in driver: SQLSTATE[HY000] [1049] Unknown database 'volkszaehler' In Exception.php line 18: SQLSTATE[HY000] [1049] Unknown database 'volkszaehler' In PDOConnection.php line 38: SQLSTATE[HY000] [1049] Unknown database 'volkszaehler' create [-c|--config CONFIG] 5. pi@raspberrypi:~ $ sudo mysql --user=root -praspberry Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 316 Server version: 10.3.29-MariaDB-0+deb10u1 Raspbian 10 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> SHOW DATABASES; ++ | Database | ++ | information_schema | | mysql | | performance_schema | ++ 3 rows in set (0.001 sec) MariaDB [(none)]> CREATE DATABASE volkszaehler; Query OK, 1 row affected (0.001 sec) MariaDB [(none)]> SHOW DATABASES; ++ | Database | ++ | information_schema | | mysql | | performance_schema | | volkszaehler | ++ 4 rows in set (0.001 sec) MariaDB [(none)]> exit Bye 6. pi@raspberrypi:~ $ sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml Creating target schema Creating tables Updating schema assets for target platform compatibility:
[vz-users] Aktuelles Image bootet nicht in RPi
Hallo zusammen, ich versuche seit einiger Zeit, das aktuelle Image (https://demo.volkszaehler.org/downloads/volkszaehler_latest.zip) in einem Raspi 4, 4 GB zumm Laufen zu bringen. Leider bootet der Raspi weder von SD-Karte noch vom gleichen Image, welches ich mittels dd auf eine SSD gebracht habe. Und mangels Konsolenausgabe kann ich auch an einem angeschlossenen Monitor nicht nachvollziehen, wo das Problem liegt. Hat jemand einen Tip, was ich noch versuchen kann ? Grüße JD.
Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte
Hallo Andreas, in der Doku zum obigen Tool heißt es u.A.: But the main advantage of rdiff-backup is that it keeps version history. This command restores host.net::/remote-dir/file as it was 10 days ago into a new location /tmp/file. rdiff-backup -r 10D host.net::/remote-dir/file /tmp/file Other acceptable time strings include 5m4s (5 minutes and 4 seconds) and 2002-03-05 (March 5th, 2002). For more information, see the TIME FORMATS section of the manual page. Daher dachte ich, daß ich im worst case eben die letzte intakte DB wiederherstelle. Grüße JD. Sent: Monday, August 09, 2021 at 11:47 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte …und auch dieses Backup wird zerstört wenn Du von einer defekten SD eine korrupte DB kopierst. Backups *NIEMALS* einfach drüber bügeln sondern rotieren! Viele Grüße, Andreas Am 09.08.2021 um 10:51 schrieb John Doe : Hallo Andreas, hierzu habe ich ein nettes Tool gefunden: https://github.com/rdiff-backup/rdiff-backup Dieses verwende ich nun, um mein komplettes lokales home-Verzeichnis auf einen cifs-share zu sichern. Und da hier eben nur die diffs zum letzten Mal gesichert werden, kann ich nun auch etwas höherfrequent ein Backup erstellen, also bspw. alle 12 oder 6 Stunden. Grüße JD. Sent: Sunday, August 08, 2021 at 2:12 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte …und vor allen Dingen: echtes Backup an einem sicheren Ort! Viele Grüße, Andreas Am 08.08.2021 um 02:03 schrieb John Doe : Hallo zusammen, nach dem Durchlauf der aggregation ist meine Datenbank bis zum Kartencrash wieder intakt. Nochmal für alle, deren Karte auch hin und wieder mal abschmiert, mein Vorgehen: 1. Der Karte eine intakte partition table mittels gpart spendiert (https://help.ubuntu.com/community/DataRecovery#Gpart) 2. ddrescue wirklich über die komplette Karte mehrfach laufen lassen (https://www.linux-magazin.de/ausgaben/2015/11/einfuehrung2/) 3. Per testdisk (aus den aktuellen Quellen https://github.com/cgsecurity/testdisk kompiliert) die sqlite.db3 auf den "neuen" Raspi kopieren 4. vzlogger und alle cron-Jobs auf dem Zielsystem abschalten 5. Einen Restore der Datenbank durchführen (https://wiki.volkszaehler.org/software/tools/dbcopy): Zunächst mit einer sicher intakten sqlite.db, danach mit der aus (3) extrahierten (dbcopy.yaml entsprechend anpassen). 6. Gemäß wiki eine aggregation durchführen. 7. cronjobs wieder aktivieren, anschliessend reboot. Grüße JD. Sent: Saturday, August 07, 2021 at 2:54 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte Hallo zusammen, ich war in der Zwischenzeit mutig und habe durch ein /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml mit entsprechendem source und target zunächst die sicher intakte sqlite.db3 und im Anschluss diejenige aus meiner Datenrettung wieder eingespielt, Ergebnis: Fast alle meine Daten scheinen per Sichtkontrolle wieder da zu sein. Lediglich ein Peak am Ende, welcher möglicherweise aus dem beginnenden Crash stammt, ist noch übrig, aber den werde ich noch manuell begradigen. Sobald das aggregate durchgelaugen ist, melde ich mich nochmal mit dem endgültigen Ergebnis. Grüße JD. Sent: Saturday, August 07, 2021 at 10:20 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte Hallo zusammen, ich habe noch mal ein wenig herumprobiert. Zunächst habe ich der Karte mit gpart einen neuen Header spendiert. Danach habe ich ddrescue einige Zeit über die Karte laufen lassen, Ergebnis: 99.99 pct rescued. In der Folge habe ich mit testdisk (kompiliert aus den aktuellen Github-Sourcen) die sqlite.db3 kopiert. Ein sqlite3 ~/Downloads/home/pi/sqlite-dumped.db3 "PRAGMA integrity_check" liefert leider Page 718135: btreeInitPage() returns error code 11 Page 699295: btreeInitPage() returns error code 11 Page 412064: btreeInitPage() returns error code 11 On tree page 370249 cell 18: Rowid 0 out of order On tree page 370249 cell 17: Rowid 0 out of order On tree page 370249 cell 16: Rowid 0 out of order On tree page 370249 cell 15: Rowid 0 out of order On tree page 370249 cell 14: Rowid 0 out of order On tree page 370249 cell 13: Rowid 0 out of order On tree page 370249 cell 12: Rowid 0 out of order On tree page 370249 cell 11: Rowid 0 out of order On tree page 370249 cell 10: Rowid 0 out of order On tree page 370249 cell 9: Rowid 0 out of order On tree page 370249 cell 8: Rowid 0 out of order On tree page 370249 cell 7: Rowid 0 out of order On tree page 370249 cell 6: Rowid 0 out of order On tree
Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte
Hallo Andreas, hierzu habe ich ein nettes Tool gefunden: https://github.com/rdiff-backup/rdiff-backup Dieses verwende ich nun, um mein komplettes lokales home-Verzeichnis auf einen cifs-share zu sichern. Und da hier eben nur die diffs zum letzten Mal gesichert werden, kann ich nun auch etwas höherfrequent ein Backup erstellen, also bspw. alle 12 oder 6 Stunden. Grüße JD. Sent: Sunday, August 08, 2021 at 2:12 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte …und vor allen Dingen: echtes Backup an einem sicheren Ort! Viele Grüße, Andreas Am 08.08.2021 um 02:03 schrieb John Doe : Hallo zusammen, nach dem Durchlauf der aggregation ist meine Datenbank bis zum Kartencrash wieder intakt. Nochmal für alle, deren Karte auch hin und wieder mal abschmiert, mein Vorgehen: 1. Der Karte eine intakte partition table mittels gpart spendiert (https://help.ubuntu.com/community/DataRecovery#Gpart) 2. ddrescue wirklich über die komplette Karte mehrfach laufen lassen (https://www.linux-magazin.de/ausgaben/2015/11/einfuehrung2/) 3. Per testdisk (aus den aktuellen Quellen https://github.com/cgsecurity/testdisk kompiliert) die sqlite.db3 auf den "neuen" Raspi kopieren 4. vzlogger und alle cron-Jobs auf dem Zielsystem abschalten 5. Einen Restore der Datenbank durchführen (https://wiki.volkszaehler.org/software/tools/dbcopy): Zunächst mit einer sicher intakten sqlite.db, danach mit der aus (3) extrahierten (dbcopy.yaml entsprechend anpassen). 6. Gemäß wiki eine aggregation durchführen. 7. cronjobs wieder aktivieren, anschliessend reboot. Grüße JD. Sent: Saturday, August 07, 2021 at 2:54 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte Hallo zusammen, ich war in der Zwischenzeit mutig und habe durch ein /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml mit entsprechendem source und target zunächst die sicher intakte sqlite.db3 und im Anschluss diejenige aus meiner Datenrettung wieder eingespielt, Ergebnis: Fast alle meine Daten scheinen per Sichtkontrolle wieder da zu sein. Lediglich ein Peak am Ende, welcher möglicherweise aus dem beginnenden Crash stammt, ist noch übrig, aber den werde ich noch manuell begradigen. Sobald das aggregate durchgelaugen ist, melde ich mich nochmal mit dem endgültigen Ergebnis. Grüße JD. Sent: Saturday, August 07, 2021 at 10:20 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte Hallo zusammen, ich habe noch mal ein wenig herumprobiert. Zunächst habe ich der Karte mit gpart einen neuen Header spendiert. Danach habe ich ddrescue einige Zeit über die Karte laufen lassen, Ergebnis: 99.99 pct rescued. In der Folge habe ich mit testdisk (kompiliert aus den aktuellen Github-Sourcen) die sqlite.db3 kopiert. Ein sqlite3 ~/Downloads/home/pi/sqlite-dumped.db3 "PRAGMA integrity_check" liefert leider Page 718135: btreeInitPage() returns error code 11 Page 699295: btreeInitPage() returns error code 11 Page 412064: btreeInitPage() returns error code 11 On tree page 370249 cell 18: Rowid 0 out of order On tree page 370249 cell 17: Rowid 0 out of order On tree page 370249 cell 16: Rowid 0 out of order On tree page 370249 cell 15: Rowid 0 out of order On tree page 370249 cell 14: Rowid 0 out of order On tree page 370249 cell 13: Rowid 0 out of order On tree page 370249 cell 12: Rowid 0 out of order On tree page 370249 cell 11: Rowid 0 out of order On tree page 370249 cell 10: Rowid 0 out of order On tree page 370249 cell 9: Rowid 0 out of order On tree page 370249 cell 8: Rowid 0 out of order On tree page 370249 cell 7: Rowid 0 out of order On tree page 370249 cell 6: Rowid 0 out of order On tree page 370249 cell 5: Rowid 0 out of order On tree page 370249 cell 4: Rowid 0 out of order On tree page 370249 cell 3: Rowid 0 out of order On tree page 370249 cell 2: Rowid 0 out of order On tree page 370249 cell 1: Rowid 0 out of order On tree page 370249 cell 0: Rowid 0 out of order Fragmentation of 412 bytes reported as 0 on page 370249 On tree page 369985 cell 275: Rowid 26718170 out of order Page 335622: btreeInitPage() returns error code 11 Page 335601: btreeInitPage() returns error code 11 Page 326664: btreeInitPage() returns error code 11 Page 326660: btreeInitPage() returns error code 11 Page 326642: btreeInitPage() returns error code 11 Page 326640: btreeInitPage() returns error code 11 Page 183558: btreeInitPage() returns error code 11 Page 145754: btreeInitPage() returns error code 11 Page 133296: btreeInitPage() returns error code 11 Page 131242: btreeInitPage() returns error code 11 Page 130006: btreeInitPage() returns error code 11 Page 21264: btreeInitPage() returns erro
Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte
Hallo zusammen, nach dem Durchlauf der aggregation ist meine Datenbank bis zum Kartencrash wieder intakt. Nochmal für alle, deren Karte auch hin und wieder mal abschmiert, mein Vorgehen: 1. Der Karte eine intakte partition table mittels gpart spendiert (https://help.ubuntu.com/community/DataRecovery#Gpart) 2. ddrescue wirklich über die komplette Karte mehrfach laufen lassen (https://www.linux-magazin.de/ausgaben/2015/11/einfuehrung2/) 3. Per testdisk (aus den aktuellen Quellen https://github.com/cgsecurity/testdisk kompiliert) die sqlite.db3 auf den "neuen" Raspi kopieren 4. vzlogger und alle cron-Jobs auf dem Zielsystem abschalten 5. Einen Restore der Datenbank durchführen (https://wiki.volkszaehler.org/software/tools/dbcopy): Zunächst mit einer sicher intakten sqlite.db, danach mit der aus (3) extrahierten (dbcopy.yaml entsprechend anpassen). 6. Gemäß wiki eine aggregation durchführen. 7. cronjobs wieder aktivieren, anschliessend reboot. Grüße JD. Sent: Saturday, August 07, 2021 at 2:54 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte Hallo zusammen, ich war in der Zwischenzeit mutig und habe durch ein /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml mit entsprechendem source und target zunächst die sicher intakte sqlite.db3 und im Anschluss diejenige aus meiner Datenrettung wieder eingespielt, Ergebnis: Fast alle meine Daten scheinen per Sichtkontrolle wieder da zu sein. Lediglich ein Peak am Ende, welcher möglicherweise aus dem beginnenden Crash stammt, ist noch übrig, aber den werde ich noch manuell begradigen. Sobald das aggregate durchgelaugen ist, melde ich mich nochmal mit dem endgültigen Ergebnis. Grüße JD. Sent: Saturday, August 07, 2021 at 10:20 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte Hallo zusammen, ich habe noch mal ein wenig herumprobiert. Zunächst habe ich der Karte mit gpart einen neuen Header spendiert. Danach habe ich ddrescue einige Zeit über die Karte laufen lassen, Ergebnis: 99.99 pct rescued. In der Folge habe ich mit testdisk (kompiliert aus den aktuellen Github-Sourcen) die sqlite.db3 kopiert. Ein sqlite3 ~/Downloads/home/pi/sqlite-dumped.db3 "PRAGMA integrity_check" liefert leider Page 718135: btreeInitPage() returns error code 11 Page 699295: btreeInitPage() returns error code 11 Page 412064: btreeInitPage() returns error code 11 On tree page 370249 cell 18: Rowid 0 out of order On tree page 370249 cell 17: Rowid 0 out of order On tree page 370249 cell 16: Rowid 0 out of order On tree page 370249 cell 15: Rowid 0 out of order On tree page 370249 cell 14: Rowid 0 out of order On tree page 370249 cell 13: Rowid 0 out of order On tree page 370249 cell 12: Rowid 0 out of order On tree page 370249 cell 11: Rowid 0 out of order On tree page 370249 cell 10: Rowid 0 out of order On tree page 370249 cell 9: Rowid 0 out of order On tree page 370249 cell 8: Rowid 0 out of order On tree page 370249 cell 7: Rowid 0 out of order On tree page 370249 cell 6: Rowid 0 out of order On tree page 370249 cell 5: Rowid 0 out of order On tree page 370249 cell 4: Rowid 0 out of order On tree page 370249 cell 3: Rowid 0 out of order On tree page 370249 cell 2: Rowid 0 out of order On tree page 370249 cell 1: Rowid 0 out of order On tree page 370249 cell 0: Rowid 0 out of order Fragmentation of 412 bytes reported as 0 on page 370249 On tree page 369985 cell 275: Rowid 26718170 out of order Page 335622: btreeInitPage() returns error code 11 Page 335601: btreeInitPage() returns error code 11 Page 326664: btreeInitPage() returns error code 11 Page 326660: btreeInitPage() returns error code 11 Page 326642: btreeInitPage() returns error code 11 Page 326640: btreeInitPage() returns error code 11 Page 183558: btreeInitPage() returns error code 11 Page 145754: btreeInitPage() returns error code 11 Page 133296: btreeInitPage() returns error code 11 Page 131242: btreeInitPage() returns error code 11 Page 130006: btreeInitPage() returns error code 11 Page 21264: btreeInitPage() returns error code 11 Page 775024: btreeInitPage() returns error code 11 Fragmentation of 384 bytes reported as 0 on page 427549 Page 427482: btreeInitPage() returns error code 11 Page 370242: btreeInitPage() returns error code 11 Page 335617: btreeInitPage() returns error code 11 Page 335612: btreeInitPage() returns error code 11 Page 326678: btreeInitPage() returns error code 11 Page 12: btreeInitPage() returns error code 11 Page 132755: btreeInitPage() returns error code 11 Page 427473: btreeInitPage() returns error code 11 Page 412090: btreeInitPage() returns error code 11 Page 341941: btreeInitPage() returns error code 11 Page 326667: btreeInitPage() returns error code 11 Page 326622: btreeInitPage() returns
Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte
Hallo zusammen, ich war in der Zwischenzeit mutig und habe durch ein /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml mit entsprechendem source und target zunächst die sicher intakte sqlite.db3 und im Anschluss diejenige aus meiner Datenrettung wieder eingespielt, Ergebnis: Fast alle meine Daten scheinen per Sichtkontrolle wieder da zu sein. Lediglich ein Peak am Ende, welcher möglicherweise aus dem beginnenden Crash stammt, ist noch übrig, aber den werde ich noch manuell begradigen. Sobald das aggregate durchgelaugen ist, melde ich mich nochmal mit dem endgültigen Ergebnis. Grüße JD. Sent: Saturday, August 07, 2021 at 10:20 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte Hallo zusammen, ich habe noch mal ein wenig herumprobiert. Zunächst habe ich der Karte mit gpart einen neuen Header spendiert. Danach habe ich ddrescue einige Zeit über die Karte laufen lassen, Ergebnis: 99.99 pct rescued. In der Folge habe ich mit testdisk (kompiliert aus den aktuellen Github-Sourcen) die sqlite.db3 kopiert. Ein sqlite3 ~/Downloads/home/pi/sqlite-dumped.db3 "PRAGMA integrity_check" liefert leider Page 718135: btreeInitPage() returns error code 11 Page 699295: btreeInitPage() returns error code 11 Page 412064: btreeInitPage() returns error code 11 On tree page 370249 cell 18: Rowid 0 out of order On tree page 370249 cell 17: Rowid 0 out of order On tree page 370249 cell 16: Rowid 0 out of order On tree page 370249 cell 15: Rowid 0 out of order On tree page 370249 cell 14: Rowid 0 out of order On tree page 370249 cell 13: Rowid 0 out of order On tree page 370249 cell 12: Rowid 0 out of order On tree page 370249 cell 11: Rowid 0 out of order On tree page 370249 cell 10: Rowid 0 out of order On tree page 370249 cell 9: Rowid 0 out of order On tree page 370249 cell 8: Rowid 0 out of order On tree page 370249 cell 7: Rowid 0 out of order On tree page 370249 cell 6: Rowid 0 out of order On tree page 370249 cell 5: Rowid 0 out of order On tree page 370249 cell 4: Rowid 0 out of order On tree page 370249 cell 3: Rowid 0 out of order On tree page 370249 cell 2: Rowid 0 out of order On tree page 370249 cell 1: Rowid 0 out of order On tree page 370249 cell 0: Rowid 0 out of order Fragmentation of 412 bytes reported as 0 on page 370249 On tree page 369985 cell 275: Rowid 26718170 out of order Page 335622: btreeInitPage() returns error code 11 Page 335601: btreeInitPage() returns error code 11 Page 326664: btreeInitPage() returns error code 11 Page 326660: btreeInitPage() returns error code 11 Page 326642: btreeInitPage() returns error code 11 Page 326640: btreeInitPage() returns error code 11 Page 183558: btreeInitPage() returns error code 11 Page 145754: btreeInitPage() returns error code 11 Page 133296: btreeInitPage() returns error code 11 Page 131242: btreeInitPage() returns error code 11 Page 130006: btreeInitPage() returns error code 11 Page 21264: btreeInitPage() returns error code 11 Page 775024: btreeInitPage() returns error code 11 Fragmentation of 384 bytes reported as 0 on page 427549 Page 427482: btreeInitPage() returns error code 11 Page 370242: btreeInitPage() returns error code 11 Page 335617: btreeInitPage() returns error code 11 Page 335612: btreeInitPage() returns error code 11 Page 326678: btreeInitPage() returns error code 11 Page 12: btreeInitPage() returns error code 11 Page 132755: btreeInitPage() returns error code 11 Page 427473: btreeInitPage() returns error code 11 Page 412090: btreeInitPage() returns error code 11 Page 341941: btreeInitPage() returns error code 11 Page 326667: btreeInitPage() returns error code 11 Page 326622: btreeInitPage() returns error code 11 Page 148619: btreeInitPage() returns error code 11 Page 148612: btreeInitPage() returns error code 11 Page 133328: btreeInitPage() returns error code 11 Page 131207: btreeInitPage() returns error code 11 Page 427494: btreeInitPage() returns error code 11 Page 148621: btreeInitPage() returns error code 11 Page 133324: btreeInitPage() returns error code 11 Page 14360: btreeInitPage() returns error code 11 Page 341881: btreeInitPage() returns error code 11 Page 326606: btreeInitPage() returns error code 11 Page 131196: btreeInitPage() returns error code 11 Error: database disk image is malformed Der Tip von https://stackoverflow.com/questions/18259692/how-to-recover-a-corrupt-sqlite3-database/18260642 liefert leider eine leere DB. Hat evtl. noch jemand eine Idee, was ich versuchen könnte ? Grüße JD. Sent: Thursday, August 05, 2021 at 6:27 PM From: "Andreas Götz" To: "volkszaehler.org - users" Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte Deine DB ist kaputt und die Daten weg, mehr lässt sich dazu nicht sagen… Viele Grüße, Andreas Am 05.08.2021 um 18:21 schrieb John Doe : Hallo zusammen,
Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte
Hallo zusammen, ich habe noch mal ein wenig herumprobiert. Zunächst habe ich der Karte mit gpart einen neuen Header spendiert. Danach habe ich ddrescue einige Zeit über die Karte laufen lassen, Ergebnis: 99.99 pct rescued. In der Folge habe ich mit testdisk (kompiliert aus den aktuellen Github-Sourcen) die sqlite.db3 kopiert. Ein sqlite3 ~/Downloads/home/pi/sqlite-dumped.db3 "PRAGMA integrity_check" liefert leider Page 718135: btreeInitPage() returns error code 11 Page 699295: btreeInitPage() returns error code 11 Page 412064: btreeInitPage() returns error code 11 On tree page 370249 cell 18: Rowid 0 out of order On tree page 370249 cell 17: Rowid 0 out of order On tree page 370249 cell 16: Rowid 0 out of order On tree page 370249 cell 15: Rowid 0 out of order On tree page 370249 cell 14: Rowid 0 out of order On tree page 370249 cell 13: Rowid 0 out of order On tree page 370249 cell 12: Rowid 0 out of order On tree page 370249 cell 11: Rowid 0 out of order On tree page 370249 cell 10: Rowid 0 out of order On tree page 370249 cell 9: Rowid 0 out of order On tree page 370249 cell 8: Rowid 0 out of order On tree page 370249 cell 7: Rowid 0 out of order On tree page 370249 cell 6: Rowid 0 out of order On tree page 370249 cell 5: Rowid 0 out of order On tree page 370249 cell 4: Rowid 0 out of order On tree page 370249 cell 3: Rowid 0 out of order On tree page 370249 cell 2: Rowid 0 out of order On tree page 370249 cell 1: Rowid 0 out of order On tree page 370249 cell 0: Rowid 0 out of order Fragmentation of 412 bytes reported as 0 on page 370249 On tree page 369985 cell 275: Rowid 26718170 out of order Page 335622: btreeInitPage() returns error code 11 Page 335601: btreeInitPage() returns error code 11 Page 326664: btreeInitPage() returns error code 11 Page 326660: btreeInitPage() returns error code 11 Page 326642: btreeInitPage() returns error code 11 Page 326640: btreeInitPage() returns error code 11 Page 183558: btreeInitPage() returns error code 11 Page 145754: btreeInitPage() returns error code 11 Page 133296: btreeInitPage() returns error code 11 Page 131242: btreeInitPage() returns error code 11 Page 130006: btreeInitPage() returns error code 11 Page 21264: btreeInitPage() returns error code 11 Page 775024: btreeInitPage() returns error code 11 Fragmentation of 384 bytes reported as 0 on page 427549 Page 427482: btreeInitPage() returns error code 11 Page 370242: btreeInitPage() returns error code 11 Page 335617: btreeInitPage() returns error code 11 Page 335612: btreeInitPage() returns error code 11 Page 326678: btreeInitPage() returns error code 11 Page 12: btreeInitPage() returns error code 11 Page 132755: btreeInitPage() returns error code 11 Page 427473: btreeInitPage() returns error code 11 Page 412090: btreeInitPage() returns error code 11 Page 341941: btreeInitPage() returns error code 11 Page 326667: btreeInitPage() returns error code 11 Page 326622: btreeInitPage() returns error code 11 Page 148619: btreeInitPage() returns error code 11 Page 148612: btreeInitPage() returns error code 11 Page 133328: btreeInitPage() returns error code 11 Page 131207: btreeInitPage() returns error code 11 Page 427494: btreeInitPage() returns error code 11 Page 148621: btreeInitPage() returns error code 11 Page 133324: btreeInitPage() returns error code 11 Page 14360: btreeInitPage() returns error code 11 Page 341881: btreeInitPage() returns error code 11 Page 326606: btreeInitPage() returns error code 11 Page 131196: btreeInitPage() returns error code 11 Error: database disk image is malformed Der Tip von https://stackoverflow.com/questions/18259692/how-to-recover-a-corrupt-sqlite3-database/18260642 liefert leider eine leere DB. Hat evtl. noch jemand eine Idee, was ich versuchen könnte ? Grüße JD. Sent: Thursday, August 05, 2021 at 6:27 PM From: "Andreas Götz" To: "volkszaehler.org - users" Subject: Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte Deine DB ist kaputt und die Daten weg, mehr lässt sich dazu nicht sagen… Viele Grüße, Andreas Am 05.08.2021 um 18:21 schrieb John Doe : Hallo zusammen, kurzes Update: Ich habe mittels testdisk aus der Karte eine sqlite.db3 herausbekommen (via Image-Erstellung der ext4-Partition). Beim Versuch des Zurückspielens nun leider das: pi@raspberrypi:~ $ sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml entities: copying 2 rows (overwrite) [] 100% < 1 sec/< 1 sec 2 rows properties: copying 16 rows (overwrite) [] 100% < 1 sec/< 1 sec 16 rows entities_in_aggregator: copying 0 rows (overwrite) 0 [>---] < 1 sec 4.0 MiB data: copying In AbstractSQLiteDriver.php line 70: An exception occur
Re: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte
Hallo zusammen, kurzes Update: Ich habe mittels testdisk aus der Karte eine sqlite.db3 herausbekommen (via Image-Erstellung der ext4-Partition). Beim Versuch des Zurückspielens nun leider das: pi@raspberrypi:~ $ sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml entities: copying 2 rows (overwrite) [] 100% < 1 sec/< 1 sec 2 rows properties: copying 16 rows (overwrite) [] 100% < 1 sec/< 1 sec 16 rows entities_in_aggregator: copying 0 rows (overwrite) 0 [>---] < 1 sec 4.0 MiB data: copying In AbstractSQLiteDriver.php line 70: An exception occurred while executing 'SELECT COUNT(1) FROM ("data")': SQLSTATE[HY000]: General error: 11 database disk image is malformed In PDOConnection.php line 90: SQLSTATE[HY000]: General error: 11 database disk image is malformed In PDOConnection.php line 88: SQLSTATE[HY000]: General error: 11 database disk image is malformed copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Abfolge: Wie im wiki beschrieben eine sqlite.db3 mit dbcopy create angelegt. Diese mit der sqlite.db3 aus testdisk ersetzt, in der dbcopy.yaml Quelle und Ziel vertauscht und obigen Befehl verwendet. Könnte da noch was zu retten sein ? Grüße JD. Sent: Wednesday, August 04, 2021 at 9:16 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: [vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte Hallo zusammen, mitr ist mal wieder eine SD-Karte abgeraucht. Ich habe ein älteres Image der Karte und zwei Backups der sqlite.db3 - ein älteres und ein uraltes. Aufgrund persönlicher Unzulänglichkeiten hat die tägliche Datensicherung nicht das getan, was ich vorhatte. Nun meine Frage: Ich habe ein einem SD-Kartenleser noch Zugriff auf die SD-Karte. Wenn ich die sqlite.dp3 aus dem Verzeichnis /home/pi auf meinen Rechner kopieren will, ergibt sich ein cp: Fehler beim Lesen von 'sqlite.db3': Eingabe-/Ausgabefehler Vermutlich, weil an der Stelle die Karte schin teilweise defekt ist. Gibt es bspw. mit testdisk eine Möglichkeit, diese relativ aktuelle sqlite.db3 doch noch zu retten ? Die Dateigröße scheint zur theoretischen DB-Größe zu passen, alleine: Ich komme nicht kopierfähig dran. Beste Grüße JD.
[vz-users] (Daten-)Rettung sqlite.db3 von SD-Karte
Hallo zusammen, mitr ist mal wieder eine SD-Karte abgeraucht. Ich habe ein älteres Image der Karte und zwei Backups der sqlite.db3 - ein älteres und ein uraltes. Aufgrund persönlicher Unzulänglichkeiten hat die tägliche Datensicherung nicht das getan, was ich vorhatte. Nun meine Frage: Ich habe ein einem SD-Kartenleser noch Zugriff auf die SD-Karte. Wenn ich die sqlite.dp3 aus dem Verzeichnis /home/pi auf meinen Rechner kopieren will, ergibt sich ein cp: Fehler beim Lesen von 'sqlite.db3': Eingabe-/Ausgabefehler Vermutlich, weil an der Stelle die Karte schin teilweise defekt ist. Gibt es bspw. mit testdisk eine Möglichkeit, diese relativ aktuelle sqlite.db3 doch noch zu retten ? Die Dateigröße scheint zur theoretischen DB-Größe zu passen, alleine: Ich komme nicht kopierfähig dran. Beste Grüße JD.
Re: [vz-users] Kopieren großer sqlite.db3 auf smb share bricht ab
Hallo zusammen, kurze Rückmeldung zu meinem Problem: Der fehlende Platz auf der SD-Karte war offenkundig die Ursache. Nachdem ich das DB-Backup nochmal komplett neu erstellt und ein wenig Platz geschaffen habe, läuft der Kopiervorgang auf das smb-Share problemlos durch. Grüße JD. Sent: Wednesday, June 23, 2021 at 12:24 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Kopieren großer sqlite.db3 auf smb share bricht ab Hallo Thomas, das Platzproblem hatte ich schon als Ursache in Verdacht. Darüber hinaus weiß ich nicht so ganz genau, wie lannge dieses Problem schon besteht und mir eventuell auch die (lokal) gesicherte sqlite.db3 zerschossen hat. Ich habe diese (lokale) sqlite.db3 jetzt mal gelöscht. Danach habe ich ältere Logs gelöscht und apt-get clean bzw. autoclean laufen lassen. Das hat ca. 10 Prozent Platz gebracht. Im Anschluss habe ich dbcopy ein neues komplettes Backup angestossen. Sobald das abgeschlossen ist, melde ich mich wieder mit dem Ergebnis. Grüße JD. Sent: Wednesday, June 23, 2021 at 12:03 PM From: "Thomas Höpfner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Kopieren großer sqlite.db3 auf smb share bricht ab Hallo, smb braucht platz zum puffern, die volle sd kann also der grund sein. bei mir ist das journal ein großer platzfresser. mit journalctl --disk-usage kannst du das prüfen das löschen geht auch, den befehl habe ich gerade nicht Thomas Am 23.06.2021 um 11:11 schrieb John Doe : Hallo zusammen, seit einigen Jahren benutze ich nun dbcopy zum Backup/Restore meiner VZ-Datenbank, alles läuft weitestgehend reibungslos. Seit gestern habe ich das Symptom, dass die lokal erzeugte sqlite.db3 von ca. 3.5 GB nicht mehr unfallfrei auf ein smb-Share auf einer Diskstation kopiert werden kann. Der Kopiervorgang bleibt reproduzierbar an der gleichen Stelle hängen (ca. 1.55GB). Was habe ich getan: apt-get update && apt-get upgrade auf dem Raspi und Neustart Neustart der DS Das Problem bleibt bestehen. VZLogger läuft soweit, auch ein händisch angestossenes dbcopy läuft lokal fehlerfrei durch. An was könnte das liegen ? Dazu muss ich sagen, dass auf der SD-Karte nur noch wenig Platz ist: Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 15239572 14477536 140396 100% / Könnte das die Ursache sein ? Einen ressourcen-fressenden Prozess habe ich nicht ausgemacht. Beste Grüße JD.
Re: [vz-users] Kopieren großer sqlite.db3 auf smb share bricht ab
Hallo Thomas, das Platzproblem hatte ich schon als Ursache in Verdacht. Darüber hinaus weiß ich nicht so ganz genau, wie lannge dieses Problem schon besteht und mir eventuell auch die (lokal) gesicherte sqlite.db3 zerschossen hat. Ich habe diese (lokale) sqlite.db3 jetzt mal gelöscht. Danach habe ich ältere Logs gelöscht und apt-get clean bzw. autoclean laufen lassen. Das hat ca. 10 Prozent Platz gebracht. Im Anschluss habe ich dbcopy ein neues komplettes Backup angestossen. Sobald das abgeschlossen ist, melde ich mich wieder mit dem Ergebnis. Grüße JD. Sent: Wednesday, June 23, 2021 at 12:03 PM From: "Thomas Höpfner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Kopieren großer sqlite.db3 auf smb share bricht ab Hallo, smb braucht platz zum puffern, die volle sd kann also der grund sein. bei mir ist das journal ein großer platzfresser. mit journalctl --disk-usage kannst du das prüfen das löschen geht auch, den befehl habe ich gerade nicht Thomas Am 23.06.2021 um 11:11 schrieb John Doe : Hallo zusammen, seit einigen Jahren benutze ich nun dbcopy zum Backup/Restore meiner VZ-Datenbank, alles läuft weitestgehend reibungslos. Seit gestern habe ich das Symptom, dass die lokal erzeugte sqlite.db3 von ca. 3.5 GB nicht mehr unfallfrei auf ein smb-Share auf einer Diskstation kopiert werden kann. Der Kopiervorgang bleibt reproduzierbar an der gleichen Stelle hängen (ca. 1.55GB). Was habe ich getan: apt-get update && apt-get upgrade auf dem Raspi und Neustart Neustart der DS Das Problem bleibt bestehen. VZLogger läuft soweit, auch ein händisch angestossenes dbcopy läuft lokal fehlerfrei durch. An was könnte das liegen ? Dazu muss ich sagen, dass auf der SD-Karte nur noch wenig Platz ist: Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 15239572 14477536 140396 100% / Könnte das die Ursache sein ? Einen ressourcen-fressenden Prozess habe ich nicht ausgemacht. Beste Grüße JD.
[vz-users] Kopieren großer sqlite.db3 auf smb share bricht ab
Hallo zusammen, seit einigen Jahren benutze ich nun dbcopy zum Backup/Restore meiner VZ-Datenbank, alles läuft weitestgehend reibungslos. Seit gestern habe ich das Symptom, dass die lokal erzeugte sqlite.db3 von ca. 3.5 GB nicht mehr unfallfrei auf ein smb-Share auf einer Diskstation kopiert werden kann. Der Kopiervorgang bleibt reproduzierbar an der gleichen Stelle hängen (ca. 1.55GB). Was habe ich getan: apt-get update && apt-get upgrade auf dem Raspi und Neustart Neustart der DS Das Problem bleibt bestehen. VZLogger läuft soweit, auch ein händisch angestossenes dbcopy läuft lokal fehlerfrei durch. An was könnte das liegen ? Dazu muss ich sagen, dass auf der SD-Karte nur noch wenig Platz ist: Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 15239572 14477536 140396 100% / Könnte das die Ursache sein ? Einen ressourcen-fressenden Prozess habe ich nicht ausgemacht. Beste Grüße JD.
Re: [vz-users] vzlogger für zwei Zähler
Hallo Uwe, da ich die gleiche Kombination produktiv betreibe: Könntest Du eine vollständige vzlogger.conf posten, damit ich sie mit meiner vergleichen kann ? Grüße JD. Sent: Tuesday, March 23, 2021 at 11:19 AM From: "Uwe Martin" To: volkszaehler-us...@lists.volkszaehler.org Subject: [vz-users] vzlogger für zwei Zähler Hallo, ich habe auf einem Raspberry PI 3 die vzlogger Software installiert, um meinen Haushaltsstromzähler und den Wärmepumpenstrom zu messen. Leider klappt es nicht so richtig. (vzlogger --version 0.8.0 based on git version: heads/master-0-gb2782d81da last commit date: Thu, 18 Mar 2021 23:30:40 +0100 ) Mit einem Lesekopf funktioniert es prima. Sobald ich den zweiten in die Konfig eintrage werden keine Daten mehr geloggt. Meine Konfig : {"retry" : 0, "verbosity" : 15, "log" : "/root/vzlogger.log", "local" : { "enabled" : false, "port" : 8080, "index" : true, "timeout" : 30, "buffer" : 600 }, "meters" : [{ "enabled" : true, "protocol" : "sml", "device" : "/dev/usb-ir-lesekopf0", }] } Sie funktioniert auch mit dem zweiten Lesekopf (/dev/usb-ir-lesekopf1). Es werden dann Daten in das Logfile geschrieben. Sobald der zweite "meter" angegeben wird kommen keine Daten mehr. Im Logfiel steht dann : Got 0 new readings from meter: Konfig für zwei Leseköpfe: { "retry" : 0, "verbosity" : 15, "log" : "/root/vzlogger.log", "local" : { "enabled" : false, "port" : 8080, "index" : true, "timeout" : 30, "buffer" : 600 }, "meters" : [{ "enabled" : true, "protocol" : "sml", "device" : "/dev/usb-ir-lesekopf0", }, { "enabled" : true, "protocol" : "sml", "device" : "/dev/usb-ir-lesekopf1", }] } Logfile habe ich mit den beiden Kofigfiles angehängt. Was ist an der Konfig falsch? Vielen Dank und viele Grüße Uwe
Re: [vz-users] DB Backup auf NAS via sqlite
Hallo Michael, versuch den mount von Deinem Raspi auf die DS mal so: sudo mount -t cifs //DS-IP/Freigabe /media/mount-point -o user=admin,vers=1.0 Ich habe mit der Protokollversion (1.0) einige Zeit probiert, aber das Kopieren einiger GB auf den share läuft bei mir einwandfrei. Grüße JD. Sent: Saturday, December 05, 2020 at 3:32 PM From: "Michael Hartmann" To: "'volkszaehler.org - users'" Subject: Re: [vz-users] DB Backup auf NAS via sqlite Die Variante ohne filemode, dirmode habe ich auch schon erfolglos durch :-/. Grüße Micha Von: volkszaehler-users [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von ?tobias.l...@me.com? Gesendet: Samstag, 5. Dezember 2020 15:18 An: volkszaehler.org - users Betreff: Re: [vz-users] DB Backup auf NAS via sqlite Hallo, Kann ich dir gar nicht mehr sagen. Probiere es doch einfach mal. Der einzige Unterschied der mir jetzt noch auffällt ist, dass ich in der fstab das share ohne filemode und ohne dir öde angegeben habe. Muss aber gestehen das ich da absut kein Fachmann für bin. Gruß Tobias Von meinem Huawei-Telefon gesendet Ursprüngliche Nachricht Von: Michael Hartmann Datum: Sa., 5. Dez. 2020, 15:09 An: "'volkszaehler.org - users'" Betreff: Re: [vz-users] DB Backup auf NAS via sqlite Hallo Tobias, ja ein DS213j. Leider hat das Deaktivieren dieser Option es auch nicht gebracht. Erfordert es einen Neustart der Diskstation um wirksam zu werden? Grüße Micha Von: volkszaehler-users [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von ?tobias.l...@me.com? Gesendet: Samstag, 5. Dezember 2020 12:29 An: volkszaehler.org - users Betreff: Re: [vz-users] DB Backup auf NAS via sqlite Hallo, Handelt es sich bei dem NAS um eine Synology? Ich hatte das selbe Problem nämlich auch. Wen ja schau mal unter Systemsteuerung/dateidienste/smb/erweiterte Einstellungen. Da gibt es bei mir einen Punkt der nennt sich opportunistic locking aktivieren. Da war bei mir standardmäßig der Haken drin. Nach dem ich diesen entfernt hatte ging es bei mir. Hatte ich irgendwie ergooglet weiß aber nicht mehr wo. Gruß Tobias Ursprüngliche Nachricht Von: Michael Hartmann Datum: Sa., 5. Dez. 2020, 11:12 An: "'volkszaehler.org - users'" Betreff: [vz-users] DB Backup auf NAS via sqlite Hallo, nachdem ich daran scheitere mein mühevoll angelegtes mysql DB Backup auf das Testsystem zu transferieren versuche ich nun den Weg über sqlite. Generell funktioniert es. Ich habe mit create/copy ein lokales sqlite Backup auf dem Produktivsystem erstellt und dieses dann auf das NAS verschoben. Dieses Backup konnte ich direkt vom NAS auf das Testsystem einspielen, wo mir im Anschluss alle Daten im Frontend zu Verfügung stehen. Nun hängt es daran auf dem Produktivsystem ein direktes Backup auf das NAS zu fahren. Ich habe das share via /etc/fstab auf dem Produktivsystem gemountet: //192.168.178.24/SmartMeter /mnt/VZ_share cifs username=SmartMeter,password=***,vers=2.0,uid=1000,file_mode=0770,dir_mode=0770 0 0 Anschließen kann der user pi alle Dateioperation auf dem share ausüben (löschen, verschieben, umbenennen,…) pi@SmartMeter:/mnt/VZ_share $ ls -l insgesamt 4917152 -rwxrwx--- 1 pi root 1740366969 Nov 15 06:12 VZ-Backup_2020-11-15_0300.img.gz -rwxrwx--- 1 pi root 1757275296 Dez 1 06:07 VZ-Backup_2020-12-01_0300.img.gz -rwxrwx--- 1 pi root 202543104 Nov 29 12:07 VZ_DB_Backup.db3 -rwxrwx--- 1 pi root 1334971979 Nov 21 16:56 VZ-Image_2020-11-21_blank_DB.img.gz Dennoch bekomme ich von dbcopy immer den Fehler, dass die DB gelocked sei! pi@SmartMeter:/ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy_sqlite.yaml In AbstractSQLiteDriver.php line 39: An exception occurred while executing 'DELETE FROM entities': SQLSTATE[HY000]: General error: 5 database is locked In Exception.php line 18: SQLSTATE[HY000]: General error: 5 database is locked In PDOConnection.php line 125: SQLSTATE[HY000]: General error: 5 database is locked copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Ich habe schon sämtliche, mir bekannten Optionen für das mounten des shares ausprobiert. Leider erfolglos. Auch ein mounten in /home/pi macht keinen Unterschied. Hat dazu jemand eine Idee? Grüße Micha
Re: [vz-users] Image mit dd erstellen / Datenbackup
Hallo Daniel, Danke für die Erläuterung. Mit "Überprüfung" dachte ich eigentlich an eine Möglichkeit, die ordinären Ganzzahlen bspw. auf monotone Steigung hin zu prüfen. Sollte die Systemzeit nach einem Reboot eben noch nicht richtig synchronisiert sein, ergeben sich nach meinem Verständnis beim Berechnen der Energiewerte doch mitunter negative bzw. unsinnige Werte (?) Mir ist bewusst, dass eine Datenbank-SW das nicht intrinsisch prüft, daher fragte ich ja bewusst nach einem Programm, bspw. einer weiteren Funktion von dbcopy. Grüße JD. Sent: Tuesday, November 24, 2020 at 11:01 AM From: "Daniel Lauckner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo, am Dienstag, 24. November 2020 um 09:21 hat John Doe geschrieben: > Ich tippe auf > inkonsistente Datenbank an der Stelle. Gibt es eigentlich eine > Möglichkeit, die "Richtigkeit" der DB im Sinne der Konsistenz, > speziell bei der Uhr-/Systemzeit zu überprüfen ? Die Fehlermeldung besagt das dbcopy einen Index zu schreiben versucht den er nicht doppelt schreiben darf. Das hat nix mit dem Inhalt der übrigens Felder im Datensatz zu tun. Und der Inhalt der Felder wird da auch nicht auf externe Plausibilität überprüft. "Zeit" ist für die Datenbank nur ein Feld mit einer ordinären Ganzzahl. > Das Problem habe > ich auch immer mal wieder und muss dann Daten per =""> > solange bereinigen, bis es wieder passt, d.h. unsinnige Peaks verschwunden sind. Wenn Peaks im Graph sind konnte die Datenbank die Anfrage bearbeiten. Da geht die Theorie schon nicht auf. mfg Daniel
Re: [vz-users] Image mit dd erstellen / Datenbackup
Stimmt ! :-D Dann hieße das nach dem letzten Post, dass das Problem mit der DB schon ganz am Anfang auftaucht... Grüße JD. Sent: Tuesday, November 24, 2020 at 10:29 AM From: "Stefan Bauer" To: "volkszaehler.org - users" Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup Ich weiß nicht, was ihr da schaut, aber wenn man das durch 1000 teilt und natürlich ohne nachkommastellen nimmt, kommt 29.05.2020 - 16:16:21 raus Stefan Von meinem iPad gesendet Am 24.11.2020 um 10:26 schrieb John Doe : Das führt zu 16. Januar 1975, 3:49b Uhr (UTC). Das scheint mir auch nicht viel richtiger zu sein ... Ich würde händisch, d.h. visuell Woche für Woche im Frontend durchgehen, nach Auffälligkeiten suchen, entsprechende (kurze) Abschnitte ggfs. löschen und dann ein neues Backup nach wiki anlegen. Grüße JD. Sent: Tuesday, November 24, 2020 at 9:56 AM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup Die Timestamps bei vz sind ms, also bitte vorher durch 1000 teilen :-) Grüße Frank Michael Hartmann <hartmann-mi...@web.de> schrieb am Di., 24. Nov. 2020, 09:52: Der Timestamp der dort berichtet wird erscheint mir auch "surreal". Zumindest wenn man voraussetzt das es sich um einen UNIX-Timestamp handelt... und nicht um ein anderes Format. Ich habe das Backup der DB auf meinem NAS via Frontend von MariaDB geprüft. Der erste Eintrag liegt Ende Mai (Inbetriebnahme VZ), der letzte zum Zeitpunkt des Backups. Diesen auffälligen Timestamp finde ich dort nicht. Grüße Micha Gesendet: Dienstag, 24. November 2020 um 09:21 Uhr Von: "John Doe" <john...@null.net> An: volkszaehler-users@demo.volkszaehler.org Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo zusammen, der timestamp 1590761781023 ergibt Dienstag, 27 März 52379, 16:30:23 Uhr. Das klingt ein wenig surreal. Wie sehen denn die Daten per visueller Kontrolle im Verlauf der Monate aus ? Könnte ein Reboot bei noch nicht wieder vorliegender korrekter Systemzeit des Raspis da ein wenig Unordnung gemacht haben ? Ich tippe auf inkonsistente Datenbank an der Stelle. Gibt es eigentlich eine Möglichkeit, die "Richtigkeit" der DB im Sinne der Konsistenz, speziell bei der Uhr-/Systemzeit zu überprüfen ? Das Problem habe ich auch immer mal wieder und muss dann Daten per ="" solange bereinigen, bis es wieder passt, d.h. unsinnige Peaks verschwunden sind. Grüße JD. Sent: Monday, November 23, 2020 at 8:48 PM From: "Michael Hartmann" <hartmann-mi...@web.de> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo Thomas, Ich bin raus. Keine Ahnung, warum ich die Daten nicht retour bekomme. Es ist scheinbar nur für Menschen mit detailierten DB-Kenntmissen lösbar. Was solls... Grüße Micha Am 22. November 2020 15:44:46 MEZ schrieb "Thomas Höpfner" <tho...@thhoe.de>: Hallo Micha, bei mir sieht es so aus: - NFS-Freigabe auf NAS backup/methusalix2 (muss einmal erstellt werden) - auf Rechner methusalix2 ein Script backup.sh mit folgenden Funktion: 1. mounten der NFS -Freigabe nach /tmp/backup 2. Backup der Datenbank mit dbcopy nach /tmp/backup/sqlite.db3 3. umount /tmp/backup - das Script wird täglich über cron gestardet Für meinen Test habe ich - VM methusalix3 erstellt - volkszähler installeirt - die Datei sqlite.db3 in die vm kopiert - ein Restore der DB mit dbcopy gestardet, das hat ca 2h gedauert - heute habe ich das Backup der letzen Nacht in die VM kopiert - und wieder ein Restore der DB mit dbcopy gestardet, diesmal hat es wenige Sekunden gedauert. -Ursprüngliche Nachricht- Von: Michael Hartmann <hartmann-mi...@web.de> Gesendet: Sonntag 22 November 2020 14:52 An: 'volkszaehler.org - users' <volkszaehler-users@demo.volkszaehler.org> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo Thomas, was soll ich sagen? Ich bekomme die Daten weder in ein mit DD erstelltes Image, noch in ein komplett neu installiertes System zurückgespielt. Es läuft immer wieder auf diesen Fehler: pi@SmartMeter:~ $ sudo /usr/bin/php /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy_restore.yaml entities: copying 7 rows (overwrite) [] 100% < 1 sec/< 1 sec 7 rows properties: copying 63 rows (overwrite) [] 100% < 1 sec/< 1 sec 63 rows entities_in_aggregator: copying 0 rows (overwrite) 0 [->--] < 1 sec 4.0 MiB data: copying 7855387 rows (overwrite) [>---] 0% < 1 sec/< 1 sec 0 rows In AbstractMySQLDriver.php line 74: An exception occurred whil
Re: [vz-users] Image mit dd erstellen / Datenbackup
Das führt zu 16. Januar 1975, 3:49b Uhr (UTC). Das scheint mir auch nicht viel richtiger zu sein ... Ich würde händisch, d.h. visuell Woche für Woche im Frontend durchgehen, nach Auffälligkeiten suchen, entsprechende (kurze) Abschnitte ggfs. löschen und dann ein neues Backup nach wiki anlegen. Grüße JD. Sent: Tuesday, November 24, 2020 at 9:56 AM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup Die Timestamps bei vz sind ms, also bitte vorher durch 1000 teilen :-) Grüße Frank Michael Hartmann <hartmann-mi...@web.de> schrieb am Di., 24. Nov. 2020, 09:52: Der Timestamp der dort berichtet wird erscheint mir auch "surreal". Zumindest wenn man voraussetzt das es sich um einen UNIX-Timestamp handelt... und nicht um ein anderes Format. Ich habe das Backup der DB auf meinem NAS via Frontend von MariaDB geprüft. Der erste Eintrag liegt Ende Mai (Inbetriebnahme VZ), der letzte zum Zeitpunkt des Backups. Diesen auffälligen Timestamp finde ich dort nicht. Grüße Micha Gesendet: Dienstag, 24. November 2020 um 09:21 Uhr Von: "John Doe" <john...@null.net> An: volkszaehler-users@demo.volkszaehler.org Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo zusammen, der timestamp 1590761781023 ergibt Dienstag, 27 März 52379, 16:30:23 Uhr. Das klingt ein wenig surreal. Wie sehen denn die Daten per visueller Kontrolle im Verlauf der Monate aus ? Könnte ein Reboot bei noch nicht wieder vorliegender korrekter Systemzeit des Raspis da ein wenig Unordnung gemacht haben ? Ich tippe auf inkonsistente Datenbank an der Stelle. Gibt es eigentlich eine Möglichkeit, die "Richtigkeit" der DB im Sinne der Konsistenz, speziell bei der Uhr-/Systemzeit zu überprüfen ? Das Problem habe ich auch immer mal wieder und muss dann Daten per ="" solange bereinigen, bis es wieder passt, d.h. unsinnige Peaks verschwunden sind. Grüße JD. Sent: Monday, November 23, 2020 at 8:48 PM From: "Michael Hartmann" <hartmann-mi...@web.de> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo Thomas, Ich bin raus. Keine Ahnung, warum ich die Daten nicht retour bekomme. Es ist scheinbar nur für Menschen mit detailierten DB-Kenntmissen lösbar. Was solls... Grüße Micha Am 22. November 2020 15:44:46 MEZ schrieb "Thomas Höpfner" <tho...@thhoe.de>: Hallo Micha, bei mir sieht es so aus: - NFS-Freigabe auf NAS backup/methusalix2 (muss einmal erstellt werden) - auf Rechner methusalix2 ein Script backup.sh mit folgenden Funktion: 1. mounten der NFS -Freigabe nach /tmp/backup 2. Backup der Datenbank mit dbcopy nach /tmp/backup/sqlite.db3 3. umount /tmp/backup - das Script wird täglich über cron gestardet Für meinen Test habe ich - VM methusalix3 erstellt - volkszähler installeirt - die Datei sqlite.db3 in die vm kopiert - ein Restore der DB mit dbcopy gestardet, das hat ca 2h gedauert - heute habe ich das Backup der letzen Nacht in die VM kopiert - und wieder ein Restore der DB mit dbcopy gestardet, diesmal hat es wenige Sekunden gedauert. -Ursprüngliche Nachricht- Von: Michael Hartmann <hartmann-mi...@web.de> Gesendet: Sonntag 22 November 2020 14:52 An: 'volkszaehler.org - users' <volkszaehler-users@demo.volkszaehler.org> Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo Thomas, was soll ich sagen? Ich bekomme die Daten weder in ein mit DD erstelltes Image, noch in ein komplett neu installiertes System zurückgespielt. Es läuft immer wieder auf diesen Fehler: pi@SmartMeter:~ $ sudo /usr/bin/php /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy_restore.yaml entities: copying 7 rows (overwrite) [] 100% < 1 sec/< 1 sec 7 rows properties: copying 63 rows (overwrite) [] 100% < 1 sec/< 1 sec 63 rows entities_in_aggregator: copying 0 rows (overwrite) 0 [->--] < 1 sec 4.0 MiB data: copying 7855387 rows (overwrite) [>---] 0% < 1 sec/< 1 sec 0 rows In AbstractMySQLDriver.php line 74: An exception occurred while executing 'INSERT INTO `data` (`id`,`channel_id`,`timestamp`,`value`) VALUES (?,?,?,?)' with para ms ["1", "2", "1590761781023", "826598.2"]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'PRIMARY' In Exception.php line 18: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'PRIMARY' In PDOStatement.php line 115: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'PRIMARY'
Re: [vz-users] Image mit dd erstellen / Datenbackup
Hallo zusammen, der timestamp 1590761781023 ergibt Dienstag, 27 März 52379, 16:30:23 Uhr. Das klingt ein wenig surreal. Wie sehen denn die Daten per visueller Kontrolle im Verlauf der Monate aus ? Könnte ein Reboot bei noch nicht wieder vorliegender korrekter Systemzeit des Raspis da ein wenig Unordnung gemacht haben ? Ich tippe auf inkonsistente Datenbank an der Stelle. Gibt es eigentlich eine Möglichkeit, die "Richtigkeit" der DB im Sinne der Konsistenz, speziell bei der Uhr-/Systemzeit zu überprüfen ? Das Problem habe ich auch immer mal wieder und muss dann Daten per ="" solange bereinigen, bis es wieder passt, d.h. unsinnige Peaks verschwunden sind. Grüße JD. Sent: Monday, November 23, 2020 at 8:48 PM From: "Michael Hartmann" To: "volkszaehler.org - users" Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo Thomas, Ich bin raus. Keine Ahnung, warum ich die Daten nicht retour bekomme. Es ist scheinbar nur für Menschen mit detailierten DB-Kenntmissen lösbar. Was solls... Grüße Micha Am 22. November 2020 15:44:46 MEZ schrieb "Thomas Höpfner" : Hallo Micha, bei mir sieht es so aus: - NFS-Freigabe auf NAS backup/methusalix2 (muss einmal erstellt werden) - auf Rechner methusalix2 ein Script backup.sh mit folgenden Funktion: 1. mounten der NFS -Freigabe nach /tmp/backup 2. Backup der Datenbank mit dbcopy nach /tmp/backup/sqlite.db3 3. umount /tmp/backup - das Script wird täglich über cron gestardet Für meinen Test habe ich - VM methusalix3 erstellt - volkszähler installeirt - die Datei sqlite.db3 in die vm kopiert - ein Restore der DB mit dbcopy gestardet, das hat ca 2h gedauert - heute habe ich das Backup der letzen Nacht in die VM kopiert - und wieder ein Restore der DB mit dbcopy gestardet, diesmal hat es wenige Sekunden gedauert. -Ursprüngliche Nachricht- Von: Michael Hartmann Gesendet: Sonntag 22 November 2020 14:52 An: 'volkszaehler.org - users' Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo Thomas, was soll ich sagen? Ich bekomme die Daten weder in ein mit DD erstelltes Image, noch in ein komplett neu installiertes System zurückgespielt. Es läuft immer wieder auf diesen Fehler: pi@SmartMeter:~ $ sudo /usr/bin/php /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy_restore.yaml entities: copying 7 rows (overwrite) [] 100% < 1 sec/< 1 sec 7 rows properties: copying 63 rows (overwrite) [] 100% < 1 sec/< 1 sec 63 rows entities_in_aggregator: copying 0 rows (overwrite) 0 [->--] < 1 sec 4.0 MiB data: copying 7855387 rows (overwrite) [>---] 0% < 1 sec/< 1 sec 0 rows In AbstractMySQLDriver.php line 74: An exception occurred while executing 'INSERT INTO `data` (`id`,`channel_id`,`timestamp`,`value`) VALUES (?,?,?,?)' with para ms ["1", "2", "1590761781023", "826598.2"]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'PRIMARY' In Exception.php line 18: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'PRIMARY' In PDOStatement.php line 115: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'PRIMARY' copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Die Kanäle werde dabei korrekt zurückgespielt, den sie stehen mir im FE zur Verfügung. Das ist frustrierend. Nun habe ich mit eurer Hilfe eine DB auf meinem NAS generiert in die ich täglich die Daten sichere, aber scheinbar ohne nutzbaren Wert da ich sie nicht wieder heraus bekomme. :-/ Grüße Micha Wie gesagt, das währe mit Netzwerk zu erklären. Mit freundlichen Grüßen, Thomas -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: [vz-users] Image mit dd erstellen / Datenbackup
Hallo MIchael, hast Du vor Beginn des Zurückspielens mittels dbcopy den vzlogger und den cron gestopt ? Wenn entweder die aggregation und/oder der vzlogger während der Rücksicherung auch auf der DB arbeiten, kann das eher nicht funktionieren (ich musste das auch erst lernen). Grüße JD. Sent: Tuesday, November 17, 2020 at 9:57 AM From: "Michael Hartmann" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo, ich habe gestern ein zweiten Versuch mit einem "frischen" DD-Image auf dem "Zweitsystem" gemacht. Das Resultat ist identisch. Beim Ergänzen der Daten aus dem DB-Backup bekomme ich den gleichen Fehler mit abweichenden Daten (s. Textfile im Anhang). Nun interessiert mich nach wie vor, woran DBCOPY sich da stört. Denn ich habe die Befürchtung, dass sich die Daten auch in eine neue Installation mit leerer DB nicht zurückspielen lassen. Das hätte ich gerne geklärt, bevor ich mir die Mühe mache auf dem Zweitsystem eine identische Installation aufzubauen um von dieser dann ein Image anzufertigen. Grüße Micha Gesendet: Montag, 16. November 2020 um 22:17 Uhr Von: "Daniel Lauckner" An: "volkszaehler.org - users" Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo, am Montag, 16. November 2020 um 16:45 hat John Doe geschrieben: > Entweder Du > spielst das Karten-Image zurück und hast für die Dauer > Crash-Beginn+Rücksicherung keine Daten (zeitliche Größenordnung > alles zusammen bis zum Wiederlaufen ca. eine Stunde) oder Du > installierst ein neues VZ-Image und spielst darin die DB und die vzlogger.conf zurück. Oder man macht sich ein Image nachdem man mit der Konfiguration fertig ist und spielt da die DB-Sicherung wieder ein. Man hat 1x die 10 Minuten Ausfall, bekommt das System aber schneller wieder ans laufen weil die persönliche Konfiguration schon vorhanden ist. mfg Daniel
Re: [vz-users] Image mit dd erstellen / Datenbackup
Hallo MIchael, das Backup einer 32GB-SD-Karte dauerte bei mir gestern an einem USB3-Leser ca. 10 Minuten. Und das im Wiki beschriebene Vorgehen der Datenbanksicherung per dbcopy, bspw. über eine CIFS-Freigabe auf Dein NAS, läuft problemlos im laufenden Betrieb. Du hast im Fall des Kartencrashs zwei Möglichkeiten: Entweder Du spielst das Karten-Image zurück und hast für die Dauer Crash-Beginn+Rücksicherung keine Daten (zeitliche Größenordnung alles zusammen bis zum Wiederlaufen ca. eine Stunde) oder Du installierst ein neues VZ-Image und spielst darin die DB und die vzlogger.conf zurück. Eine komplett lückenlose Ausfallsicherung dürfte zumindest auf oder mit dem Raspi schwer zu realisieren sein und ist m.E.n. auch nicht unbedingt notwendig, da die relativen Schwankungen im Verbrauch zumindest über ein paar Stunden nicht so groß ausfallen fürften. Grüße JD. Sent: Monday, November 16, 2020 at 3:03 PM From: "Michael Hartmann" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup Die HW lässt sich leider nicht eben umziehen. Der IR-Lesekopf hängt mit weiteren S0-Gebern an der Erweiterungsplatine der laufenden Systems. Aktuell habe ich auch wenig Zweifel, dass ein Umzug der HW Daten liefern würde. Ein solcher Test bedeutet auch, dass das laufende System offline ginge. Das Ganze ist eine Trockenübung um die Nutzbarkeit eines DD-Images zu prüfen. Denn dazu wurden hier Bedenken bzgl. Datenintegrität geäußert. Der beobachtete "Fehler" beim Ergänzen der Daten aus dem DB-Backup deutet in der Tat auf einen möglichen Fehler in der DB auf dem Image hin. Mein Ziel ist eigentlich Images und Backups der DB im laufenden Betrieb zu fahren. Da ich an der Installation nicht permanent Änderungen vornehme, könnte ich das laufende System einmalig herunterfahren um ein Image von der SD-Karte anzufertigen. Das dürfte bei 32GB aber auch schon bei 2h dauern und somit eine entsprechende Datenlücke nach sich ziehen. Da wäre ich gerne sicher, dass ich die DB auf dem Image bei Wiederherstellung zügig mit den fehlenden Daten aus dem DB-Backup ergänzen kann. Grüße Micha Gesendet: Montag, 16. November 2020 um 13:00 Uhr Von: "John Doe" An: volkszaehler-users@demo.volkszaehler.org Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo MIchael, dann hab' ich das falsch verstanden, sorry. Wenn Du einfach das "gleiche" Image (also das aus dem Produktivsystem) weiter verwendest, sollte eigentlich alles normal weiterlaufen. Was passiert denn, wenn Du den IR-Kopf mal an den Pi steckst und das Zurückspielen der gesicherten DB erst mal weglässt? Kommen denn dann im Frontend Daten an, unabhängig von der Lücke in den Daten seit der Image-Erstellung ? Grüsse JD. Sent: Monday, November 16, 2020 at 12:20 PM From: "Michael Hartmann" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo John, auf dem Image existiert ja bereits die DB, welche die Daten bis zum Zeitpunkt der Imageerstellung enthält. Ich müsste diese also löschen um dann in eine neu erstellte leere Datenbank alle Daten aus dem DB-Backup zu kopieren? Ein Ergänzen der fehlenden Daten funktioniert generell nicht? Grüße Michael Gesendet: Montag, 16. November 2020 um 12:13 Uhr Von: "John Doe" An: volkszaehler-users@demo.volkszaehler.org Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo Michael, da ich das Prozedere der Rücksicherung gerade erst wieder mal durchgearbeitet habe, hier ein Tip: Ich glaube, dass Du zuerst auf dem zweiten Raspi eine leere volkszaehler-DB mit "create" (wie im wiki) erzeugen musst. In dieser spielst Du dann die gesicherte (sqlite.db3) DB zurück; ggfs. musst Du die aggregation danach noch einmal "von Hand" laufen lassen. Grüsse JD. Sent: Friday, November 13, 2020 at 8:47 PM From: "Michael Hartmann" To: "'volkszaehler-users'" Subject: [vz-users] Image mit dd erstellen / Datenbackup Hallo, da kürzlich Bedenken bzgl. Integrität eines zur Laufzeit mit dd erstellten Images aufkamen habe ich folgendes getestet: 1. Erstellen eines Image zur Laufzeit mit dd direkt auf mein NAS 2. Reduzieren und abschießendes Packen des Images in GZIP-Format mit pishrink 3. Resultat 32GB > 5,2GB > 1,6GB 4. Enpacken mit 7ZIP unter Win10 5. Brennen des Image mit Win32DiskImager auf eine 32GB- SD-Karte 6. Inbetriebnahme der SD-Karte auf einem zweiten Raspi 3B+ Resultat: Das Image läuft. D.h. ich kann via Frontend auf alle Daten bis zum Zeitpunkt an dem das Image erstellt wurde zugreifen und beliebig darin navigieren. Da keine HW angeschlossen ist kann ich nicht sagen ob vzlogger ordnungsgemäß laufen würde. Da ich ein tägliches, inkrementelles Backup in eine DB auf meinem NAS mache, habe ich
Re: [vz-users] Image mit dd erstellen / Datenbackup
Hallo MIchael, dann hab' ich das falsch verstanden, sorry. Wenn Du einfach das "gleiche" Image (also das aus dem Produktivsystem) weiter verwendest, sollte eigentlich alles normal weiterlaufen. Was passiert denn, wenn Du den IR-Kopf mal an den Pi steckst und das Zurückspielen der gesicherten DB erst mal weglässt? Kommen denn dann im Frontend Daten an, unabhängig von der Lücke in den Daten seit der Image-Erstellung ? Grüsse JD. Sent: Monday, November 16, 2020 at 12:20 PM From: "Michael Hartmann" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo John, auf dem Image existiert ja bereits die DB, welche die Daten bis zum Zeitpunkt der Imageerstellung enthält. Ich müsste diese also löschen um dann in eine neu erstellte leere Datenbank alle Daten aus dem DB-Backup zu kopieren? Ein Ergänzen der fehlenden Daten funktioniert generell nicht? Grüße Michael Gesendet: Montag, 16. November 2020 um 12:13 Uhr Von: "John Doe" An: volkszaehler-users@demo.volkszaehler.org Betreff: Re: [vz-users] Image mit dd erstellen / Datenbackup Hallo Michael, da ich das Prozedere der Rücksicherung gerade erst wieder mal durchgearbeitet habe, hier ein Tip: Ich glaube, dass Du zuerst auf dem zweiten Raspi eine leere volkszaehler-DB mit "create" (wie im wiki) erzeugen musst. In dieser spielst Du dann die gesicherte (sqlite.db3) DB zurück; ggfs. musst Du die aggregation danach noch einmal "von Hand" laufen lassen. Grüsse JD. Sent: Friday, November 13, 2020 at 8:47 PM From: "Michael Hartmann" To: "'volkszaehler-users'" Subject: [vz-users] Image mit dd erstellen / Datenbackup Hallo, da kürzlich Bedenken bzgl. Integrität eines zur Laufzeit mit dd erstellten Images aufkamen habe ich folgendes getestet: 1. Erstellen eines Image zur Laufzeit mit dd direkt auf mein NAS 2. Reduzieren und abschießendes Packen des Images in GZIP-Format mit pishrink 3. Resultat 32GB > 5,2GB > 1,6GB 4. Enpacken mit 7ZIP unter Win10 5. Brennen des Image mit Win32DiskImager auf eine 32GB- SD-Karte 6. Inbetriebnahme der SD-Karte auf einem zweiten Raspi 3B+ Resultat: Das Image läuft. D.h. ich kann via Frontend auf alle Daten bis zum Zeitpunkt an dem das Image erstellt wurde zugreifen und beliebig darin navigieren. Da keine HW angeschlossen ist kann ich nicht sagen ob vzlogger ordnungsgemäß laufen würde. Da ich ein tägliches, inkrementelles Backup in eine DB auf meinem NAS mache, habe ich nun versucht die Daten vom Zeitpunkt der Imageerstellung bis zum Zeitpunkt des letzten Backups zu ergänzen und bin dabei wie im Wiki beschrieben vorgegangen. D.h. ich habe in /etc/dbcopy.yaml die die Angaben für Ziel und Quelle vertauscht. Der mySQ-Standarduser „vz“ wurde abgewiesen. Mit dem umfassenden Nutzer „vz-admin“ bekomme ich folgendes Ergebnis: pi@SmartMeter2:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy_alt_user.yam l Dropping FK FK_87C331C781257D5D on properties Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator Dropping FK FK_ADF3F36372F5A1AA on data Dropping FK FK_B77949FF72F5A1AA on aggregate entities: copying 7 rows (overwrite) [] 100% < 1 sec/< 1 sec 7 rows properties: copying 63 rows (overwrite) [] 100% < 1 sec/< 1 sec 63 rows entities_in_aggregator: copying 0 rows (overwrite) 0 [->--] < 1 sec 6.0 MiB data: copying 5864950 rows (partial copy) [>---] 0% < 1 sec/< 1 sec 0 rows In AbstractMySQLDriver.php line 74: An exception occurred while executing 'INSERT INTO `data` (`id`,`channel_id`,`timestamp`,` value`) VALUES (?,?,?,?)' with params ["1672482", "2", "1592585825000", "1010037"]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1672482' for key 'P RIMARY' In Exception.php line 18: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1672482' for key 'P RIMARY' In PDOStatement.php line 115: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1672482' for key 'P RIMARY' copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Evtl. korrupte DB auf dem Image? Oder eine andere Ursache? Wie wäre der Fehler zu beheben? Grüße Micha
Re: [vz-users] Image mit dd erstellen / Datenbackup
Hallo Michael, da ich das Prozedere der Rücksicherung gerade erst wieder mal durchgearbeitet habe, hier ein Tip: Ich glaube, dass Du zuerst auf dem zweiten Raspi eine leere volkszaehler-DB mit "create" (wie im wiki) erzeugen musst. In dieser spielst Du dann die gesicherte (sqlite.db3) DB zurück; ggfs. musst Du die aggregation danach noch einmal "von Hand" laufen lassen. Grüsse JD. Sent: Friday, November 13, 2020 at 8:47 PM From: "Michael Hartmann" To: "'volkszaehler-users'" Subject: [vz-users] Image mit dd erstellen / Datenbackup Hallo, da kürzlich Bedenken bzgl. Integrität eines zur Laufzeit mit dd erstellten Images aufkamen habe ich folgendes getestet: 1. Erstellen eines Image zur Laufzeit mit dd direkt auf mein NAS 2. Reduzieren und abschießendes Packen des Images in GZIP-Format mit pishrink 3. Resultat 32GB > 5,2GB > 1,6GB 4. Enpacken mit 7ZIP unter Win10 5. Brennen des Image mit Win32DiskImager auf eine 32GB- SD-Karte 6. Inbetriebnahme der SD-Karte auf einem zweiten Raspi 3B+ Resultat: Das Image läuft. D.h. ich kann via Frontend auf alle Daten bis zum Zeitpunkt an dem das Image erstellt wurde zugreifen und beliebig darin navigieren. Da keine HW angeschlossen ist kann ich nicht sagen ob vzlogger ordnungsgemäß laufen würde. Da ich ein tägliches, inkrementelles Backup in eine DB auf meinem NAS mache, habe ich nun versucht die Daten vom Zeitpunkt der Imageerstellung bis zum Zeitpunkt des letzten Backups zu ergänzen und bin dabei wie im Wiki beschrieben vorgegangen. D.h. ich habe in /etc/dbcopy.yaml die die Angaben für Ziel und Quelle vertauscht. Der mySQ-Standarduser „vz“ wurde abgewiesen. Mit dem umfassenden Nutzer „vz-admin“ bekomme ich folgendes Ergebnis: pi@SmartMeter2:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy_alt_user.yam l Dropping FK FK_87C331C781257D5D on properties Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator Dropping FK FK_ADF3F36372F5A1AA on data Dropping FK FK_B77949FF72F5A1AA on aggregate entities: copying 7 rows (overwrite) [] 100% < 1 sec/< 1 sec 7 rows properties: copying 63 rows (overwrite) [] 100% < 1 sec/< 1 sec 63 rows entities_in_aggregator: copying 0 rows (overwrite) 0 [->--] < 1 sec 6.0 MiB data: copying 5864950 rows (partial copy) [>---] 0% < 1 sec/< 1 sec 0 rows In AbstractMySQLDriver.php line 74: An exception occurred while executing 'INSERT INTO `data` (`id`,`channel_id`,`timestamp`,` value`) VALUES (?,?,?,?)' with params ["1672482", "2", "1592585825000", "1010037"]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1672482' for key 'P RIMARY' In Exception.php line 18: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1672482' for key 'P RIMARY' In PDOStatement.php line 115: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1672482' for key 'P RIMARY' copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Evtl. korrupte DB auf dem Image? Oder eine andere Ursache? Wie wäre der Fehler zu beheben? Grüße Micha
Re: [vz-users] Neubeginn nach Kartencrash
Hallo Andreas, ein pi@raspberrypi:~ $ php /var/www/volkszaehler.org/bin/doctrine orm:schema-tool:create --dump-sql The following SQL statements will be executed: CREATE TABLE aggregate (id INT AUTO_INCREMENT NOT NULL, channel_id INT DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, count INT NOT NULL, INDEX IDX_B77949FF72F5A1AA (channel_id), UNIQUE INDEX aggregate_unique (channel_id, type, timestamp), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE entities (id INT AUTO_INCREMENT NOT NULL, uuid VARCHAR(36) NOT NULL, type VARCHAR(255) NOT NULL, class VARCHAR(255) NOT NULL, UNIQUE INDEX UNIQ_50EC64E5D17F50A6 (uuid), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE entities_in_aggregator (parent_id INT NOT NULL, child_id INT NOT NULL, INDEX IDX_2BD88468727ACA70 (parent_id), INDEX IDX_2BD88468DD62C21B (child_id), PRIMARY KEY(parent_id, child_id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE properties (id INT AUTO_INCREMENT NOT NULL, entity_id INT DEFAULT NULL, pkey VARCHAR(255) NOT NULL, value LONGTEXT NOT NULL, INDEX IDX_87C331C781257D5D (entity_id), UNIQUE INDEX property_unique (entity_id, pkey), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE data (id INT AUTO_INCREMENT NOT NULL, channel_id INT DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, INDEX IDX_ADF3F36372F5A1AA (channel_id), UNIQUE INDEX data_unique (channel_id, timestamp), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; ALTER TABLE aggregate ADD CONSTRAINT FK_B77949FF72F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id); ALTER TABLE entities_in_aggregator ADD CONSTRAINT FK_2BD88468727ACA70 FOREIGN KEY (parent_id) REFERENCES entities (id); ALTER TABLE entities_in_aggregator ADD CONSTRAINT FK_2BD88468DD62C21B FOREIGN KEY (child_id) REFERENCES entities (id); ALTER TABLE properties ADD CONSTRAINT FK_87C331C781257D5D FOREIGN KEY (entity_id) REFERENCES entities (id); ALTER TABLE data ADD CONSTRAINT FK_ADF3F36372F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id); ist fehlerfrei durchgelaufen. An dem aggregate-Problem ändert das leider nichts Was könnte ich noch versuchen ? Bevor Du fragst: pi@raspberrypi:~ $ php /var/www/volkszaehler.org/bin/doctrine orm:schema-tool:create --force The "--force" option does not exist. Beste Grüße JD. Sent: Sunday, November 08, 2020 at 4:53 PM From: "Andreas Götz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Neubeginn nach Kartencrash Bis Du sicher, dass Deine Zieldatwnvank auch Indizes hat? Beim Restore werden die gelöscht um nicht an temporär Fehlenden Relationen zu scheitern. Hatten wir vmtl. auch schon: das Zauberwergzeug heisst orm schema-tool. Viele Grüße, Andreas Am 08.11.2020 um 16:25 schrieb John Doe : Hallo zusammen, mea culpa. Ihr hattet natürlich recht - ich musste mein Backup natürlich noch in die neu creierte Datenbank füllen. Habe jetzt alles soweit wieder am Laufen - bis auf eine Kleinigkeit: Ich bekomme aggregate nicht zum Laufen. vzlogger ist gestopt: pi@raspberrypi:~ $ sudo systemctl status vzlogger.service ● vzlogger.service - vzlogger Loaded: loaded (/etc/systemd/system/vzlogger.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Sun 2020-11-08 16:16:42 CET; 5min ago Process: 729 ExecStart=/usr/local/bin/vzlogger -c /etc/vzlogger.conf (code=killed, signal=KILL) Main PID: 729 (code=killed, signal=KILL) Nov 08 16:14:49 raspberrypi systemd[1]: Started vzlogger. Nov 08 16:15:01 raspberrypi systemd[1]: Stopping vzlogger... Nov 08 16:16:42 raspberrypi systemd[1]: vzlogger.service: State 'stop-sigterm' timed out. Killing. Nov 08 16:16:42 raspberrypi systemd[1]: vzlogger.service: Killing process 729 (vzlogger) with signal SIGKILL. Nov 08 16:16:42 raspberrypi systemd[1]: vzlogger.service: Main process exited, code=killed, status=9/KILL Nov 08 16:16:42 raspberrypi systemd[1]: vzlogger.service: Failed with result 'timeout'. Nov 08 16:16:42 raspberrypi systemd[1]: Stopped vzlogger. cron ist gestopt: pi@raspberrypi:~ $ sudo systemctl status cron.service ● cron.service - Regular background program processing daemon Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sun 2020-11-08 16:14:56 CET; 8min ago Docs: man:cron(8) Process: 407 ExecStart=/usr/sbin/cron -f $EXTRA_OPTS (code=killed, signal=TERM) Main PID: 407 (code=killed, signal=TERM) Nov 08 16:14:35 raspberrypi systemd[1]: Started Regular background program processing daemon. Nov 08
Re: [vz-users] Neubeginn nach Kartencrash
Hallo zusammen, mea culpa. Ihr hattet natürlich recht - ich musste mein Backup natürlich noch in die neu creierte Datenbank füllen. Habe jetzt alles soweit wieder am Laufen - bis auf eine Kleinigkeit: Ich bekomme aggregate nicht zum Laufen. vzlogger ist gestopt: pi@raspberrypi:~ $ sudo systemctl status vzlogger.service ● vzlogger.service - vzlogger Loaded: loaded (/etc/systemd/system/vzlogger.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Sun 2020-11-08 16:16:42 CET; 5min ago Process: 729 ExecStart=/usr/local/bin/vzlogger -c /etc/vzlogger.conf (code=killed, signal=KILL) Main PID: 729 (code=killed, signal=KILL) Nov 08 16:14:49 raspberrypi systemd[1]: Started vzlogger. Nov 08 16:15:01 raspberrypi systemd[1]: Stopping vzlogger... Nov 08 16:16:42 raspberrypi systemd[1]: vzlogger.service: State 'stop-sigterm' timed out. Killing. Nov 08 16:16:42 raspberrypi systemd[1]: vzlogger.service: Killing process 729 (vzlogger) with signal SIGKILL. Nov 08 16:16:42 raspberrypi systemd[1]: vzlogger.service: Main process exited, code=killed, status=9/KILL Nov 08 16:16:42 raspberrypi systemd[1]: vzlogger.service: Failed with result 'timeout'. Nov 08 16:16:42 raspberrypi systemd[1]: Stopped vzlogger. cron ist gestopt: pi@raspberrypi:~ $ sudo systemctl status cron.service ● cron.service - Regular background program processing daemon Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sun 2020-11-08 16:14:56 CET; 8min ago Docs: man:cron(8) Process: 407 ExecStart=/usr/sbin/cron -f $EXTRA_OPTS (code=killed, signal=TERM) Main PID: 407 (code=killed, signal=TERM) Nov 08 16:14:35 raspberrypi systemd[1]: Started Regular background program processing daemon. Nov 08 16:14:35 raspberrypi cron[407]: (CRON) INFO (pidfile fd = 3) Nov 08 16:14:35 raspberrypi cron[407]: (CRON) INFO (Running @reboot jobs) Nov 08 16:14:56 raspberrypi systemd[1]: Stopping Regular background program processing daemon... Nov 08 16:14:56 raspberrypi systemd[1]: cron.service: Main process exited, code=killed, status=15/TERM Nov 08 16:14:56 raspberrypi systemd[1]: cron.service: Succeeded. Nov 08 16:14:56 raspberrypi systemd[1]: Stopped Regular background program processing daemon. aggregate: php /var/www/volkszaehler.org/bin/aggregate run -m full -l day -l hour -l minute Performing 'full' aggregation on 'day' level [>---] 0% < 1 sec/< 1 sec 0 channels An diesem Zustand ändert sich über lange Zeit nichts. Hat jemand einen Tip, woran das liegen könnte ? Beste Grüße und Dank JD. Sent: Sunday, November 08, 2020 at 11:19 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Neubeginn nach Kartencrash Also mit create hast Du das Datenbankschema angelegt, das ist aber leer. Du musst auch die Daten noch reinkopieren ;) Viele Grüße, Andreas Am 08.11.2020 um 11:05 schrieb John Doe : Hallo Andreas, ich bin ein Stück weiter. Ein sudo apt-get install php-sqlite3 liess das sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml fehlerfrei durchlaufen. Allerdings scheint mir das Wiedereinspielen der gesicherten Datenbank (natürlich mit sqlite.db3 als source) irgendwie nichts zu finden: pi@raspberrypi:~ $ sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml entities: copying 0 rows (overwrite) 0 [>---] < 1 sec 4.0 MiB properties: copying 0 rows (overwrite) 0 [>---] < 1 sec 4.0 MiB entities_in_aggregator: copying 0 rows (overwrite) 0 [>---] < 1 sec 4.0 MiB data: copying 0 rows (partial copy) 0 [>---] < 1 sec 4.0 MiB Hättest Du eine Idee, woran das liegen kann ? Beste Grüße JD: Sent: Saturday, November 07, 2020 at 8:10 PM From: "Andreas Götz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Neubeginn nach Kartencrash Ist ohne Deine Datei schwer zu sagen... Viele Grüße, Andreas Am 07.11.2020 um 18:12 schrieb John Doe : Hallo zusammen, da ich mir leider doch das Vorgehen vom letzten Mal nicht notiert habe, fehlt mir jetzt wieder der Einstieg. Ich habe - eine Kopie sqlite.db3 der Datenbank - eine Kopie der vzlogger.conf - eine Kopie der dbcopy.yaml, mir der ich die Datenbank-Kopie erstellt habe. Ich habe - das aktuelle VZ-Image installiert und mit Updates versehen - die Kopie sqlite.dpb3 in das neue Home-Verzeichnis kopiert - die gesicherte vzlogger.conf und dbcopy.yaml nach /etc kopiert. Ein Aufruf von sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml bringt Creating target schema PHP Notice: Undefined variable: schema in /home/pi/volkszaehler.org/vendor/andig/dbcopy/src/Command/CreateC
Re: [vz-users] Neubeginn nach Kartencrash
Hallo Andreas, ich bin ein Stück weiter. Ein sudo apt-get install php-sqlite3 liess das sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml fehlerfrei durchlaufen. Allerdings scheint mir das Wiedereinspielen der gesicherten Datenbank (natürlich mit sqlite.db3 als source) irgendwie nichts zu finden: pi@raspberrypi:~ $ sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml entities: copying 0 rows (overwrite) 0 [>---] < 1 sec 4.0 MiB properties: copying 0 rows (overwrite) 0 [>---] < 1 sec 4.0 MiB entities_in_aggregator: copying 0 rows (overwrite) 0 [>---] < 1 sec 4.0 MiB data: copying 0 rows (partial copy) 0 [>---] < 1 sec 4.0 MiB Hättest Du eine Idee, woran das liegen kann ? Beste Grüße JD: Sent: Saturday, November 07, 2020 at 8:10 PM From: "Andreas Götz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Neubeginn nach Kartencrash Ist ohne Deine Datei schwer zu sagen... Viele Grüße, Andreas Am 07.11.2020 um 18:12 schrieb John Doe : Hallo zusammen, da ich mir leider doch das Vorgehen vom letzten Mal nicht notiert habe, fehlt mir jetzt wieder der Einstieg. Ich habe - eine Kopie sqlite.db3 der Datenbank - eine Kopie der vzlogger.conf - eine Kopie der dbcopy.yaml, mir der ich die Datenbank-Kopie erstellt habe. Ich habe - das aktuelle VZ-Image installiert und mit Updates versehen - die Kopie sqlite.dpb3 in das neue Home-Verzeichnis kopiert - die gesicherte vzlogger.conf und dbcopy.yaml nach /etc kopiert. Ein Aufruf von sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml bringt Creating target schema PHP Notice: Undefined variable: schema in /home/pi/volkszaehler.org/vendor/andig/dbcopy/src/Command/CreateCommand.php on line 155 PHP Fatal error: Uncaught Error: Call to a member function toSql() on null in /home/pi/volkszaehler.org/vendor/andig/dbcopy/src/Command/CreateCommand.php:155 Stack trace: #0 /home/pi/volkszaehler.org/vendor/symfony/console/Command/Command.php(255): DatabaseCopy\Command\CreateCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #1 /home/pi/volkszaehler.org/vendor/symfony/console/Application.php(921): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #2 /home/pi/volkszaehler.org/vendor/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand(Object(DatabaseCopy\Command\CreateCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #3 /home/pi/volkszaehler.org/vendor/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun(Object(Symfony\Co in /home/pi/volkszaehler.org/vendor/andig/dbcopy/src/Command/CreateCommand.php on line 155 Was mache ich denn diesmal wieder falsch ? Beste Grüße JD.
Re: [vz-users] Neubeginn nach Kartencrash
Hallo Andreas, hier die dbcopy.yaml: # DATABASE DEFINITION target: driver: pdo_mysql host: localhost user: root password: demo dbname: volkszaehler source: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: entire table will be truncated on target and copied from source # pk: selective copy by primary key. only data not present on target # will be copied from source. tables: entities: copy properties: copy entities_in_aggregator: copy data: pk aggregate: skip Beste Grüße JD. Sent: Saturday, November 07, 2020 at 8:10 PM From: "Andreas Götz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Neubeginn nach Kartencrash Ist ohne Deine Datei schwer zu sagen... Viele Grüße, Andreas Am 07.11.2020 um 18:12 schrieb John Doe : Hallo zusammen, da ich mir leider doch das Vorgehen vom letzten Mal nicht notiert habe, fehlt mir jetzt wieder der Einstieg. Ich habe - eine Kopie sqlite.db3 der Datenbank - eine Kopie der vzlogger.conf - eine Kopie der dbcopy.yaml, mir der ich die Datenbank-Kopie erstellt habe. Ich habe - das aktuelle VZ-Image installiert und mit Updates versehen - die Kopie sqlite.dpb3 in das neue Home-Verzeichnis kopiert - die gesicherte vzlogger.conf und dbcopy.yaml nach /etc kopiert. Ein Aufruf von sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml bringt Creating target schema PHP Notice: Undefined variable: schema in /home/pi/volkszaehler.org/vendor/andig/dbcopy/src/Command/CreateCommand.php on line 155 PHP Fatal error: Uncaught Error: Call to a member function toSql() on null in /home/pi/volkszaehler.org/vendor/andig/dbcopy/src/Command/CreateCommand.php:155 Stack trace: #0 /home/pi/volkszaehler.org/vendor/symfony/console/Command/Command.php(255): DatabaseCopy\Command\CreateCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #1 /home/pi/volkszaehler.org/vendor/symfony/console/Application.php(921): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #2 /home/pi/volkszaehler.org/vendor/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand(Object(DatabaseCopy\Command\CreateCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #3 /home/pi/volkszaehler.org/vendor/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun(Object(Symfony\Co in /home/pi/volkszaehler.org/vendor/andig/dbcopy/src/Command/CreateCommand.php on line 155 Was mache ich denn diesmal wieder falsch ? Beste Grüße JD.
[vz-users] Neubeginn nach Kartencrash
Hallo zusammen, da ich mir leider doch das Vorgehen vom letzten Mal nicht notiert habe, fehlt mir jetzt wieder der Einstieg. Ich habe - eine Kopie sqlite.db3 der Datenbank - eine Kopie der vzlogger.conf - eine Kopie der dbcopy.yaml, mir der ich die Datenbank-Kopie erstellt habe. Ich habe - das aktuelle VZ-Image installiert und mit Updates versehen - die Kopie sqlite.dpb3 in das neue Home-Verzeichnis kopiert - die gesicherte vzlogger.conf und dbcopy.yaml nach /etc kopiert. Ein Aufruf von sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml bringt Creating target schema PHP Notice: Undefined variable: schema in /home/pi/volkszaehler.org/vendor/andig/dbcopy/src/Command/CreateCommand.php on line 155 PHP Fatal error: Uncaught Error: Call to a member function toSql() on null in /home/pi/volkszaehler.org/vendor/andig/dbcopy/src/Command/CreateCommand.php:155 Stack trace: #0 /home/pi/volkszaehler.org/vendor/symfony/console/Command/Command.php(255): DatabaseCopy\Command\CreateCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #1 /home/pi/volkszaehler.org/vendor/symfony/console/Application.php(921): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #2 /home/pi/volkszaehler.org/vendor/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand(Object(DatabaseCopy\Command\CreateCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #3 /home/pi/volkszaehler.org/vendor/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun(Object(Symfony\Co in /home/pi/volkszaehler.org/vendor/andig/dbcopy/src/Command/CreateCommand.php on line 155 Was mache ich denn diesmal wieder falsch ? Beste Grüße JD.
Re: [vz-users] Bevorstehender Kartencrash (?)
Hallo zusammen, die Probleme im Frontend haben sich wieder eingestellt, ich habe aber zugegebenrmassen noch nichts weiter in Richtung Ursachenforschung unternommen. Im /var/log/vzlogger.log steht gehäuft: [Nov 04 11:23:32][chn1] CURL Error from middleware: 'ConnectionException': 'An exception occurred in driver: SQLSTATE[HY000] [2002] Connection refused' Ist es sicher, dass da wirklich die SD-Karte nicht defekt ist oder wird ? Ein sudo time badblocks -sv /dev/mmcblk0 hat da in den letzten Tagen nichts Besonderes ergeben (ca. 100 minor faults). Nach einem Reboot läuft alles wieder normal, leider sind aber auch alle Daten bis zum Reboot verschwunden. Beste Grüße JD. Sent: Tuesday, November 03, 2020 at 3:45 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash (?) Hallo Daniel, perfekt, Danke für die Info. Ich werde nochmal den Sitz des Lesekopfes prüfen und mich ggfs. um Ersatz bemühen. Beste Grüße JD. Sent: Tuesday, November 03, 2020 at 3:39 PM From: "Daniel Lauckner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash (?) Hallo, am Dienstag, 3. November 2020 um 15:32 hat John Doe geschrieben: > Für den Fall eines defekten IR-Lesekopfes: Kann ich diesen einfach > so ersetzen, oder muss ich in der DB dann neue UIDs anlegen ? Keine neue UUID nötig, prüfe aber ob dem neuen Kopf das selbe Device zugeordnet wurde. Ansonsten udev-Regel oder vzlogger.conf anpassen. mfg Daniel
Re: [vz-users] Bevorstehender Kartencrash (?)
Hallo Daniel, perfekt, Danke für die Info. Ich werde nochmal den Sitz des Lesekopfes prüfen und mich ggfs. um Ersatz bemühen. Beste Grüße JD. Sent: Tuesday, November 03, 2020 at 3:39 PM From: "Daniel Lauckner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash (?) Hallo, am Dienstag, 3. November 2020 um 15:32 hat John Doe geschrieben: > Für den Fall eines defekten IR-Lesekopfes: Kann ich diesen einfach > so ersetzen, oder muss ich in der DB dann neue UIDs anlegen ? Keine neue UUID nötig, prüfe aber ob dem neuen Kopf das selbe Device zugeordnet wurde. Ansonsten udev-Regel oder vzlogger.conf anpassen. mfg Daniel
Re: [vz-users] Bevorstehender Kartencrash (?)
Hallo Daniel, besten Dank für die schnelle Antwort. Einen verrutschten Lesekopf würde ich auschliessen wollen, da dieser mit Powerstrips auf den Zähler geklebt ist und bisher "eigentlich" immer stabil war. Für den Fall eines defekten IR-Lesekopfes: Kann ich diesen einfach so ersetzen, oder muss ich in der DB dann neue UIDs anlegen ? Beste Grüße JD. Sent: Tuesday, November 03, 2020 at 3:22 PM From: "Daniel Lauckner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash (?) Hallo, am Dienstag, 3. November 2020 um 15:16 hat John Doe geschrieben: > [Oct 15 21:33:16][d0] read timed out!, context: 1, bytes read: 0, last byte 0x2f Das sind Lesefehler auf der Schnittstelle zum Zähler. Kein Problem mit der SD. Ursache könnte ein verrutschter Lesekopf oder nachlassende Elektronik sein. mfg Daniel
[vz-users] Bevorstehender Kartencrash (?)
Hallo zusammen, bei meinem bis vorgestern problemlos laufenden VZ auf einem RPi3 stellen sich zunehmend Aussetzer dergestalt ein, dass im Frontend keine Daten mehr ankommen. Im /var/log/vzlogger.log steht vermehrt das Folgende: [Oct 15 21:32:48][main] vzlogger v0.7.0 based on heads/master-0-g12e74ddd43 from Sun, 2 Jun 2019 20:48:14 +0200 started. [Oct 15 21:32:49][main] log level is 0 [Oct 15 21:33:16][d0] read timed out!, context: 1, bytes read: 0, last byte 0x2f [Oct 15 21:33:17][d0] read timed out!, context: 1, bytes read: 0, last byte 0x2f [Nov 01 13:41:35][main] vzlogger v0.7.0 based on heads/master-0-g12e74ddd43 from Sun, 2 Jun 2019 20:48:14 +0200 started. [Nov 01 13:41:35][main] log level is 0 [Nov 03 15:06:56][d0] read timed out!, context: 1, bytes read: 0, last byte 0x2f [Nov 03 15:06:57][d0] read timed out!, context: 1, bytes read: 0, last byte 0x2f Kündigt sich da ein neuerlicher Kartencrash an und sollte ich mich um Neuinstallation bemühen ? Ich habe eine Sicherung der lauffähigen vzlogger.conf und der Datenbank bis gestern. Schlusshinweis: Ein update/upgrade liefert das Folgende: Unpacking raspberrypi-kernel (1.20201022-1) over (1.20200902-1) ... dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing archive /tmp/apt-dpkg-install-lTa17a/14-raspberrypi-kernel_1.20201022-1_armhf.deb (--unpack): cannot copy extracted data for './lib/modules/5.4.72-v7+/kernel/drivers/staging/rtl8188eu/r8188eu.ko' to '/lib/modules/5.4.72-v7+/kernel/drivers/staging/rtl8188eu/r8188eu.ko.dpkg-new': unexpected end of file or stream run-parts: executing /etc/kernel/postrm.d/initramfs-tools 5.4.72+ /boot/kernel.img run-parts: executing /etc/kernel/postrm.d/initramfs-tools 5.4.72-v7+ /boot/kernel7.img run-parts: executing /etc/kernel/postrm.d/initramfs-tools 5.4.72-v7l+ /boot/kernel7l.img run-parts: executing /etc/kernel/postrm.d/initramfs-tools 5.4.72-v8+ /boot/kernel8.img You do not have enough space in /boot to install this package. Skipping Pi 4 support Unpacking raspberrypi-bootloader (1.20201022-1) over (1.20200902-1) ... Preparing to unpack .../18-libx11-data_2%3a1.6.7-1+deb10u1_all.deb ... Unpacking libx11-data (2:1.6.7-1+deb10u1) over (2:1.6.7-1) ... dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing archive /tmp/apt-dpkg-install-lTa17a/18-libx11-data_2%3a1.6.7-1+deb10u1_all.deb (--unpack): cannot copy extracted data for './usr/share/X11/XErrorDB' to '/usr/share/X11/XErrorDB.dpkg-new': unexpected end of file or stream Preparing to unpack .../19-libx11-6_2%3a1.6.7-1+deb10u1_armhf.deb ... Unpacking libx11-6:armhf (2:1.6.7-1+deb10u1) over (2:1.6.7-1) ... dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing archive /tmp/apt-dpkg-install-lTa17a/19-libx11-6_2%3a1.6.7-1+deb10u1_armhf.deb (--unpack): cannot copy extracted data for './usr/lib/arm-linux-gnueabihf/libX11.so.6.3.0' to '/usr/lib/arm-linux-gnueabihf/libX11.so.6.3.0.dpkg-new': unexpected end of file or stream Preparing to unpack .../20-mariadb-client_1%3a10.3.25-0+deb10u1_all.deb ... Unpacking mariadb-client (1:10.3.25-0+deb10u1) over (1:10.3.23-0+deb10u1) ... dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing archive /tmp/apt-dpkg-install-lTa17a/20-mariadb-client_1%3a10.3.25-0+deb10u1_all.deb (--unpack): cannot copy extracted data for './usr/share/doc/mariadb-client/changelog.Debian.gz' to '/usr/share/doc/mariadb-client/changelog.Debian.gz.dpkg-new': unexpected end of file or stream Preparing to unpack .../21-mariadb-server_1%3a10.3.25-0+deb10u1_all.deb ... Unpacking mariadb-server (1:10.3.25-0+deb10u1) over (1:10.3.23-0+deb10u1) ... dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing archive /tmp/apt-dpkg-install-lTa17a/21-mariadb-server_1%3a10.3.25-0+deb10u1_all.deb (--unpack): cannot copy extracted data for './usr/share/doc/mariadb-server/changelog.Debian.gz' to '/usr/share/doc/mariadb-server/changelog.Debian.gz.dpkg-new': unexpected end of file or stream Preparing to unpack .../22-raspberrypi-sys-mods_20201026_armhf.deb ... Unpacking raspberrypi-sys-mods (20201026) over (20200812) ... Preparing to unpack .../23-raspi-config_20201027_all.deb ... Unpacking raspi-config (20201027) over (20200902) ... Preparing to unpack .../24-rpi-eeprom_10.2-1_armhf.deb ... Unpacking rpi-eeprom (10.2-1) over (9.0-1) ... Errors were encountered while processing: /tmp/apt-dpkg-install-lTa17a/14-raspberrypi-kernel_1.20201022-1_armhf.deb
Re: [vz-users] Fehlerhafte Daten in der DB löschen/korrigieren
Hallo Thomas, perfekt, tausend Dank ! Habe Deinen Tip gerade mit einem alten Relikt aus einem Crash-Übergang ausprobiert und er hat exakt so funktioniert. Danach habe ich einige Jahre gesucht, nochmal Danke! Grüße JD. Sent: Thursday, October 01, 2020 at 10:43 AM From: "Thomas Höpfner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Fehlerhafte Daten in der DB löschen/korrigieren Hallo, man kann die Daten auch über das Frondent löschen. - Zeitbereich eingrenzen auf die zu löschten Daten - in der Auswertung auf deas blaue "I" klicken - in den sich öffnenten Fenster auf "Daten" klicken jetz öffnet sich eine Seite mit den in der Graphik angezeigten Daten .json formatiert - an die URL dieser Seite hängst du folgendes an: =delete Bei den Syntax bin ich mir nicht sicher, habe es schon länger nicht mehr gemacht. Deshalb das Ganze ohne Gewähr. Mit freundlichen Grüßen, Thomas -Ursprüngliche Nachricht- Von: Ralf Wismann Gesendet: Donnerstag 1 Oktober 2020 10:09 An: 'volkszaehler.org - users' Betreff: Re: [vz-users] Fehlerhafte Daten in der DB löschen/korrigieren Hallo >Wie kann ich die Daten des Kanals vom Monat Mai aus der DB >löschen/korrigieren? Lösche bei mir fehlerhafte Daten über ein Skript raus. Dazu nutze ich den „harten“ delete Befehle wie er hier beschrieben ist: https://wiki.volkszaehler.org/howto/datenmengen Ich würde die Befehle aber dringend raten im phpmyAdmin zu simulieren und zu testen bevor nachher was falsches gelöscht wird. VG Ralf
Re: [vz-users] SD-Karten-Crash
Hallo Rupert, das Crash-Problem hatte ich auch bereits einige Male und wurde letztlich auch (nur) durch Leidensdruck an eine Backup-Strategie, in meinem Fall per cron/dbcopy auf ein NAS, herangeführt. Gute Erfahrungen habe ich mit Transcend-Karten in der Größe von mindestens 16 GB gemacht. Wenn ich auf einem RPi3 die aggtime optimiere (-1), halten die Karten mindestens ein Jahr. Eventuell wäre ein RPi4 mit kleiner externer SSD, von welcher dr Raspi bootet, eine Lösung ? Grüße JD. Sent: Sunday, September 27, 2020 at 5:38 PM From: "Rupert Schöttler" To: volkszaehler-users@demo.volkszaehler.org Subject: [vz-users] SD-Karten-Crash Hallo NG, nachdem die letzte SD-Karte nicht mal 1 Monat durchgehalten hat, reicht's mir schön langsam -- trotz guter Backup-Strategie und guter Doku des Vorgehens beim Setup ... Auf dem Pi 1 Model B läuft nur vzlogger ohne Middleware oder Datenbank, dazu der mqtt-gpio-monitor (für digitale Ein- und Ausgänge) sowie rpimonitor (ein nettes Tool zum Beobachten des Systemstatus). Auf die SD-Karte wird eigentlich kaum was geschrieben: Log2Ram verlagert /var/log ins RAM und schreibt die Daten nur 1x tgl. auf die Karte. die Datenbank von rpimonitor habe ich auch nach /var/log umgeleitet Dann kenne ich als letztes nur die Fake-Hardware-Clock, die die Datei /etc/fake-hwclock.data per cron aktualisiert. Das habe ich von stündlich auf täglich hoch gesetzt. Dann sind es nur noch die OS-Updates, die ich so 1x pro Woche laufen lasse, wenn was ansteht. Also eigentlich nicht viel Schreib-Zugriff auf die Karte. Trotzdem hatte die Toshiba Exceria-Karte (micro-SDHC UHS-I Class 10, 32 GB) nach nicht mal 4 Wochen einen Defekt, so dass ein Update nicht mehr durchlief und der Pi beim reboot nicht mehr startete. Ein anderer Rechner konnte die Karte auch nicht mounten... Vorher ist mir eine MediaRange-Karte (SDHC Class 10, 32GB) gestorben, die war >1 Jahr aktiv. Eure Meinung: Sind diese Karten, insbes. die von Toshiba, schlechte oder zu "billige" Qualität für so eine Anwendung? Ich installiere immer erst ein aktuelles OS, also z.B. Buster Lite, und dann "meine" Software hinterher. Es gibt ja auch das Image (https://demo.volkszaehler.org/downloads/volkszaehler_latest.zip). Ist dort was speziell optimiert, um die SD-Karte zu schonen? Einen zweiten Pi habe ich im Einsatz mit der VZ-Datenbank und -Middleware sowie vielen andern Services. Der bootet nur noch von der SD-Karte, das root-FS liegt seit > 2,5 Jahren fehlerfrei auf einer SSD. Diese Lösung habe ich nun auch für den VZlogger-Pi vor. Das Auslagern des root-FS auf einen USB-Stick ist ja schon lange im Wiki https://wiki.volkszaehler.org/howto/performance-optimierung_des_raspberry_pi beschrieben, allerdings auch mit dem Hinweis auf die max. Anzahl Schreibzyklen bei "normalen" USB-Speichersticks. Nun habe ich bei meiner Recherche ein "USB Flash Drive" https://www.samsung.com/de/memory-storage/usb-3-1-flash-drive-fit-plus-2020/MUF-256ABAPC/ gefunden. Hat damit jemand Erfahrungen oder kann es beurteilen: Ist das sozusagen eine SSD im USB-Stecker-Format ("FIT Plus")? Danke fürs Lesen bis hierher und jede Antwort :-) Gruß von Lech und Wertach Rupert
Re: [vz-users] Neuinstallation Volkszähler
Hallo Christian, da ich das Thema "Wiederherstellung einer alten DB" gerade erst vor ein paar Wochen durchexerziert habe, versuche ich mal "sinnvoll" zu antworten. Zunächst zur Frage Booten (und Betreiben des Systems und des VZ) von SD-Karte oder SSD: Ich persönlich benutze und würde hierfür auch immer die SD-Karte verwenden. Einerseits braucht der Raspi sicherlich weniger Strom und andererseits sehe ich den Vorteil nicht. Außerdem müßtest Du hierfür meiner Ansicht nach SSDs verwenden, die dauerlastfähig sind, also z.B. NAS-geeignet sind, was dann die Kostenfrage wieder aufwirft. Wenn Du in der vzlogger.conf die aggtime entsprechend einstellst und sich damit die Schreibzugriffe auf die Karte in Grenzen halten, hält nach meiner Erfahrung eine Transcend-Karte auch bis zu einem Jahr durch. Zur Frage Backup/Wiederherstellung der DB: Mit "dbcopy" (https://wiki.volkszaehler.org/software/tools/dbcopy) klappt das eigentlich relativ ordentlich (wenn man sich nicht wie ich ein wenig blöde anstellt). Du kannst per cron-Job täglich Backups z.B. auf ein NAS o.Ä. ablegen und diese dann, falls die SD-Karte abgeraucht ist, schnell inklusive aller Channels/UUIDs wieder herstellen. Der Verlust der Daten enstpricht dann oft nur wenigen Stunden. Beste Grüße JD: Sent: Tuesday, July 14, 2020 at 9:49 PM From: "Christian Wulff" To: "'volkszaehler.org - users'" Subject: Re: [vz-users] Neuinstallation Volkszähler Moin Andreas, Okay, 1) beantwortet 4) spare ich mir für später auf, wenn die SSD läuft Nun konkreter zu 2) und 3): ………wie geht das? Ich weiß, 1000 Wege führen nach Rom, finde den besten, du hast aber nur einen Versuch. Daher die Frage in die Runde, an die Leute, die schon mehr Erfahrungen als ich gesammelt haben (ich gehe davon aus, dass das relativ viele sind, weil ich sehr wenig Ahnung davon habe). Wenn ich mich Recht erinnere hatte ich bei meiner letzten Installation 2016 von der SD Karte gebootet und dann nur noch auf der SSD gearbeitet, damit auf der SD Karte nicht mehr geschrieben wird, und die Karte dadurch nicht gekillt wird (hab ich auch vorher schon 2x ausprobiert ). Wenn ich es jetzt richtig verstehe, braucht man heute die SD Karte gar nicht mehr, weil man auch von SSD direkt booten kann. Soweit richtigNun ist mir aber 2019 eine kostengünstige SSD (Verbatim VX450 externe MSSD 128GB) abgeraucht. Die Konfigurationsdateien sind aber glaub ich auf der SD Karte gespeichert. Demnach wäre es doch schlauer nicht von der SSD zu booten, sondern weiterhin von der SD Karte auf der auch die Konfigurationsdateien gespeichert sind (cmdline.txt, crontab, fstab, options.js, push-server.php, push-server.service, raspiBackup.conf, rc.local, volkszaehler.conf.php, vzlogger.conf). Wenn die SSD wieder kaputt gehen sollte, so hat man wenigstens die ganzen Konfigurationsdateien auf einem anderen Speichermedium. Oder sehe ich das falsch, und das direkt booten von SSD hat irgendwelche anderen Vorteile die mir momentan noch nicht bekannt sind? (Jetzt mal völlig ohne Backup gedacht, das Backup kommt natürlich auch noch am Ende der Installations-Geschichte) Lieben Gruß, Chris Von: Andreas Goetz Gesendet: Dienstag, 14. Juli 2020 21:21 An: volkszaehler.org - users Betreff: Re: [vz-users] Neuinstallation Volkszähler Hallo Chris, Du brauchst m.E. keine Ramdisk. SSD Installation hat nix mit VZ zu tun- da kannst Du jedes Tutorial verwenden das für Dich funktioniert. Deine alte DB kannst Du restoren und damit sind alle IDs und Daten wieder da. Viele Grüße, Andreas On 14. Jul 2020, at 21:13, Christian Wulffwrote: Moin, ich bin immer noch bei der Neuinstallation meines Volkszählers, die leider etwas ins Stocken geraten ist (bin leider ein völliges Linux greenhorn ohne Hintergrundwissen aber mit viel try Methodik). Hardware: RPi 3 Model B V1.2 SanDisk Ultra microSDHC 16GB Class 10 Speicherkarte Samsung SSD 860pro 256GB RaspberryPi-Erweiterung mit Schaltausgängen_Rev.1 Eigene Erweiterung mit zusätzlichem DS2482-800 2x IR-Schreib-Lesekopf mit USB-Interface UGREEN USB 3.0 Hub 4 Port Mini USB Hub Sensorliste: 1x Wasseruhr mit S0 Schnittstelle 2x Stromzähler, davon 1x mit Doppeltarif 47x DS18b20 über 1-Wire und teilweise über ESP8266 und WLAN angebunden 8x BME280 mit Temperatur, Luftfeuchtigkeit und Luftdruck über ESP8266 und WLAN angebunden 3x Lüfterdrehzahl über ESP8266 und WLAN angebunden In Summe momentan also 78 Kanäle Es ist aber noch mehr in Planung, da ist also noch nicht Schluss. Spätestens wenn ich Zeit für die CAN Anbindung an die Heizung habe, werden es etwas über 100 Kanäle am Ende sein. Aktueller Stand: -Aktuelles VZ Image installiert ✓ -Node-RED installiert ✓ -Mosquitto installiert ✓ -1-Wire läuft ✓ -SSD in Betrieb nehmen - -Alte Datenbank aus 2016-2019 wieder einspielen - Nun wollte ich die SSD in
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, der restore ist fehlerfrei durchgelaufen: sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml Dropping FK FK_87C331C781257D5D on properties Dropping FK FK_2BD88468727ACA70 on entities_in_aggregator Dropping FK FK_2BD88468DD62C21B on entities_in_aggregator Dropping FK FK_ADF3F36372F5A1AA on data Dropping FK FK_B77949FF72F5A1AA on aggregate entities: copying 0 rows (overwrite) 0 [>---] < 1 sec 6.0 MiB properties: copying 16 rows (overwrite) [] 100% < 1 sec/< 1 sec 16 rows entities_in_aggregator: copying 0 rows (overwrite) 0 [>---] < 1 sec 6.0 MiB data: copying 29250330 rows (partial copy) [] 100% 3 hrs/3 hrs 29250330 rows aggregate: skipping Creating FK FK_B77949FF72F5A1AA on aggregate pi@raspberrypi:~ $ Wenn ich nun allerdings in der DB nach UIDs suche, finde ich keine: sudo mysql -u root -h localhost volkszaehler Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 160 Server version: 10.3.22-MariaDB-0+deb10u1 Raspbian 10 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [volkszaehler]> SELECT * FROM entities; Empty set (0.008 sec) MariaDB [volkszaehler]> Ich habe bisher noch keine neuen Kanäle im WebIF angelegt, da ich vermute, dass es wieder auf das Gleiche hinausläuft. Hättest Du noch einen Tip für mich ? Beste Grüße JD. Sent: Friday, June 19, 2020 at 2:00 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Keine Ahnung wie Screen funktioniert- wenn 2 Restores parallel laufen wird es allerdings auch diesen Fehler geben... Am 19.06.2020 um 13:09 schrieb John Doe : Hallo Andreas, die Ursache des Abbruchs mit dem Fehler "duplicate entry ..." glaube ich gefunden zu haben: Ich benutze aufgrund der langen Zeit für den restore auf dem Raspi screen, konkret: sudo screen /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml Das Verlassen der Screen-Session führt reproduzierbar zu dem o.g. Fehler, dass bedeutet dass ein unmittelbar an das Verlassen anschliessendes screen -r schon keine laufende Session mehr zeigt. Ein danach angeworfenes sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml , also ohne screen, bringt reproduzierbar diesen Fehler, und zwar unabhängig von den vorher wiederhergestellten rows. Möglicherweise ist da der restore etwas fragil. Ich werde das ganze jetzt nochmal in der Konsole ohne screen anwerfen und weiter berichten. Beste Grüße JD. Sent: Friday, June 19, 2020 at 11:05 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash JD, das hatten wir alles schon! Du versuchst einen Restore in eine nicht leere Datenbank. Viele Grüße, Andreas On 19. Jun 2020, at 11:04, John Doe <john...@null.net> wrote: Hallo Andreas, der restore ist fehlgeschlagen mit "Duplicate entry for PRIMARY .." Wohin soll ich die sqlite.db3 schicken ? Ich kann das vermutlich erst heute nachmittag tun, da Sie ca. 1.6 GB hat und ich aktuell nicht genügend Bandbreite für einen Upload in akzeptabler Zeit habe. Beste Grüße JD. Sent: Friday, June 19, 2020 at 10:31 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash V.a. zeig bitte den Api Aufruf. Ich will sehen ob Deine Sicherung überhaupt „public“ Kanäle enthält! Am 19.06.2020 um 10:30 schrieb John Doe <john...@null.net>: Hallo Andreas, aktuell lasse ich nochmal einen restore laufen. Danach schaue ich mir mittels deines Tips die UIDs aus der Sicherung an und trage diese dann in die vzlogger.conf ein. Ich werde keine neuen Kanäle anlegen und ggfs. Deinen Tip mit dem Abo über die UIDs anwenden. Ich melde mich in ca. zwei Stunden wieder. Bis hierhin wie immer besten Dank und Grüße JD. Sent: Friday, June 19, 2020 at 10:01 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Ergänzung: Am 19.06.2020 um 09:48 schrieb Andreas Goetz <cpui...@gmail.com>: Noch eine Idee: gibt doch mal- für Deine Installation- folgenden Apiaufruf im Browser ein: https://demo.volkszaehler.org/middleware.php/channel.json Evtl middleware
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, die Ursache des Abbruchs mit dem Fehler "duplicate entry ..." glaube ich gefunden zu haben: Ich benutze aufgrund der langen Zeit für den restore auf dem Raspi screen, konkret: sudo screen /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml Das Verlassen der Screen-Session führt reproduzierbar zu dem o.g. Fehler, dass bedeutet dass ein unmittelbar an das Verlassen anschliessendes screen -r schon keine laufende Session mehr zeigt. Ein danach angeworfenes sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml , also ohne screen, bringt reproduzierbar diesen Fehler, und zwar unabhängig von den vorher wiederhergestellten rows. Möglicherweise ist da der restore etwas fragil. Ich werde das ganze jetzt nochmal in der Konsole ohne screen anwerfen und weiter berichten. Beste Grüße JD. Sent: Friday, June 19, 2020 at 11:05 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash JD, das hatten wir alles schon! Du versuchst einen Restore in eine nicht leere Datenbank. Viele Grüße, Andreas On 19. Jun 2020, at 11:04, John Doe <john...@null.net> wrote: Hallo Andreas, der restore ist fehlgeschlagen mit "Duplicate entry for PRIMARY .." Wohin soll ich die sqlite.db3 schicken ? Ich kann das vermutlich erst heute nachmittag tun, da Sie ca. 1.6 GB hat und ich aktuell nicht genügend Bandbreite für einen Upload in akzeptabler Zeit habe. Beste Grüße JD. Sent: Friday, June 19, 2020 at 10:31 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash V.a. zeig bitte den Api Aufruf. Ich will sehen ob Deine Sicherung überhaupt „public“ Kanäle enthält! Am 19.06.2020 um 10:30 schrieb John Doe <john...@null.net>: Hallo Andreas, aktuell lasse ich nochmal einen restore laufen. Danach schaue ich mir mittels deines Tips die UIDs aus der Sicherung an und trage diese dann in die vzlogger.conf ein. Ich werde keine neuen Kanäle anlegen und ggfs. Deinen Tip mit dem Abo über die UIDs anwenden. Ich melde mich in ca. zwei Stunden wieder. Bis hierhin wie immer besten Dank und Grüße JD. Sent: Friday, June 19, 2020 at 10:01 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Ergänzung: Am 19.06.2020 um 09:48 schrieb Andreas Goetz <cpui...@gmail.com>: Noch eine Idee: gibt doch mal- für Deine Installation- folgenden Apiaufruf im Browser ein: https://demo.volkszaehler.org/middleware.php/channel.json Evtl middleware.php durch „api“ ersetzen. Da siehst Du schonmal alle „public“ Kanäle. Oder mail mir mal Deine sqlite.db, dann schau ich was da überhaupt drin ist ... Und danach bitte auch nochmal https://demo.volkszaehler.org/middleware.php/channel/.json Mit der UUID aus der ursprünglichen vzlogger.conf. Viele Grüße, Andreas Am 19.06.2020 um 09:34 schrieb John Doe <john...@null.net>: Hallo zusammen, hallo Andreas, nachdem ich nun zum zweiten Mal eine DB-Sicherung per dbcopy zurück gespielt habe, hat sich das exakt gleiche Problem ergeben. Daher hätte ich nun nochmal eine prinzipielle Frage zum Vorgang: Ich habe eine Kopie der von mir vor der Sicherung benutzten vzlogger.conf und natürlich die gesicherte sqlite.db3. Nachdem ich die Sicherung zurück gespielt habe, sind wieder alle abonnierbaren Kanäle weg. Wenn ich neue öffentliche Kanäle anlege und deren UIDs in die vzlogger.conf eintrage, sehe ich nur die aktuellen Messwerte. Nun meine Frage: Gibt es eine Möglichkeit, die UIDs aus der DB-Sicherung zu ermitteln und diese dann in die vzlogger.conf einzutragen ? Und warum sind trotz der passenden Paarung aus sqlite.db3 und vzlogger.conf jedes Mal alle angelegten Kanäle weg ? Beste Grüße JD. Sent: Wednesday, June 17, 2020 at 11:09 AM From: "John Doe" <john...@null.net> To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Andreas, ja, ich habe die dbcopy.yaml, die ich zur Sicherung vom Raspi zum NAS benutzt habe, noch. Ich bin mir vollständig sicher, dass ich vor Beginn der Sicherung source und target korrekt gesetzt bzw. gegenüber dem vorherigen restore getauscht hatte, und so steht es auch in der dbcopy.yaml. Glücklicherweise habe ich noch die ursprüngliche Sicherung, mit der ich den restore unter 1. angestossen hatte. Ich werde das nochmal durch exerzieren und wieder berichten. Beste Grüße JD. Sent: Tuesday, June 16, 2020 at 9:36 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users"
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, der restore ist fehlgeschlagen mit "Duplicate entry for PRIMARY .." Wohin soll ich die sqlite.db3 schicken ? Ich kann das vermutlich erst heute nachmittag tun, da Sie ca. 1.6 GB hat und ich aktuell nicht genügend Bandbreite für einen Upload in akzeptabler Zeit habe. Beste Grüße JD. Sent: Friday, June 19, 2020 at 10:31 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash V.a. zeig bitte den Api Aufruf. Ich will sehen ob Deine Sicherung überhaupt „public“ Kanäle enthält! Am 19.06.2020 um 10:30 schrieb John Doe : Hallo Andreas, aktuell lasse ich nochmal einen restore laufen. Danach schaue ich mir mittels deines Tips die UIDs aus der Sicherung an und trage diese dann in die vzlogger.conf ein. Ich werde keine neuen Kanäle anlegen und ggfs. Deinen Tip mit dem Abo über die UIDs anwenden. Ich melde mich in ca. zwei Stunden wieder. Bis hierhin wie immer besten Dank und Grüße JD. Sent: Friday, June 19, 2020 at 10:01 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Ergänzung: Am 19.06.2020 um 09:48 schrieb Andreas Goetz : Noch eine Idee: gibt doch mal- für Deine Installation- folgenden Apiaufruf im Browser ein: https://demo.volkszaehler.org/middleware.php/channel.json Evtl middleware.php durch „api“ ersetzen. Da siehst Du schonmal alle „public“ Kanäle. Oder mail mir mal Deine sqlite.db, dann schau ich was da überhaupt drin ist ... Und danach bitte auch nochmal https://demo.volkszaehler.org/middleware.php/channel/.json Mit der UUID aus der ursprünglichen vzlogger.conf. Viele Grüße, Andreas Am 19.06.2020 um 09:34 schrieb John Doe : Hallo zusammen, hallo Andreas, nachdem ich nun zum zweiten Mal eine DB-Sicherung per dbcopy zurück gespielt habe, hat sich das exakt gleiche Problem ergeben. Daher hätte ich nun nochmal eine prinzipielle Frage zum Vorgang: Ich habe eine Kopie der von mir vor der Sicherung benutzten vzlogger.conf und natürlich die gesicherte sqlite.db3. Nachdem ich die Sicherung zurück gespielt habe, sind wieder alle abonnierbaren Kanäle weg. Wenn ich neue öffentliche Kanäle anlege und deren UIDs in die vzlogger.conf eintrage, sehe ich nur die aktuellen Messwerte. Nun meine Frage: Gibt es eine Möglichkeit, die UIDs aus der DB-Sicherung zu ermitteln und diese dann in die vzlogger.conf einzutragen ? Und warum sind trotz der passenden Paarung aus sqlite.db3 und vzlogger.conf jedes Mal alle angelegten Kanäle weg ? Beste Grüße JD. Sent: Wednesday, June 17, 2020 at 11:09 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Andreas, ja, ich habe die dbcopy.yaml, die ich zur Sicherung vom Raspi zum NAS benutzt habe, noch. Ich bin mir vollständig sicher, dass ich vor Beginn der Sicherung source und target korrekt gesetzt bzw. gegenüber dem vorherigen restore getauscht hatte, und so steht es auch in der dbcopy.yaml. Glücklicherweise habe ich noch die ursprüngliche Sicherung, mit der ich den restore unter 1. angestossen hatte. Ich werde das nochmal durch exerzieren und wieder berichten. Beste Grüße JD. Sent: Tuesday, June 16, 2020 at 9:36 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo JD! On 15. Jun 2020, at 19:41, John Doe <john...@null.net> wrote: Hallo Andreas, passiert ist das Folgende (von der Dir das Meiste ja schon bekannt ist): 1. Ich habe mittels dbcopy nach wiki (https://wiki.volkszaehler.org/software/tools/dbcopy) eine sqlite.db3 nach einem Kartencrash zurück gespielt. 2. Nachdem ich in der Folge im WebIF keine Daten sah, habe ich neue (öffentliche) Kanäle angelegt und die UIDs in die vzlogger.conf eingetragen, Ergebnis: Zumindest kame wieder Werte an. 3. Nach Deinem Hieinweis, dass nach einem Restore die "alten" UIDs (aus der Sicherung) wieder aktuell sind, habe ich wiederum diese "alten" in die vzlogger.conf "zurück" eingetragen. Danach lief alles wie gewünscht, die alten Daten waren da und es kamen auch aktuelle Werte an. Bis hierhin alles super. 4. Ich habe ein Directory von einem NAS auf den Raspi per CIFS gemountet und da hinein wie gehabt eine Sicherung per dbcopy angeworfen, welche problemlos durchgelaufen ist. 5. Danach habe ich nochmal das WebIF angeguckt und alle Daten waren weg, sowohl die Daten aus dem Restore als auch jene, welche danach dazu gekommen waren. Kanäle zum Abonnieren existierten nicht mehr. Dafür gibts nur eine Erklärung die mir einfällt: Du hast *noch* einen Restore gemacht und zwar aus einer leeren DB auf Deinem NAS?! Bist Du zu 100% sicher dass die Konfiguration richtig (und v.a. anders!) war als beim ersten Restore
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, aktuell lasse ich nochmal einen restore laufen. Danach schaue ich mir mittels deines Tips die UIDs aus der Sicherung an und trage diese dann in die vzlogger.conf ein. Ich werde keine neuen Kanäle anlegen und ggfs. Deinen Tip mit dem Abo über die UIDs anwenden. Ich melde mich in ca. zwei Stunden wieder. Bis hierhin wie immer besten Dank und Grüße JD. Sent: Friday, June 19, 2020 at 10:01 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Ergänzung: Am 19.06.2020 um 09:48 schrieb Andreas Goetz : Noch eine Idee: gibt doch mal- für Deine Installation- folgenden Apiaufruf im Browser ein: https://demo.volkszaehler.org/middleware.php/channel.json Evtl middleware.php durch „api“ ersetzen. Da siehst Du schonmal alle „public“ Kanäle. Oder mail mir mal Deine sqlite.db, dann schau ich was da überhaupt drin ist ... Und danach bitte auch nochmal https://demo.volkszaehler.org/middleware.php/channel/.json Mit der UUID aus der ursprünglichen vzlogger.conf. Viele Grüße, Andreas Am 19.06.2020 um 09:34 schrieb John Doe : Hallo zusammen, hallo Andreas, nachdem ich nun zum zweiten Mal eine DB-Sicherung per dbcopy zurück gespielt habe, hat sich das exakt gleiche Problem ergeben. Daher hätte ich nun nochmal eine prinzipielle Frage zum Vorgang: Ich habe eine Kopie der von mir vor der Sicherung benutzten vzlogger.conf und natürlich die gesicherte sqlite.db3. Nachdem ich die Sicherung zurück gespielt habe, sind wieder alle abonnierbaren Kanäle weg. Wenn ich neue öffentliche Kanäle anlege und deren UIDs in die vzlogger.conf eintrage, sehe ich nur die aktuellen Messwerte. Nun meine Frage: Gibt es eine Möglichkeit, die UIDs aus der DB-Sicherung zu ermitteln und diese dann in die vzlogger.conf einzutragen ? Und warum sind trotz der passenden Paarung aus sqlite.db3 und vzlogger.conf jedes Mal alle angelegten Kanäle weg ? Beste Grüße JD. Sent: Wednesday, June 17, 2020 at 11:09 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Andreas, ja, ich habe die dbcopy.yaml, die ich zur Sicherung vom Raspi zum NAS benutzt habe, noch. Ich bin mir vollständig sicher, dass ich vor Beginn der Sicherung source und target korrekt gesetzt bzw. gegenüber dem vorherigen restore getauscht hatte, und so steht es auch in der dbcopy.yaml. Glücklicherweise habe ich noch die ursprüngliche Sicherung, mit der ich den restore unter 1. angestossen hatte. Ich werde das nochmal durch exerzieren und wieder berichten. Beste Grüße JD. Sent: Tuesday, June 16, 2020 at 9:36 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo JD! On 15. Jun 2020, at 19:41, John Doe <john...@null.net> wrote: Hallo Andreas, passiert ist das Folgende (von der Dir das Meiste ja schon bekannt ist): 1. Ich habe mittels dbcopy nach wiki (https://wiki.volkszaehler.org/software/tools/dbcopy) eine sqlite.db3 nach einem Kartencrash zurück gespielt. 2. Nachdem ich in der Folge im WebIF keine Daten sah, habe ich neue (öffentliche) Kanäle angelegt und die UIDs in die vzlogger.conf eingetragen, Ergebnis: Zumindest kame wieder Werte an. 3. Nach Deinem Hieinweis, dass nach einem Restore die "alten" UIDs (aus der Sicherung) wieder aktuell sind, habe ich wiederum diese "alten" in die vzlogger.conf "zurück" eingetragen. Danach lief alles wie gewünscht, die alten Daten waren da und es kamen auch aktuelle Werte an. Bis hierhin alles super. 4. Ich habe ein Directory von einem NAS auf den Raspi per CIFS gemountet und da hinein wie gehabt eine Sicherung per dbcopy angeworfen, welche problemlos durchgelaufen ist. 5. Danach habe ich nochmal das WebIF angeguckt und alle Daten waren weg, sowohl die Daten aus dem Restore als auch jene, welche danach dazu gekommen waren. Kanäle zum Abonnieren existierten nicht mehr. Dafür gibts nur eine Erklärung die mir einfällt: Du hast *noch* einen Restore gemacht und zwar aus einer leeren DB auf Deinem NAS?! Bist Du zu 100% sicher dass die Konfiguration richtig (und v.a. anders!) war als beim ersten Restore? Hast du sie noch? Dir ist klar, dass Du für die Aktion die “Richtung” wieder von Raspi nach NAS umdrehen musst und der Raspi jetzt die Quelle ist während beim Restore SQlite die Quelle war? Auch hier habe ich wiederum neue Kanäle angelegt und deren UIDs in die vzlogger.conf eingetragen, seitdem laufen zumindest wieder aktuelle Daten ein. Alle "alten" Daten (aus dem restore + ca. drei Tage) bleiben verschwunden. Ja klar. Du hast mit einer leeren DB neu angefangen. Das hättest Du einfacher haben können :O Jetzt liegst bei Dir- Fehler aus 5 verstehen und nochmal 1-3 machen? Viele Grüße, Andreas
Re: [vz-users] Bevorstehender Kartencrash
Hallo Anderas, besten Dank für Deine schnelle Antwort. In der Tat wundert mich das Ganze auch, daher beschreibe ich alles nochmal kurz: 1. Nach dem letzten restore waren alle Daten (gesicherte und aktuell laufende minus der Ausfall durch den restore) wieder da. 2. Ich habe wie gehabt mit einer dbcopy.yaml, in der die sqlite.db3 das target ist, eine Sicherung vom Ganzen gemacht. Ein Aufruf der WebIFs unmittelbar danach erbrachte keinerlei öffentliche Kanäle, die ich abonnieren hätte können. 3. Beim erneuten restore aus der jetzt zweiten Sicherung ("erste DB" plus ca. zwei Tage) bin ich wie folgt vorgegangen: - sudo systemctl stop vzlogger - sudo systemctl stop cron - sudo mysql -u root -h localhost volkszaehler - DROP DATABASE volkszaehler; - CREATE DATABASE volkszaehler; - Beim anschliessenden dbyopy copy -c /etc/dbcopy.yaml meckerte das Script über ein fehlendes Schema, also - sudo volkszaehler.org/bin/doctrine orm:schema-tool:create - sudo volkszaehler.org/bin/doctrine orm:schema-tool:create --dump-sql Danach lief der restore durch. Im Anschluss danach wieder das gleiche Bild: Keine abonnierbaren Kanäle. Als ich zwei neue (es gibt zwei Leseköpfe und zwei Zaehler) angelegt habe, gab es beim ersten Versuch eine Fehlermeldung a la "duplicate ... name ... bei INSERT", ich vermute, dass sich das auf den Namen des Kanals bezieht. Beim nochmaligen Versuch, einen öffentlichen Kanal anzulegen, klappte alles mit dem Effekt, dass ich wieder "nur" aktuelle Messwerte sehe. Aktuell (d.h. für die aktuell aquirierten Werte) zeit Dein Tip: MariaDB [volkszaehler]> SELECT * FROM entities; ++--++-+ | id | uuid | type | class | ++--++-+ | 3 | 0431d6e0-b1f6-11ea-85c7-55017c264e5a | electric meter | channel | | 4 | 1ebedad0-b1f6-11ea-84a7-e17ea0029fb1 | electric meter | channel | ++--++-+ 2 rows in set (0.001 sec) Sollte ich ggfs. den letzten restore nochmal machen und dann in die vzlogger.conf die UIDs aus der DB wie oben ernittelt eintragen, also keine neuen anlegen ? Beste Grüsse JD. Sent: Friday, June 19, 2020 at 9:42 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Moin JD, Du machst irgendetwas *massiv* merkwürdiges. Am 19.06.2020 um 09:34 schrieb John Doe : Hallo zusammen, hallo Andreas, nachdem ich nun zum zweiten Mal eine DB-Sicherung per dbcopy zurück gespielt habe, hat sich das exakt gleiche Problem ergeben. Daher hätte ich nun nochmal eine prinzipielle Frage zum Vorgang: Ich habe eine Kopie der von mir vor der Sicherung benutzten vzlogger.conf und natürlich die gesicherte sqlite.db3. Nachdem ich die Sicherung zurück gespielt habe, sind wieder alle abonnierbaren Kanäle weg. Wir waren uns zuletzt einig, dass Du alle Daten wieder hattest. Es war also nichts *weg*! Mir ist völlig unklar was Du meinst da wir über diese Stelle schonmal hinaus waren? Was meinst Zu mit „alle Kanäle weg“? Dass sie im Browser nicht mehr als „public“ angezeigt werden? Screenshot? Kennst Du die uuid der Kanäle und könntest sie über die uuid abonnieren? Screenshot des Ergebnisses? Wenn ich neue öffentliche Kanäle anlege und deren UIDs in die vzlogger.conf eintrage, sehe ich nur die aktuellen Messwerte. Ja natürlich. Anderer Kanal, andere Daten. Nun meine Frage: Gibt es eine Möglichkeit, die UIDs aus der DB-Sicherung zu ermitteln und diese dann in die vzlogger.conf einzutragen ? Ja klar, es ist ja nur eine Datenbank. Du kannst mit SQL, auch auf der Kommandozeile, einfach alle „entities“ selektieren. Ohne am Rechner zu sitzen kann ich das nicht ausprobieren, aber so in der Art von „SELECT * FROM entities“. Dazu stehen dann in „properties“ alle relevanten Daten die per JOIN dazu gemischt werden können. Und warum sind trotz der passenden Paarung aus sqlite.db3 und vzlogger.conf jedes Mal alle angelegten Kanäle weg ? Wie gesagt. Da ist ziemlich sicher nichts weg, zumal im letzten Anlauf in dem Schritt auch nichts weg war. Ich weiss aber auch nicht wie ich Dir hier helfen soll :/ Viele Grüße, Andreas Beste Grüße JD. Sent: Wednesday, June 17, 2020 at 11:09 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Andreas, ja, ich habe die dbcopy.yaml, die ich zur Sicherung vom Raspi zum NAS benutzt habe, noch. Ich bin mir vollständig sicher, dass ich vor Beginn der Sicherung source und target korrekt gesetzt bzw. gegenüber dem vorherigen restore getauscht hatte, und so steht es auch in der dbcopy.yaml. Glücklicherweise habe ich noch die ursprüngliche Sic
Re: [vz-users] Bevorstehender Kartencrash
Hallo zusammen, hallo Andreas, nachdem ich nun zum zweiten Mal eine DB-Sicherung per dbcopy zurück gespielt habe, hat sich das exakt gleiche Problem ergeben. Daher hätte ich nun nochmal eine prinzipielle Frage zum Vorgang: Ich habe eine Kopie der von mir vor der Sicherung benutzten vzlogger.conf und natürlich die gesicherte sqlite.db3. Nachdem ich die Sicherung zurück gespielt habe, sind wieder alle abonnierbaren Kanäle weg. Wenn ich neue öffentliche Kanäle anlege und deren UIDs in die vzlogger.conf eintrage, sehe ich nur die aktuellen Messwerte. Nun meine Frage: Gibt es eine Möglichkeit, die UIDs aus der DB-Sicherung zu ermitteln und diese dann in die vzlogger.conf einzutragen ? Und warum sind trotz der passenden Paarung aus sqlite.db3 und vzlogger.conf jedes Mal alle angelegten Kanäle weg ? Beste Grüße JD. Sent: Wednesday, June 17, 2020 at 11:09 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Andreas, ja, ich habe die dbcopy.yaml, die ich zur Sicherung vom Raspi zum NAS benutzt habe, noch. Ich bin mir vollständig sicher, dass ich vor Beginn der Sicherung source und target korrekt gesetzt bzw. gegenüber dem vorherigen restore getauscht hatte, und so steht es auch in der dbcopy.yaml. Glücklicherweise habe ich noch die ursprüngliche Sicherung, mit der ich den restore unter 1. angestossen hatte. Ich werde das nochmal durch exerzieren und wieder berichten. Beste Grüße JD. Sent: Tuesday, June 16, 2020 at 9:36 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo JD! On 15. Jun 2020, at 19:41, John Doe <john...@null.net> wrote: Hallo Andreas, passiert ist das Folgende (von der Dir das Meiste ja schon bekannt ist): 1. Ich habe mittels dbcopy nach wiki (https://wiki.volkszaehler.org/software/tools/dbcopy) eine sqlite.db3 nach einem Kartencrash zurück gespielt. 2. Nachdem ich in der Folge im WebIF keine Daten sah, habe ich neue (öffentliche) Kanäle angelegt und die UIDs in die vzlogger.conf eingetragen, Ergebnis: Zumindest kame wieder Werte an. 3. Nach Deinem Hieinweis, dass nach einem Restore die "alten" UIDs (aus der Sicherung) wieder aktuell sind, habe ich wiederum diese "alten" in die vzlogger.conf "zurück" eingetragen. Danach lief alles wie gewünscht, die alten Daten waren da und es kamen auch aktuelle Werte an. Bis hierhin alles super. 4. Ich habe ein Directory von einem NAS auf den Raspi per CIFS gemountet und da hinein wie gehabt eine Sicherung per dbcopy angeworfen, welche problemlos durchgelaufen ist. 5. Danach habe ich nochmal das WebIF angeguckt und alle Daten waren weg, sowohl die Daten aus dem Restore als auch jene, welche danach dazu gekommen waren. Kanäle zum Abonnieren existierten nicht mehr. Dafür gibts nur eine Erklärung die mir einfällt: Du hast *noch* einen Restore gemacht und zwar aus einer leeren DB auf Deinem NAS?! Bist Du zu 100% sicher dass die Konfiguration richtig (und v.a. anders!) war als beim ersten Restore? Hast du sie noch? Dir ist klar, dass Du für die Aktion die “Richtung” wieder von Raspi nach NAS umdrehen musst und der Raspi jetzt die Quelle ist während beim Restore SQlite die Quelle war? Auch hier habe ich wiederum neue Kanäle angelegt und deren UIDs in die vzlogger.conf eingetragen, seitdem laufen zumindest wieder aktuelle Daten ein. Alle "alten" Daten (aus dem restore + ca. drei Tage) bleiben verschwunden. Ja klar. Du hast mit einer leeren DB neu angefangen. Das hättest Du einfacher haben können :O Jetzt liegst bei Dir- Fehler aus 5 verstehen und nochmal 1-3 machen? Viele Grüße, Andreas Beste Grüße Ralf. Sent: Monday, June 15, 2020 at 4:08 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Ich nochmal... Am 15.06.2020 um 10:55 schrieb John Doe <john...@null.net>: Hallo Daniel, unmittelbar nach dem Lauf von dbcopy gab es leider keine Kanäle mehr, die ich abonnieren konnte - die Auswahlbox war leer. Dbcopy löscht die Zieltabelle mit den Metadaten und stellt sie aus dem Backup wieder her. Entweder hast Du genau in der Sekunde geschaut als sie weg waren oder Du hast aus einem leeren Backup wieder hergestellt? Deshlab die Frage nach Deinen Kopiereinstellungen. Daher hatte ich die Neuanlage der UIDs versucht. Nun läuft zwar der vzlogger wieder, aber meine "alten" Werte sind trotzdem weg. Deine Daten waren ja zwischendurch schonmal wieder da. Zur Not Vorgang von vorne wiederholen. Natürlich könnte ich jetzt wieder das alte Backup nochmal zurückspielen, aber auf Dauer kann das ja nicht gewollt sein ...(?) Nach dem Restore solltest Du nicht
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, ja, ich habe die dbcopy.yaml, die ich zur Sicherung vom Raspi zum NAS benutzt habe, noch. Ich bin mir vollständig sicher, dass ich vor Beginn der Sicherung source und target korrekt gesetzt bzw. gegenüber dem vorherigen restore getauscht hatte, und so steht es auch in der dbcopy.yaml. Glücklicherweise habe ich noch die ursprüngliche Sicherung, mit der ich den restore unter 1. angestossen hatte. Ich werde das nochmal durch exerzieren und wieder berichten. Beste Grüße JD. Sent: Tuesday, June 16, 2020 at 9:36 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo JD! On 15. Jun 2020, at 19:41, John Doe <john...@null.net> wrote: Hallo Andreas, passiert ist das Folgende (von der Dir das Meiste ja schon bekannt ist): 1. Ich habe mittels dbcopy nach wiki (https://wiki.volkszaehler.org/software/tools/dbcopy) eine sqlite.db3 nach einem Kartencrash zurück gespielt. 2. Nachdem ich in der Folge im WebIF keine Daten sah, habe ich neue (öffentliche) Kanäle angelegt und die UIDs in die vzlogger.conf eingetragen, Ergebnis: Zumindest kame wieder Werte an. 3. Nach Deinem Hieinweis, dass nach einem Restore die "alten" UIDs (aus der Sicherung) wieder aktuell sind, habe ich wiederum diese "alten" in die vzlogger.conf "zurück" eingetragen. Danach lief alles wie gewünscht, die alten Daten waren da und es kamen auch aktuelle Werte an. Bis hierhin alles super. 4. Ich habe ein Directory von einem NAS auf den Raspi per CIFS gemountet und da hinein wie gehabt eine Sicherung per dbcopy angeworfen, welche problemlos durchgelaufen ist. 5. Danach habe ich nochmal das WebIF angeguckt und alle Daten waren weg, sowohl die Daten aus dem Restore als auch jene, welche danach dazu gekommen waren. Kanäle zum Abonnieren existierten nicht mehr. Dafür gibts nur eine Erklärung die mir einfällt: Du hast *noch* einen Restore gemacht und zwar aus einer leeren DB auf Deinem NAS?! Bist Du zu 100% sicher dass die Konfiguration richtig (und v.a. anders!) war als beim ersten Restore? Hast du sie noch? Dir ist klar, dass Du für die Aktion die “Richtung” wieder von Raspi nach NAS umdrehen musst und der Raspi jetzt die Quelle ist während beim Restore SQlite die Quelle war? Auch hier habe ich wiederum neue Kanäle angelegt und deren UIDs in die vzlogger.conf eingetragen, seitdem laufen zumindest wieder aktuelle Daten ein. Alle "alten" Daten (aus dem restore + ca. drei Tage) bleiben verschwunden. Ja klar. Du hast mit einer leeren DB neu angefangen. Das hättest Du einfacher haben können :O Jetzt liegst bei Dir- Fehler aus 5 verstehen und nochmal 1-3 machen? Viele Grüße, Andreas Beste Grüße Ralf. Sent: Monday, June 15, 2020 at 4:08 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Ich nochmal... Am 15.06.2020 um 10:55 schrieb John Doe <john...@null.net>: Hallo Daniel, unmittelbar nach dem Lauf von dbcopy gab es leider keine Kanäle mehr, die ich abonnieren konnte - die Auswahlbox war leer. Dbcopy löscht die Zieltabelle mit den Metadaten und stellt sie aus dem Backup wieder her. Entweder hast Du genau in der Sekunde geschaut als sie weg waren oder Du hast aus einem leeren Backup wieder hergestellt? Deshlab die Frage nach Deinen Kopiereinstellungen. Daher hatte ich die Neuanlage der UIDs versucht. Nun läuft zwar der vzlogger wieder, aber meine "alten" Werte sind trotzdem weg. Deine Daten waren ja zwischendurch schonmal wieder da. Zur Not Vorgang von vorne wiederholen. Natürlich könnte ich jetzt wieder das alte Backup nochmal zurückspielen, aber auf Dauer kann das ja nicht gewollt sein ...(?) Nach dem Restore solltest Du nicht den gleichen Fehler wieder machen- leider wird aus Deiner Beschreibung nicht klar was da wirklich passiert ist... Viele Grüße, Andreas Beste Grüße JD. Sent: Monday, June 15, 2020 at 9:58 AM From: "Daniel Lauckner" <v...@jahp.de> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo, am Montag, 15. Juni 2020 um 09:45 hat John Doe geschrieben: > Als ich danach wieder mein Web-Frontend aufgerufen habe, waren alle > erstellten und zuvor existierenden Kanäle weg. Klingt als müsstest du einfach nur die Kanäle neu abonnieren. mfg Daniel
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, passiert ist das Folgende (von der Dir das Meiste ja schon bekannt ist): 1. Ich habe mittels dbcopy nach wiki (https://wiki.volkszaehler.org/software/tools/dbcopy) eine sqlite.db3 nach einem Kartencrash zurück gespielt. 2. Nachdem ich in der Folge im WebIF keine Daten sah, habe ich neue (öffentliche) Kanäle angelegt und die UIDs in die vzlogger.conf eingetragen, Ergebnis: Zumindest kame wieder Werte an. 3. Nach Deinem Hieinweis, dass nach einem Restore die "alten" UIDs (aus der Sicherung) wieder aktuell sind, habe ich wiederum diese "alten" in die vzlogger.conf "zurück" eingetragen. Danach lief alles wie gewünscht, die alten Daten waren da und es kamen auch aktuelle Werte an. 4. Ich habe ein Directory von einem NAS auf den Raspi per CIFS gemountet und da hinein wie gehabt eine Sicherung per dbcopy angeworfen, welche problemlos durchgelaufen ist. 5. Danach habe ich nochmal das WebIF angeguckt und alle Daten waren weg, sowohl die Daten aus dem Restore als auch jene, welche danach dazu gekommen waren. Kanäle zum Abonnieren existierten nicht mehr. Auch hier habe ich wiederum neue Kanäle angelegt und deren UIDs in die vzlogger.conf eingetragen, seitdem laufen zumindest wieder aktuelle Daten ein. Alle "alten" Daten (aus dem restore + ca. drei Tage) bleiben verschwunden. Beste Grüße Ralf. Sent: Monday, June 15, 2020 at 4:08 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Ich nochmal... Am 15.06.2020 um 10:55 schrieb John Doe : Hallo Daniel, unmittelbar nach dem Lauf von dbcopy gab es leider keine Kanäle mehr, die ich abonnieren konnte - die Auswahlbox war leer. Dbcopy löscht die Zieltabelle mit den Metadaten und stellt sie aus dem Backup wieder her. Entweder hast Du genau in der Sekunde geschaut als sie weg waren oder Du hast aus einem leeren Backup wieder hergestellt? Deshlab die Frage nach Deinen Kopiereinstellungen. Daher hatte ich die Neuanlage der UIDs versucht. Nun läuft zwar der vzlogger wieder, aber meine "alten" Werte sind trotzdem weg. Deine Daten waren ja zwischendurch schonmal wieder da. Zur Not Vorgang von vorne wiederholen. Natürlich könnte ich jetzt wieder das alte Backup nochmal zurückspielen, aber auf Dauer kann das ja nicht gewollt sein ...(?) Nach dem Restore solltest Du nicht den gleichen Fehler wieder machen- leider wird aus Deiner Beschreibung nicht klar was da wirklich passiert ist... Viele Grüße, Andreas Beste Grüße JD. Sent: Monday, June 15, 2020 at 9:58 AM From: "Daniel Lauckner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo, am Montag, 15. Juni 2020 um 09:45 hat John Doe geschrieben: > Als ich danach wieder mein Web-Frontend aufgerufen habe, waren alle > erstellten und zuvor existierenden Kanäle weg. Klingt als müsstest du einfach nur die Kanäle neu abonnieren. mfg Daniel
Re: [vz-users] Bevorstehender Kartencrash
Hallo Daniel, unmittelbar nach dem Lauf von dbcopy gab es leider keine Kanäle mehr, die ich abonnieren konnte - die Auswahlbox war leer. Daher hatte ich die Neuanlage der UIDs versucht. Nun läuft zwar der vzlogger wieder, aber meine "alten" Werte sind trotzdem weg. Natürlich könnte ich jetzt wieder das alte Backup nochmal zurückspielen, aber auf Dauer kann das ja nicht gewollt sein ...(?) Beste Grüße JD. Sent: Monday, June 15, 2020 at 9:58 AM From: "Daniel Lauckner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo, am Montag, 15. Juni 2020 um 09:45 hat John Doe geschrieben: > Als ich danach wieder mein Web-Frontend aufgerufen habe, waren alle > erstellten und zuvor existierenden Kanäle weg. Klingt als müsstest du einfach nur die Kanäle neu abonnieren. mfg Daniel
Re: [vz-users] Bevorstehender Kartencrash
Hallo zusammen, hallo Andreas, jetzt hat sich bei mir im Nachgang doch noch ein Problemchen ergeben. Ich habe, nachdem ich die gesichterte Datenbank zurück gespielt hatte, mittels dbcopy wiederum ein Backup auf mein NAS via CIFS gemacht. Dieses ist fehlerfrei zu Ende gelaufen. Als ich danach wieder mein Web-Frontend aufgerufen habe, waren alle erstellten und zuvor existierenden Kanäle weg. Daher wollte ich den Weg über die Neuanlage von öffentlichen Kanälen gehen und deren UIDs anschliessend wieder in die vzlogger.conf eintragen. Wenn ich dies versuche, bekam ich beim ersten Mal eine Fehlermeldung im Web-IF, die ich leider nicht mehr ganz zusammen bekomme, sie lautete sinngemäß: "Error ... insert into ..." Danach gelang mir das Erstellen des öffentlichen Kanals, aber auch nach dem Eintragen der öffentlichen UID sind meine Kanäle weg. Hat noch jemand eine Idee, was da schiefgelaufen sein könnte ? Beste Grüße JD. Sent: Thursday, June 11, 2020 at 12:03 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hi JD, die Ursache hast Du gerade selbst identifiziert- vzlogger. Es wird nur funktionieren wenn Du es machst wie vorgeschlagen: - cron aus - vzlogger aus - aggregate laufen lassen anderenfalls wird es vmtl ewig zäh bleiben weil die aggregation niemals zu Ende läuft (lock Problem) und die Prozesse aus dem Cron auch noch anfangen sich aufzustapeln bis das System zum Stillstand kommt. Vielleicht können wir das später im Code besser lösen so dass sich aggregate das “LOCK TABLE” selber holt, das Ergebnis wäre allerdings das Gleiche- ab dem Zeitpunkt bleibt die Datenbank für andere Prozesse gesperrt. Viele Grüße, Andreas On 11. Jun 2020, at 11:52, John Doe <john...@null.net> wrote: Hallo Andreas, Deinen Tip habe ich versucht, anhand des wikis (https://wiki.volkszaehler.org/howto/datenmengen) umzusetzen mit php /var/www/volkszaehler.org/bin/aggregate run -m full -l day -l hour -l minute , das stiess relativ bald wieder an das lock-Problem. Daraufhin habe ich den cron zwischenzeitlich stillgelegt. Allerdings läuft/lief der vzlogger ja auch noch, deshalb habe ich den wiki-Tip mit diesen drei Zeilen (auch aus dem wiki) im crontab umzusetzen: */10 * * * * php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null 1 * * * * php /var/www/volkszaehler.org/bin/aggregate run -m delta -l hour >/dev/null 0 1 * * * php /var/www/volkszaehler.org/bin/aggregate run -m delta -l day >/dev/null Danach habe ich den cron natürlich wieder eingeschaltet. Das Ergebnis ist in allen Fällen negativ, d.h. es bleibt zäh. Gibt es noch etwas anderes, was ich an der Web-Frontendperformance optimieren könnte ? Wie ist das denn im originären Image eingestellt ? Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 6:52 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Ja: Aggregationstabelle wieder füllen (bin/aggregate) und dann den cronjob wieder einschalten der regelmässig die Deltas aktualisiert. Du hattest cron komplett deaktiviert glaube ich? Viele Grüße, Andreas Am 10.06.2020 um 18:49 schrieb John Doe <john...@null.net>: Hallo Andreas, noch eine kurze Frage: Seit dem Restore reagiert das Web-Frontend unglaublich "zäh", das Wechseln zwischen Woche, Monat, Jahr etc. kommt nahezu immer mit "Gateway timeout" raus. Gibt 's da noch etwas zu Optimieren ? Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 6:32 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hi JD, On 10. Jun 2020, at 18:29, John Doe <john...@null.net> wrote: Hallo Andreas, nach dem Neuaufsetzten hatte ich in der vzlogger.conf die UIDs eingetragen, die mir nach dem Neu-Anlegen der Kanäle im Web-Frontend angezeigt wurden. Nach dem heutigen restore haten diese andere UIDs (verifiziert durch das "i”). Dann ist es klar: Du hast *neue* Kanäle angelegt und in die vzlogger.conf eingetragen. Anschließend hattest Du alles gelöscht und die *alten* Kanäle restored, die vzlogger war aber noch die alte. Zwei Schritte zuviel ;) Nachdem ich diese in der vzlogger.conf eingetragen hatte, lief alles auf Anhieb. Aber egal, Hauptsache es läuft wieder. Erstaunlicherweise hat sich gezeigt, dass die letzten Eiträge aus der DB vom 06.06. spät Abends sind, der Raspi aber zumindest bis zum Morgen des 07.06. in Kontakt mit der Firewall stand. Das wiki für meinen Teil der letzten Tage übernehme ich gerne. Was genau muss ich (neben der Prosa) dafür tun ? Da müssen die Experten helfen- eige
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, perfekt, läuft alles wieder rund. An wen soll ich mich wegen des wikis wenden ? Beste Grüße JD. Sent: Thursday, June 11, 2020 at 12:03 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hi JD, die Ursache hast Du gerade selbst identifiziert- vzlogger. Es wird nur funktionieren wenn Du es machst wie vorgeschlagen: - cron aus - vzlogger aus - aggregate laufen lassen anderenfalls wird es vmtl ewig zäh bleiben weil die aggregation niemals zu Ende läuft (lock Problem) und die Prozesse aus dem Cron auch noch anfangen sich aufzustapeln bis das System zum Stillstand kommt. Vielleicht können wir das später im Code besser lösen so dass sich aggregate das “LOCK TABLE” selber holt, das Ergebnis wäre allerdings das Gleiche- ab dem Zeitpunkt bleibt die Datenbank für andere Prozesse gesperrt. Viele Grüße, Andreas On 11. Jun 2020, at 11:52, John Doe <john...@null.net> wrote: Hallo Andreas, Deinen Tip habe ich versucht, anhand des wikis (https://wiki.volkszaehler.org/howto/datenmengen) umzusetzen mit php /var/www/volkszaehler.org/bin/aggregate run -m full -l day -l hour -l minute , das stiess relativ bald wieder an das lock-Problem. Daraufhin habe ich den cron zwischenzeitlich stillgelegt. Allerdings läuft/lief der vzlogger ja auch noch, deshalb habe ich den wiki-Tip mit diesen drei Zeilen (auch aus dem wiki) im crontab umzusetzen: */10 * * * * php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null 1 * * * * php /var/www/volkszaehler.org/bin/aggregate run -m delta -l hour >/dev/null 0 1 * * * php /var/www/volkszaehler.org/bin/aggregate run -m delta -l day >/dev/null Danach habe ich den cron natürlich wieder eingeschaltet. Das Ergebnis ist in allen Fällen negativ, d.h. es bleibt zäh. Gibt es noch etwas anderes, was ich an der Web-Frontendperformance optimieren könnte ? Wie ist das denn im originären Image eingestellt ? Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 6:52 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Ja: Aggregationstabelle wieder füllen (bin/aggregate) und dann den cronjob wieder einschalten der regelmässig die Deltas aktualisiert. Du hattest cron komplett deaktiviert glaube ich? Viele Grüße, Andreas Am 10.06.2020 um 18:49 schrieb John Doe <john...@null.net>: Hallo Andreas, noch eine kurze Frage: Seit dem Restore reagiert das Web-Frontend unglaublich "zäh", das Wechseln zwischen Woche, Monat, Jahr etc. kommt nahezu immer mit "Gateway timeout" raus. Gibt 's da noch etwas zu Optimieren ? Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 6:32 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hi JD, On 10. Jun 2020, at 18:29, John Doe <john...@null.net> wrote: Hallo Andreas, nach dem Neuaufsetzten hatte ich in der vzlogger.conf die UIDs eingetragen, die mir nach dem Neu-Anlegen der Kanäle im Web-Frontend angezeigt wurden. Nach dem heutigen restore haten diese andere UIDs (verifiziert durch das "i”). Dann ist es klar: Du hast *neue* Kanäle angelegt und in die vzlogger.conf eingetragen. Anschließend hattest Du alles gelöscht und die *alten* Kanäle restored, die vzlogger war aber noch die alte. Zwei Schritte zuviel ;) Nachdem ich diese in der vzlogger.conf eingetragen hatte, lief alles auf Anhieb. Aber egal, Hauptsache es läuft wieder. Erstaunlicherweise hat sich gezeigt, dass die letzten Eiträge aus der DB vom 06.06. spät Abends sind, der Raspi aber zumindest bis zum Morgen des 07.06. in Kontakt mit der Firewall stand. Das wiki für meinen Teil der letzten Tage übernehme ich gerne. Was genau muss ich (neben der Prosa) dafür tun ? Da müssen die Experten helfen- eigentlich nur den richtigen Platz im Wiki suchen und dann strukturiert dokumentieren: - welches Problem soll gelöst werden? - aus welchen Schritten besteht die Lösung? - wie sehen die Schritte im Einzelnen aus? - welche Werkzeuge kommen jeweils zum Einsatz wenn man auf Probleme stößt? Beste Grüße JD. Schönen Abend und Viele Grüße, Andreas Sent: Wednesday, June 10, 2020 at 5:07 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Das ist auch schwer zu glauben. Die UUIDs stehen in der Datenbank, die können nicht spontan nicht mehr passen. Wenn sie das tun dann hast Du vmtl. eine falsche vzlogger.conf zurück gespielt? Nachdem wir das jetz
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, Deinen Tip habe ich versucht, anhand des wikis (https://wiki.volkszaehler.org/howto/datenmengen) umzusetzen mit php /var/www/volkszaehler.org/bin/aggregate run -m full -l day -l hour -l minute , das stiess relativ bald wieder an das lock-Problem. Daraufhin habe ich den cron zwischenzeitlich stillgelegt. Allerdings läuft/lief der vzlogger ja auch noch, deshalb habe ich den wiki-Tip mit diesen drei Zeilen (auch aus dem wiki) im crontab umzusetzen: */10 * * * * php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null 1 * * * * php /var/www/volkszaehler.org/bin/aggregate run -m delta -l hour >/dev/null 0 1 * * * php /var/www/volkszaehler.org/bin/aggregate run -m delta -l day >/dev/null Danach habe ich den cron natürlich wieder eingeschaltet. Das Ergebnis ist in allen Fällen negativ, d.h. es bleibt zäh. Gibt es noch etwas anderes, was ich an der Web-Frontendperformance optimieren könnte ? Wie ist das denn im originären Image eingestellt ? Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 6:52 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Ja: Aggregationstabelle wieder füllen (bin/aggregate) und dann den cronjob wieder einschalten der regelmässig die Deltas aktualisiert. Du hattest cron komplett deaktiviert glaube ich? Viele Grüße, Andreas Am 10.06.2020 um 18:49 schrieb John Doe : Hallo Andreas, noch eine kurze Frage: Seit dem Restore reagiert das Web-Frontend unglaublich "zäh", das Wechseln zwischen Woche, Monat, Jahr etc. kommt nahezu immer mit "Gateway timeout" raus. Gibt 's da noch etwas zu Optimieren ? Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 6:32 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hi JD, On 10. Jun 2020, at 18:29, John Doe <john...@null.net> wrote: Hallo Andreas, nach dem Neuaufsetzten hatte ich in der vzlogger.conf die UIDs eingetragen, die mir nach dem Neu-Anlegen der Kanäle im Web-Frontend angezeigt wurden. Nach dem heutigen restore haten diese andere UIDs (verifiziert durch das "i”). Dann ist es klar: Du hast *neue* Kanäle angelegt und in die vzlogger.conf eingetragen. Anschließend hattest Du alles gelöscht und die *alten* Kanäle restored, die vzlogger war aber noch die alte. Zwei Schritte zuviel ;) Nachdem ich diese in der vzlogger.conf eingetragen hatte, lief alles auf Anhieb. Aber egal, Hauptsache es läuft wieder. Erstaunlicherweise hat sich gezeigt, dass die letzten Eiträge aus der DB vom 06.06. spät Abends sind, der Raspi aber zumindest bis zum Morgen des 07.06. in Kontakt mit der Firewall stand. Das wiki für meinen Teil der letzten Tage übernehme ich gerne. Was genau muss ich (neben der Prosa) dafür tun ? Da müssen die Experten helfen- eigentlich nur den richtigen Platz im Wiki suchen und dann strukturiert dokumentieren: - welches Problem soll gelöst werden? - aus welchen Schritten besteht die Lösung? - wie sehen die Schritte im Einzelnen aus? - welche Werkzeuge kommen jeweils zum Einsatz wenn man auf Probleme stößt? Beste Grüße JD. Schönen Abend und Viele Grüße, Andreas Sent: Wednesday, June 10, 2020 at 5:07 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Das ist auch schwer zu glauben. Die UUIDs stehen in der Datenbank, die können nicht spontan nicht mehr passen. Wenn sie das tun dann hast Du vmtl. eine falsche vzlogger.conf zurück gespielt? Nachdem wir das jetzt mit allen Stolperfallen durchgespielt haben- hättest Du evtl. Lust den Prozess des Restore vielleicht nochmal für‘s Wiki zu dokumentieren? Umzug auf ein NAS wäre dann in analoger Form möglich, Docker kann zusätzlich umgesetzt werden. Viele Grüße, Andreas Am 10.06.2020 um 17:01 schrieb John Doe <john...@null.net>: Hallo Andreas, erstmal Danke für Deine Leidensfäfigkeit! Ich hab' den Fehler gefunden - die UIDs in der vzlogger.conf passten nicht mehr. Jetzt läuft alles bestens. Ich werde mal darüber nachdenken, das Ganze etwas ausfallsicherer zu machen. Allerdings sehe ich aktuell noch keinen Mehrwert darin, den Raspi von einer SSD booten zu lassen und das Ganze dann auf diesem Wege auszulagern, da dieser Verbund wiederum natürlich mehr Strom verbraucht ... Nochmal Danke für Deine Bemühungen! Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 4:56 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Erstmal Glückwunsch! Ich würde ja die gleiche Frage stellen wie immer: was steht im L
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, noch eine kurze Frage: Seit dem Restore reagiert das Web-Frontend unglaublich "zäh", das Wechseln zwischen Woche, Monat, Jahr etc. kommt nahezu immer mit "Gateway timeout" raus. Gibt 's da noch etwas zu Optimieren ? Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 6:32 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hi JD, On 10. Jun 2020, at 18:29, John Doe <john...@null.net> wrote: Hallo Andreas, nach dem Neuaufsetzten hatte ich in der vzlogger.conf die UIDs eingetragen, die mir nach dem Neu-Anlegen der Kanäle im Web-Frontend angezeigt wurden. Nach dem heutigen restore haten diese andere UIDs (verifiziert durch das "i”). Dann ist es klar: Du hast *neue* Kanäle angelegt und in die vzlogger.conf eingetragen. Anschließend hattest Du alles gelöscht und die *alten* Kanäle restored, die vzlogger war aber noch die alte. Zwei Schritte zuviel ;) Nachdem ich diese in der vzlogger.conf eingetragen hatte, lief alles auf Anhieb. Aber egal, Hauptsache es läuft wieder. Erstaunlicherweise hat sich gezeigt, dass die letzten Eiträge aus der DB vom 06.06. spät Abends sind, der Raspi aber zumindest bis zum Morgen des 07.06. in Kontakt mit der Firewall stand. Das wiki für meinen Teil der letzten Tage übernehme ich gerne. Was genau muss ich (neben der Prosa) dafür tun ? Da müssen die Experten helfen- eigentlich nur den richtigen Platz im Wiki suchen und dann strukturiert dokumentieren: - welches Problem soll gelöst werden? - aus welchen Schritten besteht die Lösung? - wie sehen die Schritte im Einzelnen aus? - welche Werkzeuge kommen jeweils zum Einsatz wenn man auf Probleme stößt? Beste Grüße JD. Schönen Abend und Viele Grüße, Andreas Sent: Wednesday, June 10, 2020 at 5:07 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Das ist auch schwer zu glauben. Die UUIDs stehen in der Datenbank, die können nicht spontan nicht mehr passen. Wenn sie das tun dann hast Du vmtl. eine falsche vzlogger.conf zurück gespielt? Nachdem wir das jetzt mit allen Stolperfallen durchgespielt haben- hättest Du evtl. Lust den Prozess des Restore vielleicht nochmal für‘s Wiki zu dokumentieren? Umzug auf ein NAS wäre dann in analoger Form möglich, Docker kann zusätzlich umgesetzt werden. Viele Grüße, Andreas Am 10.06.2020 um 17:01 schrieb John Doe <john...@null.net>: Hallo Andreas, erstmal Danke für Deine Leidensfäfigkeit! Ich hab' den Fehler gefunden - die UIDs in der vzlogger.conf passten nicht mehr. Jetzt läuft alles bestens. Ich werde mal darüber nachdenken, das Ganze etwas ausfallsicherer zu machen. Allerdings sehe ich aktuell noch keinen Mehrwert darin, den Raspi von einer SSD booten zu lassen und das Ganze dann auf diesem Wege auszulagern, da dieser Verbund wiederum natürlich mehr Strom verbraucht ... Nochmal Danke für Deine Bemühungen! Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 4:56 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Erstmal Glückwunsch! Ich würde ja die gleiche Frage stellen wie immer: was steht im Logfile? In diesem Falle also dem von vzlogger? Wenn da nix drin steht: kannst Du das Volkszähler API im Browser aufrufen? Viele Grüße, Andreas Am 10.06.2020 um 16:37 schrieb John Doe <john...@null.net>: Hallo Andreas, das war 's: Ein /etc/init.d/cron stop hat es ermöglicht, das der restore fehlerfrei durchgelaufen ist. Im Webfrontend ist alles da - bis auf das Problemchen, das keine aktuellen Werte mehr ankommen ... Der cronjob und der vzlogger laufen: pi@raspberrypi:~ $ /etc/init.d/cron status ● cron.service - Regular background program processing daemon Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-06-10 16:28:20 CEST; 8min ago Docs: man:cron(8) Main PID: 410 (cron) Tasks: 4 (limit: 2068) CGroup: /system.slice/cron.service ├─ 410 /usr/sbin/cron -f ├─1043 /usr/sbin/CRON -f ├─1047 /bin/sh -c php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null └─1048 php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute Jun 10 16:28:20 raspberrypi systemd[1]: Started Regular background program processing daemon. Jun 10 16:28:20 raspberrypi cron[410]: (CRON) INFO (pidfile fd = 3) Jun 10 16:28:20 raspberrypi cron[410]: (CRON) INFO (Running @reboot jobs) Jun 10 16:30:01 raspberrypi CRON[1043]: pam_unix(cron:session): session opened for user pi by (uid=
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, nach dem Neuaufsetzten hatte ich in der vzlogger.conf die UIDs eingetragen, die mir nach dem Neu-Anlegen der Kanäle im Web-Frontend angezeigt wurden. Nach dem heutigen restore haten diese andere UIDs (verifiziert durch das "i"). Nachdem ich diese in der vzlogger.conf eingetragen hatte, lief alles auf Anhieb. Aber egal, Hauptsache es läuft wieder. Erstaunlicherweise hat sich gezeigt, dass die letzten Eiträge aus der DB vom 06.06. spät Abends sind, der Raspi aber zumindest bis zum Morgen des 07.06. in Kontakt mit der Firewall stand. Das wiki für meinen Teil der letzten Tage übernehme ich gerne. Was genau muss ich (neben der Prosa) dafür tun ? Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 5:07 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Das ist auch schwer zu glauben. Die UUIDs stehen in der Datenbank, die können nicht spontan nicht mehr passen. Wenn sie das tun dann hast Du vmtl. eine falsche vzlogger.conf zurück gespielt? Nachdem wir das jetzt mit allen Stolperfallen durchgespielt haben- hättest Du evtl. Lust den Prozess des Restore vielleicht nochmal für‘s Wiki zu dokumentieren? Umzug auf ein NAS wäre dann in analoger Form möglich, Docker kann zusätzlich umgesetzt werden. Viele Grüße, Andreas Am 10.06.2020 um 17:01 schrieb John Doe : Hallo Andreas, erstmal Danke für Deine Leidensfäfigkeit! Ich hab' den Fehler gefunden - die UIDs in der vzlogger.conf passten nicht mehr. Jetzt läuft alles bestens. Ich werde mal darüber nachdenken, das Ganze etwas ausfallsicherer zu machen. Allerdings sehe ich aktuell noch keinen Mehrwert darin, den Raspi von einer SSD booten zu lassen und das Ganze dann auf diesem Wege auszulagern, da dieser Verbund wiederum natürlich mehr Strom verbraucht ... Nochmal Danke für Deine Bemühungen! Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 4:56 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Erstmal Glückwunsch! Ich würde ja die gleiche Frage stellen wie immer: was steht im Logfile? In diesem Falle also dem von vzlogger? Wenn da nix drin steht: kannst Du das Volkszähler API im Browser aufrufen? Viele Grüße, Andreas Am 10.06.2020 um 16:37 schrieb John Doe : Hallo Andreas, das war 's: Ein /etc/init.d/cron stop hat es ermöglicht, das der restore fehlerfrei durchgelaufen ist. Im Webfrontend ist alles da - bis auf das Problemchen, das keine aktuellen Werte mehr ankommen ... Der cronjob und der vzlogger laufen: pi@raspberrypi:~ $ /etc/init.d/cron status ● cron.service - Regular background program processing daemon Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-06-10 16:28:20 CEST; 8min ago Docs: man:cron(8) Main PID: 410 (cron) Tasks: 4 (limit: 2068) CGroup: /system.slice/cron.service ├─ 410 /usr/sbin/cron -f ├─1043 /usr/sbin/CRON -f ├─1047 /bin/sh -c php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null └─1048 php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute Jun 10 16:28:20 raspberrypi systemd[1]: Started Regular background program processing daemon. Jun 10 16:28:20 raspberrypi cron[410]: (CRON) INFO (pidfile fd = 3) Jun 10 16:28:20 raspberrypi cron[410]: (CRON) INFO (Running @reboot jobs) Jun 10 16:30:01 raspberrypi CRON[1043]: pam_unix(cron:session): session opened for user pi by (uid=0) Jun 10 16:30:01 raspberrypi CRON[1047]: (pi) CMD (php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null) pi@raspberrypi:~ $ sudo systemctl status vzlogger ● vzlogger.service - vzlogger Loaded: loaded (/etc/systemd/system/vzlogger.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-06-10 16:28:35 CEST; 8min ago Main PID: 738 (vzlogger) Tasks: 5 (limit: 2068) CGroup: /system.slice/vzlogger.service └─738 /usr/local/bin/vzlogger -c /etc/vzlogger.conf Jun 10 16:28:35 raspberrypi systemd[1]: Started vzlogger. Hättest Du eine Idee, woran das liegen kann ? Grüße JD. Sent: Wednesday, June 10, 2020 at 1:31 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Moment- mir kommt noch ein Gedanke. Kann es sein, dass bei Dir auch der cron-Job für die Aggretation noch aktiv ist? Da dieser auch Massendatenoperationen mit der `data` Tabelle macht darf der auch nicht laufen! Bei Dir scheinen definitiv >1 Prozess auf der Datenbank rumzudaddeln die sich dann (“deadlock”) ins Gehege kommen. Es sollte *nur* der Restore laufen! Viele Grüße, Andreas On 10. Jun 2020, at 13:28, Andreas Goetz <cpui...@gmail.com> wrote: Womit bricht es
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, erstmal Danke für Deine Leidensfäfigkeit! Ich hab' den Fehler gefunden - die UIDs in der vzlogger.conf passten nicht mehr. Jetzt läuft alles bestens. Ich werde mal darüber nachdenken, das Ganze etwas ausfallsicherer zu machen. Allerdings sehe ich aktuell noch keinen Mehrwert darin, den Raspi von einer SSD booten zu lassen und das Ganze dann auf diesem Wege auszulagern, da dieser Verbund wiederum natürlich mehr Strom verbraucht ... Nochmal Danke für Deine Bemühungen! Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 4:56 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Erstmal Glückwunsch! Ich würde ja die gleiche Frage stellen wie immer: was steht im Logfile? In diesem Falle also dem von vzlogger? Wenn da nix drin steht: kannst Du das Volkszähler API im Browser aufrufen? Viele Grüße, Andreas Am 10.06.2020 um 16:37 schrieb John Doe : Hallo Andreas, das war 's: Ein /etc/init.d/cron stop hat es ermöglicht, das der restore fehlerfrei durchgelaufen ist. Im Webfrontend ist alles da - bis auf das Problemchen, das keine aktuellen Werte mehr ankommen ... Der cronjob und der vzlogger laufen: pi@raspberrypi:~ $ /etc/init.d/cron status ● cron.service - Regular background program processing daemon Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-06-10 16:28:20 CEST; 8min ago Docs: man:cron(8) Main PID: 410 (cron) Tasks: 4 (limit: 2068) CGroup: /system.slice/cron.service ├─ 410 /usr/sbin/cron -f ├─1043 /usr/sbin/CRON -f ├─1047 /bin/sh -c php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null └─1048 php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute Jun 10 16:28:20 raspberrypi systemd[1]: Started Regular background program processing daemon. Jun 10 16:28:20 raspberrypi cron[410]: (CRON) INFO (pidfile fd = 3) Jun 10 16:28:20 raspberrypi cron[410]: (CRON) INFO (Running @reboot jobs) Jun 10 16:30:01 raspberrypi CRON[1043]: pam_unix(cron:session): session opened for user pi by (uid=0) Jun 10 16:30:01 raspberrypi CRON[1047]: (pi) CMD (php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null) pi@raspberrypi:~ $ sudo systemctl status vzlogger ● vzlogger.service - vzlogger Loaded: loaded (/etc/systemd/system/vzlogger.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-06-10 16:28:35 CEST; 8min ago Main PID: 738 (vzlogger) Tasks: 5 (limit: 2068) CGroup: /system.slice/vzlogger.service └─738 /usr/local/bin/vzlogger -c /etc/vzlogger.conf Jun 10 16:28:35 raspberrypi systemd[1]: Started vzlogger. Hättest Du eine Idee, woran das liegen kann ? Grüße JD. Sent: Wednesday, June 10, 2020 at 1:31 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Moment- mir kommt noch ein Gedanke. Kann es sein, dass bei Dir auch der cron-Job für die Aggretation noch aktiv ist? Da dieser auch Massendatenoperationen mit der `data` Tabelle macht darf der auch nicht laufen! Bei Dir scheinen definitiv >1 Prozess auf der Datenbank rumzudaddeln die sich dann (“deadlock”) ins Gehege kommen. Es sollte *nur* der Restore laufen! Viele Grüße, Andreas On 10. Jun 2020, at 13:28, Andreas Goetz <cpui...@gmail.com> wrote: Womit bricht es ab? gleicher Fehler? Wenn Dein vzlogger gestoppt ist dann starte den Kopiervorgang- wie ich geschrieben hatte- einfach neu. Der geht an der letzten Stelle wieder los. Wenn Du jedesmal zwischendurch ohne Not die Datenbank platt machst wird das natürlich nichts :O Viele Grüße, Andreas On 10. Jun 2020, at 13:26, John Doe <john...@null.net> wrote: Hallo Andreas, ich habe jetzt einige Male "von vorne begonnen": pi@raspberrypi:~ $ bin/doctrine orm:schema-tool:drop --force pi@raspberrypi:~ $ bin/doctrine orm:schema-tool:create pi@raspberrypi:~ $ bin/doctrine orm:schema-tool:create --dump-sql pi@raspberrypi:~ $ sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml Das Kopieren von data bricht immer wieder an zufälligen Stellen ab, beim letzten Mal nach ca. 150/2900 rows. vzlogger ist sicher gestopt: pi@raspberrypi:~ $ sudo systemctl status vzlogger ● vzlogger.service - vzlogger Loaded: loaded (/etc/systemd/system/vzlogger.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Wed 2020-06-10 12:22:05 CEST; 1h 3min ago Main PID: 750 (code=killed, signal=KILL) Ich probiere das Ganze heute abend nochmal und berichte dann wieder. Grüße JD. Sent: Wednesday, June 10, 2020 at 12:34 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, das war 's: Ein /etc/init.d/cron stop hat es ermöglicht, das der restore fehlerfrei durchgelaufen ist. Im Webfrontend ist alles da - bis auf das Problemchen, das keine aktuellen Werte mehr ankommen ... Der cronjob und der vzlogger laufen: pi@raspberrypi:~ $ /etc/init.d/cron status ● cron.service - Regular background program processing daemon Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-06-10 16:28:20 CEST; 8min ago Docs: man:cron(8) Main PID: 410 (cron) Tasks: 4 (limit: 2068) CGroup: /system.slice/cron.service ├─ 410 /usr/sbin/cron -f ├─1043 /usr/sbin/CRON -f ├─1047 /bin/sh -c php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null └─1048 php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute Jun 10 16:28:20 raspberrypi systemd[1]: Started Regular background program processing daemon. Jun 10 16:28:20 raspberrypi cron[410]: (CRON) INFO (pidfile fd = 3) Jun 10 16:28:20 raspberrypi cron[410]: (CRON) INFO (Running @reboot jobs) Jun 10 16:30:01 raspberrypi CRON[1043]: pam_unix(cron:session): session opened for user pi by (uid=0) Jun 10 16:30:01 raspberrypi CRON[1047]: (pi) CMD (php /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute >/dev/null) pi@raspberrypi:~ $ sudo systemctl status vzlogger ● vzlogger.service - vzlogger Loaded: loaded (/etc/systemd/system/vzlogger.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-06-10 16:28:35 CEST; 8min ago Main PID: 738 (vzlogger) Tasks: 5 (limit: 2068) CGroup: /system.slice/vzlogger.service └─738 /usr/local/bin/vzlogger -c /etc/vzlogger.conf Jun 10 16:28:35 raspberrypi systemd[1]: Started vzlogger. Hättest Du eine Idee, woran das liegen kann ? Grüße JD. Sent: Wednesday, June 10, 2020 at 1:31 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Moment- mir kommt noch ein Gedanke. Kann es sein, dass bei Dir auch der cron-Job für die Aggretation noch aktiv ist? Da dieser auch Massendatenoperationen mit der `data` Tabelle macht darf der auch nicht laufen! Bei Dir scheinen definitiv >1 Prozess auf der Datenbank rumzudaddeln die sich dann (“deadlock”) ins Gehege kommen. Es sollte *nur* der Restore laufen! Viele Grüße, Andreas On 10. Jun 2020, at 13:28, Andreas Goetz <cpui...@gmail.com> wrote: Womit bricht es ab? gleicher Fehler? Wenn Dein vzlogger gestoppt ist dann starte den Kopiervorgang- wie ich geschrieben hatte- einfach neu. Der geht an der letzten Stelle wieder los. Wenn Du jedesmal zwischendurch ohne Not die Datenbank platt machst wird das natürlich nichts :O Viele Grüße, Andreas On 10. Jun 2020, at 13:26, John Doe <john...@null.net> wrote: Hallo Andreas, ich habe jetzt einige Male "von vorne begonnen": pi@raspberrypi:~ $ bin/doctrine orm:schema-tool:drop --force pi@raspberrypi:~ $ bin/doctrine orm:schema-tool:create pi@raspberrypi:~ $ bin/doctrine orm:schema-tool:create --dump-sql pi@raspberrypi:~ $ sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml Das Kopieren von data bricht immer wieder an zufälligen Stellen ab, beim letzten Mal nach ca. 150/2900 rows. vzlogger ist sicher gestopt: pi@raspberrypi:~ $ sudo systemctl status vzlogger ● vzlogger.service - vzlogger Loaded: loaded (/etc/systemd/system/vzlogger.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Wed 2020-06-10 12:22:05 CEST; 1h 3min ago Main PID: 750 (code=killed, signal=KILL) Ich probiere das Ganze heute abend nochmal und berichte dann wieder. Grüße JD. Sent: Wednesday, June 10, 2020 at 12:34 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hi JD, hast Du die Datenbank wieder leer gemacht? Falls nein droht Dir inkonsistenter Stand oder schlimmstenfalls Abbruch des Restores…. Falls Du es laufen lassen willst und es dann doch noch abbrechen sollte weisst Du was zu tun ist: die Datenbank komplett wieder abräumen kann auch bin/doctrine orm:schema-tool:drop Viele Grüße, Andreas On 10. Jun 2020, at 12:28, John Doe <john...@null.net> wrote: Hallo Andreas, Du hattest irgendwie recht: Ich hatte zwar ein sudo systemctl status vzlogger vor dem restore spendiert, allerdings schien der Dienst sich noch in einem Zombizustand zu befinden: pi@raspberrypi:~ $ sudo systemctl status vzlogger ● vzlogger.service - vzlogger Loaded: loaded (/etc/systemd/system/vzlogger.service; enabled; vendor preset: enabled) Active: deactivating (stop-sigterm) since
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, ich habe jetzt einige Male "von vorne begonnen": pi@raspberrypi:~ $ bin/doctrine orm:schema-tool:drop --force pi@raspberrypi:~ $ bin/doctrine orm:schema-tool:create pi@raspberrypi:~ $ bin/doctrine orm:schema-tool:create --dump-sql pi@raspberrypi:~ $ sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml Das Kopieren von data bricht immer wieder an zufälligen Stellen ab, beim letzten Mal nach ca. 150/2900 rows. vzlogger ist sicher gestopt: pi@raspberrypi:~ $ sudo systemctl status vzlogger ● vzlogger.service - vzlogger Loaded: loaded (/etc/systemd/system/vzlogger.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Wed 2020-06-10 12:22:05 CEST; 1h 3min ago Main PID: 750 (code=killed, signal=KILL) Ich probiere das Ganze heute abend nochmal und berichte dann wieder. Grüße JD. Sent: Wednesday, June 10, 2020 at 12:34 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hi JD, hast Du die Datenbank wieder leer gemacht? Falls nein droht Dir inkonsistenter Stand oder schlimmstenfalls Abbruch des Restores…. Falls Du es laufen lassen willst und es dann doch noch abbrechen sollte weisst Du was zu tun ist: die Datenbank komplett wieder abräumen kann auch bin/doctrine orm:schema-tool:drop Viele Grüße, Andreas On 10. Jun 2020, at 12:28, John Doe <john...@null.net> wrote: Hallo Andreas, Du hattest irgendwie recht: Ich hatte zwar ein sudo systemctl status vzlogger vor dem restore spendiert, allerdings schien der Dienst sich noch in einem Zombizustand zu befinden: pi@raspberrypi:~ $ sudo systemctl status vzlogger ● vzlogger.service - vzlogger Loaded: loaded (/etc/systemd/system/vzlogger.service; enabled; vendor preset: enabled) Active: deactivating (stop-sigterm) since Wed 2020-06-10 12:20:24 CEST; 1min 38s ago Main PID: 750 (vzlogger) Tasks: 1 (limit: 2068) CGroup: /system.slice/vzlogger.service └─750 /usr/local/bin/vzlogger -c /etc/vzlogger.conf Jun 10 12:20:10 raspberrypi systemd[1]: Started vzlogger. Jun 10 12:20:24 raspberrypi systemd[1]: Stopping vzlogger... Ich habe rebootet, gecheckt: pi@raspberrypi:~ $ sudo systemctl stop vzlogger Und den restore nochmal angeworfen. Aktuell läuft er noch, ich melde moich wieder. Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 12:03 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash In dem Fall kannst Du den Restore Prozess einfach nochmal anstarten. Die große Tabelle ist data, die wird dann nur schrittweise kopiert. Aber zur Sicherheit: Du hast nicht noch parallel vzlogger gegen die neue (Ziel-)Datenbank laufen? Es wundert mich doch sehr dass es da einen Deadlock in MySQL gibt. Viele Grüße, Andreas Am 10.06.2020 um 11:52 schrieb John Doe <john...@null.net>: Schade, zu früh gefreut: data: copying 29003424 rows (partial copy) [>---] 2% 3 mins/2 hrs 629000 rows In AbstractMySQLDriver.php line 34: An exception occurred while executing 'INSERT INTO `data` (`id`,`channel_id`,`timestamp`,`value`) VALUES (?,?,?,?)' with params [ "629070", "1", "1560170157864", "52342.2111"]: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction In PDOStatement.php line 119: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction In PDOStatement.php line 117: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constrain
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, Du hattest irgendwie recht: Ich hatte zwar ein sudo systemctl status vzlogger vor dem restore spendiert, allerdings schien der Dienst sich noch in einem Zombizustand zu befinden: pi@raspberrypi:~ $ sudo systemctl status vzlogger ● vzlogger.service - vzlogger Loaded: loaded (/etc/systemd/system/vzlogger.service; enabled; vendor preset: enabled) Active: deactivating (stop-sigterm) since Wed 2020-06-10 12:20:24 CEST; 1min 38s ago Main PID: 750 (vzlogger) Tasks: 1 (limit: 2068) CGroup: /system.slice/vzlogger.service └─750 /usr/local/bin/vzlogger -c /etc/vzlogger.conf Jun 10 12:20:10 raspberrypi systemd[1]: Started vzlogger. Jun 10 12:20:24 raspberrypi systemd[1]: Stopping vzlogger... Ich habe rebootet, gecheckt: pi@raspberrypi:~ $ sudo systemctl stop vzlogger Und den restore nochmal angeworfen. Aktuell läuft er noch, ich melde moich wieder. Beste Grüße JD. Sent: Wednesday, June 10, 2020 at 12:03 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash In dem Fall kannst Du den Restore Prozess einfach nochmal anstarten. Die große Tabelle ist data, die wird dann nur schrittweise kopiert. Aber zur Sicherheit: Du hast nicht noch parallel vzlogger gegen die neue (Ziel-)Datenbank laufen? Es wundert mich doch sehr dass es da einen Deadlock in MySQL gibt. Viele Grüße, Andreas Am 10.06.2020 um 11:52 schrieb John Doe : Schade, zu früh gefreut: data: copying 29003424 rows (partial copy) [>---] 2% 3 mins/2 hrs 629000 rows In AbstractMySQLDriver.php line 34: An exception occurred while executing 'INSERT INTO `data` (`id`,`channel_id`,`timestamp`,`value`) VALUES (?,?,?,?)' with params [ "629070", "1", "1560170157864", "52342.2111"]: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction In PDOStatement.php line 119: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction In PDOStatement.php line 117: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Grüße JD. Sent: Wednesday, June 10, 2020 at 11:49 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Andreas, das sieht besser aus: pi@raspberrypi:~/volkszaehler.org $ bin/doctrine orm:schema-tool:create ! ! [CAUTION] This operation should not be executed in a production environment! ! Creating database schema... [OK] Database schema created successfully! Aktuell wird die Datenbank kopiert, daher melde ich mich in zwei Stunden mit dem Ergebnis. Bis dahin erst mal tausend Dank ! Grüße JD. Sent: Wednesday, June 10, 2020 at 11:34 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash OK, dann ohne das —force. Alternativ kannst Du auch (falls das Schema in Teilen existiert) ein inkrementelles Update machen: bin/doctrine orm:schema-tool:update Viele Grüße, Andreas On 10. Jun 2020, at 11:20, John Doe <john...@null.net> wrote: Hallo Andreas, gerne: pi@raspberrypi:~/volkszaehler.org $ bin/doctrine orm:schema-tool:create --dump-sql The foll
Re: [vz-users] Bevorstehender Kartencrash
Schade, zu früh gefreut: data: copying 29003424 rows (partial copy) [>---] 2% 3 mins/2 hrs 629000 rows In AbstractMySQLDriver.php line 34: An exception occurred while executing 'INSERT INTO `data` (`id`,`channel_id`,`timestamp`,`value`) VALUES (?,?,?,?)' with params [ "629070", "1", "1560170157864", "52342.2111"]: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction In PDOStatement.php line 119: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction In PDOStatement.php line 117: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Grüße JD. Sent: Wednesday, June 10, 2020 at 11:49 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Andreas, das sieht besser aus: pi@raspberrypi:~/volkszaehler.org $ bin/doctrine orm:schema-tool:create ! ! [CAUTION] This operation should not be executed in a production environment! ! Creating database schema... [OK] Database schema created successfully! Aktuell wird die Datenbank kopiert, daher melde ich mich in zwei Stunden mit dem Ergebnis. Bis dahin erst mal tausend Dank ! Grüße JD. Sent: Wednesday, June 10, 2020 at 11:34 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash OK, dann ohne das —force. Alternativ kannst Du auch (falls das Schema in Teilen existiert) ein inkrementelles Update machen: bin/doctrine orm:schema-tool:update Viele Grüße, Andreas On 10. Jun 2020, at 11:20, John Doe <john...@null.net> wrote: Hallo Andreas, gerne: pi@raspberrypi:~/volkszaehler.org $ bin/doctrine orm:schema-tool:create --dump-sql The following SQL statements will be executed: CREATE TABLE aggregate (id INT AUTO_INCREMENT NOT NULL, channel_id INT DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, count INT NOT NULL, INDEX IDX_B77949FF72F5A1AA (channel_id), UNIQUE INDEX aggregate_unique (channel_id, type, timestamp), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE entities (id INT AUTO_INCREMENT NOT NULL, uuid VARCHAR(36) NOT NULL, type VARCHAR(255) NOT NULL, class VARCHAR(255) NOT NULL, UNIQUE INDEX UNIQ_50EC64E5D17F50A6 (uuid), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE entities_in_aggregator (parent_id INT NOT NULL, child_id INT NOT NULL, INDEX IDX_2BD88468727ACA70 (parent_id), INDEX IDX_2BD88468DD62C21B (child_id), PRIMARY KEY(parent_id, child_id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE properties (id INT AUTO_INCREMENT NOT NULL, entity_id INT DEFAULT NULL, pkey VARCHAR(255) NOT NULL, value LONGTEXT NOT NULL, INDEX IDX_87C331C781257D5D (entity_id), UNIQUE INDEX property_unique (entity_id, pkey), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE data (id INT AUTO_INCREMENT NOT NULL, channel_id INT DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, INDEX IDX_ADF3F36372F5A1AA (channel_id), UNIQUE INDEX data_unique (channel_id, timestamp), PRIM
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, das sieht besser aus: pi@raspberrypi:~/volkszaehler.org $ bin/doctrine orm:schema-tool:create ! ! [CAUTION] This operation should not be executed in a production environment! ! Creating database schema... [OK] Database schema created successfully! Aktuell wird die Datenbank kopiert, daher melde ich mich in zwei Stunden mit dem Ergebnis. Bis dahin erst mal tausend Dank ! Grüße JD. Sent: Wednesday, June 10, 2020 at 11:34 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash OK, dann ohne das —force. Alternativ kannst Du auch (falls das Schema in Teilen existiert) ein inkrementelles Update machen: bin/doctrine orm:schema-tool:update Viele Grüße, Andreas On 10. Jun 2020, at 11:20, John Doe <john...@null.net> wrote: Hallo Andreas, gerne: pi@raspberrypi:~/volkszaehler.org $ bin/doctrine orm:schema-tool:create --dump-sql The following SQL statements will be executed: CREATE TABLE aggregate (id INT AUTO_INCREMENT NOT NULL, channel_id INT DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, count INT NOT NULL, INDEX IDX_B77949FF72F5A1AA (channel_id), UNIQUE INDEX aggregate_unique (channel_id, type, timestamp), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE entities (id INT AUTO_INCREMENT NOT NULL, uuid VARCHAR(36) NOT NULL, type VARCHAR(255) NOT NULL, class VARCHAR(255) NOT NULL, UNIQUE INDEX UNIQ_50EC64E5D17F50A6 (uuid), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE entities_in_aggregator (parent_id INT NOT NULL, child_id INT NOT NULL, INDEX IDX_2BD88468727ACA70 (parent_id), INDEX IDX_2BD88468DD62C21B (child_id), PRIMARY KEY(parent_id, child_id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE properties (id INT AUTO_INCREMENT NOT NULL, entity_id INT DEFAULT NULL, pkey VARCHAR(255) NOT NULL, value LONGTEXT NOT NULL, INDEX IDX_87C331C781257D5D (entity_id), UNIQUE INDEX property_unique (entity_id, pkey), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE data (id INT AUTO_INCREMENT NOT NULL, channel_id INT DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, INDEX IDX_ADF3F36372F5A1AA (channel_id), UNIQUE INDEX data_unique (channel_id, timestamp), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; ALTER TABLE aggregate ADD CONSTRAINT FK_B77949FF72F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id); ALTER TABLE entities_in_aggregator ADD CONSTRAINT FK_2BD88468727ACA70 FOREIGN KEY (parent_id) REFERENCES entities (id); ALTER TABLE entities_in_aggregator ADD CONSTRAINT FK_2BD88468DD62C21B FOREIGN KEY (child_id) REFERENCES entities (id); ALTER TABLE properties ADD CONSTRAINT FK_87C331C781257D5D FOREIGN KEY (entity_id) REFERENCES entities (id); ALTER TABLE data ADD CONSTRAINT FK_ADF3F36372F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id); pi@raspberrypi:~/volkszaehler.org $ bin/doctrine orm:schema-tool:create —force Too many arguments, expected arguments "command". orm:schema-tool:create [--dump-sql] Grüße JD. Sent: Wednesday, June 10, 2020 at 10:48 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Mhhm, alles sehr merkwürdig. Versuch bitte nochmal das Schema im Ziel anzulegen: bin/doctrine orm:schema-tool:create --dump-sql Output bitte zeigen. Dann: bin/doctrine orm:schema-tool:create —force zum anlegen. Vielen Dank, Andreas On 10. Jun 2020, at 10:44, John Doe <john...@null.net> wrote: Hallo Andreas, das scheint zunächst zu klappen: pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml Creating target schema Creating tables Updating schema assets for target platform compatibility: sqlite Die dbcopy.yaml: # DATABASE DEFINITION source: driver: pdo_mysql host: localhost user: vz password: demo dbname: volkszaehler target: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: v
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, gerne: pi@raspberrypi:~/volkszaehler.org $ bin/doctrine orm:schema-tool:create --dump-sql The following SQL statements will be executed: CREATE TABLE aggregate (id INT AUTO_INCREMENT NOT NULL, channel_id INT DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, count INT NOT NULL, INDEX IDX_B77949FF72F5A1AA (channel_id), UNIQUE INDEX aggregate_unique (channel_id, type, timestamp), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE entities (id INT AUTO_INCREMENT NOT NULL, uuid VARCHAR(36) NOT NULL, type VARCHAR(255) NOT NULL, class VARCHAR(255) NOT NULL, UNIQUE INDEX UNIQ_50EC64E5D17F50A6 (uuid), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE entities_in_aggregator (parent_id INT NOT NULL, child_id INT NOT NULL, INDEX IDX_2BD88468727ACA70 (parent_id), INDEX IDX_2BD88468DD62C21B (child_id), PRIMARY KEY(parent_id, child_id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE properties (id INT AUTO_INCREMENT NOT NULL, entity_id INT DEFAULT NULL, pkey VARCHAR(255) NOT NULL, value LONGTEXT NOT NULL, INDEX IDX_87C331C781257D5D (entity_id), UNIQUE INDEX property_unique (entity_id, pkey), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE data (id INT AUTO_INCREMENT NOT NULL, channel_id INT DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, INDEX IDX_ADF3F36372F5A1AA (channel_id), UNIQUE INDEX data_unique (channel_id, timestamp), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; ALTER TABLE aggregate ADD CONSTRAINT FK_B77949FF72F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id); ALTER TABLE entities_in_aggregator ADD CONSTRAINT FK_2BD88468727ACA70 FOREIGN KEY (parent_id) REFERENCES entities (id); ALTER TABLE entities_in_aggregator ADD CONSTRAINT FK_2BD88468DD62C21B FOREIGN KEY (child_id) REFERENCES entities (id); ALTER TABLE properties ADD CONSTRAINT FK_87C331C781257D5D FOREIGN KEY (entity_id) REFERENCES entities (id); ALTER TABLE data ADD CONSTRAINT FK_ADF3F36372F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id); pi@raspberrypi:~/volkszaehler.org $ bin/doctrine orm:schema-tool:create —force Too many arguments, expected arguments "command". orm:schema-tool:create [--dump-sql] Grüße JD. Sent: Wednesday, June 10, 2020 at 10:48 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Mhhm, alles sehr merkwürdig. Versuch bitte nochmal das Schema im Ziel anzulegen: bin/doctrine orm:schema-tool:create --dump-sql Output bitte zeigen. Dann: bin/doctrine orm:schema-tool:create —force zum anlegen. Vielen Dank, Andreas On 10. Jun 2020, at 10:44, John Doe <john...@null.net> wrote: Hallo Andreas, das scheint zunächst zu klappen: pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml Creating target schema Creating tables Updating schema assets for target platform compatibility: sqlite Die dbcopy.yaml: # DATABASE DEFINITION source: driver: pdo_mysql host: localhost user: vz password: demo dbname: volkszaehler target: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: entire table will be truncated on target and copied from source # pk: selective copy by primary key. only data not present on target # will be copied from source. tables: entities: copy properties: copy entities_in_aggregator: copy data: pk aggregate: skip Bei Vertauschung von sorec und target passiert leider das: pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml In CopyCommand.php line 49: Table entities doesn't exist.To create the schema run doctrine.php orm:schema-tool:create --dump-sql copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints]
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, das scheint zunächst zu klappen: pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml Creating target schema Creating tables Updating schema assets for target platform compatibility: sqlite Die dbcopy.yaml: # DATABASE DEFINITION source: driver: pdo_mysql host: localhost user: vz password: demo dbname: volkszaehler target: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: entire table will be truncated on target and copied from source # pk: selective copy by primary key. only data not present on target # will be copied from source. tables: entities: copy properties: copy entities_in_aggregator: copy data: pk aggregate: skip Bei Vertauschung von sorec und target passiert leider das: pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml In CopyCommand.php line 49: Table entities doesn't exist.To create the schema run doctrine.php orm:schema-tool:create --dump-sql copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Hättest Du noch einen Tip, oder ist mein Backup verloren ? Grüße JD. Sent: Wednesday, June 10, 2020 at 10:35 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Klar: ❯ ./vendor/bin/dbcopy Database backup tool Usage: command [options] [arguments] Options: -h, --help Display this help message. Available commands: clear Clear target tables copy Run copy create Create target schema drop Drop target schema help Displays help for a command influx Copy data to InfluxDB list Lists commands create wäre in diesem Fall das Kommando der Wahl! Viele Grüße, Andreas On 10. Jun 2020, at 09:52, John Doe <john...@null.net> wrote: Hallo zusammen, ein DROP DATABASE volkszaehler; CREATE DATABASE volkszaehler; hat nun leider zur Folge, das nach dem Wiederherstellen meines Backups mit sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml meine Kanäle weg sind. Hat noch jemand einen Tip, wie ich meine alten Daten wieder herstellen kann ? Beste Grüße JD. Sent: Tuesday, June 09, 2020 at 7:07 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Sieht aus als wären die Daten schon vorhanden (duplicate key)- hattest Du die Zieldatenbank denn wieder leer gemacht? Viele Grüße, Andreas Am 09.06.2020 um 19:02 schrieb John Doe <john...@null.net>: Hallo Andreas, es scheint prinzipiell am User, unabhängig vom PW zu liegen: mysql -u root -h localhost volkszaehler ERROR 1698 (28000): Access denied for user 'root'@'localhost' 127.0.0.1 führt zum gleichen Ergebnis. Mit sudo mysql -u root -h localhost volkszaehler klappt das Ganze. Leider hängt es nun hier: data: copying 28925979 rows (partial copy) [>---] 0% < 1 sec/< 1 sec 0 rows In AbstractMySQLDriver.php line 55: An exception occurred while executing 'INSERT INTO `data` (`id`,`channel_id`,`timestamp`,`value`) VALUES (?, ?,?,?)' with params ["77446", "1", "1559552806523", "52268.478"]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '77446' for key 'PRIMARY' In PDOStatement.php line 119: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '77446' for key 'PRIMARY'
Re: [vz-users] Bevorstehender Kartencrash
Hallo zusammen, ein DROP DATABASE volkszaehler; CREATE DATABASE volkszaehler; hat nun leider zur Folge, das nach dem Wiederherstellen meines Backups mit sudo /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml meine Kanäle weg sind. Hat noch jemand einen Tip, wie ich meine alten Daten wieder herstellen kann ? Beste Grüße JD. Sent: Tuesday, June 09, 2020 at 7:07 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Sieht aus als wären die Daten schon vorhanden (duplicate key)- hattest Du die Zieldatenbank denn wieder leer gemacht? Viele Grüße, Andreas Am 09.06.2020 um 19:02 schrieb John Doe : Hallo Andreas, es scheint prinzipiell am User, unabhängig vom PW zu liegen: mysql -u root -h localhost volkszaehler ERROR 1698 (28000): Access denied for user 'root'@'localhost' 127.0.0.1 führt zum gleichen Ergebnis. Mit sudo mysql -u root -h localhost volkszaehler klappt das Ganze. Leider hängt es nun hier: data: copying 28925979 rows (partial copy) [>---] 0% < 1 sec/< 1 sec 0 rows In AbstractMySQLDriver.php line 55: An exception occurred while executing 'INSERT INTO `data` (`id`,`channel_id`,`timestamp`,`value`) VALUES (?, ?,?,?)' with params ["77446", "1", "1559552806523", "52268.478"]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '77446' for key 'PRIMARY' In PDOStatement.php line 119: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '77446' for key 'PRIMARY' In PDOStatement.php line 117: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '77446' for key 'PRIMARY' copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Grüße JD. Sent: Tuesday, June 09, 2020 at 6:07 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash On 9. Jun 2020, at 17:28, John Doe <john...@null.net> wrote: Hallo Andreas, das klappt nicht: pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml In AbstractMySQLDriver.php line 106: An exception occurred in driver: SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' In PDOConnection.php line 31: SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' In PDOConnection.php line 27: SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Ich bin mir hundertprozentig sicher, dass die user/pw-Kombi stimmt ... Das ist…. sehr unwahrscheinlich. Was passiert denn beim Login auf der Kommandozeile mit der gleichen Kombination (https://stackoverflow.com/questions/5131931/connecting-to-mysql-from-the-command-line)? Evtl. liegt es auch an https://github.com/volkszaehler/volkszaehler.org/pull/799? Viele Grüße, Andreas Grüße JD. Sent: Tuesday, June 09, 2020 at 5:18 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Sieht nicht offensichtlich falsch aus. Falls sie im Backup ist könntest Du auch noch die aggregate Tabelle kopieren, anderenfalls müsstest Du die im Ziel neu erstellen, sinnigerweise bevor Du Aggregation wieder einschaltest (sonst könnten sich die SQL Queries dazu aufstapeln). Viele Grüße, Andreas On 9. J
Re: [vz-users] Bevorstehender Kartencrash
Ouh... Guter Tipp. Eher nicht. Wie würde ich das anstellen? Grüße JD. > Sent: Tuesday, June 09, 2020 at 7:07 PM > From: "Andreas Goetz" > To: "volkszaehler.org - users" > Subject: Re: [vz-users] Bevorstehender Kartencrash > > Sieht aus als wären die Daten schon vorhanden (duplicate key)- hattest Du die > Zieldatenbank denn wieder leer gemacht? > > Viele Grüße, Andreas > > > Am 09.06.2020 um 19:02 schrieb John Doe : > > > > > > Hallo Andreas, > > > > es scheint prinzipiell am User, unabhängig vom PW zu liegen: > > > > mysql -u root -h localhost volkszaehler > > ERROR 1698 (28000): Access denied for user 'root'@'localhost' > > > > 127.0.0.1 führt zum gleichen Ergebnis. > > Mit > > > > sudo mysql -u root -h localhost volkszaehler > > > > klappt das Ganze. Leider hängt es nun hier: > > > > data: copying 28925979 rows (partial copy) > > [>---] 0% < 1 sec/< 1 sec 0 rows > > In AbstractMySQLDriver.php line 55: > > > > > > An exception occurred while executing 'INSERT INTO `data` > > (`id`,`channel_id`,`timestamp`,`value`) VALUES (?, > > ?,?,?)' with params ["77446", "1", "1559552806523", "52268.478"]: > > > > > > > > SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry > > '77446' for key 'PRIMARY' > > > > > > In PDOStatement.php line 119: > > > > > > SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry > > '77446' for key 'PRIMARY' > > > > > > In PDOStatement.php line 117: > > > > > > SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry > > '77446' for key 'PRIMARY' > > > > > > copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] > > [...] > > > > Grüße > > > > JD. > > > > > > > > Sent: Tuesday, June 09, 2020 at 6:07 PM > > From: "Andreas Goetz" > > To: "volkszaehler.org - users" > > Subject: Re: [vz-users] Bevorstehender Kartencrash > > > > On 9. Jun 2020, at 17:28, John Doe wrote: > > > > Hallo Andreas, > > > > das klappt nicht: > > > > pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c > > /etc/dbcopy.yaml > > In AbstractMySQLDriver.php line 106: > > > > > > An exception occurred in driver: SQLSTATE[HY000] [1698] Access denied for > > user 'root'@'localhost' > > > > > > In PDOConnection.php line 31: > > > > SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' > > > > In PDOConnection.php line 27: > > > > SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' > > > > copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] > > [...] > > > > > > Ich bin mir hundertprozentig sicher, dass die user/pw-Kombi stimmt ... > > > > Das ist…. sehr unwahrscheinlich. Was passiert denn beim Login auf der > > Kommandozeile mit der gleichen Kombination > > (https://stackoverflow.com/questions/5131931/connecting-to-mysql-from-the-command-line)? > > > > Evtl. liegt es auch an > > https://github.com/volkszaehler/volkszaehler.o
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, es scheint prinzipiell am User, unabhängig vom PW zu liegen: mysql -u root -h localhost volkszaehler ERROR 1698 (28000): Access denied for user 'root'@'localhost' 127.0.0.1 führt zum gleichen Ergebnis. Mit sudo mysql -u root -h localhost volkszaehler klappt das Ganze. Leider hängt es nun hier: data: copying 28925979 rows (partial copy) [>---] 0% < 1 sec/< 1 sec 0 rows In AbstractMySQLDriver.php line 55: An exception occurred while executing 'INSERT INTO `data` (`id`,`channel_id`,`timestamp`,`value`) VALUES (?, ?,?,?)' with params ["77446", "1", "1559552806523", "52268.478"]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '77446' for key 'PRIMARY' In PDOStatement.php line 119: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '77446' for key 'PRIMARY' In PDOStatement.php line 117: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '77446' for key 'PRIMARY' copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Grüße JD. Sent: Tuesday, June 09, 2020 at 6:07 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash On 9. Jun 2020, at 17:28, John Doe <john...@null.net> wrote: Hallo Andreas, das klappt nicht: pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml In AbstractMySQLDriver.php line 106: An exception occurred in driver: SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' In PDOConnection.php line 31: SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' In PDOConnection.php line 27: SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Ich bin mir hundertprozentig sicher, dass die user/pw-Kombi stimmt ... Das ist…. sehr unwahrscheinlich. Was passiert denn beim Login auf der Kommandozeile mit der gleichen Kombination (https://stackoverflow.com/questions/5131931/connecting-to-mysql-from-the-command-line)? Evtl. liegt es auch an https://github.com/volkszaehler/volkszaehler.org/pull/799? Viele Grüße, Andreas Grüße JD. Sent: Tuesday, June 09, 2020 at 5:18 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Sieht nicht offensichtlich falsch aus. Falls sie im Backup ist könntest Du auch noch die aggregate Tabelle kopieren, anderenfalls müsstest Du die im Ziel neu erstellen, sinnigerweise bevor Du Aggregation wieder einschaltest (sonst könnten sich die SQL Queries dazu aufstapeln). Viele Grüße, Andreas On 9. Jun 2020, at 17:13, John Doe <john...@null.net> wrote: Okay, letzte Frage: Passt das so, bevor ich starte? # DATABASE DEFINITION source: #driver: pdo_mysql driver: pdo_sqlite #host: localhost #user: vz #password: demo #dbname: volkszaehler path: sqlite.db3 target: driver: pdo_mysql host: localhost user: root password: raspberry dbname: volkszaehler #path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, das klappt nicht: pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy copy -c /etc/dbcopy.yaml In AbstractMySQLDriver.php line 106: An exception occurred in driver: SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' In PDOConnection.php line 31: SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' In PDOConnection.php line 27: SQLSTATE[HY000] [1698] Access denied for user 'root'@'localhost' copy [-c|--config CONFIG] [-b|--batch BATCH] [-k|--keep-constraints] [--] [...] Ich bin mir hundertprozentig sicher, dass die user/pw-Kombi stimmt ... Grüße JD. Sent: Tuesday, June 09, 2020 at 5:18 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Sieht nicht offensichtlich falsch aus. Falls sie im Backup ist könntest Du auch noch die aggregate Tabelle kopieren, anderenfalls müsstest Du die im Ziel neu erstellen, sinnigerweise bevor Du Aggregation wieder einschaltest (sonst könnten sich die SQL Queries dazu aufstapeln). Viele Grüße, Andreas On 9. Jun 2020, at 17:13, John Doe <john...@null.net> wrote: Okay, letzte Frage: Passt das so, bevor ich starte? # DATABASE DEFINITION source: #driver: pdo_mysql driver: pdo_sqlite #host: localhost #user: vz #password: demo #dbname: volkszaehler path: sqlite.db3 target: driver: pdo_mysql host: localhost user: root password: raspberry dbname: volkszaehler #path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: entire table will be truncated on target and copied from source # pk: selective copy by primary key. only data not present on target # will be copied from source. tables: entities: copy properties: copy entities_in_aggregator: copy data: pk aggregate: skip Beste Grüße JD. Sent: Tuesday, June 09, 2020 at 5:02 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Ja genau- und mach auch von der „neuen“ Quelle vorher noch ein Backup! Better be safe than sorry... Viele Grüße, Andreas Am 09.06.2020 um 17:00 schrieb John Doe <john...@null.net>: Hallo Andreas, danke für die schnelle Reaktion. Dann opfere ich logischerweise den kleineren Datensatz. Die GrundIdee mit dem Vertauschen von Quelle und Ziel klappt aber dann ? Beste Grüße JD. Sent: Tuesday, June 09, 2020 at 4:46 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hi, On 9. Jun 2020, at 16:43, John Doe <john...@null.net> wrote: Hallo zusammen, bevor ich jetzt wieder Mist mit der Datenbank mache, würde ich gerne hier nachfragen. 1. Neuer aufgesetzter VZ läuft zunächst mal wieder auf einem RPi3 wie gewünscht. 2. dbcopy läuft auch, ich kann lokal eine sqlite.db3 anlegen. 3. Da ich noch die Sicherung der alten DB habe (ebenfalls sqlite.db3), würde ich diese mit der aktuellen gerne "mergen". Kann ich das einfach doof und hoffentlich gefahrlos tun, indem ich in der dbcopy.yaml Quelle und Ziel vertausche ? Bleiben meine aktuell schon vorliegenden Daten existent ? Das kannst Du auf KEINEN Fall tun: - es gibt keinen “merge” Prozess - in beiden Datenbanken werden die gleichen IDs existieren - die Entities werden bei Default Einstellungen überschrieben —> vmtl. Desaster DBCopy ist ausschließlich dafür geeignet, “linear” von einer DB in eine andere DB zu kopieren die ein Subset der identischen Daten enthält. Bei Dir scheinen aber in beiden DBs disjunkte Datenbestände zu liegen- Du wirst nicht drum herum kommen einen der DB-Stände zu opfern. Viele Grüße, Andreas Beste Grüße JD. Sent: Tuesday, June 09, 2020 at 9:24 AM From: "
Re: [vz-users] Bevorstehender Kartencrash
Okay, letzte Frage: Passt das so, bevor ich starte? # DATABASE DEFINITION source: #driver: pdo_mysql driver: pdo_sqlite #host: localhost #user: vz #password: demo #dbname: volkszaehler path: sqlite.db3 target: driver: pdo_mysql host: localhost user: root password: raspberry dbname: volkszaehler #path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: entire table will be truncated on target and copied from source # pk: selective copy by primary key. only data not present on target # will be copied from source. tables: entities: copy properties: copy entities_in_aggregator: copy data: pk aggregate: skip Beste Grüße JD. Sent: Tuesday, June 09, 2020 at 5:02 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Ja genau- und mach auch von der „neuen“ Quelle vorher noch ein Backup! Better be safe than sorry... Viele Grüße, Andreas Am 09.06.2020 um 17:00 schrieb John Doe : Hallo Andreas, danke für die schnelle Reaktion. Dann opfere ich logischerweise den kleineren Datensatz. Die GrundIdee mit dem Vertauschen von Quelle und Ziel klappt aber dann ? Beste Grüße JD. Sent: Tuesday, June 09, 2020 at 4:46 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hi, On 9. Jun 2020, at 16:43, John Doe <john...@null.net> wrote: Hallo zusammen, bevor ich jetzt wieder Mist mit der Datenbank mache, würde ich gerne hier nachfragen. 1. Neuer aufgesetzter VZ läuft zunächst mal wieder auf einem RPi3 wie gewünscht. 2. dbcopy läuft auch, ich kann lokal eine sqlite.db3 anlegen. 3. Da ich noch die Sicherung der alten DB habe (ebenfalls sqlite.db3), würde ich diese mit der aktuellen gerne "mergen". Kann ich das einfach doof und hoffentlich gefahrlos tun, indem ich in der dbcopy.yaml Quelle und Ziel vertausche ? Bleiben meine aktuell schon vorliegenden Daten existent ? Das kannst Du auf KEINEN Fall tun: - es gibt keinen “merge” Prozess - in beiden Datenbanken werden die gleichen IDs existieren - die Entities werden bei Default Einstellungen überschrieben —> vmtl. Desaster DBCopy ist ausschließlich dafür geeignet, “linear” von einer DB in eine andere DB zu kopieren die ein Subset der identischen Daten enthält. Bei Dir scheinen aber in beiden DBs disjunkte Datenbestände zu liegen- Du wirst nicht drum herum kommen einen der DB-Stände zu opfern. Viele Grüße, Andreas Beste Grüße JD. Sent: Tuesday, June 09, 2020 at 9:24 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Christian, On 8. Jun 2020, at 19:46, Christian Wimmer <christ...@nega.at> wrote: Hallo JD Danke, das hört sich gut an. Ich verwende nur Sandisk. Am liebsten würde ich ja die DB auf das NAS auslagern, so dass nur dort geschrieben wird. Aber das liest sich alles so kompliziert. Jetzt verbreitest Du aber ziemliche Panik ;) Eine Datenbank auf dem NAS zu nutzen statt einer Datenbank auf dem Raspi bedeutet einfach nur die Konfigurationsdatei zu ändern (URL, User, Passwort). Wenn Du z.B. schon ein Backup auf dem NAS hättest könnte das direkt Deine “Haupt”Datenbank werden (brauchst Du dann natürlich ein neues Backup). Viele Grüße, Andreas Von: volkszaehler-users <volkszaehler-users-boun...@demo.volkszaehler.org> Im Auftrag von John Doe Gesendet: Montag, 8. Juni 2020 19:15 An: volkszaehler-users@demo.volkszaehler.org Betreff: Re: [vz-users] Bevorstehender Kartencrash Hallo Christian, das hängt wohl auch von der Aggregation-Time ab. Ich glaube aber tendenziell ausgemacht zu haben, dass Sandisk-Karten bei gleicher vzlogger.conf länger halten als Transcend. Erstere lief bei mir über Jahre, letztere einige Monate bis ca. halbes Jahr. Beste Grüße JD. Sent: Monday, June 08, 2020 at 6:13 PM From: "Christian Wimmer" <christ...@nega.at> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Frage zwischendurch: wie lange hält im Durchschnitt eine SD-Karte? Von: volkszaehler-users <volkszaehler-users-b
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, danke für die schnelle Reaktion. Dann opfere ich logischerweise den kleineren Datensatz. Die GrundIdee mit dem Vertauschen von Quelle und Ziel klappt aber dann ? Beste Grüße JD. Sent: Tuesday, June 09, 2020 at 4:46 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hi, On 9. Jun 2020, at 16:43, John Doe <john...@null.net> wrote: Hallo zusammen, bevor ich jetzt wieder Mist mit der Datenbank mache, würde ich gerne hier nachfragen. 1. Neuer aufgesetzter VZ läuft zunächst mal wieder auf einem RPi3 wie gewünscht. 2. dbcopy läuft auch, ich kann lokal eine sqlite.db3 anlegen. 3. Da ich noch die Sicherung der alten DB habe (ebenfalls sqlite.db3), würde ich diese mit der aktuellen gerne "mergen". Kann ich das einfach doof und hoffentlich gefahrlos tun, indem ich in der dbcopy.yaml Quelle und Ziel vertausche ? Bleiben meine aktuell schon vorliegenden Daten existent ? Das kannst Du auf KEINEN Fall tun: - es gibt keinen “merge” Prozess - in beiden Datenbanken werden die gleichen IDs existieren - die Entities werden bei Default Einstellungen überschrieben —> vmtl. Desaster DBCopy ist ausschließlich dafür geeignet, “linear” von einer DB in eine andere DB zu kopieren die ein Subset der identischen Daten enthält. Bei Dir scheinen aber in beiden DBs disjunkte Datenbestände zu liegen- Du wirst nicht drum herum kommen einen der DB-Stände zu opfern. Viele Grüße, Andreas Beste Grüße JD. Sent: Tuesday, June 09, 2020 at 9:24 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Christian, On 8. Jun 2020, at 19:46, Christian Wimmer <christ...@nega.at> wrote: Hallo JD Danke, das hört sich gut an. Ich verwende nur Sandisk. Am liebsten würde ich ja die DB auf das NAS auslagern, so dass nur dort geschrieben wird. Aber das liest sich alles so kompliziert. Jetzt verbreitest Du aber ziemliche Panik ;) Eine Datenbank auf dem NAS zu nutzen statt einer Datenbank auf dem Raspi bedeutet einfach nur die Konfigurationsdatei zu ändern (URL, User, Passwort). Wenn Du z.B. schon ein Backup auf dem NAS hättest könnte das direkt Deine “Haupt”Datenbank werden (brauchst Du dann natürlich ein neues Backup). Viele Grüße, Andreas Von: volkszaehler-users <volkszaehler-users-boun...@demo.volkszaehler.org> Im Auftrag von John Doe Gesendet: Montag, 8. Juni 2020 19:15 An: volkszaehler-users@demo.volkszaehler.org Betreff: Re: [vz-users] Bevorstehender Kartencrash Hallo Christian, das hängt wohl auch von der Aggregation-Time ab. Ich glaube aber tendenziell ausgemacht zu haben, dass Sandisk-Karten bei gleicher vzlogger.conf länger halten als Transcend. Erstere lief bei mir über Jahre, letztere einige Monate bis ca. halbes Jahr. Beste Grüße JD. Sent: Monday, June 08, 2020 at 6:13 PM From: "Christian Wimmer" <christ...@nega.at> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Frage zwischendurch: wie lange hält im Durchschnitt eine SD-Karte? Von: volkszaehler-users <volkszaehler-users-boun...@demo.volkszaehler.org> Im Auftrag von Andreas Goetz Gesendet: Montag, 8. Juni 2020 17:34 An: volkszaehler-users <volkszaehler-users@demo.volkszaehler.org> Betreff: Re: [vz-users] Bevorstehender Kartencrash Servus On 8. Jun 2020, at 16:38, Daniel Lauckner <v...@jahp.de> wrote: Hallo, am Montag, 8. Juni 2020 um 11:02 hat John Doe geschrieben: Gibt es ein wiki zum Docker-Image und dessen Installation ? Nein. Also “Installation” ist ja bei Docker relativ :). Wenn Du schmerzresistent bist (und es am Ende dokumentieren möchtest) lass es uns gerne zusammen ausprobieren ;). Das Image heißt volkszaehler/volkszaehler, die Oberfläche+API lauscht dann auf 8080. Die Configdatei muss nach /vz/etc/middleware.json gemappt werden. Falls ich Deinen Weg mit der Datenbank-Installation auf dem NAS gehe: Welche DB-Software würdest Du vorschlagen ? Am besten die SQL-Datenbank was das NAS anbietet. Üblicherweise MySQL oder MariaDB. …oder einfach auch einen Docker Container mit Volume Mount für die Datenablage. Normalerweise sind diese Images deutlich besser als jede NAS-gebundelte Funktionalität und bekommen auch häufigere Updates. Mit freundlichen Grüßen Daniel Viele Grüße, Andreas
Re: [vz-users] Bevorstehender Kartencrash
Hallo zusammen, bevor ich jetzt wieder Mist mit der Datenbank mache, würde ich gerne hier nachfragen. 1. Neuer aufgesetzter VZ läuft zunächst mal wieder auf einem RPi3 wie gewünscht. 2. dbcopy läuft auch, ich kann lokal eine sqlite.db3 anlegen. 3. Da ich noch die Sicherung der alten DB habe (ebenfalls sqlite.db3), würde ich diese mit der aktuellen gerne "mergen". Kann ich das einfach doof und hoffentlich gefahrlos tun, indem ich in der dbcopy.yaml Quelle und Ziel vertausche ? Bleiben meine aktuell schon vorliegenden Daten existent ? Beste Grüße JD. Sent: Tuesday, June 09, 2020 at 9:24 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Christian, On 8. Jun 2020, at 19:46, Christian Wimmer <christ...@nega.at> wrote: Hallo JD Danke, das hört sich gut an. Ich verwende nur Sandisk. Am liebsten würde ich ja die DB auf das NAS auslagern, so dass nur dort geschrieben wird. Aber das liest sich alles so kompliziert. Jetzt verbreitest Du aber ziemliche Panik ;) Eine Datenbank auf dem NAS zu nutzen statt einer Datenbank auf dem Raspi bedeutet einfach nur die Konfigurationsdatei zu ändern (URL, User, Passwort). Wenn Du z.B. schon ein Backup auf dem NAS hättest könnte das direkt Deine “Haupt”Datenbank werden (brauchst Du dann natürlich ein neues Backup). Viele Grüße, Andreas Von: volkszaehler-users <volkszaehler-users-boun...@demo.volkszaehler.org> Im Auftrag von John Doe Gesendet: Montag, 8. Juni 2020 19:15 An: volkszaehler-users@demo.volkszaehler.org Betreff: Re: [vz-users] Bevorstehender Kartencrash Hallo Christian, das hängt wohl auch von der Aggregation-Time ab. Ich glaube aber tendenziell ausgemacht zu haben, dass Sandisk-Karten bei gleicher vzlogger.conf länger halten als Transcend. Erstere lief bei mir über Jahre, letztere einige Monate bis ca. halbes Jahr. Beste Grüße JD. Sent: Monday, June 08, 2020 at 6:13 PM From: "Christian Wimmer" <christ...@nega.at> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Frage zwischendurch: wie lange hält im Durchschnitt eine SD-Karte? Von: volkszaehler-users <volkszaehler-users-boun...@demo.volkszaehler.org> Im Auftrag von Andreas Goetz Gesendet: Montag, 8. Juni 2020 17:34 An: volkszaehler-users <volkszaehler-users@demo.volkszaehler.org> Betreff: Re: [vz-users] Bevorstehender Kartencrash Servus On 8. Jun 2020, at 16:38, Daniel Lauckner <v...@jahp.de> wrote: Hallo, am Montag, 8. Juni 2020 um 11:02 hat John Doe geschrieben: Gibt es ein wiki zum Docker-Image und dessen Installation ? Nein. Also “Installation” ist ja bei Docker relativ :). Wenn Du schmerzresistent bist (und es am Ende dokumentieren möchtest) lass es uns gerne zusammen ausprobieren ;). Das Image heißt volkszaehler/volkszaehler, die Oberfläche+API lauscht dann auf 8080. Die Configdatei muss nach /vz/etc/middleware.json gemappt werden. Falls ich Deinen Weg mit der Datenbank-Installation auf dem NAS gehe: Welche DB-Software würdest Du vorschlagen ? Am besten die SQL-Datenbank was das NAS anbietet. Üblicherweise MySQL oder MariaDB. …oder einfach auch einen Docker Container mit Volume Mount für die Datenablage. Normalerweise sind diese Images deutlich besser als jede NAS-gebundelte Funktionalität und bekommen auch häufigere Updates. Mit freundlichen Grüßen Daniel Viele Grüße, Andreas
Re: [vz-users] Bevorstehender Kartencrash
Hallo zusammen, ein rpi-update brachte einen neuen Kernel: pi@raspberrypi:~ $ uname -a Linux raspberrypi 5.4.44-v7+ #1320 SMP Wed Jun 3 16:07:06 BST 2020 armv7l GNU/Linux Jetzt läuft das auch wieder. Grüße JD. Sent: Monday, June 08, 2020 at 10:00 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo zusammen, der volkszaehler auf einem RPi3 läuft erst mal wieder. Nun wollte ich auch, wie gehabt, meinen mount-Point zum NAS für das DB-Backup wieder einrichten. Ein sudo mount -t cifs //NAS-IP/Freigabe /mountpoint -o user=nasadmin,vers=1.0 liefert nun allerdings mount error: cifs filesystem not supported by the system mount error(19): No such device Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) Ein modprobe cifs liefert modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.19.50-v7+/modules.dep.bin' modprobe: FATAL: Module cifs not found in directory /lib/modules/4.19.50-v7+ Wurde da im Buster-Image mit einem neuen Kernel was geändert ? Beste Grüße JD. Sent: Monday, June 08, 2020 at 9:13 PM From: "G. Stenzel" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Wie wäre es mit einer kleinen SSD (~ 25 €) mit USB-Adapter am Pi direkt oder an einem USB-Hub. Ich habe hier eine 120 GB Kingston A400 am RPi1B mit USB-Hub laufen. Am HUB hängt noch ein Lesekopf und ein 1Wire-Stick (der Pi hat nur 2x USB). >Hallo JD > >Danke, das hört sich gut an. Ich verwende nur Sandisk. > >Am liebsten würde ich ja die DB auf das NAS auslagern, so dass nur dort geschrieben wird. >Aber das liest sich alles so kompliziert. > > > >Von: volkszaehler-users Im Auftrag von John Doe >Gesendet: Montag, 8. Juni 2020 19:15 >An: volkszaehler-users@demo.volkszaehler.org >Betreff: Re: [vz-users] Bevorstehender Kartencrash > >Hallo Christian, > >das hängt wohl auch von der Aggregation-Time ab. Ich glaube aber tendenziell ausgemacht zu haben, dass Sandisk-Karten bei gleicher vzlogger.conf länger halten als Transcend. Erstere lief bei mir über Jahre, letztere einige Monate bis ca. halbes Jahr. >Beste Grüße > >JD. > > >Sent: Monday, June 08, 2020 at 6:13 PM >From: "Christian Wimmer" > >To: "volkszaehler.org - users" > >Subject: Re: [vz-users] Bevorstehender Kartencrash >Hallo > >Frage zwischendurch: wie lange hält im Durchschnitt eine SD-Karte? > > > >Von: volkszaehler-users > Im Auftrag von Andreas Goetz >Gesendet: Montag, 8. Juni 2020 17:34 >An: volkszaehler-users > >Betreff: Re: [vz-users] Bevorstehender Kartencrash > >Servus > > >On 8. Jun 2020, at 16:38, Daniel Lauckner > wrote: > >Hallo, > > >am Montag, 8. Juni 2020 um 11:02 hat John Doe geschrieben: > >Gibt es ein wiki zum Docker-Image und dessen Installation ? > >Nein. > >Also “Installation” ist ja bei Docker relativ :). Wenn Du schmerzresistent bist (und es am Ende dokumentieren möchtest) lass es uns gerne zusammen ausprobieren ;). Das Image heißt volkszaehler/volkszaehler, die Oberfläche+API lauscht dann auf 8080. Die Configdatei muss nach /vz/etc/middleware.json gemappt werden. > >Falls ich Deinen Weg mit der Datenbank-Installation auf dem NAS >gehe: Welche DB-Software würdest Du vorschlagen ? > >Am besten die SQL-Datenbank was das NAS anbietet. >Üblicherweise MySQL oder MariaDB. > >…oder einfach auch einen Docker Container mit Volume Mount für die Datenablage. Normalerweise sind diese Images deutlich besser als jede NAS-gebundelte Funktionalität und bekommen auch häufigere Updates. > > >Mit freundlichen Grüßen >Daniel > >Viele Grüße, Andreas
Re: [vz-users] Bevorstehender Kartencrash
Hallo zusammen, der volkszaehler auf einem RPi3 läuft erst mal wieder. Nun wollte ich auch, wie gehabt, meinen mount-Point zum NAS für das DB-Backup wieder einrichten. Ein sudo mount -t cifs //NAS-IP/Freigabe /mountpoint -o user=nasadmin,vers=1.0 liefert nun allerdings mount error: cifs filesystem not supported by the system mount error(19): No such device Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) Ein modprobe cifs liefert modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.19.50-v7+/modules.dep.bin' modprobe: FATAL: Module cifs not found in directory /lib/modules/4.19.50-v7+ Wurde da im Buster-Image mit einem neuen Kernel was geändert ? Beste Grüße JD. Sent: Monday, June 08, 2020 at 9:13 PM From: "G. Stenzel" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Wie wäre es mit einer kleinen SSD (~ 25 €) mit USB-Adapter am Pi direkt oder an einem USB-Hub. Ich habe hier eine 120 GB Kingston A400 am RPi1B mit USB-Hub laufen. Am HUB hängt noch ein Lesekopf und ein 1Wire-Stick (der Pi hat nur 2x USB). >Hallo JD > >Danke, das hört sich gut an. Ich verwende nur Sandisk. > >Am liebsten würde ich ja die DB auf das NAS auslagern, so dass nur dort geschrieben wird. >Aber das liest sich alles so kompliziert. > > > >Von: volkszaehler-users Im Auftrag von John Doe >Gesendet: Montag, 8. Juni 2020 19:15 >An: volkszaehler-users@demo.volkszaehler.org >Betreff: Re: [vz-users] Bevorstehender Kartencrash > >Hallo Christian, > >das hängt wohl auch von der Aggregation-Time ab. Ich glaube aber tendenziell ausgemacht zu haben, dass Sandisk-Karten bei gleicher vzlogger.conf länger halten als Transcend. Erstere lief bei mir über Jahre, letztere einige Monate bis ca. halbes Jahr. >Beste Grüße > >JD. > > >Sent: Monday, June 08, 2020 at 6:13 PM >From: "Christian Wimmer" > >To: "volkszaehler.org - users" > >Subject: Re: [vz-users] Bevorstehender Kartencrash >Hallo > >Frage zwischendurch: wie lange hält im Durchschnitt eine SD-Karte? > > > >Von: volkszaehler-users > Im Auftrag von Andreas Goetz >Gesendet: Montag, 8. Juni 2020 17:34 >An: volkszaehler-users > >Betreff: Re: [vz-users] Bevorstehender Kartencrash > >Servus > > >On 8. Jun 2020, at 16:38, Daniel Lauckner > wrote: > >Hallo, > > >am Montag, 8. Juni 2020 um 11:02 hat John Doe geschrieben: > >Gibt es ein wiki zum Docker-Image und dessen Installation ? > >Nein. > >Also “Installation” ist ja bei Docker relativ :). Wenn Du schmerzresistent bist (und es am Ende dokumentieren möchtest) lass es uns gerne zusammen ausprobieren ;). Das Image heißt volkszaehler/volkszaehler, die Oberfläche+API lauscht dann auf 8080. Die Configdatei muss nach /vz/etc/middleware.json gemappt werden. > >Falls ich Deinen Weg mit der Datenbank-Installation auf dem NAS >gehe: Welche DB-Software würdest Du vorschlagen ? > >Am besten die SQL-Datenbank was das NAS anbietet. >Üblicherweise MySQL oder MariaDB. > >…oder einfach auch einen Docker Container mit Volume Mount für die Datenablage. Normalerweise sind diese Images deutlich besser als jede NAS-gebundelte Funktionalität und bekommen auch häufigere Updates. > > >Mit freundlichen Grüßen >Daniel > >Viele Grüße, Andreas
Re: [vz-users] Bevorstehender Kartencrash
Hallo Christian, das hängt wohl auch von der Aggregation-Time ab. Ich glaube aber tendenziell ausgemacht zu haben, dass Sandisk-Karten bei gleicher vzlogger.conf länger halten als Transcend. Erstere lief bei mir über Jahre, letztere einige Monate bis ca. halbes Jahr. Beste Grüße JD. Sent: Monday, June 08, 2020 at 6:13 PM From: "Christian Wimmer" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo Frage zwischendurch: wie lange hält im Durchschnitt eine SD-Karte? Von: volkszaehler-users Im Auftrag von Andreas Goetz Gesendet: Montag, 8. Juni 2020 17:34 An: volkszaehler-users Betreff: Re: [vz-users] Bevorstehender Kartencrash Servus On 8. Jun 2020, at 16:38, Daniel Lauckner <v...@jahp.de> wrote: Hallo, am Montag, 8. Juni 2020 um 11:02 hat John Doe geschrieben: Gibt es ein wiki zum Docker-Image und dessen Installation ? Nein. Also “Installation” ist ja bei Docker relativ :). Wenn Du schmerzresistent bist (und es am Ende dokumentieren möchtest) lass es uns gerne zusammen ausprobieren ;). Das Image heißt volkszaehler/volkszaehler, die Oberfläche+API lauscht dann auf 8080. Die Configdatei muss nach /vz/etc/middleware.json gemappt werden. Falls ich Deinen Weg mit der Datenbank-Installation auf dem NAS gehe: Welche DB-Software würdest Du vorschlagen ? Am besten die SQL-Datenbank was das NAS anbietet. Üblicherweise MySQL oder MariaDB. …oder einfach auch einen Docker Container mit Volume Mount für die Datenablage. Normalerweise sind diese Images deutlich besser als jede NAS-gebundelte Funktionalität und bekommen auch häufigere Updates. Mit freundlichen Grüßen Daniel Viele Grüße, Andreas
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, der Tip mit Docker ändert die Lage natürlich grundlegend: In der Tat läuft auf dem NAS schon Docker, bisher mit piHole. Gibt es ein wiki zum Docker-Image und dessen Installation ? Google hat dazu bisher nichts ausgespuckt ... Falls ich Deinen Weg mit der Datenbank-Installation auf dem NAS gehe: Welche DB-Software würdest Du vorschlagen ? Grüße JD. Sent: Monday, June 08, 2020 at 10:56 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hi JD, On 8. Jun 2020, at 10:46, John Doe <john...@null.net> wrote: Hallo Andreas, das Backup landet bereits auf einem NAS, dass per CIFS in den VZ-Raspi gemountet ist (und per cron-Job einmal am Tag läuft). Könntest Du Deinen zweiten Hinweis [...]"Alternativ das Backup per dbcopy aus einer anderen Installation sukzessive einspielen. " eventuell noch ein wenig erläutern ? Mit dbcopy kannst Du zwischen 2 “live” Datenbanken kopieren- das geht natürlich in beide Richtungen. Meintest Du damit, dass ich vorübergehend zwei Raspis installieren soll, den angedachten Produktiv-Raspi schon mal wieder an die Zähler hänge und die alten Daten bzw. das Backup auf dem zweiten Raspi nach und nach in den Produktiv-Raspi schiebe ? Du bräuchtest also den neuen Raspi mit leerer Datenbank und würdest *aus* dem Backup kopieren bis alle Daten drüben sind. Falls ja: Wie bekomme ich die Anbindung zwischen den beiden Systemen hin ? Und wie lagere ich generell die Datenbank auf das NAS aus ? DB auf NAS installieren und die VZ Konfiguration so ändern dass sie auf das NAS statt auf die lokale Datenbank zeigt. Falls Dein NAS Docker kann könntest Du sogar volkszaehler selber auf dem NAS laufen lassen. Beste Grüße JD. Viele Grüße, Andreas Sent: Monday, June 08, 2020 at 10:09 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Moin JD, On 8. Jun 2020, at 10:04, John Doe <john...@null.net> wrote: Hallo zusammen, nachdem mir mal wieder eine Karte abgeraucht ist, wollte ich mich nur kurz nach dem korrekten Procedere für ein Update auf Buster erkundigen. Ich habe ein Backup der Datenbank und eine Kopie der vzlogger.conf. Wie allerdings bekomme ich ersteres (logistisch) auf die Karte ? Evtl. auf einen USB-Stick kopieren, diesen an den Raspi steckern und anschließend per dbrestore wieder einpflegen ? Es sind immerhin ca. 1.6 GB Datenmenge. das wäre eine Möglichkeit. Alternativ das Backup per dbcopy aus einer anderen Installation sukzessive einspielen. Wenn Du ohnehin neu anfängst: überleg doch mal ob Deine DB nicht irgendwo anderswo liegen könnte, z.B. auf einem NAS (falls Du eins hast)? Viele Grüße, Andreas Beste Grüße JD. Sent: Tuesday, December 03, 2019 at 10:04 PM From: "John Doe" <john...@null.net> To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo zusammen, wollte nur kurz Bescheid geben: Ich habe einen Dump zurückgespielt, alles läuft soweit wieder. 1.5 Tage fehlen mir, aber das kann ich verkraften bzw. interpolieren. Als Randeffekt habe ich https://github.com/Drewsif/PiShrink gefunden, da ich ein kleines Problemchen mit der neu beschafften Karte hatte (diese war ein paar Bytes zu klein). Da Skript löst angenehmerweise auch verwaiste inodes auf. Grüße, JD. Sent: Monday, December 02, 2019 at 10:43 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Moin, bzgl. Wiki sollten reinschauen helfen- ich kenne mich da auch nicht aus. Oder einfach mal auf der Kommandozeile schauen welche Parameter “aggregate” so anbietet, Aufruf ähnlich zu dem aus cron. Wenn Du aber einen “guten” Dump hast nimm einfach den- da ist die vollständige Datenbank ja schon drin. Also: - Dump auf neuer Karte wieder herstellen - System hochfahren und testen - Restliche Daten per DBCopy von live System in neues System kopieren Karten tauschen und fertig. Viele Grüße, Andreas On 2. Dec 2019, at 10:36, John Doe <john...@null.net> wrote: Hallo Andreas, danke für die schnelle Meldung. Die Sache mit dem Dump war etwas missverständlich formuliert - ich habe natürlich "offline" gedumpt, also Karte aus dem Raspi. Gibt es für die Aggreegation nach dem DB-Restore ein wiki ? Beste Grüße, JD: Sent: Monday, December 02, 2019 at 10:17 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevo
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, das Backup landet bereits auf einem NAS, dass per CIFS in den VZ-Raspi gemountet ist (und per cron-Job einmal am Tag läuft). Könntest Du Deinen zweiten Hinweis [...]"Alternativ das Backup per dbcopy aus einer anderen Installation sukzessive einspielen. " eventuell noch ein wenig erläutern ? Meintest Du damit, dass ich vorübergehend zwei Raspis installieren soll, den angedachten Produktiv-Raspi schon mal wieder an die Zähler hänge und die alten Daten bzw. das Backup auf dem zweiten Raspi nach und nach in den Produktiv-Raspi schiebe ? Falls ja: Wie bekomme ich die Anbindung zwischen den beiden Systemen hin ? Und wie lagere ich generell die Datenbank auf das NAS aus ? Beste Grüße JD. Sent: Monday, June 08, 2020 at 10:09 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Moin JD, On 8. Jun 2020, at 10:04, John Doe <john...@null.net> wrote: Hallo zusammen, nachdem mir mal wieder eine Karte abgeraucht ist, wollte ich mich nur kurz nach dem korrekten Procedere für ein Update auf Buster erkundigen. Ich habe ein Backup der Datenbank und eine Kopie der vzlogger.conf. Wie allerdings bekomme ich ersteres (logistisch) auf die Karte ? Evtl. auf einen USB-Stick kopieren, diesen an den Raspi steckern und anschließend per dbrestore wieder einpflegen ? Es sind immerhin ca. 1.6 GB Datenmenge. das wäre eine Möglichkeit. Alternativ das Backup per dbcopy aus einer anderen Installation sukzessive einspielen. Wenn Du ohnehin neu anfängst: überleg doch mal ob Deine DB nicht irgendwo anderswo liegen könnte, z.B. auf einem NAS (falls Du eins hast)? Viele Grüße, Andreas Beste Grüße JD. Sent: Tuesday, December 03, 2019 at 10:04 PM From: "John Doe" <john...@null.net> To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo zusammen, wollte nur kurz Bescheid geben: Ich habe einen Dump zurückgespielt, alles läuft soweit wieder. 1.5 Tage fehlen mir, aber das kann ich verkraften bzw. interpolieren. Als Randeffekt habe ich https://github.com/Drewsif/PiShrink gefunden, da ich ein kleines Problemchen mit der neu beschafften Karte hatte (diese war ein paar Bytes zu klein). Da Skript löst angenehmerweise auch verwaiste inodes auf. Grüße, JD. Sent: Monday, December 02, 2019 at 10:43 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Moin, bzgl. Wiki sollten reinschauen helfen- ich kenne mich da auch nicht aus. Oder einfach mal auf der Kommandozeile schauen welche Parameter “aggregate” so anbietet, Aufruf ähnlich zu dem aus cron. Wenn Du aber einen “guten” Dump hast nimm einfach den- da ist die vollständige Datenbank ja schon drin. Also: - Dump auf neuer Karte wieder herstellen - System hochfahren und testen - Restliche Daten per DBCopy von live System in neues System kopieren Karten tauschen und fertig. Viele Grüße, Andreas On 2. Dec 2019, at 10:36, John Doe <john...@null.net> wrote: Hallo Andreas, danke für die schnelle Meldung. Die Sache mit dem Dump war etwas missverständlich formuliert - ich habe natürlich "offline" gedumpt, also Karte aus dem Raspi. Gibt es für die Aggreegation nach dem DB-Restore ein wiki ? Beste Grüße, JD: Sent: Monday, December 02, 2019 at 10:17 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hi Joe, ich bin da unsicher, aber dump eines *laufenden* Systems klingt nicht nach funktionsfähiger Karte!!! Um auf Nummer sicher zu gehen würde ich Dir Neuinstallation vorschlagen und DB Restore mit DBCopy. Damit kannst Du Deltas dann auch nochmal nachfahren bis Du glücklich bist. Anschließend auf dem Zielsystem noch Aggregation einmalig durchführen. Die Dateien werden nicht mitkopiert, das dauert also eine ganze Weile. Erst im Anschluss die cron Jobs für Aggregation einschalten, sonst überholen die sich mit dem Initialaufbau…. Viele Grüße, Andreas On 2. Dec 2019, at 10:07, John Doe <john...@null.net> wrote: Hallo zusammen, bei meinem laufenden Volkszähler scheint sich wieder mal ein Kartencrash anzukündigen (Symptom: frequent steigendes hart Stehenbleiben). Da ich aus "Schmerzen" lerne, habe ich 1. per dbcopy eine tägliche Datensicherung angelegt und 2. heute einen kompletten Dump der aktuell noch laufenden Karte erzeugt. Nun meine Frage: Sollte ich einfach den Dump auf eine neue Karte kopieren oder eine komplette Neuinstallation anlegen, die vzlogger.conf kopieren und die Datenbanksicherung per dbcopy zurückspielen (analog zum Wiki: https://wiki.volkszaehler.org/software/tools/dbcopy) ? Beste Grüße, JD.
Re: [vz-users] Bevorstehender Kartencrash
Hallo zusammen, nachdem mir mal wieder eine Karte abgeraucht ist, wollte ich mich nur kurz nach dem korrekten Procedere für ein Update auf Buster erkundigen. Ich habe ein Backup der Datenbank und eine Kopie der vzlogger.conf. Wie allerdings bekomme ich ersteres (logistisch) auf die Karte ? Evtl. auf einen USB-Stick kopieren, diesen an den Raspi steckern und anschließend per dbrestore wieder einpflegen ? Es sind immerhin ca. 1.6 GB Datenmenge. Beste Grüße JD. Sent: Tuesday, December 03, 2019 at 10:04 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo zusammen, wollte nur kurz Bescheid geben: Ich habe einen Dump zurückgespielt, alles läuft soweit wieder. 1.5 Tage fehlen mir, aber das kann ich verkraften bzw. interpolieren. Als Randeffekt habe ich https://github.com/Drewsif/PiShrink gefunden, da ich ein kleines Problemchen mit der neu beschafften Karte hatte (diese war ein paar Bytes zu klein). Da Skript löst angenehmerweise auch verwaiste inodes auf. Grüße, JD. Sent: Monday, December 02, 2019 at 10:43 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Moin, bzgl. Wiki sollten reinschauen helfen- ich kenne mich da auch nicht aus. Oder einfach mal auf der Kommandozeile schauen welche Parameter “aggregate” so anbietet, Aufruf ähnlich zu dem aus cron. Wenn Du aber einen “guten” Dump hast nimm einfach den- da ist die vollständige Datenbank ja schon drin. Also: - Dump auf neuer Karte wieder herstellen - System hochfahren und testen - Restliche Daten per DBCopy von live System in neues System kopieren Karten tauschen und fertig. Viele Grüße, Andreas On 2. Dec 2019, at 10:36, John Doe <john...@null.net> wrote: Hallo Andreas, danke für die schnelle Meldung. Die Sache mit dem Dump war etwas missverständlich formuliert - ich habe natürlich "offline" gedumpt, also Karte aus dem Raspi. Gibt es für die Aggreegation nach dem DB-Restore ein wiki ? Beste Grüße, JD: Sent: Monday, December 02, 2019 at 10:17 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hi Joe, ich bin da unsicher, aber dump eines *laufenden* Systems klingt nicht nach funktionsfähiger Karte!!! Um auf Nummer sicher zu gehen würde ich Dir Neuinstallation vorschlagen und DB Restore mit DBCopy. Damit kannst Du Deltas dann auch nochmal nachfahren bis Du glücklich bist. Anschließend auf dem Zielsystem noch Aggregation einmalig durchführen. Die Dateien werden nicht mitkopiert, das dauert also eine ganze Weile. Erst im Anschluss die cron Jobs für Aggregation einschalten, sonst überholen die sich mit dem Initialaufbau…. Viele Grüße, Andreas On 2. Dec 2019, at 10:07, John Doe <john...@null.net> wrote: Hallo zusammen, bei meinem laufenden Volkszähler scheint sich wieder mal ein Kartencrash anzukündigen (Symptom: frequent steigendes hart Stehenbleiben). Da ich aus "Schmerzen" lerne, habe ich 1. per dbcopy eine tägliche Datensicherung angelegt und 2. heute einen kompletten Dump der aktuell noch laufenden Karte erzeugt. Nun meine Frage: Sollte ich einfach den Dump auf eine neue Karte kopieren oder eine komplette Neuinstallation anlegen, die vzlogger.conf kopieren und die Datenbanksicherung per dbcopy zurückspielen (analog zum Wiki: https://wiki.volkszaehler.org/software/tools/dbcopy) ? Beste Grüße, JD.
Re: [vz-users] probleme mit fertigem image raspi 3
Versuch' 's mal mit dem Typ "Elektrische Energie" (electric meter). Beste Grüße, JD. Sent: Sunday, March 08, 2020 at 7:48 PM From: "wilhelm" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] probleme mit fertigem image raspi 3 Am 08.03.2020 um 10:05 schrieb wilhelm: Am 07.03.2020 um 17:37 schrieb Andreas Götz: Ich seh keine Bilder? Viele Grüße, Andreas Am 07.03.2020 um 16:56 schrieb wilhelm : Am 06.03.2020 um 19:52 schrieb Andreas Götz: Zeig doch mal bitte die Konfiguration des Zählerstandskanals und zugehörigen vzlogger. Du bist auch socher dass keine konstante Last dran hängt? Welche Leistung wird angezeigt? Viele Grüße, Andreas Am 06.03.2020 um 19:39 schrieb wilhelm : Am 06.03.2020 um 16:55 schrieb wilhelm: Am 06.03.2020 um 16:45 schrieb wilhelm: Am 06.03.2020 um 10:45 schrieb Christian S: Hallo. Bei mir steht Leistungswerte (el. Energy) als Typ powersensor was muss denn dort eingestellt werden ? Wirf mal einen Blick auf die Liste der Kanaltypen. Ich bin mir sicher. Du wirst fündig. Es steht sogar indirekt in der Antwort von Andreas... Grüße Am Fr., 6. März 2020 um 10:27 Uhr schrieb wilhelm: Am 05.03.2020 um 22:46 schrieb Andreas Goetz: > Hallo Dieter, > > Probiers doch einfach mal aus! Bei deinen Zählerständen stimmt der Kanaltyp nicht- bitte ändern, dann siehst Du auch einen Leistungsverlauf. > > Viele Grüße, Andreas > >> Am 05.03.2020 um 22:32 schrieb wilhelm : >> >> Am 05.03.2020 um 21:34 schrieb Daniel Lauckner: >>> Hallo, >>> >>> >>> am Mittwoch, 4. März 2020 um 22:08 hat wilhelm geschrieben: kann es denn sein wenn ich die putty session beende das der Prozess dann gestoppt wird ? normalerweise doch nicht ? >>> Doch. Ein Prozess der von der Kommandozeile gestartet wird und im >>> Vordergrund läuft wird beendet wenn man sich abmeldet. >>> >>> Deswegen ist vzlogger im Image ja auch so eingerichtet das er als >>> Hintergrundprozess (ohne Kommandozeile) läuft. >>> Dazu muss er aber fehlerfrei anlaufen. Richtige Konfig und so... >>> >>> >>> mfg Daniel >>> >> danke für alle hinweise womit ich den Vzlogger zum laufen bringen konnte. >> Nun möchte ich aber folgendes sehen da ich eine pv anlage habe, >> - Welchen Verbrauch habe ich zu einem bestimmten zeitpunkt ( als Grafik) >> - Welche Menge produziere( speise ich ein) ich im gleichen Zeitraum ( als Grafik) >> derzeit werdenm mir nur die Zählerstände mitgeteilt was mehr oder minder eine fast gerade Linie gibt. >> Ich kann nicht erkennen wenn z. B ein großer Verbraucher eingeschaltet wird wie sich das auswirkt. >> Ist dies möglich über virtuelle Kanäle z.B. durch Subtraktion einzelner Kanäle oder welche möglichkeiten gibt es ? >> MfG >> dieter Bei mir steht Leistungswerte (el. Energy) als Typ powersensor was muss denn dort eingestellt werden ? Hier das Bild was sich zeigt immer eine durchgehende linie anstatt eine dem aktuellen Verbrauch bzw der Einspeisung folgende linie s. anhang auch wenn mir vorgeworfen wird ich würde nicht alles lesen so bitte ich um Verständnis für meine manchmal vielleicht dummen nachfragen ,denn ich bin kein Experte wie manche hier . Nach meinem Verständnis kommen ja nur die Kanaltypen Leistungswerte und Zählerstände in Frage mit den ident zahlen 1.80 und 2.80 mit den Kanaltypen habe ich etliches probiert es kommen aber nur gerade Linien heraus ! oder liegt es an dem zeitlichen input der Daten die ja im wie ich glaube 15 sekunden Abstand erfolgen und hierdurch ein anstieg oder Abfall kaum sichtbar wird ? Andererseits sehe ich unter der Spalte Verbrauch jedoch sich ändernde Werte. ich bitte nochmals um Hilfe damit ich endlich zu einem Erfolgserlebnis kommen kann. Danke hier die Bilder für Kanal sowie die Anzeige Frontend und log und die Schaltung des Raspi an den Zähler Soweit ich es beurteilen kann stimmt die Anzeige der Werte im Frontend mit den Werten die der Zähler anzeigt überein. einzig das Problem der Auflösung für die X und Y Achse möchte ich so haben dass ich sehen kann was zu welcher zeit eingespeist wird und was verbraucht wird. Diese Anzeige ist zu grob wie ich ja schon mal bemerkt hatte. Auflösung X achse reicht alle 3- 4 Minuten ein wert und Y Achse im Watt Bereich oberhalb des Erreichetn Wertes. Beispiel: Bezug Grundwert 38 Kw und der Verbrauch oberhalb in Watt Einspeisung Grundwert 11Kw und die darüber hinausgehenden Werte in Watt Wenn ich mir die Werte als CSV datei anzeigen lasse in EXcel kann man erkennen das pro minute ca 40 KW werte geliefert werden. Ich weis nicht ob ich mich verständlich ausgedrückt habe ? da scheint mein Thunderbird automatisch auf text umzustellen daher keine Bilder hier nun erneut mit Bildern Schönen
Re: [vz-users] Manuelles Löschen eines Wertes aus der DB
Hallo Frank, danke für Deine Geduld. Konkret sieht es aus wie folgt: Erste Lücke, ca. drei Stunden. Zweite Lücke, ca. eine Stunde. Dritte Lücke, knapp drei Stunden. Dann der einzelne Peak. Vierte Lücke (direkt hinter dem Peak), ca. 37 Stunden. Danach geht 's normal Werte. Grüße JD. Sent: Friday, February 28, 2020 at 7:47 PM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Um wie viele falsche Werte geht es denn (vom Peak bis zur Lücke)? Wenn du nicht manuell deren Timestamps anpassen willst, musst du die alle löschen. John Doe <john...@null.net> schrieb am Fr., 28. Feb. 2020, 19:43: Hallo Frank, die Lücke existiert und ist ca. 40 Stunden lang ... Der Peak wird aktuell am linken Ende, also zu Beginn der Lücke dargestellt. Welchen Wert der DB sollte ich denn nun wie anpassen ? Grüße JD. Sent: Friday, February 28, 2020 at 7:10 PM From: "Frank Richter" <frank.richte...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Wenn deine Systemzeit vorwärts verstellt wurde, müsstest du das als Lücke im Graph finden können. Wenn du die Darstellung temporär auf "points" änderst, siehst du es leichter. Grüße Frank John Doe <john...@null.net> schrieb am Fr., 28. Feb. 2020, 19:00: Hallo Frank, das mit dem "Verschieben" des Problems/Peaks habe ich mir schon gedacht ... Aber wie finde ich denn den wieder "korrekten" Zeitpunkt ? Der gepostete Ausschnitt ist exakt das, was Dein Tip zur Abfrage ergeben hat, d.h. zwischen der Kante existieren keinerlei andere Werte. Grüße JD. Sent: Friday, February 28, 2020 at 6:48 PM From: "Frank Richter" <frank.richte...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Du hast da offensichtlich Zählerstände mit falschem Timestamp geloggt. Wenn du den ersten davon löschst, verschiebst du den Peak halt zum nächsten Messwert. Du musst den Zeitpunkt finden, wo die Zeit wieder korrekt ist (müsste dann ein längerer Zeitraum ohne Messwerte und mit ungewöhnlichen geringer Leistung sein). Grüße Frank John Doe <john...@null.net> schrieb am Fr., 28. Feb. 2020, 18:10: Hallo Frank, danke für den Tip! Ausschnitt vom Ergebnis der relevanten Phase sieht so aus: | 14285609 | 1 | 1575269994751 | 41139.5769 | | 14285610 | 1 | 1575269996809 | 41139.5787 | | 14285611 | 1 | 1575269998869 | 41139.5805 | | 14285612 | 1 | 157527929 | 41139.5823 | | 14285622 | 1 | 1575270050002 | 41162.974 | | 14285623 | 1 | 1575270052076 | 41162.9756 | | 14285624 | 1 | 1575270054149 | 41162.9772 | Kurioserweise sieht man aber, wie ich schrieb, hier bloß den "normalen" Zählerstand. Im akkumulierten Verbrauch, d.h. in der Jahresansicht der Daten im GUI, sieht man dann den Peak der ja irgendwie aus ca. 13 kWh in einer Millisekunde resultiert. Sollte ich vielleicht doch ein anderes Feld als data betrachten ? Grüße JD. Sent: Friday, February 28, 2020 at 11:06 AM From: "USER VZ" <vz-u...@thhoe.de> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Hallo, in der Datenbank stehen die Werte die du erfasst. Wenn du den Zählerstand abfragst dann steht der auch in der DB. Versuche doch bitte alle Datensätze aus der Zeit des Crashs zu ermitteln. zb: select * from data where channel_id=1 and timestamp>“kurz vor dem crash“ and timestamp<„kurz nach dem peak“ timestamp ist dabei unixtime in Microsekunden. Thomas Am 28.02.2020 um 10:32 schrieb John Doe <john...@null.net>: Hey Jakob, sorry für die späte Rückmeldung. Ein select * from data where channel_id = 1 order by value desc limit 1; bringt bei mir leider keinen (sinnvollen) Output; Database changed MariaDB [volkszaehler]> SELECT * from data where channel_id = 1 order by value desc limit 1; +--++---+--+ | id | channel_id | timestamp | value | +--++---+--+ | 2815 | 1 | 1582879317183 | 42256.52 | +--++---+--+ 1 row in set (11 min 23.290 sec) Mir scheint der value eher den Zählerstand anzugeben, allerdings wollte ich ja den akkumulierten Verbrauch, der aufgrund des DB-Crashs nicht stimmen kann, ändern, z.B. einen Eintrag mit ca. 5 MW(h). Benutze ich vielleicht die falsche DB und/oder das falsche Feld ? Grüße JD. Sent: Wednesday, February 19, 2020 at
Re: [vz-users] Manuelles Löschen eines Wertes aus der DB
Hallo Frank, die Lücke existiert und ist ca. 40 Stunden lang ... Der Peak wird aktuell am linken Ende, also zu Beginn der Lücke dargestellt. Welchen Wert der DB sollte ich denn nun wie anpassen ? Grüße JD. Sent: Friday, February 28, 2020 at 7:10 PM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Wenn deine Systemzeit vorwärts verstellt wurde, müsstest du das als Lücke im Graph finden können. Wenn du die Darstellung temporär auf "points" änderst, siehst du es leichter. Grüße Frank John Doe <john...@null.net> schrieb am Fr., 28. Feb. 2020, 19:00: Hallo Frank, das mit dem "Verschieben" des Problems/Peaks habe ich mir schon gedacht ... Aber wie finde ich denn den wieder "korrekten" Zeitpunkt ? Der gepostete Ausschnitt ist exakt das, was Dein Tip zur Abfrage ergeben hat, d.h. zwischen der Kante existieren keinerlei andere Werte. Grüße JD. Sent: Friday, February 28, 2020 at 6:48 PM From: "Frank Richter" <frank.richte...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Du hast da offensichtlich Zählerstände mit falschem Timestamp geloggt. Wenn du den ersten davon löschst, verschiebst du den Peak halt zum nächsten Messwert. Du musst den Zeitpunkt finden, wo die Zeit wieder korrekt ist (müsste dann ein längerer Zeitraum ohne Messwerte und mit ungewöhnlichen geringer Leistung sein). Grüße Frank John Doe <john...@null.net> schrieb am Fr., 28. Feb. 2020, 18:10: Hallo Frank, danke für den Tip! Ausschnitt vom Ergebnis der relevanten Phase sieht so aus: | 14285609 | 1 | 1575269994751 | 41139.5769 | | 14285610 | 1 | 1575269996809 | 41139.5787 | | 14285611 | 1 | 1575269998869 | 41139.5805 | | 14285612 | 1 | 157527929 | 41139.5823 | | 14285622 | 1 | 1575270050002 | 41162.974 | | 14285623 | 1 | 1575270052076 | 41162.9756 | | 14285624 | 1 | 1575270054149 | 41162.9772 | Kurioserweise sieht man aber, wie ich schrieb, hier bloß den "normalen" Zählerstand. Im akkumulierten Verbrauch, d.h. in der Jahresansicht der Daten im GUI, sieht man dann den Peak der ja irgendwie aus ca. 13 kWh in einer Millisekunde resultiert. Sollte ich vielleicht doch ein anderes Feld als data betrachten ? Grüße JD. Sent: Friday, February 28, 2020 at 11:06 AM From: "USER VZ" <vz-u...@thhoe.de> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Hallo, in der Datenbank stehen die Werte die du erfasst. Wenn du den Zählerstand abfragst dann steht der auch in der DB. Versuche doch bitte alle Datensätze aus der Zeit des Crashs zu ermitteln. zb: select * from data where channel_id=1 and timestamp>“kurz vor dem crash“ and timestamp<„kurz nach dem peak“ timestamp ist dabei unixtime in Microsekunden. Thomas Am 28.02.2020 um 10:32 schrieb John Doe <john...@null.net>: Hey Jakob, sorry für die späte Rückmeldung. Ein select * from data where channel_id = 1 order by value desc limit 1; bringt bei mir leider keinen (sinnvollen) Output; Database changed MariaDB [volkszaehler]> SELECT * from data where channel_id = 1 order by value desc limit 1; +--++---+--+ | id | channel_id | timestamp | value | +--++---+--+ | 2815 | 1 | 1582879317183 | 42256.52 | +--++---+--+ 1 row in set (11 min 23.290 sec) Mir scheint der value eher den Zählerstand anzugeben, allerdings wollte ich ja den akkumulierten Verbrauch, der aufgrund des DB-Crashs nicht stimmen kann, ändern, z.B. einen Eintrag mit ca. 5 MW(h). Benutze ich vielleicht die falsche DB und/oder das falsche Feld ? Grüße JD. Sent: Wednesday, February 19, 2020 at 4:58 PM From: "Jakob Hirsch" <j...@plonk.de> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Hi! On 2020-02-19 11:45, John Doe wrote: > Aber mit meinem Denkansatz > SELECT MAX(value) FROM data WHERE channel_id = 1; > > komme ich irgendwie nicht weiter, da so ja nur der Maximalwert, nicht > aber die zugehörige ID. die ich löschen möchte, ausgegeben wird. select * from data where channel_id = 33 order by value desc limit 1; Aber wenn du den wert schon kennst, kannst du den auch direkt löschen (vorher anschauen): select * from data where channel_id = 33 order by value desc limit 1; und wenn es passt: delete from data where channel_id=1 and value = 12345.6; Gruß J
Re: [vz-users] Manuelles Löschen eines Wertes aus der DB
Hallo Frank, das mit dem "Verschieben" des Problems/Peaks habe ich mir schon gedacht ... Aber wie finde ich denn den wieder "korrekten" Zeitpunkt ? Der gepostete Ausschnitt ist exakt das, was Dein Tip zur Abfrage ergeben hat, d.h. zwischen der Kante existieren keinerlei andere Werte. Grüße JD. Sent: Friday, February 28, 2020 at 6:48 PM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Du hast da offensichtlich Zählerstände mit falschem Timestamp geloggt. Wenn du den ersten davon löschst, verschiebst du den Peak halt zum nächsten Messwert. Du musst den Zeitpunkt finden, wo die Zeit wieder korrekt ist (müsste dann ein längerer Zeitraum ohne Messwerte und mit ungewöhnlichen geringer Leistung sein). Grüße Frank John Doe <john...@null.net> schrieb am Fr., 28. Feb. 2020, 18:10: Hallo Frank, danke für den Tip! Ausschnitt vom Ergebnis der relevanten Phase sieht so aus: | 14285609 | 1 | 1575269994751 | 41139.5769 | | 14285610 | 1 | 1575269996809 | 41139.5787 | | 14285611 | 1 | 1575269998869 | 41139.5805 | | 14285612 | 1 | 157527929 | 41139.5823 | | 14285622 | 1 | 1575270050002 | 41162.974 | | 14285623 | 1 | 1575270052076 | 41162.9756 | | 14285624 | 1 | 1575270054149 | 41162.9772 | Kurioserweise sieht man aber, wie ich schrieb, hier bloß den "normalen" Zählerstand. Im akkumulierten Verbrauch, d.h. in der Jahresansicht der Daten im GUI, sieht man dann den Peak der ja irgendwie aus ca. 13 kWh in einer Millisekunde resultiert. Sollte ich vielleicht doch ein anderes Feld als data betrachten ? Grüße JD. Sent: Friday, February 28, 2020 at 11:06 AM From: "USER VZ" <vz-u...@thhoe.de> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Hallo, in der Datenbank stehen die Werte die du erfasst. Wenn du den Zählerstand abfragst dann steht der auch in der DB. Versuche doch bitte alle Datensätze aus der Zeit des Crashs zu ermitteln. zb: select * from data where channel_id=1 and timestamp>“kurz vor dem crash“ and timestamp<„kurz nach dem peak“ timestamp ist dabei unixtime in Microsekunden. Thomas Am 28.02.2020 um 10:32 schrieb John Doe <john...@null.net>: Hey Jakob, sorry für die späte Rückmeldung. Ein select * from data where channel_id = 1 order by value desc limit 1; bringt bei mir leider keinen (sinnvollen) Output; Database changed MariaDB [volkszaehler]> SELECT * from data where channel_id = 1 order by value desc limit 1; +--++---+--+ | id | channel_id | timestamp | value | +--++---+--+ | 2815 | 1 | 1582879317183 | 42256.52 | +--++---+--+ 1 row in set (11 min 23.290 sec) Mir scheint der value eher den Zählerstand anzugeben, allerdings wollte ich ja den akkumulierten Verbrauch, der aufgrund des DB-Crashs nicht stimmen kann, ändern, z.B. einen Eintrag mit ca. 5 MW(h). Benutze ich vielleicht die falsche DB und/oder das falsche Feld ? Grüße JD. Sent: Wednesday, February 19, 2020 at 4:58 PM From: "Jakob Hirsch" <j...@plonk.de> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Hi! On 2020-02-19 11:45, John Doe wrote: > Aber mit meinem Denkansatz > SELECT MAX(value) FROM data WHERE channel_id = 1; > > komme ich irgendwie nicht weiter, da so ja nur der Maximalwert, nicht > aber die zugehörige ID. die ich löschen möchte, ausgegeben wird. select * from data where channel_id = 33 order by value desc limit 1; Aber wenn du den wert schon kennst, kannst du den auch direkt löschen (vorher anschauen): select * from data where channel_id = 33 order by value desc limit 1; und wenn es passt: delete from data where channel_id=1 and value = 12345.6; Gruß J
Re: [vz-users] Manuelles Löschen eines Wertes aus der DB
Hallo Frank, danke für den Tip! Ausschnitt vom Ergebnis der relevanten Phase sieht so aus: | 14285609 | 1 | 1575269994751 | 41139.5769 | | 14285610 | 1 | 1575269996809 | 41139.5787 | | 14285611 | 1 | 1575269998869 | 41139.5805 | | 14285612 | 1 | 157527929 | 41139.5823 | | 14285622 | 1 | 1575270050002 | 41162.974 | | 14285623 | 1 | 1575270052076 | 41162.9756 | | 14285624 | 1 | 1575270054149 | 41162.9772 | Kurioserweise sieht man aber, wie ich schrieb, hier bloß den "normalen" Zählerstand. Im akkumulierten Verbrauch, d.h. in der Jahresansicht der Daten im GUI, sieht man dann den Peak der ja irgendwie aus ca. 13 kWh in einer Millisekunde resultiert. Sollte ich vielleicht doch ein anderes Feld als data betrachten ? Grüße JD. Sent: Friday, February 28, 2020 at 11:06 AM From: "USER VZ" To: "volkszaehler.org - users" Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Hallo, in der Datenbank stehen die Werte die du erfasst. Wenn du den Zählerstand abfragst dann steht der auch in der DB. Versuche doch bitte alle Datensätze aus der Zeit des Crashs zu ermitteln. zb: select * from data where channel_id=1 and timestamp>“kurz vor dem crash“ and timestamp<„kurz nach dem peak“ timestamp ist dabei unixtime in Microsekunden. Thomas Am 28.02.2020 um 10:32 schrieb John Doe : Hey Jakob, sorry für die späte Rückmeldung. Ein select * from data where channel_id = 1 order by value desc limit 1; bringt bei mir leider keinen (sinnvollen) Output; Database changed MariaDB [volkszaehler]> SELECT * from data where channel_id = 1 order by value desc limit 1; +--++---+--+ | id | channel_id | timestamp | value | +--++---+--+ | 2815 | 1 | 1582879317183 | 42256.52 | +--++---+--+ 1 row in set (11 min 23.290 sec) Mir scheint der value eher den Zählerstand anzugeben, allerdings wollte ich ja den akkumulierten Verbrauch, der aufgrund des DB-Crashs nicht stimmen kann, ändern, z.B. einen Eintrag mit ca. 5 MW(h). Benutze ich vielleicht die falsche DB und/oder das falsche Feld ? Grüße JD. Sent: Wednesday, February 19, 2020 at 4:58 PM From: "Jakob Hirsch" To: "volkszaehler.org - users" Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Hi! On 2020-02-19 11:45, John Doe wrote: > Aber mit meinem Denkansatz > SELECT MAX(value) FROM data WHERE channel_id = 1; > > komme ich irgendwie nicht weiter, da so ja nur der Maximalwert, nicht > aber die zugehörige ID. die ich löschen möchte, ausgegeben wird. select * from data where channel_id = 33 order by value desc limit 1; Aber wenn du den wert schon kennst, kannst du den auch direkt löschen (vorher anschauen): select * from data where channel_id = 33 order by value desc limit 1; und wenn es passt: delete from data where channel_id=1 and value = 12345.6; Gruß J
Re: [vz-users] Manuelles Löschen eines Wertes aus der DB
Hey Jakob, sorry für die späte Rückmeldung. Ein select * from data where channel_id = 1 order by value desc limit 1; bringt bei mir leider keinen (sinnvollen) Output; Database changed MariaDB [volkszaehler]> SELECT * from data where channel_id = 1 order by value desc limit 1; +--++---+--+ | id | channel_id | timestamp | value | +--++---+--+ | 2815 | 1 | 1582879317183 | 42256.52 | +--++---+--+ 1 row in set (11 min 23.290 sec) Mir scheint der value eher den Zählerstand anzugeben, allerdings wollte ich ja den akkumulierten Verbrauch, der aufgrund des DB-Crashs nicht stimmen kann, ändern, z.B. einen Eintrag mit ca. 5 MW(h). Benutze ich vielleicht die falsche DB und/oder das falsche Feld ? Grüße JD. Sent: Wednesday, February 19, 2020 at 4:58 PM From: "Jakob Hirsch" To: "volkszaehler.org - users" Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Hi! On 2020-02-19 11:45, John Doe wrote: > Aber mit meinem Denkansatz > SELECT MAX(value) FROM data WHERE channel_id = 1; > > komme ich irgendwie nicht weiter, da so ja nur der Maximalwert, nicht > aber die zugehörige ID. die ich löschen möchte, ausgegeben wird. select * from data where channel_id = 33 order by value desc limit 1; Aber wenn du den wert schon kennst, kannst du den auch direkt löschen (vorher anschauen): select * from data where channel_id = 33 order by value desc limit 1; und wenn es passt: delete from data where channel_id=1 and value = 12345.6; Gruß J
Re: [vz-users] Manuelles Löschen eines Wertes aus der DB
Okay, und wofür steht in Deinem zweiten Link der Parameter value ? Grüße JD. Sent: Wednesday, February 19, 2020 at 3:07 PM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB VZ benutzt grundsätzlich keine Datenbank-IDs. Bei from und to funktionieren entweder Unix-Timestamps in ms oder alles was PHP sonst als Zeitangabe versteht. John Doe <john...@null.net> schrieb am Mi., 19. Feb. 2020, 14:55: Okay, ich versuche präziser zu formuliern . ;-) Den ersten Deiner Links habe ich mit timestamps getestet, ohne zunächst etwas zu löschen, sondern um, wie von Dir vorgeschlagen, erst mal den richtigen Bereich zu ermitteln. Hat geklappt, d.h. ich habe einen einzelnen Wert gefunden, der den erwähnten Peak repräsentiert. Nun meine Frage: Steht der value-Parameter in Deinem zweiten Link auch für einen timestamp, oder doch für eine Datenbank-ID? Grüße JD. Sent: Wednesday, February 19, 2020 at 2:43 PM From: "Frank Richter" <frank.richte...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Ich befürchte ich verstehe die Frage nicht. Grüße Frank John Doe <john...@null.net> schrieb am Mi., 19. Feb. 2020, 14:19: Hallo Frank, muss/kann ich in beiden Fällen timestamps verwenden oder nur für den from..to..-Fall ? Ich frage, da ich glaube, mit der from=...=...-Auswahl die einzelnen problematischen Daten gefunden zu haben. Grüße JD. Sent: Wednesday, February 19, 2020 at 12:36 PM From: "Frank Richter" <frank.richte...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Du musst dort sogar Timestamps eintragen... John Doe <john...@null.net> schrieb am Mi., 19. Feb. 2020, 12:33: Hallo Frank, exakt die Einträge hinter from=... und to=... versuchte ich ja über die Konsole zu ermitteln, also idealerweise die ID des einen Peaks ... Oder kann ich da auch timestamps eintragen ? Grüße JD. Sent: Wednesday, February 19, 2020 at 12:27 PM From: "Frank Richter" <frank.richte...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB z.B.: http://IP/middleware.php/data/UUID.json?from=...=...=delete oder: http://IP/middleware.php/data/UUID.json?value=...=delete Vorher ohne operation=delete testen, ob die richtigen Datensätze selektiert werden. Grüße Frank John Doe <john...@null.net> schrieb am Mi., 19. Feb. 2020, 12:08: Hallo Andreas, besten Dank für den Tip. Hättest Du evtl. auch noch ein bis zwei weitere Infos, wikis hierzu oder dergleichen ? Grüße JD. Sent: Wednesday, February 19, 2020 at 11:56 AM From: "Andreas Götz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Lösch einfach über das Api- dann musst Du Dir diese ganzen Fragen nicht stellen Viele Grüße, Andreas Am 19.02.2020 um 11:45 schrieb John Doe <john...@null.net>: Hallo zusammen, kleines Update: Ich habe es schon mal auf der Konsole bis hierhin geschafft: mysql -u root SHOW DATABASES; USE volkszaehler; SHOW TABLES FROM volkszaehler; SHOW FILEDS FROM data; Aber mit meinem Denkansatz SELECT MAX(value) FROM data WHERE channel_id = 1; komme ich irgendwie nicht weiter, da so ja nur der Maximalwert, nicht aber die zugehörige ID. die ich löschen möchte, ausgegeben wird. Hat jemand noch einen Tip, wie ich das bewerkstelligen könnte ? Grüße JD. Sent: Wednesday, February 19, 2020 at 9:52 AM From: "John Doe" <john...@null.net> To: volkszaehler-users@demo.volkszaehler.org Subject: [vz-users] Manuelles Löschen eines Wertes aus der DB Hallo zusammen, nach einem kleinen Versehen aufgrund eines Kartencrashs/-wechsels habe ich nun einen unschönen "Peak" in meinen Daten. Hat jemand einen Tip für mich, wie ich diesen einen Wert manuell aus der DB löschen kann, wahlweise direkt auf der Konsole im SQL oder über phpmaAdmin ? Bitte entschuldigt, wenn ich mich jetzt nicht konkret in die Tiefen der DB-Struktur und -organisationen eingearbeitet habe ... Grüße JD.
Re: [vz-users] Manuelles Löschen eines Wertes aus der DB
Okay, ich versuche präziser zu formuliern . ;-) Den ersten Deiner Links habe ich mit timestamps getestet, ohne zunächst etwas zu löschen, sondern um, wie von Dir vorgeschlagen, erst mal den richtigen Bereich zu ermitteln. Hat geklappt, d.h. ich habe einen einzelnen Wert gefunden, der den erwähnten Peak repräsentiert. Nun meine Frage: Steht der value-Parameter in Deinem zweiten Link auch für einen timestamp, oder doch für eine Datenbank-ID? Grüße JD. Sent: Wednesday, February 19, 2020 at 2:43 PM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Ich befürchte ich verstehe die Frage nicht. Grüße Frank John Doe <john...@null.net> schrieb am Mi., 19. Feb. 2020, 14:19: Hallo Frank, muss/kann ich in beiden Fällen timestamps verwenden oder nur für den from..to..-Fall ? Ich frage, da ich glaube, mit der from=...=...-Auswahl die einzelnen problematischen Daten gefunden zu haben. Grüße JD. Sent: Wednesday, February 19, 2020 at 12:36 PM From: "Frank Richter" <frank.richte...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Du musst dort sogar Timestamps eintragen... John Doe <john...@null.net> schrieb am Mi., 19. Feb. 2020, 12:33: Hallo Frank, exakt die Einträge hinter from=... und to=... versuchte ich ja über die Konsole zu ermitteln, also idealerweise die ID des einen Peaks ... Oder kann ich da auch timestamps eintragen ? Grüße JD. Sent: Wednesday, February 19, 2020 at 12:27 PM From: "Frank Richter" <frank.richte...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB z.B.: http://IP/middleware.php/data/UUID.json?from=...=...=delete oder: http://IP/middleware.php/data/UUID.json?value=...=delete Vorher ohne operation=delete testen, ob die richtigen Datensätze selektiert werden. Grüße Frank John Doe <john...@null.net> schrieb am Mi., 19. Feb. 2020, 12:08: Hallo Andreas, besten Dank für den Tip. Hättest Du evtl. auch noch ein bis zwei weitere Infos, wikis hierzu oder dergleichen ? Grüße JD. Sent: Wednesday, February 19, 2020 at 11:56 AM From: "Andreas Götz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Lösch einfach über das Api- dann musst Du Dir diese ganzen Fragen nicht stellen Viele Grüße, Andreas Am 19.02.2020 um 11:45 schrieb John Doe <john...@null.net>: Hallo zusammen, kleines Update: Ich habe es schon mal auf der Konsole bis hierhin geschafft: mysql -u root SHOW DATABASES; USE volkszaehler; SHOW TABLES FROM volkszaehler; SHOW FILEDS FROM data; Aber mit meinem Denkansatz SELECT MAX(value) FROM data WHERE channel_id = 1; komme ich irgendwie nicht weiter, da so ja nur der Maximalwert, nicht aber die zugehörige ID. die ich löschen möchte, ausgegeben wird. Hat jemand noch einen Tip, wie ich das bewerkstelligen könnte ? Grüße JD. Sent: Wednesday, February 19, 2020 at 9:52 AM From: "John Doe" <john...@null.net> To: volkszaehler-users@demo.volkszaehler.org Subject: [vz-users] Manuelles Löschen eines Wertes aus der DB Hallo zusammen, nach einem kleinen Versehen aufgrund eines Kartencrashs/-wechsels habe ich nun einen unschönen "Peak" in meinen Daten. Hat jemand einen Tip für mich, wie ich diesen einen Wert manuell aus der DB löschen kann, wahlweise direkt auf der Konsole im SQL oder über phpmaAdmin ? Bitte entschuldigt, wenn ich mich jetzt nicht konkret in die Tiefen der DB-Struktur und -organisationen eingearbeitet habe ... Grüße JD.
Re: [vz-users] Manuelles Löschen eines Wertes aus der DB
Hallo Frank, muss/kann ich in beiden Fällen timestamps verwenden oder nur für den from..to..-Fall ? Ich frage, da ich glaube, mit der from=...=...-Auswahl die einzelnen problematischen Daten gefunden zu haben. Grüße JD. Sent: Wednesday, February 19, 2020 at 12:36 PM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Du musst dort sogar Timestamps eintragen... John Doe <john...@null.net> schrieb am Mi., 19. Feb. 2020, 12:33: Hallo Frank, exakt die Einträge hinter from=... und to=... versuchte ich ja über die Konsole zu ermitteln, also idealerweise die ID des einen Peaks ... Oder kann ich da auch timestamps eintragen ? Grüße JD. Sent: Wednesday, February 19, 2020 at 12:27 PM From: "Frank Richter" <frank.richte...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB z.B.: http://IP/middleware.php/data/UUID.json?from=...=...=delete oder: http://IP/middleware.php/data/UUID.json?value=...=delete Vorher ohne operation=delete testen, ob die richtigen Datensätze selektiert werden. Grüße Frank John Doe <john...@null.net> schrieb am Mi., 19. Feb. 2020, 12:08: Hallo Andreas, besten Dank für den Tip. Hättest Du evtl. auch noch ein bis zwei weitere Infos, wikis hierzu oder dergleichen ? Grüße JD. Sent: Wednesday, February 19, 2020 at 11:56 AM From: "Andreas Götz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Lösch einfach über das Api- dann musst Du Dir diese ganzen Fragen nicht stellen Viele Grüße, Andreas Am 19.02.2020 um 11:45 schrieb John Doe <john...@null.net>: Hallo zusammen, kleines Update: Ich habe es schon mal auf der Konsole bis hierhin geschafft: mysql -u root SHOW DATABASES; USE volkszaehler; SHOW TABLES FROM volkszaehler; SHOW FILEDS FROM data; Aber mit meinem Denkansatz SELECT MAX(value) FROM data WHERE channel_id = 1; komme ich irgendwie nicht weiter, da so ja nur der Maximalwert, nicht aber die zugehörige ID. die ich löschen möchte, ausgegeben wird. Hat jemand noch einen Tip, wie ich das bewerkstelligen könnte ? Grüße JD. Sent: Wednesday, February 19, 2020 at 9:52 AM From: "John Doe" <john...@null.net> To: volkszaehler-users@demo.volkszaehler.org Subject: [vz-users] Manuelles Löschen eines Wertes aus der DB Hallo zusammen, nach einem kleinen Versehen aufgrund eines Kartencrashs/-wechsels habe ich nun einen unschönen "Peak" in meinen Daten. Hat jemand einen Tip für mich, wie ich diesen einen Wert manuell aus der DB löschen kann, wahlweise direkt auf der Konsole im SQL oder über phpmaAdmin ? Bitte entschuldigt, wenn ich mich jetzt nicht konkret in die Tiefen der DB-Struktur und -organisationen eingearbeitet habe ... Grüße JD.
Re: [vz-users] Manuelles Löschen eines Wertes aus der DB
Hallo Frank, exakt die Einträge hinter from=... und to=... versuchte ich ja über die Konsole zu ermitteln, also idealerweise die ID des einen Peaks ... Oder kann ich da auch timestamps eintragen ? Grüße JD. Sent: Wednesday, February 19, 2020 at 12:27 PM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB z.B.: http://IP/middleware.php/data/UUID.json?from=...=...=delete oder: http://IP/middleware.php/data/UUID.json?value=...=delete Vorher ohne operation=delete testen, ob die richtigen Datensätze selektiert werden. Grüße Frank John Doe <john...@null.net> schrieb am Mi., 19. Feb. 2020, 12:08: Hallo Andreas, besten Dank für den Tip. Hättest Du evtl. auch noch ein bis zwei weitere Infos, wikis hierzu oder dergleichen ? Grüße JD. Sent: Wednesday, February 19, 2020 at 11:56 AM From: "Andreas Götz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Lösch einfach über das Api- dann musst Du Dir diese ganzen Fragen nicht stellen Viele Grüße, Andreas Am 19.02.2020 um 11:45 schrieb John Doe <john...@null.net>: Hallo zusammen, kleines Update: Ich habe es schon mal auf der Konsole bis hierhin geschafft: mysql -u root SHOW DATABASES; USE volkszaehler; SHOW TABLES FROM volkszaehler; SHOW FILEDS FROM data; Aber mit meinem Denkansatz SELECT MAX(value) FROM data WHERE channel_id = 1; komme ich irgendwie nicht weiter, da so ja nur der Maximalwert, nicht aber die zugehörige ID. die ich löschen möchte, ausgegeben wird. Hat jemand noch einen Tip, wie ich das bewerkstelligen könnte ? Grüße JD. Sent: Wednesday, February 19, 2020 at 9:52 AM From: "John Doe" <john...@null.net> To: volkszaehler-users@demo.volkszaehler.org Subject: [vz-users] Manuelles Löschen eines Wertes aus der DB Hallo zusammen, nach einem kleinen Versehen aufgrund eines Kartencrashs/-wechsels habe ich nun einen unschönen "Peak" in meinen Daten. Hat jemand einen Tip für mich, wie ich diesen einen Wert manuell aus der DB löschen kann, wahlweise direkt auf der Konsole im SQL oder über phpmaAdmin ? Bitte entschuldigt, wenn ich mich jetzt nicht konkret in die Tiefen der DB-Struktur und -organisationen eingearbeitet habe ... Grüße JD.
Re: [vz-users] Manuelles Löschen eines Wertes aus der DB
Hallo Andreas, besten Dank für den Tip. Hättest Du evtl. auch noch ein bis zwei weitere Infos, wikis hierzu oder dergleichen ? Grüße JD. Sent: Wednesday, February 19, 2020 at 11:56 AM From: "Andreas Götz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Manuelles Löschen eines Wertes aus der DB Lösch einfach über das Api- dann musst Du Dir diese ganzen Fragen nicht stellen Viele Grüße, Andreas Am 19.02.2020 um 11:45 schrieb John Doe : Hallo zusammen, kleines Update: Ich habe es schon mal auf der Konsole bis hierhin geschafft: mysql -u root SHOW DATABASES; USE volkszaehler; SHOW TABLES FROM volkszaehler; SHOW FILEDS FROM data; Aber mit meinem Denkansatz SELECT MAX(value) FROM data WHERE channel_id = 1; komme ich irgendwie nicht weiter, da so ja nur der Maximalwert, nicht aber die zugehörige ID. die ich löschen möchte, ausgegeben wird. Hat jemand noch einen Tip, wie ich das bewerkstelligen könnte ? Grüße JD. Sent: Wednesday, February 19, 2020 at 9:52 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: [vz-users] Manuelles Löschen eines Wertes aus der DB Hallo zusammen, nach einem kleinen Versehen aufgrund eines Kartencrashs/-wechsels habe ich nun einen unschönen "Peak" in meinen Daten. Hat jemand einen Tip für mich, wie ich diesen einen Wert manuell aus der DB löschen kann, wahlweise direkt auf der Konsole im SQL oder über phpmaAdmin ? Bitte entschuldigt, wenn ich mich jetzt nicht konkret in die Tiefen der DB-Struktur und -organisationen eingearbeitet habe ... Grüße JD.
Re: [vz-users] Manuelles Löschen eines Wertes aus der DB
Hallo zusammen, kleines Update: Ich habe es schon mal auf der Konsole bis hierhin geschafft: mysql -u root SHOW DATABASES; USE volkszaehler; SHOW TABLES FROM volkszaehler; SHOW FILEDS FROM data; Aber mit meinem Denkansatz SELECT MAX(value) FROM data WHERE channel_id = 1; komme ich irgendwie nicht weiter, da so ja nur der Maximalwert, nicht aber die zugehörige ID. die ich löschen möchte, ausgegeben wird. Hat jemand noch einen Tip, wie ich das bewerkstelligen könnte ? Grüße JD. Sent: Wednesday, February 19, 2020 at 9:52 AM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: [vz-users] Manuelles Löschen eines Wertes aus der DB Hallo zusammen, nach einem kleinen Versehen aufgrund eines Kartencrashs/-wechsels habe ich nun einen unschönen "Peak" in meinen Daten. Hat jemand einen Tip für mich, wie ich diesen einen Wert manuell aus der DB löschen kann, wahlweise direkt auf der Konsole im SQL oder über phpmaAdmin ? Bitte entschuldigt, wenn ich mich jetzt nicht konkret in die Tiefen der DB-Struktur und -organisationen eingearbeitet habe ... Grüße JD.
[vz-users] Manuelles Löschen eines Wertes aus der DB
Hallo zusammen, nach einem kleinen Versehen aufgrund eines Kartencrashs/-wechsels habe ich nun einen unschönen "Peak" in meinen Daten. Hat jemand einen Tip für mich, wie ich diesen einen Wert manuell aus der DB löschen kann, wahlweise direkt auf der Konsole im SQL oder über phpmaAdmin ? Bitte entschuldigt, wenn ich mich jetzt nicht konkret in die Tiefen der DB-Struktur und -organisationen eingearbeitet habe ... Grüße JD.
Re: [vz-users] Bevorstehender Kartencrash
Hallo zusammen, wollte nur kurz Bescheid geben: Ich habe einen Dump zurückgespielt, alles läuft soweit wieder. 1.5 Tage fehlen mir, aber das kann ich verkraften bzw. interpolieren. Als Randeffekt habe ich https://github.com/Drewsif/PiShrink gefunden, da ich ein kleines Problemchen mit der neu beschafften Karte hatte (diese war ein paar Bytes zu klein). Da Skript löst angenehmerweise auch verwaiste inodes auf. Grüße, JD. Sent: Monday, December 02, 2019 at 10:43 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Moin, bzgl. Wiki sollten reinschauen helfen- ich kenne mich da auch nicht aus. Oder einfach mal auf der Kommandozeile schauen welche Parameter “aggregate” so anbietet, Aufruf ähnlich zu dem aus cron. Wenn Du aber einen “guten” Dump hast nimm einfach den- da ist die vollständige Datenbank ja schon drin. Also: - Dump auf neuer Karte wieder herstellen - System hochfahren und testen - Restliche Daten per DBCopy von live System in neues System kopieren Karten tauschen und fertig. Viele Grüße, Andreas On 2. Dec 2019, at 10:36, John Doe <john...@null.net> wrote: Hallo Andreas, danke für die schnelle Meldung. Die Sache mit dem Dump war etwas missverständlich formuliert - ich habe natürlich "offline" gedumpt, also Karte aus dem Raspi. Gibt es für die Aggreegation nach dem DB-Restore ein wiki ? Beste Grüße, JD: Sent: Monday, December 02, 2019 at 10:17 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hi Joe, ich bin da unsicher, aber dump eines *laufenden* Systems klingt nicht nach funktionsfähiger Karte!!! Um auf Nummer sicher zu gehen würde ich Dir Neuinstallation vorschlagen und DB Restore mit DBCopy. Damit kannst Du Deltas dann auch nochmal nachfahren bis Du glücklich bist. Anschließend auf dem Zielsystem noch Aggregation einmalig durchführen. Die Dateien werden nicht mitkopiert, das dauert also eine ganze Weile. Erst im Anschluss die cron Jobs für Aggregation einschalten, sonst überholen die sich mit dem Initialaufbau…. Viele Grüße, Andreas On 2. Dec 2019, at 10:07, John Doe <john...@null.net> wrote: Hallo zusammen, bei meinem laufenden Volkszähler scheint sich wieder mal ein Kartencrash anzukündigen (Symptom: frequent steigendes hart Stehenbleiben). Da ich aus "Schmerzen" lerne, habe ich 1. per dbcopy eine tägliche Datensicherung angelegt und 2. heute einen kompletten Dump der aktuell noch laufenden Karte erzeugt. Nun meine Frage: Sollte ich einfach den Dump auf eine neue Karte kopieren oder eine komplette Neuinstallation anlegen, die vzlogger.conf kopieren und die Datenbanksicherung per dbcopy zurückspielen (analog zum Wiki: https://wiki.volkszaehler.org/software/tools/dbcopy) ? Beste Grüße, JD.
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, so mach ich 's. Ich werde spätestens übermorgen wieder berichten, wenn die neuen Karten da sind. Beste Grüße, JD. Sent: Monday, December 02, 2019 at 10:43 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Moin, bzgl. Wiki sollten reinschauen helfen- ich kenne mich da auch nicht aus. Oder einfach mal auf der Kommandozeile schauen welche Parameter “aggregate” so anbietet, Aufruf ähnlich zu dem aus cron. Wenn Du aber einen “guten” Dump hast nimm einfach den- da ist die vollständige Datenbank ja schon drin. Also: - Dump auf neuer Karte wieder herstellen - System hochfahren und testen - Restliche Daten per DBCopy von live System in neues System kopieren Karten tauschen und fertig. Viele Grüße, Andreas On 2. Dec 2019, at 10:36, John Doe <john...@null.net> wrote: Hallo Andreas, danke für die schnelle Meldung. Die Sache mit dem Dump war etwas missverständlich formuliert - ich habe natürlich "offline" gedumpt, also Karte aus dem Raspi. Gibt es für die Aggreegation nach dem DB-Restore ein wiki ? Beste Grüße, JD: Sent: Monday, December 02, 2019 at 10:17 AM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] Bevorstehender Kartencrash Hi Joe, ich bin da unsicher, aber dump eines *laufenden* Systems klingt nicht nach funktionsfähiger Karte!!! Um auf Nummer sicher zu gehen würde ich Dir Neuinstallation vorschlagen und DB Restore mit DBCopy. Damit kannst Du Deltas dann auch nochmal nachfahren bis Du glücklich bist. Anschließend auf dem Zielsystem noch Aggregation einmalig durchführen. Die Dateien werden nicht mitkopiert, das dauert also eine ganze Weile. Erst im Anschluss die cron Jobs für Aggregation einschalten, sonst überholen die sich mit dem Initialaufbau…. Viele Grüße, Andreas On 2. Dec 2019, at 10:07, John Doe <john...@null.net> wrote: Hallo zusammen, bei meinem laufenden Volkszähler scheint sich wieder mal ein Kartencrash anzukündigen (Symptom: frequent steigendes hart Stehenbleiben). Da ich aus "Schmerzen" lerne, habe ich 1. per dbcopy eine tägliche Datensicherung angelegt und 2. heute einen kompletten Dump der aktuell noch laufenden Karte erzeugt. Nun meine Frage: Sollte ich einfach den Dump auf eine neue Karte kopieren oder eine komplette Neuinstallation anlegen, die vzlogger.conf kopieren und die Datenbanksicherung per dbcopy zurückspielen (analog zum Wiki: https://wiki.volkszaehler.org/software/tools/dbcopy) ? Beste Grüße, JD.
Re: [vz-users] Bevorstehender Kartencrash
Hallo Andreas, danke für die schnelle Meldung. Die Sache mit dem Dump war etwas missverständlich formuliert - ich habe natürlich "offline" gedumpt, also Karte aus dem Raspi. Gibt es für die Aggreegation nach dem DB-Restore ein wiki ? Beste Grüße, JD: Sent: Monday, December 02, 2019 at 10:17 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Hi Joe, ich bin da unsicher, aber dump eines *laufenden* Systems klingt nicht nach funktionsfähiger Karte!!! Um auf Nummer sicher zu gehen würde ich Dir Neuinstallation vorschlagen und DB Restore mit DBCopy. Damit kannst Du Deltas dann auch nochmal nachfahren bis Du glücklich bist. Anschließend auf dem Zielsystem noch Aggregation einmalig durchführen. Die Dateien werden nicht mitkopiert, das dauert also eine ganze Weile. Erst im Anschluss die cron Jobs für Aggregation einschalten, sonst überholen die sich mit dem Initialaufbau…. Viele Grüße, Andreas On 2. Dec 2019, at 10:07, John Doe <john...@null.net> wrote: Hallo zusammen, bei meinem laufenden Volkszähler scheint sich wieder mal ein Kartencrash anzukündigen (Symptom: frequent steigendes hart Stehenbleiben). Da ich aus "Schmerzen" lerne, habe ich 1. per dbcopy eine tägliche Datensicherung angelegt und 2. heute einen kompletten Dump der aktuell noch laufenden Karte erzeugt. Nun meine Frage: Sollte ich einfach den Dump auf eine neue Karte kopieren oder eine komplette Neuinstallation anlegen, die vzlogger.conf kopieren und die Datenbanksicherung per dbcopy zurückspielen (analog zum Wiki: https://wiki.volkszaehler.org/software/tools/dbcopy) ? Beste Grüße, JD.
[vz-users] Bevorstehender Kartencrash
Hallo zusammen, bei meinem laufenden Volkszähler scheint sich wieder mal ein Kartencrash anzukündigen (Symptom: frequent steigendes hart Stehenbleiben). Da ich aus "Schmerzen" lerne, habe ich 1. per dbcopy eine tägliche Datensicherung angelegt und 2. heute einen kompletten Dump der aktuell noch laufenden Karte erzeugt. Nun meine Frage: Sollte ich einfach den Dump auf eine neue Karte kopieren oder eine komplette Neuinstallation anlegen, die vzlogger.conf kopieren und die Datenbanksicherung per dbcopy zurückspielen (analog zum Wiki: https://wiki.volkszaehler.org/software/tools/dbcopy) ? Beste Grüße, JD.
Re: [vz-users] Probleme beim Datenbank-BackUp
Hallo Tobias, perfekt, das war 's! Besten Dank und Grüße, JD. Sent: Friday, June 14, 2019 at 2:51 PM From: "tobias.l...@me.com" To: "volkszaehler.org - users" Subject: Re: [vz-users] Probleme beim Datenbank-BackUp Hallo, Ich glaube mit der Änderung auf die .yaml config hat sich auch das comando geändert. Ich meine das es jetzt copy ist und nicht mehr backup. Wenn du nur dbcopy aufrufst, ohne Komanndos und Optionen, also pi@raspberrypi:~ $ ./dbcopy/dbcopy dann bekommst du eine Liste mit möglichen kommandos und optionen. Das Wiki ist an dieser Stelle nucht ganz up to date. Gruß Tobias Ursprüngliche Nachricht Betreff: Re: [vz-users] Probleme beim Datenbank-BackUp Von: John Doe An: volkszaehler-users@demo.volkszaehler.org Cc: "volkszaehler.org - users" Hallo Frank, ich habe nach dem Wiki (https://wiki.volkszaehler.org/software/tools/dbcopy) dbcopy noch einmal neu gebaut - der Fehler bleibt. pi@raspberrypi:~ $ ./dbcopy/dbcopy backup --config /etc/dbcopy.yaml Command "backup" is not defined. Was kann ich noch versuchen ? Grüße, JD. Sent: Thursday, June 13, 2019 at 10:35 PM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Probleme beim Datenbank-BackUp update war falsch, sorry. Hatte nicht nachgeschaut. Korrekt ist backup. Also nicht dbcopy create, sondern dbcopy backup. Steht übrigens auch im Wiki... Am Do., 13. Juni 2019 um 22:31 Uhr schrieb John Doe <john...@null.net>: Hallo Frank, ein Update von was denn? Und woher kommt der Fehler? Grüße, JD. > Sent: Thursday, June 13, 2019 at 9:14 PM > From: "Frank Richter" <frank.richte...@gmail.com> > To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> > Subject: Re: [vz-users] Probleme beim Datenbank-BackUp > > Die Fehlermeldung ist eigentlich eindeutig: die Tabelle gibt's schon, also > ist create der falsche Befehl. Ich glaub update müsste passen. > > Grüße > Frank > > John Doe <john...@null.net> schrieb am Do., 13. Juni 2019, 20:00: > > > Hallo zusammen, > > > > mein Problem nach dem rpi-update hat sich durch ein aktuelles rpi-update > > erledigt, alles läuft soweit wieder. > > Leider habe ich jetzt wieder ein Problem mit dem Backup der Datenbank: > > > > sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c > > /etc/dbcopy.yaml > > Creating target schema > > Creating tables > > Updating schema assets for target platform compatibility: sqlite > > table: aggregate > > table: data > > table: entities > > table: entities_in_aggregator > > table: properties > > CREATE TABLE aggregate (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT > > NOT NULL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, > > CONSTRAINT FK_B77949FF72F5A1AA FOREIGN KEY (channel_id) REFERENCES entities > > (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE UNIQUE INDEX aggregate_unique ON aggregate (channel_id, type, > > timestamp) > > CREATE INDEX IDX_B77949FF72F5A1AA ON aggregate (channel_id) > > CREATE TABLE data (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > channel_id INTEGER DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE > > PRECISION NOT NULL, CONSTRAINT FK_ADF3F36372F5A1AA FOREIGN KEY (channel_id) > > REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE UNIQUE INDEX data_unique ON data (channel_id, timestamp) > > CREATE INDEX IDX_ADF3F36372F5A1AA ON data (channel_id) > > CREATE TABLE entities (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, uuid > > VARCHAR(36) NOT NULL, type VARCHAR(255) NOT NULL, class VARCHAR(255) NOT > > NULL) > > CREATE UNIQUE INDEX UNIQ_50EC64E5D17F50A6 ON entities (uuid) > > CREATE TABLE entities_in_aggregator (parent_id INTEGER NOT NULL, child_id > > INTEGER NOT NULL, PRIMARY KEY(parent_id, child_id), CONSTRAINT > > FK_2BD88468727ACA70 FOREIGN KEY (parent_id) REFERENCES entities (id) NOT > > DEFERRABLE INITIALLY IMMEDIATE, CONSTRAINT FK_2BD88468DD62C21B FOREIGN KEY > > (child_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE INDEX IDX_2BD88468727ACA70 ON entities_in_aggregator (parent_id) > > CREATE INDEX IDX_2BD88468DD62C21B ON entities_in_aggregator (child_id) > > CREATE TABLE properties (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > entity_id INTEGER DEFAULT NULL, pkey VARCHAR(255) NOT NULL, value CLOB NOT > > NULL, CONSTRAINT FK_87C331C781257D5D FOREIGN KEY (entity_id) REFERENCES > > entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > >
Re: [vz-users] Probleme beim Datenbank-BackUp
Hallo Frank, ich habe nach dem Wiki (https://wiki.volkszaehler.org/software/tools/dbcopy) dbcopy noch einmal neu gebaut - der Fehler bleibt. pi@raspberrypi:~ $ ./dbcopy/dbcopy backup --config /etc/dbcopy.yaml Command "backup" is not defined. Was kann ich noch versuchen ? Grüße, JD. Sent: Thursday, June 13, 2019 at 10:35 PM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Probleme beim Datenbank-BackUp update war falsch, sorry. Hatte nicht nachgeschaut. Korrekt ist backup. Also nicht dbcopy create, sondern dbcopy backup. Steht übrigens auch im Wiki... Am Do., 13. Juni 2019 um 22:31 Uhr schrieb John Doe <john...@null.net>: Hallo Frank, ein Update von was denn? Und woher kommt der Fehler? Grüße, JD. > Sent: Thursday, June 13, 2019 at 9:14 PM > From: "Frank Richter" <frank.richte...@gmail.com> > To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> > Subject: Re: [vz-users] Probleme beim Datenbank-BackUp > > Die Fehlermeldung ist eigentlich eindeutig: die Tabelle gibt's schon, also > ist create der falsche Befehl. Ich glaub update müsste passen. > > Grüße > Frank > > John Doe <john...@null.net> schrieb am Do., 13. Juni 2019, 20:00: > > > Hallo zusammen, > > > > mein Problem nach dem rpi-update hat sich durch ein aktuelles rpi-update > > erledigt, alles läuft soweit wieder. > > Leider habe ich jetzt wieder ein Problem mit dem Backup der Datenbank: > > > > sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c > > /etc/dbcopy.yaml > > Creating target schema > > Creating tables > > Updating schema assets for target platform compatibility: sqlite > > table: aggregate > > table: data > > table: entities > > table: entities_in_aggregator > > table: properties > > CREATE TABLE aggregate (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT > > NOT NULL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, > > CONSTRAINT FK_B77949FF72F5A1AA FOREIGN KEY (channel_id) REFERENCES entities > > (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE UNIQUE INDEX aggregate_unique ON aggregate (channel_id, type, > > timestamp) > > CREATE INDEX IDX_B77949FF72F5A1AA ON aggregate (channel_id) > > CREATE TABLE data (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > channel_id INTEGER DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE > > PRECISION NOT NULL, CONSTRAINT FK_ADF3F36372F5A1AA FOREIGN KEY (channel_id) > > REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE UNIQUE INDEX data_unique ON data (channel_id, timestamp) > > CREATE INDEX IDX_ADF3F36372F5A1AA ON data (channel_id) > > CREATE TABLE entities (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, uuid > > VARCHAR(36) NOT NULL, type VARCHAR(255) NOT NULL, class VARCHAR(255) NOT > > NULL) > > CREATE UNIQUE INDEX UNIQ_50EC64E5D17F50A6 ON entities (uuid) > > CREATE TABLE entities_in_aggregator (parent_id INTEGER NOT NULL, child_id > > INTEGER NOT NULL, PRIMARY KEY(parent_id, child_id), CONSTRAINT > > FK_2BD88468727ACA70 FOREIGN KEY (parent_id) REFERENCES entities (id) NOT > > DEFERRABLE INITIALLY IMMEDIATE, CONSTRAINT FK_2BD88468DD62C21B FOREIGN KEY > > (child_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE INDEX IDX_2BD88468727ACA70 ON entities_in_aggregator (parent_id) > > CREATE INDEX IDX_2BD88468DD62C21B ON entities_in_aggregator (child_id) > > CREATE TABLE properties (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > entity_id INTEGER DEFAULT NULL, pkey VARCHAR(255) NOT NULL, value CLOB NOT > > NULL, CONSTRAINT FK_87C331C781257D5D FOREIGN KEY (entity_id) REFERENCES > > entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE UNIQUE INDEX property_unique ON properties (entity_id, pkey) > > CREATE INDEX IDX_87C331C781257D5D ON properties (entity_id) > > In AbstractSQLiteDriver.php line 47: > > An exception occurred while executing 'CREATE TABLE aggregate (id > > INTEGER PRIMARY KEY AUTOINCRE > > MENT NOT NULL, channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, > > timestamp BIGINT NOT NU > > LL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, CONSTRAINT > > FK_B77949FF72F5A1AA FOR > > EIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY > > IMMEDIATE)': > > SQLSTATE[HY000]: General error: 1 table aggregate already exists > > > > In PDOConnection.php line 43: > > SQLSTATE[HY000]: General error: 1 table aggregate already exists > > > > In PDOConnection.php line 41: > > SQLSTATE[HY000]: General error: 1 table aggregate already exists > > > > create [-c|--config CONFIG] > > > > Hat jemand einen Tip, was ich tun könnte ? > > Grüße, > > > > JD. > > >
Re: [vz-users] Probleme beim Datenbank-BackUp
Hallo Frank, ein /var/www/volkszaehler.org/vendor/bin/dbcopy backup -c /etc/dbcopy.yaml liefert Command "backup" is not defined. Sollte ich dbcopy noch einmal neu bauen ? Grüße, JD. Sent: Thursday, June 13, 2019 at 10:35 PM From: "Frank Richter" To: "volkszaehler.org - users" Subject: Re: [vz-users] Probleme beim Datenbank-BackUp update war falsch, sorry. Hatte nicht nachgeschaut. Korrekt ist backup. Also nicht dbcopy create, sondern dbcopy backup. Steht übrigens auch im Wiki... Am Do., 13. Juni 2019 um 22:31 Uhr schrieb John Doe <john...@null.net>: Hallo Frank, ein Update von was denn? Und woher kommt der Fehler? Grüße, JD. > Sent: Thursday, June 13, 2019 at 9:14 PM > From: "Frank Richter" <frank.richte...@gmail.com> > To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> > Subject: Re: [vz-users] Probleme beim Datenbank-BackUp > > Die Fehlermeldung ist eigentlich eindeutig: die Tabelle gibt's schon, also > ist create der falsche Befehl. Ich glaub update müsste passen. > > Grüße > Frank > > John Doe <john...@null.net> schrieb am Do., 13. Juni 2019, 20:00: > > > Hallo zusammen, > > > > mein Problem nach dem rpi-update hat sich durch ein aktuelles rpi-update > > erledigt, alles läuft soweit wieder. > > Leider habe ich jetzt wieder ein Problem mit dem Backup der Datenbank: > > > > sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c > > /etc/dbcopy.yaml > > Creating target schema > > Creating tables > > Updating schema assets for target platform compatibility: sqlite > > table: aggregate > > table: data > > table: entities > > table: entities_in_aggregator > > table: properties > > CREATE TABLE aggregate (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT > > NOT NULL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, > > CONSTRAINT FK_B77949FF72F5A1AA FOREIGN KEY (channel_id) REFERENCES entities > > (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE UNIQUE INDEX aggregate_unique ON aggregate (channel_id, type, > > timestamp) > > CREATE INDEX IDX_B77949FF72F5A1AA ON aggregate (channel_id) > > CREATE TABLE data (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > channel_id INTEGER DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE > > PRECISION NOT NULL, CONSTRAINT FK_ADF3F36372F5A1AA FOREIGN KEY (channel_id) > > REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE UNIQUE INDEX data_unique ON data (channel_id, timestamp) > > CREATE INDEX IDX_ADF3F36372F5A1AA ON data (channel_id) > > CREATE TABLE entities (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, uuid > > VARCHAR(36) NOT NULL, type VARCHAR(255) NOT NULL, class VARCHAR(255) NOT > > NULL) > > CREATE UNIQUE INDEX UNIQ_50EC64E5D17F50A6 ON entities (uuid) > > CREATE TABLE entities_in_aggregator (parent_id INTEGER NOT NULL, child_id > > INTEGER NOT NULL, PRIMARY KEY(parent_id, child_id), CONSTRAINT > > FK_2BD88468727ACA70 FOREIGN KEY (parent_id) REFERENCES entities (id) NOT > > DEFERRABLE INITIALLY IMMEDIATE, CONSTRAINT FK_2BD88468DD62C21B FOREIGN KEY > > (child_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE INDEX IDX_2BD88468727ACA70 ON entities_in_aggregator (parent_id) > > CREATE INDEX IDX_2BD88468DD62C21B ON entities_in_aggregator (child_id) > > CREATE TABLE properties (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > entity_id INTEGER DEFAULT NULL, pkey VARCHAR(255) NOT NULL, value CLOB NOT > > NULL, CONSTRAINT FK_87C331C781257D5D FOREIGN KEY (entity_id) REFERENCES > > entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE UNIQUE INDEX property_unique ON properties (entity_id, pkey) > > CREATE INDEX IDX_87C331C781257D5D ON properties (entity_id) > > In AbstractSQLiteDriver.php line 47: > > An exception occurred while executing 'CREATE TABLE aggregate (id > > INTEGER PRIMARY KEY AUTOINCRE > > MENT NOT NULL, channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, > > timestamp BIGINT NOT NU > > LL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, CONSTRAINT > > FK_B77949FF72F5A1AA FOR > > EIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY > > IMMEDIATE)': > > SQLSTATE[HY000]: General error: 1 table aggregate already exists > > > > In PDOConnection.php line 43: > > SQLSTATE[HY000]: General error: 1 table aggregate already exists > > > > In PDOConnection.php line 41: > > SQLSTATE[HY000]: General error: 1 table aggregate already exists > > > > create [-c|--config CONFIG] > > > > Hat jemand einen Tip, was ich tun könnte ? > > Grüße, > > > > JD. > > >
Re: [vz-users] Probleme beim Datenbank-BackUp
Hallo Frank, ein Update von was denn? Und woher kommt der Fehler? Grüße, JD. > Sent: Thursday, June 13, 2019 at 9:14 PM > From: "Frank Richter" > To: "volkszaehler.org - users" > Subject: Re: [vz-users] Probleme beim Datenbank-BackUp > > Die Fehlermeldung ist eigentlich eindeutig: die Tabelle gibt's schon, also > ist create der falsche Befehl. Ich glaub update müsste passen. > > Grüße > Frank > > John Doe schrieb am Do., 13. Juni 2019, 20:00: > > > Hallo zusammen, > > > > mein Problem nach dem rpi-update hat sich durch ein aktuelles rpi-update > > erledigt, alles läuft soweit wieder. > > Leider habe ich jetzt wieder ein Problem mit dem Backup der Datenbank: > > > > sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c > > /etc/dbcopy.yaml > > Creating target schema > > Creating tables > > Updating schema assets for target platform compatibility: sqlite > > table: aggregate > > table: data > > table: entities > > table: entities_in_aggregator > > table: properties > > CREATE TABLE aggregate (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT > > NOT NULL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, > > CONSTRAINT FK_B77949FF72F5A1AA FOREIGN KEY (channel_id) REFERENCES entities > > (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE UNIQUE INDEX aggregate_unique ON aggregate (channel_id, type, > > timestamp) > > CREATE INDEX IDX_B77949FF72F5A1AA ON aggregate (channel_id) > > CREATE TABLE data (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > channel_id INTEGER DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE > > PRECISION NOT NULL, CONSTRAINT FK_ADF3F36372F5A1AA FOREIGN KEY (channel_id) > > REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE UNIQUE INDEX data_unique ON data (channel_id, timestamp) > > CREATE INDEX IDX_ADF3F36372F5A1AA ON data (channel_id) > > CREATE TABLE entities (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, uuid > > VARCHAR(36) NOT NULL, type VARCHAR(255) NOT NULL, class VARCHAR(255) NOT > > NULL) > > CREATE UNIQUE INDEX UNIQ_50EC64E5D17F50A6 ON entities (uuid) > > CREATE TABLE entities_in_aggregator (parent_id INTEGER NOT NULL, child_id > > INTEGER NOT NULL, PRIMARY KEY(parent_id, child_id), CONSTRAINT > > FK_2BD88468727ACA70 FOREIGN KEY (parent_id) REFERENCES entities (id) NOT > > DEFERRABLE INITIALLY IMMEDIATE, CONSTRAINT FK_2BD88468DD62C21B FOREIGN KEY > > (child_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE INDEX IDX_2BD88468727ACA70 ON entities_in_aggregator (parent_id) > > CREATE INDEX IDX_2BD88468DD62C21B ON entities_in_aggregator (child_id) > > CREATE TABLE properties (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, > > entity_id INTEGER DEFAULT NULL, pkey VARCHAR(255) NOT NULL, value CLOB NOT > > NULL, CONSTRAINT FK_87C331C781257D5D FOREIGN KEY (entity_id) REFERENCES > > entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) > > CREATE UNIQUE INDEX property_unique ON properties (entity_id, pkey) > > CREATE INDEX IDX_87C331C781257D5D ON properties (entity_id) > > In AbstractSQLiteDriver.php line 47: > > An exception occurred while executing 'CREATE TABLE aggregate (id > > INTEGER PRIMARY KEY AUTOINCRE > > MENT NOT NULL, channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, > > timestamp BIGINT NOT NU > > LL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, CONSTRAINT > > FK_B77949FF72F5A1AA FOR > > EIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY > > IMMEDIATE)': > > SQLSTATE[HY000]: General error: 1 table aggregate already exists > > > > In PDOConnection.php line 43: > > SQLSTATE[HY000]: General error: 1 table aggregate already exists > > > > In PDOConnection.php line 41: > > SQLSTATE[HY000]: General error: 1 table aggregate already exists > > > > create [-c|--config CONFIG] > > > > Hat jemand einen Tip, was ich tun könnte ? > > Grüße, > > > > JD. > > >
[vz-users] Probleme beim Datenbank-BackUp
Hallo zusammen, mein Problem nach dem rpi-update hat sich durch ein aktuelles rpi-update erledigt, alles läuft soweit wieder. Leider habe ich jetzt wieder ein Problem mit dem Backup der Datenbank: sudo /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml Creating target schema Creating tables Updating schema assets for target platform compatibility: sqlite table: aggregate table: data table: entities table: entities_in_aggregator table: properties CREATE TABLE aggregate (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, CONSTRAINT FK_B77949FF72F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE UNIQUE INDEX aggregate_unique ON aggregate (channel_id, type, timestamp) CREATE INDEX IDX_B77949FF72F5A1AA ON aggregate (channel_id) CREATE TABLE data (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, channel_id INTEGER DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, CONSTRAINT FK_ADF3F36372F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE UNIQUE INDEX data_unique ON data (channel_id, timestamp) CREATE INDEX IDX_ADF3F36372F5A1AA ON data (channel_id) CREATE TABLE entities (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, uuid VARCHAR(36) NOT NULL, type VARCHAR(255) NOT NULL, class VARCHAR(255) NOT NULL) CREATE UNIQUE INDEX UNIQ_50EC64E5D17F50A6 ON entities (uuid) CREATE TABLE entities_in_aggregator (parent_id INTEGER NOT NULL, child_id INTEGER NOT NULL, PRIMARY KEY(parent_id, child_id), CONSTRAINT FK_2BD88468727ACA70 FOREIGN KEY (parent_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE, CONSTRAINT FK_2BD88468DD62C21B FOREIGN KEY (child_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE INDEX IDX_2BD88468727ACA70 ON entities_in_aggregator (parent_id) CREATE INDEX IDX_2BD88468DD62C21B ON entities_in_aggregator (child_id) CREATE TABLE properties (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, entity_id INTEGER DEFAULT NULL, pkey VARCHAR(255) NOT NULL, value CLOB NOT NULL, CONSTRAINT FK_87C331C781257D5D FOREIGN KEY (entity_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE UNIQUE INDEX property_unique ON properties (entity_id, pkey) CREATE INDEX IDX_87C331C781257D5D ON properties (entity_id) In AbstractSQLiteDriver.php line 47: An exception occurred while executing 'CREATE TABLE aggregate (id INTEGER PRIMARY KEY AUTOINCRE MENT NOT NULL, channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT NOT NU LL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, CONSTRAINT FK_B77949FF72F5A1AA FOR EIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE)': SQLSTATE[HY000]: General error: 1 table aggregate already exists In PDOConnection.php line 43: SQLSTATE[HY000]: General error: 1 table aggregate already exists In PDOConnection.php line 41: SQLSTATE[HY000]: General error: 1 table aggregate already exists create [-c|--config CONFIG] Hat jemand einen Tip, was ich tun könnte ? Grüße, JD.
Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ?
Hallo Thomas, selbs'verständlich. Gruß, JD. > Sent: Thursday, June 13, 2019 at 1:05 PM > From: "Thomas Höpfner" > To: "volkszaehler.org - users" > Subject: Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ? > > Hallo, > > ich hoffe du hast nach dem Crash eine neue Karte genommen. > Sonnst... > > Thomas > > > > Am 13.06.2019 um 12:51 schrieb John Doe : > > > > Hallo Daniel, > > > > der Rat zu rpi-update war mir unbekannt.. > > Phpmyadmin ist (da ich das aktuelle Image verwende) nicht installiert. > > Bist Du sicher, daß eine Deinstallation von Apache die Lösung bringt? Sind > > meine Daten noch da? > > Grüße, > > > > JD. > > > >> Sent: Thursday, June 13, 2019 at 11:52 AM > >> From: "Daniel Lauckner" > >> To: "volkszaehler.org - users" > >> Subject: Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ? > >> > >> Hallo, > >> > >> > >> am Mittwoch, 12. Juni 2019 um 22:42 hat John Doe geschrieben: > >>> und ein rpi-updateangestoßen. > >> > >> "Deshalb generell die Empfehlung, Finger weg von "rpi-update". Es sei > >> denn man weiß, warum man das tut." > >> https://www.elektronik-kompendium.de/sites/raspberry-pi/2006061.htm > >> > >>> Ergebnis: Ich lande nach dem Aufruf von http://raspi-vz-ip auf der > >>> Apache2 Debian Default Page. > >> > >> Mglich das eine Abhägigkeit besteht (insbesondere wenn du in Richtung > >> phpmyadmin rumgespielt hast) die beim Update aufgelöst wurde. > >> Apache deaktivieren und ev. deinstallieren. > >> > >> > >> mfg Daniel > >> > >> > >
Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ?
Hallo Daniel, der Rat zu rpi-update war mir unbekannt.. Phpmyadmin ist (da ich das aktuelle Image verwende) nicht installiert. Bist Du sicher, daß eine Deinstallation von Apache die Lösung bringt? Sind meine Daten noch da? Grüße, JD. > Sent: Thursday, June 13, 2019 at 11:52 AM > From: "Daniel Lauckner" > To: "volkszaehler.org - users" > Subject: Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ? > > Hallo, > > > am Mittwoch, 12. Juni 2019 um 22:42 hat John Doe geschrieben: > > und ein rpi-updateangestoßen. > > "Deshalb generell die Empfehlung, Finger weg von "rpi-update". Es sei > denn man weiß, warum man das tut." > https://www.elektronik-kompendium.de/sites/raspberry-pi/2006061.htm > > > Ergebnis: Ich lande nach dem Aufruf von http://raspi-vz-ip auf der Apache2 > > Debian Default Page. > > Mglich das eine Abhägigkeit besteht (insbesondere wenn du in Richtung > phpmyadmin rumgespielt hast) die beim Update aufgelöst wurde. > Apache deaktivieren und ev. deinstallieren. > > > mfg Daniel > >
Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ?
Hallo zusammen, nachdem mein neu aufgesetztes System jetzt einige Tage gelaufen ist, habe ich heute mal ein update/upgrade und ein rpi-updateangestoßen. Ergebnis: Ich lande nach dem Aufruf von http://raspi-vz-ip auf der Apache2 Debian Default Page. Hat jemand einen Tip, was jetzt wieder kaputt gegangen ist ? Grüße, JD. Sent: Tuesday, June 04, 2019 at 12:39 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ? Hallo John, ich muss es trotzdem nochmal sagen- zur Sicherheit: dbcopy ersetzt immer noch kein Backup! So kann es z.B. theoretisch passieren, dass Du im produktiven System alle Kanäle löschst (oder DB kaputt, oder…). Wenn dann dbcopy läuft werden die auch aus der Kopie gelöscht (selbst wenn die Daten erhalten bleiben unschön). Du solltest also auch von der Kopie regelmäßige Sicherungen machen: bei SQlite einfach als Kopie der Datei bei MySQL mit mysqldump oder phpmyadmin Das Backup der dbcopy-Kopie tut dann weniger weh, diese DB darf ja ruhig auch mal länger gesperrt oder offline sein… Ich hoffe Deine Daten sind jetzt sicher :) Viele Grüße, Andreas On 2. Jun 2019, at 18:46, John Doe <john...@null.net> wrote: Hallo Andreas, der letzte Tip hat funktioniert: Nach Installation von php-sqlite3 scheint es durchgelaufen zu sein: $ /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml Creating target schema Creating tables Updating schema assets for target platform compatibility: sqlite table: aggregate table: data table: entities table: entities_in_aggregator table: properties Ish schaue mir jetzt mal die Kopie an und versuche evtl mal eine Rücksicherung. Bis hierhin danke für Deine Geduld ! Grüße, JD. Sent: Sunday, June 02, 2019 at 6:22 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ? Deinem PHP fehlt das richtige Modul: In AbstractSQLiteDriver.php line 70: An exception occurred in driver: could not find driver Aktuell keine Idee woher wenn: apt-get update apt-get install php-sqlite3 (oder php-sqlite) nicht funktioniert. Sorry :( On 2. Jun 2019, at 18:18, John Doe <john...@null.net> wrote: Hallo Andreas, die dbcopy.yaml habe ich, bis auf die User-Daten, erst mal so gelassen: # DATABASE DEFINITION source: driver: pdo_mysql host: localhost user: vz password: demo dbname: volkszaehler target: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # DATABASE DEFINITION source: driver: pdo_mysql host: localhost user: vz password: demo dbname: volkszaehler target: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: Der analoge Aufruf endet wie vorher: pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml Creating target schema Creating tables Updating schema assets for target platform compatibility: sqlite table: aggregate table: data table: entities table: entities_in_aggregator table: properties CREATE TABLE aggregate (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, CONSTRAINT FK_B77949FF72F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE UNIQUE INDEX aggregate_unique ON aggregate (channel_id, type, timestamp) CREATE INDEX IDX_B77949FF72F5A1AA ON aggregate (channel_id) CREATE TABLE data (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, channel_id INTEGER DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, CONSTRAINT FK_ADF3F36372F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE UNIQUE INDEX data_unique ON data (channel_id, timestamp) CREATE INDEX IDX_ADF3F36372F5A1AA ON data (channel_id) CREATE TABLE entities (id INTEGER PRIMARY KEY AUTOINCREMENT
Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ?
Hallo Andreas, danke für 's Feedback. Normalerweise erzeuge ich das Backup ja offline mittels dd im Ganzen, nur fehlen mir dann eben die Daten aus der Zeit, während das Backup (von der Karte, die sich hierfür in einem anderen Rechner befindet) läuft. Daher hatte ich ins Blaue versucht, aus dem laufenden Betrieb zu sichern. Und dann kam mein Problem nach dem MW-Update. Da sich phpmyadmin nicht im aktuellen Image befindet: Wie müsste ich das mit der DB verdrahten? Grüße, JD. > Sent: Tuesday, June 04, 2019 at 12:39 PM > From: "Andreas Goetz" > To: "volkszaehler.org - users" > Subject: Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ? > > Hallo John, > > ich muss es trotzdem nochmal sagen- zur Sicherheit: dbcopy ersetzt immer noch > kein Backup! > > So kann es z.B. theoretisch passieren, dass Du im produktiven System alle > Kanäle löschst (oder DB kaputt, oder…). Wenn dann dbcopy läuft werden die > auch aus der Kopie gelöscht (selbst wenn die Daten erhalten bleiben unschön). > > Du solltest also auch von der Kopie regelmäßige Sicherungen machen: > bei SQlite einfach als Kopie der Datei > bei MySQL mit mysqldump oder phpmyadmin > > Das Backup der dbcopy-Kopie tut dann weniger weh, diese DB darf ja ruhig auch > mal länger gesperrt oder offline sein… > > Ich hoffe Deine Daten sind jetzt sicher :) > > Viele Grüße, > Andreas > > > > On 2. Jun 2019, at 18:46, John Doe wrote: > > > > Hallo Andreas, > > > > der letzte Tip hat funktioniert: > > > > Nach Installation von php-sqlite3 scheint es durchgelaufen zu sein: > > > > $ /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml > > Creating target schema > > Creating tables > > Updating schema assets for target platform compatibility: sqlite > > table: aggregate > > table: data > > table: entities > > table: entities_in_aggregator > > table: properties > > > > Ish schaue mir jetzt mal die Kopie an und versuche evtl mal eine > > Rücksicherung. > > Bis hierhin danke für Deine Geduld ! > > > > Grüße, > > > > JD. > > > > Sent: Sunday, June 02, 2019 at 6:22 PM > > From: "Andreas Goetz" > > To: "volkszaehler.org - users" > > Subject: Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ? > > Deinem PHP fehlt das richtige Modul: > > > > In AbstractSQLiteDriver.php line 70: > > An exception occurred in driver: could not find driver > > > > Aktuell keine Idee woher wenn: > > > > apt-get update > > apt-get install php-sqlite3 (oder php-sqlite) > > > > nicht funktioniert. > > > > Sorry :( > > > > On 2. Jun 2019, at 18:18, John Doe > <mailto:john...@null.net>> wrote: > > > > Hallo Andreas, > > > > die dbcopy.yaml habe ich, bis auf die User-Daten, erst mal so gelassen: > > > > # DATABASE DEFINITION > > source: > > driver: pdo_mysql > > host: localhost > > user: vz > > password: demo > > dbname: volkszaehler > > target: > > driver: pdo_sqlite > > host: localhost > > user: root > > password: raspberry > > dbname: volkszaehler_backup > > path: sqlite.db3 # path is only used if driver = pdo_sqlite > > # influxdb target database connection > > influx: > > dsn: influxdb://localhost:8086 <> > > dbname: volkszaehler > > measurement: data > > # DATABASE DEFINITION > > source: > > driver: pdo_mysql > > host: localhost > > user: vz > > password: demo > > dbname: volkszaehler > > target: > > driver: pdo_sqlite > > host: localhost > > user: root > > password: raspberry > > dbname: volkszaehler_backup > > path: sqlite.db3 # path is only used if driver = pdo_sqlite > > # influxdb target database connection > > influx: > > dsn: influxdb://localhost:8086 <> > > dbname: volkszaehler > > measurement: data > > # TABLE DEFINITION > > # > > # tables will be processed in the order they are mentioned: > > # - foreign keys on target will be dropped > > # - if a table is not listed here, it will not be touched > > # transfer mode > > # skip: table will not be copied > > # copy: > > > > Der analoge Aufruf endet wie vorher: > > > > pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy
Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ?
Hallo Andreas, der letzte Tip hat funktioniert: Nach Installation von php-sqlite3 scheint es durchgelaufen zu sein: $ /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml Creating target schema Creating tables Updating schema assets for target platform compatibility: sqlite table: aggregate table: data table: entities table: entities_in_aggregator table: properties Ish schaue mir jetzt mal die Kopie an und versuche evtl mal eine Rücksicherung. Bis hierhin danke für Deine Geduld ! Grüße, JD. Sent: Sunday, June 02, 2019 at 6:22 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ? Deinem PHP fehlt das richtige Modul: In AbstractSQLiteDriver.php line 70: An exception occurred in driver: could not find driver Aktuell keine Idee woher wenn: apt-get update apt-get install php-sqlite3 (oder php-sqlite) nicht funktioniert. Sorry :( On 2. Jun 2019, at 18:18, John Doe <john...@null.net> wrote: Hallo Andreas, die dbcopy.yaml habe ich, bis auf die User-Daten, erst mal so gelassen: # DATABASE DEFINITION source: driver: pdo_mysql host: localhost user: vz password: demo dbname: volkszaehler target: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # DATABASE DEFINITION source: driver: pdo_mysql host: localhost user: vz password: demo dbname: volkszaehler target: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: Der analoge Aufruf endet wie vorher: pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml Creating target schema Creating tables Updating schema assets for target platform compatibility: sqlite table: aggregate table: data table: entities table: entities_in_aggregator table: properties CREATE TABLE aggregate (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, CONSTRAINT FK_B77949FF72F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE UNIQUE INDEX aggregate_unique ON aggregate (channel_id, type, timestamp) CREATE INDEX IDX_B77949FF72F5A1AA ON aggregate (channel_id) CREATE TABLE data (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, channel_id INTEGER DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, CONSTRAINT FK_ADF3F36372F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE UNIQUE INDEX data_unique ON data (channel_id, timestamp) CREATE INDEX IDX_ADF3F36372F5A1AA ON data (channel_id) CREATE TABLE entities (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, uuid VARCHAR(36) NOT NULL, type VARCHAR(255) NOT NULL, class VARCHAR(255) NOT NULL) CREATE UNIQUE INDEX UNIQ_50EC64E5D17F50A6 ON entities (uuid) CREATE TABLE entities_in_aggregator (parent_id INTEGER NOT NULL, child_id INTEGER NOT NULL, PRIMARY KEY(parent_id, child_id), CONSTRAINT FK_2BD88468727ACA70 FOREIGN KEY (parent_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE, CONSTRAINT FK_2BD88468DD62C21B FOREIGN KEY (child_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE INDEX IDX_2BD88468DD62C21B ON entities_in_aggregator (child_id) CREATE INDEX IDX_2BD88468727ACA70 ON entities_in_aggregator (parent_id) CREATE TABLE properties (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, entity_id INTEGER DEFAULT NULL, pkey VARCHAR(255) NOT NULL, value CLOB NOT NULL, CONSTRAINT FK_87C331C781257D5D FOREIGN KEY (entity_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE UNIQUE INDEX property_unique ON properties (entity_id, pkey) CREATE INDEX IDX_87C331C781257D5D ON properties (entity_id) In AbstractSQLiteDriver.php line 70: An exception occurred in driver: could not find driver In PDOConnection.php line 31: could not find driver In PDOConnection.php line 27: could not find driver create [-c|--config CONFIG] Grüße, JD. Sent: Sunday, June 02, 2019 at 5:59 PM From: "An
Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ?
Hallo Andreas, die dbcopy.yaml habe ich, bis auf die User-Daten, erst mal so gelassen: # DATABASE DEFINITION source: driver: pdo_mysql host: localhost user: vz password: demo dbname: volkszaehler target: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # DATABASE DEFINITION source: driver: pdo_mysql host: localhost user: vz password: demo dbname: volkszaehler target: driver: pdo_sqlite host: localhost user: root password: raspberry dbname: volkszaehler_backup path: sqlite.db3 # path is only used if driver = pdo_sqlite # influxdb target database connection influx: dsn: influxdb://localhost:8086 dbname: volkszaehler measurement: data # TABLE DEFINITION # # tables will be processed in the order they are mentioned: # - foreign keys on target will be dropped # - if a table is not listed here, it will not be touched # transfer mode # skip: table will not be copied # copy: Der analoge Aufruf endet wie vorher: pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.yaml Creating target schema Creating tables Updating schema assets for target platform compatibility: sqlite table: aggregate table: data table: entities table: entities_in_aggregator table: properties CREATE TABLE aggregate (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, channel_id INTEGER DEFAULT NULL, type SMALLINT NOT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, count INTEGER NOT NULL, CONSTRAINT FK_B77949FF72F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE UNIQUE INDEX aggregate_unique ON aggregate (channel_id, type, timestamp) CREATE INDEX IDX_B77949FF72F5A1AA ON aggregate (channel_id) CREATE TABLE data (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, channel_id INTEGER DEFAULT NULL, timestamp BIGINT NOT NULL, value DOUBLE PRECISION NOT NULL, CONSTRAINT FK_ADF3F36372F5A1AA FOREIGN KEY (channel_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE UNIQUE INDEX data_unique ON data (channel_id, timestamp) CREATE INDEX IDX_ADF3F36372F5A1AA ON data (channel_id) CREATE TABLE entities (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, uuid VARCHAR(36) NOT NULL, type VARCHAR(255) NOT NULL, class VARCHAR(255) NOT NULL) CREATE UNIQUE INDEX UNIQ_50EC64E5D17F50A6 ON entities (uuid) CREATE TABLE entities_in_aggregator (parent_id INTEGER NOT NULL, child_id INTEGER NOT NULL, PRIMARY KEY(parent_id, child_id), CONSTRAINT FK_2BD88468727ACA70 FOREIGN KEY (parent_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE, CONSTRAINT FK_2BD88468DD62C21B FOREIGN KEY (child_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE INDEX IDX_2BD88468DD62C21B ON entities_in_aggregator (child_id) CREATE INDEX IDX_2BD88468727ACA70 ON entities_in_aggregator (parent_id) CREATE TABLE properties (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, entity_id INTEGER DEFAULT NULL, pkey VARCHAR(255) NOT NULL, value CLOB NOT NULL, CONSTRAINT FK_87C331C781257D5D FOREIGN KEY (entity_id) REFERENCES entities (id) NOT DEFERRABLE INITIALLY IMMEDIATE) CREATE UNIQUE INDEX property_unique ON properties (entity_id, pkey) CREATE INDEX IDX_87C331C781257D5D ON properties (entity_id) In AbstractSQLiteDriver.php line 70: An exception occurred in driver: could not find driver In PDOConnection.php line 31: could not find driver In PDOConnection.php line 27: could not find driver create [-c|--config CONFIG] Grüße, JD. Sent: Sunday, June 02, 2019 at 5:59 PM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ? Genau da wo Du die .json gefunden hast- vorausgesetzt es ist ein aktuellen vz/dbcopy. Diese etc/dbcopy.dist.yaml kopierst Du nach etc/dbcopy.yaml (oder wohin Du willst) und passt die dann Deinen Bedürfnissen an. Viele Grüße, Andreas PS.: dass aktuelles dbcopy keine .json Konfigurationen mehr kann hatte ich ich vorher schonmal geschrieben ;) On 2. Jun 2019, at 17:57, John Doe <john...@null.net> wrote: Hallo Andreas, ich rufe dbcopy so auf, wie es im wiki steht: /var/www/volkszaehler.org/vendor/bin/dbcopy create -c /etc/dbcopy.json Wo finde ich die yaml-Datei ? Grüße, JD. Sent: Sunday, June 02, 2019 at 5:42 PM From: "Andreas Goetz" <cpui...@gmail.com> To: "volkszaehler.org - users" <volkszaehler-users@demo.volkszaehler.org> Subject: Re: [vz-users] SD-Kartencrash nach Update - noch etwas zu Retten ? Bevor es hektisch wird: hast Du sichergestellt, dass D