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, 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
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 /tmp/apt
Re: [vz-users] Bevorstehender Kartencrash
Hallo zusammen, hallo Andreas, zunächst mal vielen Dank für Eure zahlreichen und anhaltenden Bemühungen und Tips. Kurz zum Intro: Ich habe alle Daten bis auf ca. 14 Tage wieder, aber das kann ich verschmerzen. Die Datenaquise läuft normal. Aggregate ist auch fehlerfrei durchgelaufen, so dass das WebIF normal schnell reagiert. Was hatte ich vorher falsch gemacht: 1. In meiner Euphorie hatte ich die dbcopy.yaml nach dem letzten restore nicht mehr geändert, sprich: source und target nicht mehr getauscht. Somit habe ich dann ausu dem laufenden vzlogger heraus nochmals in die aktuell laufende DB restored, das hat wohl einiges zerstört. 2. Der Fehler beim nochmaligen restoren der DB, die als intakt bekannt ist (die erste), kam eindeutig reproduzierbar von der Benutzung von screen. Wenn ich die screen-Session verlassen habe und anschliessend wieder aufrufen wollte, war diese nicht mehr existent, weil dbcopy sofort mit dem bekannten Fehler beendet wurde, Wenn ich screen nicht benutze, sondern den restore mit dbcopy "normal" in einer Shell zu Ende laufen lasse, funktioniert alles Bestens. Ich muss nicht mals neue Kanäle bzw. UIDs anlegen. ;-) Nochmal an alle Beteiligten und insbesondere Andreas vielen Dank für Eure Geduld, ich habe wieder Einiges gelernt. Beste Grüße JD. Sent: Friday, June 19, 2020 at 10:04 PM From: "Andreas Götz" To: "volkszaehler-users" Subject: Re: [vz-users] Bevorstehender Kartencrash ... oder eben 2 INSERT Statements mit je 3 Feldern von denen eines eine Konstante ist. Ich würde Das probieren, schlimmer werden kanns nicht mehr... Viele Grüße, Andreas > Am 19.06.2020 um 19:34 schrieb Daniel Lauckner : > > Hallo, > > > am Freitag, 19. Juni 2020 um 18:43 hat John Doe geschrieben: >> Alle tables scheinen ja vorhanden zu sein: > > Tables sind Struktur, die wurde von doctrine angelegt. > >> Daten scheinen prinzipiell vorhanden zu sein: > > Wir haben eine Tabelle "data", wenn von "Daten" die Rede ist > assoziiere ich erstmal diese. > >> MariaDB [volkszaehler]> SELECT * FROM properties; > [...] >> 16 rows in set (0.000 sec) > > Das hilft dir aber nicht viel wenn die entities leer ist. > Du hast nämlich Einstellungen zu Kanälen die es gar nicht gibt. > > > Dreckige Lösung: > - Tabelle properties leeren. > - Neue Kanäle anlegen. > - In Tabelle entities die id ändern das sie zu den vorhandenen Daten > in "data" passen. > - In Tabelle entities die uuid ändern das sie zu vzlogger passen. > - Bei Bedarf Einstellungen in properties nachbessern. > > > mfg Daniel >
Re: [vz-users] Bevorstehender Kartencrash
... oder eben 2 INSERT Statements mit je 3 Feldern von denen eines eine Konstante ist. Ich würde Das probieren, schlimmer werden kanns nicht mehr... Viele Grüße, Andreas > Am 19.06.2020 um 19:34 schrieb Daniel Lauckner : > > Hallo, > > > am Freitag, 19. Juni 2020 um 18:43 hat John Doe geschrieben: >> Alle tables scheinen ja vorhanden zu sein: > > Tables sind Struktur, die wurde von doctrine angelegt. > >> Daten scheinen prinzipiell vorhanden zu sein: > > Wir haben eine Tabelle "data", wenn von "Daten" die Rede ist > assoziiere ich erstmal diese. > >> MariaDB [volkszaehler]> SELECT * FROM properties; > [...] >> 16 rows in set (0.000 sec) > > Das hilft dir aber nicht viel wenn die entities leer ist. > Du hast nämlich Einstellungen zu Kanälen die es gar nicht gibt. > > > Dreckige Lösung: > - Tabelle properties leeren. > - Neue Kanäle anlegen. > - In Tabelle entities die id ändern das sie zu den vorhandenen Daten > in "data" passen. > - In Tabelle entities die uuid ändern das sie zu vzlogger passen. > - Bei Bedarf Einstellungen in properties nachbessern. > > > mfg Daniel >
Re: [vz-users] Bevorstehender Kartencrash
Hallo, am Freitag, 19. Juni 2020 um 18:43 hat John Doe geschrieben: > Alle tables scheinen ja vorhanden zu sein: Tables sind Struktur, die wurde von doctrine angelegt. > Daten scheinen prinzipiell vorhanden zu sein: Wir haben eine Tabelle "data", wenn von "Daten" die Rede ist assoziiere ich erstmal diese. > MariaDB [volkszaehler]> SELECT * FROM properties; [...] > 16 rows in set (0.000 sec) Das hilft dir aber nicht viel wenn die entities leer ist. Du hast nämlich Einstellungen zu Kanälen die es gar nicht gibt. Dreckige Lösung: - Tabelle properties leeren. - Neue Kanäle anlegen. - In Tabelle entities die id ändern das sie zu den vorhandenen Daten in "data" passen. - In Tabelle entities die uuid ändern das sie zu vzlogger passen. - Bei Bedarf Einstellungen in properties nachbessern. mfg Daniel
Re: [vz-users] Bevorstehender Kartencrash
Also... > On 19. Jun 2020, at 18:33, John Doe wrote: > > 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) Das ist eindeutig. In Deinem Backup sind keine Kanäle drin. Ich kann nur nochmal vermuten, dass Du irgendwie aus einer leeren DB mal in dieses Backup *rein* kopiert hast. Läuft bei Dir evtl. Backup als cron und lief noch? Dann wäre das eine Erklärung... > 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 hrs29250330 rows > aggregate: skipping > Creating FK FK_B77949FF72F5A1AA on aggregate > pi@raspberrypi:~ $ > > Wenn ich nun allerdings in der DB nach UIDs suche, finde ich keine: Nein, denn es wurden keine restored. > 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 ? Nimm das Backup aus dem Du beim ersten mal die Daten und Kanäle(!) restauriert hast. Wir waren schon an dem Stand wo alles wieder da war! Ansonsten bliebe nur noch die entities Tabelle von Hand in SQL aufzubauen so dass Deine properties dazu passen. Vielmehr als ID (analog entity_id aus properties), UUID (aus der vzlogger.conf) und TYPE (bei Dir wohl immer “channel” wenn DU keien Gruppen hast) steht da ja nicht drin. Nach gefühlt 100 Stunden mit dem Thema muss ich jetzt aber langsam sagen ich hab Urlaub :O > Beste Grüße > > JD. Sorry, Andreas > > 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 <mailto: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 Bandbreit
Re: [vz-users] Bevorstehender Kartencrash
Letzte Frage: Alle tables scheinen ja vorhanden zu sein: MariaDB [volkszaehler]> SHOW tables; ++ | Tables_in_volkszaehler | ++ | aggregate | | data | | entities | | entities_in_aggregator | | properties | ++ 5 rows in set (0.001 sec) Könnte ich nicht zwei willkürlich UIDs setzen und diese anschliessend in der vzlogger.conf eintragen ? Beste Grüße JD. Sent: Friday, June 19, 2020 at 6:38 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: Re: [vz-users] Bevorstehender Kartencrash Kleiner Nachtrag noch: Daten scheinen prinzipiell vorhanden zu sein: MariaDB [volkszaehler]> SELECT * FROM properties; ++---+++ | id | entity_id | pkey | value | ++---+++ | 1 | 1 | title | Haus-Strom | | 2 | 1 | resolution | 1 | | 3 | 1 | public | 1 | | 4 | 1 | color | #00 | | 5 | 1 | style | steps | | 6 | 1 | fillstyle | 0 | | 7 | 1 | linestyle | solid | | 8 | 1 | yaxis | auto | | 9 | 2 | title | WP-Strom | | 10 | 2 | resolution | 1 | | 11 | 2 | public | 1 | | 12 | 2 | color | #c62828 | | 13 | 2 | style | steps | | 14 | 2 | fillstyle | 0 | | 15 | 2 | linestyle | solid | | 16 | 2 | yaxis | auto | ++---+++ 16 rows in set (0.000 sec) MariaDB [volkszaehler]> Grüße JD. Sent: Friday, June 19, 2020 at 6:33 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: 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 1
Re: [vz-users] Bevorstehender Kartencrash
Kleiner Nachtrag noch: Daten scheinen prinzipiell vorhanden zu sein: MariaDB [volkszaehler]> SELECT * FROM properties; ++---+++ | id | entity_id | pkey | value | ++---+++ | 1 | 1 | title | Haus-Strom | | 2 | 1 | resolution | 1 | | 3 | 1 | public | 1 | | 4 | 1 | color | #00 | | 5 | 1 | style | steps | | 6 | 1 | fillstyle | 0 | | 7 | 1 | linestyle | solid | | 8 | 1 | yaxis | auto | | 9 | 2 | title | WP-Strom | | 10 | 2 | resolution | 1 | | 11 | 2 | public | 1 | | 12 | 2 | color | #c62828 | | 13 | 2 | style | steps | | 14 | 2 | fillstyle | 0 | | 15 | 2 | linestyle | solid | | 16 | 2 | yaxis | auto | ++---+++ 16 rows in set (0.000 sec) MariaDB [volkszaehler]> Grüße JD. Sent: Friday, June 19, 2020 at 6:33 PM From: "John Doe" To: volkszaehler-users@demo.volkszaehler.org Subject: 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.
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/ch
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 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" > 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, d
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
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 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" > 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 > <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 > <https://demo.volkszaehler.org/middleware.php/channel.json>/.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 <mailto: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 > <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 Re
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
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 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
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
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 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 h
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
Und noch ein letzter Hinweis: nach dem Restore der Datenbank ist alles wie vorher. Das heisst insbesondere, dass auch die UUIDs noch identisch sind. Lass also bitte Deine vzlogger.conf in Ruhe- die hat damit überhaupt nichts zu tun! Meine Vermutung: Deine Kanäle sind und waren nie public und du siehst sie deshalb nicht... Die einzige Frage ist wie Du die Kanäle wieder im Browser siehst. Da Du die UUIDs kennst- sie stehen in der vzlogger.conf- kannst Du sie per UUID abonnieren, selbst wenn sie nicht „public“ sind. 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 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" > To: "volkszaehler.org - users" > Subject: Re: [v
Re: [vz-users] Bevorstehender Kartencrash
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 ... 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 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" > 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
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 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 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
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 JD! > On 15. Jun 2020, at 19:41, John Doe 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 > <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" > 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 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
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 JD, > Am 15.06.2020 um 09:45 schrieb John Doe : > > > 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. D.h. Du hast die Richtung jetzt wieder geändert- vom Raspi aufs Nas, nciht mehr wie vorher umgekehrt? > Als ich danach wieder mein Web-Frontend aufgerufen habe, waren alle > erstellten und zuvor existierenden Kanäle weg. Schwer vorstellbar. Das Frontend hat mit der Datenbank erstmal gar nichts zu tun. > Daher wollte ich den Weg über die Neuanlage von öffentlichen Kanälen gehen > und deren UIDs anschliessend wieder in die vzlogger.conf eintragen. Verstehe ich nicht. Die Kanäle hattest Du doch beim Backup alle wieder hergestellt? 1. wieso überhaupt das erneute Backup von Raspi aufs Nas? Du hattest dich schon ein Backup mit identische, Stand? 2. warum Kanäle neu anlegen? Ich dachte Du wolltest im den Kanälen aus dem Restore weiter arbeiten? > 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 ..." Spannend. > Danach gelang mir das Erstellen des öffentlichen Kanals, aber auch nach dem > Eintragen der öffentlichen UID sind meine Kanäle weg. Versteht ich auch nicht. Einmal legst du an, einmal „trägst du ein“? > Hat noch jemand eine Idee, was da schiefgelaufen sein könnte ? Ich glaube Du müsstest mal erklären was Du eigentlich vor hast. Mich hast Du abgehängt. Dann bitte Screenshot vom Browser beim abonnieren öffentlicher Kanäle. Letztlich könnten wir per SQL einfach mal schauen was in Deiner DB steht um dem Rätselraten ein Ende zu machen ;) Viele Grüße, Andreas > 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 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" > 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 >
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, 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-
Re: [vz-users] Bevorstehender Kartencrash
Hallo, wenn du dich angemeldet hat schreib mir oder Justin eine Mail mit deinem Usernmane, dann wirst du freigeschalten. mfg Daniel
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 je
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 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" > 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 <mailto: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" mailto:cpui...@gmail.com>> > To: "volkszaehler.org <http://volkszaehler.org/> - users" > <mailto: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? > > Nachd
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
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 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" > 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.servi
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 u
Re: [vz-users] Bevorstehender Kartencrash
Hi JD, > On 10. Jun 2020, at 18:29, John Doe 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" > 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 -
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
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 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 wrote: > &g
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>
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 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 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" > 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
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)
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 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 > <mailto: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 >> <http://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" mailto:cpui...@gmail.com>> >> To: "volkszaehler.org <http://volkszaehler.org/> - users" >> > <mailto: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 > <mailto: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" mailto:cpui...@gmail.com>> >> To: "volkszaehler.org <http://volkszaehler.org/> - users" >> > <mailto: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 d
Re: [vz-users] Bevorstehender Kartencrash
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 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" > 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 <mailto: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" mailto:cpui...@gmail.com>> > To: "volkszaehler.org <http://volkszaehler.org/> - users" > <mailto: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 <mailto: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 D
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-con
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 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" > 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... >
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
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 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 =
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, timest
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
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 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" > 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 <mailto:john...@null.net>> wrote: > > Hallo Andreas, > > das scheint zunächst zu klappen: > > pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy > <http://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 > #
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-constrai
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 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] [--] > [...] > > 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 > copyRun copy > create Create target schema > dropDrop target schema > helpDisplays help for a command > influx Copy data to InfluxDB > listLists commands > > create wäre in diesem Fall das Kommando der Wahl! > > Viele Grüße, Andreas > > On 10. Jun 2020, at 09:52, John Doe <mailto: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 > <http://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" mailto:cpui...@gmail.com>> > To: "volkszaehler.org <http://volkszaehler.org/> - users" > <mailto: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 <mailto: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 > > s
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 Dupli
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 copyRun copy create Create target schema dropDrop target schema helpDisplays help for a command influx Copy data to InfluxDB listLists commands create wäre in diesem Fall das Kommando der Wahl! Viele Grüße, Andreas > On 10. Jun 2020, at 09:52, John Doe 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 > <http://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 <mailto:john...@null.net>> wrote: > > Hallo Andreas, > > das klappt nicht: > > pi@raspberrypi:~ $ /var/www/volkszaehler.org/vendor/bin/dbcopy > <http://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: >
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 erstell
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/5131
Re: [vz-users] Bevorstehender Kartencrash
Aktuelles Image? Dann solltest du vz-admin/secure als DB-Zugangsdaten verwenden. root tut nur noch in Verbindung mit sudo, wie du schon festgestellt hast. Grüße Frank John Doe schrieb am Di., 9. Juni 2020, 19:02: > 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.org/pull/799? > > Viele Grüße, Andreas > > > 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 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:
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.org/pull/799? > > Viele Grüße, Andreas > > 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 &g
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 DEFI
Re: [vz-users] Bevorstehender Kartencrash
Hallo Christian, es wäre wahrscheinlich gut Deine Fragen in einem neuen Thread zu diskutieren. > On 9. Jun 2020, at 17:05, Christian Wimmer wrote: > > Hallo Andreas! > > Panik wollte ich keine verbreiten! 😉 > > Nein, auf der Synology hab ich noch kein Backup. > Dazu kenn ich mich noch Zuwenig mit Linux und Dbcopy (glaub ich fürs Backup – > oder doch nicht?) aus. > > Kann ich zB auf der Syno eine MySQL oder eventuell MaruaDB (je nachdem welche > besser/einfacher ist) anlegen Wo auch immer Du willst. > und diese Daten (User, PW und Pfad) in der vzlogger.conf ändern? Nein kannst Du nicht da die Datenbank gar nciht in der vzlogger.conf konfiguriert wird. Die Architektur ist so: vzlogger —> volkszaehler API (aka “Middleware”) —> Datenbank Die Konfiguration erfolgt also in der etc/middleware.yaml. vzlogger kann völlig unabhängig davon auf einem beliebigen Gerät laufen. Viele Grüße, Andreas > > > > Von: volkszaehler-users Im > Auftrag von Andreas Goetz > Gesendet: Dienstag, 9. Juni 2020 09:24 > An: volkszaehler.org - users > Betreff: Re: [vz-users] Bevorstehender Kartencrash > > Hallo Christian, > > > On 8. Jun 2020, at 19:46, Christian Wimmer <mailto: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 <mailto:volkszaehler-users-boun...@demo.volkszaehler.org>> Im Auftrag von > John Doe > Gesendet: Montag, 8. Juni 2020 19:15 > An: volkszaehler-users@demo.volkszaehler.org > <mailto: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" mailto:christ...@nega.at>> > To: "volkszaehler.org <http://volkszaehler.org/> - users" > <mailto: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 <mailto:volkszaehler-users-boun...@demo.volkszaehler.org>> Im Auftrag von > Andreas Goetz > Gesendet: Montag, 8. Juni 2020 17:34 > An: volkszaehler-users <mailto:volkszaehler-users@demo.volkszaehler.org>> > Betreff: Re: [vz-users] Bevorstehender Kartencrash > > Servus > > > On 8. Jun 2020, at 16:38, Daniel Lauckner <mailto: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
> 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 <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 <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" > 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 <mailto: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" mailto:cpui...@gmail.com>> > To: "volkszaehler.org <http://volkszaehler.org/> - users" > <mailto: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 <mailto: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" mailto:cpui...@gmail.com>> > To: "volkszaehler.org <http://volkszaehler.org/> - users" > <mailto:volkszaehler-users@demo.volkszaehler.org>> > Subject: Re: [vz-users] B
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
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 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" > 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 <mailto: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" mailto:cpui...@gmail.com>> > To: "volkszaehler.org <http://volkszaehler.org/> - users" > <mailto:volkszaehler-users@demo.volkszaehler.org>> > Subject: Re: [vz-users] Bevorstehender Kartencrash > Hallo Christian, > > On 8. Jun 2020, at 19:46, Christian Wimmer <mailto: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 (brauch
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! Panik wollte ich keine verbreiten! 😉 Nein, auf der Synology hab ich noch kein Backup. Dazu kenn ich mich noch Zuwenig mit Linux und Dbcopy (glaub ich fürs Backup – oder doch nicht?) aus. Kann ich zB auf der Syno eine MySQL oder eventuell MaruaDB (je nachdem welche besser/einfacher ist) anlegen und diese Daten (User, PW und Pfad) in der vzlogger.conf ändern? Von: volkszaehler-users Im Auftrag von Andreas Goetz Gesendet: Dienstag, 9. Juni 2020 09:24 An: volkszaehler.org - users Betreff: Re: [vz-users] Bevorstehender Kartencrash Hallo Christian, On 8. Jun 2020, at 19:46, Christian Wimmer mailto: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 mailto:volkszaehler-users-boun...@demo.volkszaehler.org>> Im Auftrag von John Doe Gesendet: Montag, 8. Juni 2020 19:15 An: volkszaehler-users@demo.volkszaehler.org<mailto: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" mailto:christ...@nega.at>> To: "volkszaehler.org<http://volkszaehler.org> - users" mailto: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 mailto:volkszaehler-users-boun...@demo.volkszaehler.org>> Im Auftrag von Andreas Goetz Gesendet: Montag, 8. Juni 2020 17:34 An: volkszaehler-users mailto:volkszaehler-users@demo.volkszaehler.org>> Betreff: Re: [vz-users] Bevorstehender Kartencrash Servus On 8. Jun 2020, at 16:38, Daniel Lauckner mailto: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
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 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" > To: "volkszaehler.org - users" > Subject: Re: [vz-users] Bevorstehender Kartencrash > Hallo Christian, > > On 8. Jun 2020, at 19:46, Christian Wimmer 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 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 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
Hi, > On 9. Jun 2020, at 16:43, John Doe 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" > To: "volkszaehler.org - users" > Subject: Re: [vz-users] Bevorstehender Kartencrash > Hallo Christian, > > On 8. Jun 2020, at 19:46, Christian Wimmer <mailto: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 <mailto:volkszaehler-users-boun...@demo.volkszaehler.org>> Im Auftrag von > John Doe > Gesendet: Montag, 8. Juni 2020 19:15 > An: volkszaehler-users@demo.volkszaehler.org > <mailto: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" mailto:christ...@nega.at>> > To: "volkszaehler.org <http://volkszaehler.org/> - users" > <mailto: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 <mailto:volkszaehler-users-boun...@demo.volkszaehler.org>> Im Auftrag von > Andreas Goetz > Gesendet: Montag, 8. Juni 2020 17:34 > An: volkszaehler-users <mailto:volkszaehler-users@demo.volkszaehler.org>> > Betreff: Re: [vz-users] Bevorstehender Kartencrash > > Servus > > > On 8. Jun 2020, at 16:38, Daniel Lauckner <mailto: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 Christian, > On 8. Jun 2020, at 19:46, Christian Wimmer 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 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" mailto:christ...@nega.at>> > To: "volkszaehler.org - users" <mailto: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 <mailto:volkszaehler-users-boun...@demo.volkszaehler.org>> Im Auftrag von > Andreas Goetz > Gesendet: Montag, 8. Juni 2020 17:34 > An: volkszaehler-users <mailto:volkszaehler-users@demo.volkszaehler.org>> > Betreff: Re: [vz-users] Bevorstehender Kartencrash > > Servus > > > On 8. Jun 2020, at 16:38, Daniel Lauckner <mailto: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
Nein, im ganz großen Netz. Soweit ich mich erinnere steht aber im VZ-Wiki auch eine Anleitung zum USB-boot. >Ok, ich klone quasi die SD auf die SSD und stell den PI so ein, dass er von >SSD bootet. > >Muss ich mal googeln. >Oder meinst du mit "im Netz" die Volkszähler-Seite (Wiki, ...)? > > > > >-Ursprüngliche Nachricht- >Von: volkszaehler-users Im >Auftrag von G.Stenzel >Gesendet: Montag, 8. Juni 2020 22:57 >An: volkszaehler.org - users >Betreff: Re: [vz-users] Bevorstehender Kartencrash > >Auf der SSD ist alles. Der Pi3 kann direkt von der SSD booten. >Im Netz findet sich die Anleitung (1x von Karte booten, USB-Bootmode >aktivieren, Kartenimage auf SSD übertragen, von SSD booten). >Mit einem 3D-Drucker kann man sich noch ein Kombigehäuse drucken (SSD unten, >Raspi oben) > >>Das mit der SSD hört sich gut an. >>Wie schiebt man die DB auf die SSD? Muss in der vzlogger.conf dies gemacht >>werden? >>Im Endeffekt schätze ich, würde es eventuell reichen, wenn auf der SSD >>eine neue DB läuft, da ich zur Auswertung und Visualisierung ioBroker >>verwende. Da hol ich mir mit einem Script die Werte vom VZ in den ioBroker. >>Das Script liest das JSON aus unter diesem Pfad. >>http://10.0.1.93/middleware.php/data.json?from=now&uuid[]= >> >> >> >> >>-Ursprüngliche Nachricht- >>Von: volkszaehler-users >> Im Auftrag von >>G.Stenzel >>Gesendet: Montag, 8. Juni 2020 21:14 >>An: volkszaehler.org - users >>Betreff: 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" mailto:christ...@nega.at>> >>>To: "volkszaehler.org - users" >>>mailto:volkszaehler-users@de >>>m >>>o.volkszaehler.org>> >>>Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo >>> >>>Frage zwischendurch: wie lange hält im Durchschnitt eine SD-Karte? >>> >>> >>> >>>Von: volkszaehler-users >>>mailto:volkszaehler- >>>u sers-boun...@demo.volkszaehler.org>> Im Auftrag von Andreas Goetz >>>Gesendet: Montag, 8. Juni 2020 17:34 >>>An: volkszaehler-users >>>mailto:volkszaehler-users@de >>>m >>>o.volkszaehler.org>> >>>Betreff: Re: [vz-users] Bevorstehender Kartencrash >>> >>>Servus >>> >>> >>>On 8. Jun 2020, at 16:38, Daniel Lauckner >>>mailto: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
Ok, ich klone quasi die SD auf die SSD und stell den PI so ein, dass er von SSD bootet. Muss ich mal googeln. Oder meinst du mit "im Netz" die Volkszähler-Seite (Wiki, ...)? -Ursprüngliche Nachricht- Von: volkszaehler-users Im Auftrag von G.Stenzel Gesendet: Montag, 8. Juni 2020 22:57 An: volkszaehler.org - users Betreff: Re: [vz-users] Bevorstehender Kartencrash Auf der SSD ist alles. Der Pi3 kann direkt von der SSD booten. Im Netz findet sich die Anleitung (1x von Karte booten, USB-Bootmode aktivieren, Kartenimage auf SSD übertragen, von SSD booten). Mit einem 3D-Drucker kann man sich noch ein Kombigehäuse drucken (SSD unten, Raspi oben) >Das mit der SSD hört sich gut an. >Wie schiebt man die DB auf die SSD? Muss in der vzlogger.conf dies gemacht >werden? >Im Endeffekt schätze ich, würde es eventuell reichen, wenn auf der SSD >eine neue DB läuft, da ich zur Auswertung und Visualisierung ioBroker >verwende. Da hol ich mir mit einem Script die Werte vom VZ in den ioBroker. >Das Script liest das JSON aus unter diesem Pfad. >http://10.0.1.93/middleware.php/data.json?from=now&uuid[]= > > > > >-Ursprüngliche Nachricht- >Von: volkszaehler-users > Im Auftrag von >G.Stenzel >Gesendet: Montag, 8. Juni 2020 21:14 >An: volkszaehler.org - users >Betreff: 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" mailto:christ...@nega.at>> >>To: "volkszaehler.org - users" >>mailto:volkszaehler-users@de >>m >>o.volkszaehler.org>> >>Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo >> >>Frage zwischendurch: wie lange hält im Durchschnitt eine SD-Karte? >> >> >> >>Von: volkszaehler-users >>mailto:volkszaehler- >>u sers-boun...@demo.volkszaehler.org>> Im Auftrag von Andreas Goetz >>Gesendet: Montag, 8. Juni 2020 17:34 >>An: volkszaehler-users >>mailto:volkszaehler-users@de >>m >>o.volkszaehler.org>> >>Betreff: Re: [vz-users] Bevorstehender Kartencrash >> >>Servus >> >> >>On 8. Jun 2020, at 16:38, Daniel Lauckner mailto: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
Auf der SSD ist alles. Der Pi3 kann direkt von der SSD booten. Im Netz findet sich die Anleitung (1x von Karte booten, USB-Bootmode aktivieren, Kartenimage auf SSD übertragen, von SSD booten). Mit einem 3D-Drucker kann man sich noch ein Kombigehäuse drucken (SSD unten, Raspi oben) >Das mit der SSD hört sich gut an. >Wie schiebt man die DB auf die SSD? Muss in der vzlogger.conf dies gemacht >werden? >Im Endeffekt schätze ich, würde es eventuell reichen, wenn auf der SSD eine >neue DB läuft, da ich zur Auswertung und >Visualisierung ioBroker verwende. Da hol ich mir mit einem Script die Werte >vom VZ in den ioBroker. >Das Script liest das JSON aus unter diesem Pfad. >http://10.0.1.93/middleware.php/data.json?from=now&uuid[]= > > > > >-Ursprüngliche Nachricht- >Von: volkszaehler-users Im >Auftrag von G.Stenzel >Gesendet: Montag, 8. Juni 2020 21:14 >An: volkszaehler.org - users >Betreff: 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" mailto:christ...@nega.at>> >>To: "volkszaehler.org - users" >>mailto:volkszaehler-users@dem >>o.volkszaehler.org>> >>Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo >> >>Frage zwischendurch: wie lange hält im Durchschnitt eine SD-Karte? >> >> >> >>Von: volkszaehler-users >>mailto:volkszaehler-u >>sers-boun...@demo.volkszaehler.org>> Im Auftrag von Andreas Goetz >>Gesendet: Montag, 8. Juni 2020 17:34 >>An: volkszaehler-users >>mailto:volkszaehler-users@dem >>o.volkszaehler.org>> >>Betreff: Re: [vz-users] Bevorstehender Kartencrash >> >>Servus >> >> >>On 8. Jun 2020, at 16:38, Daniel Lauckner mailto: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
Das mit der SSD hört sich gut an. Wie schiebt man die DB auf die SSD? Muss in der vzlogger.conf dies gemacht werden? Im Endeffekt schätze ich, würde es eventuell reichen, wenn auf der SSD eine neue DB läuft, da ich zur Auswertung und Visualisierung ioBroker verwende. Da hol ich mir mit einem Script die Werte vom VZ in den ioBroker. Das Script liest das JSON aus unter diesem Pfad. http://10.0.1.93/middleware.php/data.json?from=now&uuid[]= -Ursprüngliche Nachricht- Von: volkszaehler-users Im Auftrag von G.Stenzel Gesendet: Montag, 8. Juni 2020 21:14 An: volkszaehler.org - users Betreff: 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" mailto:christ...@nega.at>> >To: "volkszaehler.org - users" >mailto:volkszaehler-users@dem >o.volkszaehler.org>> >Subject: Re: [vz-users] Bevorstehender Kartencrash Hallo > >Frage zwischendurch: wie lange hält im Durchschnitt eine SD-Karte? > > > >Von: volkszaehler-users >mailto:volkszaehler-u >sers-boun...@demo.volkszaehler.org>> Im Auftrag von Andreas Goetz >Gesendet: Montag, 8. Juni 2020 17:34 >An: volkszaehler-users >mailto:volkszaehler-users@dem >o.volkszaehler.org>> >Betreff: Re: [vz-users] Bevorstehender Kartencrash > >Servus > > >On 8. Jun 2020, at 16:38, Daniel Lauckner mailto: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
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" mailto:christ...@nega.at>> >To: "volkszaehler.org - users" >mailto: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 >mailto:volkszaehler-users-boun...@demo.volkszaehler.org>> > Im Auftrag von Andreas Goetz >Gesendet: Montag, 8. Juni 2020 17:34 >An: volkszaehler-users >mailto:volkszaehler-users@demo.volkszaehler.org>> >Betreff: Re: [vz-users] Bevorstehender Kartencrash > >Servus > > >On 8. Jun 2020, at 16:38, Daniel Lauckner mailto: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 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" mailto:christ...@nega.at>> To: "volkszaehler.org - users" mailto: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 mailto:volkszaehler-users-boun...@demo.volkszaehler.org>> Im Auftrag von Andreas Goetz Gesendet: Montag, 8. Juni 2020 17:34 An: volkszaehler-users mailto:volkszaehler-users@demo.volkszaehler.org>> Betreff: Re: [vz-users] Bevorstehender Kartencrash Servus On 8. Jun 2020, at 16:38, Daniel Lauckner mailto: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 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
Das kann man so nicht sagen. Wenn sie defekt ist dann ist die Wahrscheinlichkeit dass ein Backup gut gewesen wäre jedenfalls 100% ;) Viele Grüße, Andreas > Am 08.06.2020 um 18:14 schrieb Christian Wimmer : > > > 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 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 mailto: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
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, am Montag, 8. Juni 2020 um 11:02 hat John Doe geschrieben: > Gibt es ein wiki zum Docker-Image und dessen Installation ? Nein. > 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. mfg Daniel
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
Hi JD, > On 8. Jun 2020, at 10:46, John Doe 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" > To: "volkszaehler.org - users" > Subject: Re: [vz-users] Bevorstehender Kartencrash > Moin JD, > > On 8. Jun 2020, at 10:04, John Doe <mailto: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" mailto:john...@null.net>> > To: volkszaehler-users@demo.volkszaehler.org > <mailto: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 <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" mailto:cpui...@gmail.com>> > To: "volkszaehler.org <http://volkszaehler.org/> - users" > <mailto: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 <mailto: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" mailto:cpui...@gmail.com>> > To: "volkszaehler.org <http://volkszaehler.org/> - users" > <mailto:volkszaehler-user
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
Moin JD, > On 8. Jun 2020, at 10:04, John Doe 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" > 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 <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 <mailto: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" mailto:cpui...@gmail.com>> > To: "volkszaehler.org <http://volkszaehler.org/> - users" > <mailto: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 <mailto: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 > <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] Bevorstehender Kartencrash
Jetzt nicht mehr bzw. nur händisch auf der DB- der Peak wäre nicht entstanden hättest Du wie vorgeschlagen alle Daten mitgenommen :/ > Am 04.12.2019 um 15:35 schrieb John Doe : > > > Hallo zusammen, > > eine (wiederkehrende) Frage hätte ich noch: > Als Kollateralschaden des zurückgespielten und "kalt", d.h. mit zu Beginn > inkonsistenten Daten gestarteten Raspis hat sich ein unschönes Artefakt > (überhöhter Peak) am zu Beginn der Wiederaufnahme ergeben. Läßt sich dieser > irgendwie "glätten"? > > Grüße, > > JD. > > > Sent: Wednesday, December 04, 2019 at 8:48 AM > From: "Andreas Goetz" > To: "volkszaehler.org - users" > Subject: Re: [vz-users] Bevorstehender Kartencrash > Moin JD, > > wichtig ist dass Du zufrieden bist und Deine Daten retten konntest. Die > verbliebenen 1,5 Tage hättest Du Dir auch noch sichern können wenn Du nochmal > aus dem "kranken" System DBCopy in das "neue" System gemacht hättest- > allerdings bevor da neue Daten reingeschrieben werden ;) > > Viele Grüße, > Andreas > > >> On Tue, Dec 3, 2019 at 9:05 PM John Doe wrote: >> 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 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" >> 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 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, eine (wiederkehrende) Frage hätte ich noch: Als Kollateralschaden des zurückgespielten und "kalt", d.h. mit zu Beginn inkonsistenten Daten gestarteten Raspis hat sich ein unschönes Artefakt (überhöhter Peak) am zu Beginn der Wiederaufnahme ergeben. Läßt sich dieser irgendwie "glätten"? Grüße, JD. Sent: Wednesday, December 04, 2019 at 8:48 AM From: "Andreas Goetz" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash Moin JD, wichtig ist dass Du zufrieden bist und Deine Daten retten konntest. Die verbliebenen 1,5 Tage hättest Du Dir auch noch sichern können wenn Du nochmal aus dem "kranken" System DBCopy in das "neue" System gemacht hättest- allerdings bevor da neue Daten reingeschrieben werden ;) Viele Grüße, Andreas On Tue, Dec 3, 2019 at 9:05 PM John Doe <john...@null.net> wrote: 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
Moin JD, wichtig ist dass Du zufrieden bist und Deine Daten retten konntest. Die verbliebenen 1,5 Tage hättest Du Dir auch noch sichern können wenn Du nochmal aus dem "kranken" System DBCopy in das "neue" System gemacht hättest- allerdings bevor da neue Daten reingeschrieben werden ;) Viele Grüße, Andreas On Tue, Dec 3, 2019 at 9:05 PM John Doe wrote: > 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 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" > *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 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, am Dienstag, 3. Dezember 2019 um 21:04 hat John Doe geschrieben: > https://github.com/Drewsif/PiShrink Nutze ich auch um das VZ-Image zu verkleinern bevor es gepackt und online gestellt wird. Dementsprechend steht auch ein Absatz dazu im HowTo "Image erstellen". mfg Daniel
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
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 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" > 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 <mailto: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 > <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.