Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden Andreas Goetz
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.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

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden 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.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)

 


Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden Andreas Goetz
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 - 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]

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden John Doe
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  wrote:
 


Womit bricht es ab? gleicher Fehler?
 

Wenn Dein vzlogger gestoppt ist dann starte den Kopiervorgang-

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden Andreas Goetz
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:
>  
> 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 

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden 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:
 




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] Bevorstehe

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden Andreas Goetz
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 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, all

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden 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 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: 

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden Andreas Goetz
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" mailto:cpui...@gmail.com>>
>> 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 > > 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  - 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"]: 
>> 
>>   

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden Andreas Goetz
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  > 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  - 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  
>   
>  

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden John Doe
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  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: volks

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden Andreas Goetz
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...
>   
>   
>  [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: "Andr

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden John Doe
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  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_

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden Andreas Goetz
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 = 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,

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden 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 = 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;
   

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden John Doe
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 = 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  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 =

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden Andreas Goetz
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  > 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:

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden John Doe
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  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 T

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden Andreas Goetz
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  > 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" mailto:cpui...@gmail.com>>
> 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"]:   
>   
>   
> 

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden John Doe
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  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" 
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:
  

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden Andreas Goetz
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 
>  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  > 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
>  
> 

Re: [vz-users] Bevorstehender Kartencrash

2020-06-10 Diskussionsfäden John Doe
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  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 DEFI