Re: [vz-users] Datenbank auf NAS verlagern
Die Geräuschentwicklung hatte ich nicht bedacht. Ist aber für mich nicht relevant da das NAS in einem Nebenraum (HWR) steht. Ich könnte eine kleine SSD an einen USB2.0 Port anschließen. Andere Möglichkeiten bietet die Synology DS213J nicht. Fraglich ob das bzgl. Übertragungsgeschwindigkeit langt? Auch werde ich die Auslagerung von DB, Middelware und Frontend auf die SSD alleine nicht hinbekommen. Grüße Micha Von: volkszaehler-users [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Stefan Bauer Gesendet: Dienstag, 3. November 2020 16:47 An: volkszaehler.org - users Betreff: Re: [vz-users] Datenbank auf NAS verlagern Ich habe bei mir meine DB und auch middleware + Frontend auf das NAS ausgelagert. Ich habe allerdings den Vorteil, dass ich neben den HDDs im NAS noch eine kleinere SSD habe, die ich dafür nutze. Damit können sich die HDDs schlafen legen und machen keinen Lärm und der Rest wird lautlos auf der SSD verarbeitet... Stefan Von meinem iPad gesendet Am 03.11.2020 um 15:09 schrieb Michael Hartmann : Hallo, nachdem es mir mit Hilfe einiger Nutzer dieser Liste gelungen ist eine Kopie der DB auf meiner Synology Diskstation anzulegen und mittels täglichem Cronjob aktuell zu halten, erwäge ich nun die Middleware direkt in die DB auf dem NAS schreiben zu lassen. Für mich erkennbare Vorteile liegen in einer Verringerung der Zugriffe auf die SD-Karte des Raspberry und einer damit einhergehenden längeren Lebensdauer. Weiter habe ich auf dem NAS durch Spiegelung auf eine zweite HDD zwar kein Backup aber zumindest eine Sicherung für den Fall eines HDD Ausfalls. Dem entgegen steht das die Festplatten auf dem NAS bedingt durch kontinuierliche Zugriffe der Middleware auf die DB permanent laufen. Aktuell habe ich die Synology so konfiguriert, dass die Festplatten bei Inaktivität abgeschaltet werden (längere Lebensdauer?, geringere Gesamtstromaufnahme des NAS). Bei der aktuellen Nutzung des NAS sind die HDDs tatsächlich über lange Zeit aus. Die verbauten HDDs sind WD red für 24/7 Betrieb. Ich bin unsicher, was hier Sinn macht und wäre an Rückmeldungen interessiert. Grüße Micha
Re: [vz-users] Datenbank auf NAS verlagern
* DB und auch middleware + Frontend auf das NAS ausgelagert Hallo Stefan! Ist das einfach umzusetzen? LG Von: volkszaehler-users Im Auftrag von Stefan Bauer Gesendet: Dienstag, 3. November 2020 16:47 An: volkszaehler.org - users Betreff: Re: [vz-users] Datenbank auf NAS verlagern Ich habe bei mir meine DB und auch middleware + Frontend auf das NAS ausgelagert. Ich habe allerdings den Vorteil, dass ich neben den HDDs im NAS noch eine kleinere SSD habe, die ich dafür nutze. Damit können sich die HDDs schlafen legen und machen keinen Lärm und der Rest wird lautlos auf der SSD verarbeitet... Stefan Von meinem iPad gesendet Am 03.11.2020 um 15:09 schrieb Michael Hartmann mailto:hartmann-mi...@web.de>>: Hallo, nachdem es mir mit Hilfe einiger Nutzer dieser Liste gelungen ist eine Kopie der DB auf meiner Synology Diskstation anzulegen und mittels täglichem Cronjob aktuell zu halten, erwäge ich nun die Middleware direkt in die DB auf dem NAS schreiben zu lassen. Für mich erkennbare Vorteile liegen in einer Verringerung der Zugriffe auf die SD-Karte des Raspberry und einer damit einhergehenden längeren Lebensdauer. Weiter habe ich auf dem NAS durch Spiegelung auf eine zweite HDD zwar kein Backup aber zumindest eine Sicherung für den Fall eines HDD Ausfalls. Dem entgegen steht das die Festplatten auf dem NAS bedingt durch kontinuierliche Zugriffe der Middleware auf die DB permanent laufen. Aktuell habe ich die Synology so konfiguriert, dass die Festplatten bei Inaktivität abgeschaltet werden (längere Lebensdauer?, geringere Gesamtstromaufnahme des NAS). Bei der aktuellen Nutzung des NAS sind die HDDs tatsächlich über lange Zeit aus. Die verbauten HDDs sind WD red für 24/7 Betrieb. Ich bin unsicher, was hier Sinn macht und wäre an Rückmeldungen interessiert. Grüße Micha
Re: [vz-users] Datenbank auf NAS verlagern
Ich habe bei mir meine DB und auch middleware + Frontend auf das NAS ausgelagert. Ich habe allerdings den Vorteil, dass ich neben den HDDs im NAS noch eine kleinere SSD habe, die ich dafür nutze. Damit können sich die HDDs schlafen legen und machen keinen Lärm und der Rest wird lautlos auf der SSD verarbeitet... Stefan Von meinem iPad gesendet > Am 03.11.2020 um 15:09 schrieb Michael Hartmann : > > > Hallo, > > nachdem es mir mit Hilfe einiger Nutzer dieser Liste gelungen ist eine Kopie > der DB auf meiner Synology Diskstation anzulegen und mittels täglichem > Cronjob aktuell zu halten, erwäge ich nun die Middleware direkt in die DB auf > dem NAS schreiben zu lassen. > > Für mich erkennbare Vorteile liegen in einer Verringerung der Zugriffe auf > die SD-Karte des Raspberry und einer damit einhergehenden längeren > Lebensdauer. Weiter habe ich auf dem NAS durch Spiegelung auf eine zweite HDD > zwar kein Backup aber zumindest eine Sicherung für den Fall eines HDD > Ausfalls. > > Dem entgegen steht das die Festplatten auf dem NAS bedingt durch > kontinuierliche Zugriffe der Middleware auf die DB permanent laufen. Aktuell > habe ich die Synology so konfiguriert, dass die Festplatten bei Inaktivität > abgeschaltet werden (längere Lebensdauer?, geringere Gesamtstromaufnahme des > NAS). Bei der aktuellen Nutzung des NAS sind die HDDs tatsächlich über lange > Zeit aus. Die verbauten HDDs sind WD red für 24/7 Betrieb. > > Ich bin unsicher, was hier Sinn macht und wäre an Rückmeldungen interessiert. > > Grüße > > Micha
Re: [vz-users] Bevorstehender Kartencrash (?)
Hallo Daniel, perfekt, Danke für die Info. Ich werde nochmal den Sitz des Lesekopfes prüfen und mich ggfs. um Ersatz bemühen. Beste Grüße JD. Sent: Tuesday, November 03, 2020 at 3:39 PM From: "Daniel Lauckner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash (?) Hallo, am Dienstag, 3. November 2020 um 15:32 hat John Doe geschrieben: > Für den Fall eines defekten IR-Lesekopfes: Kann ich diesen einfach > so ersetzen, oder muss ich in der DB dann neue UIDs anlegen ? Keine neue UUID nötig, prüfe aber ob dem neuen Kopf das selbe Device zugeordnet wurde. Ansonsten udev-Regel oder vzlogger.conf anpassen. mfg Daniel
Re: [vz-users] Bevorstehender Kartencrash (?)
Hallo, am Dienstag, 3. November 2020 um 15:32 hat John Doe geschrieben: > Für den Fall eines defekten IR-Lesekopfes: Kann ich diesen einfach > so ersetzen, oder muss ich in der DB dann neue UIDs anlegen ? Keine neue UUID nötig, prüfe aber ob dem neuen Kopf das selbe Device zugeordnet wurde. Ansonsten udev-Regel oder vzlogger.conf anpassen. mfg Daniel
Re: [vz-users] Bevorstehender Kartencrash (?)
Hallo Daniel, besten Dank für die schnelle Antwort. Einen verrutschten Lesekopf würde ich auschliessen wollen, da dieser mit Powerstrips auf den Zähler geklebt ist und bisher "eigentlich" immer stabil war. Für den Fall eines defekten IR-Lesekopfes: Kann ich diesen einfach so ersetzen, oder muss ich in der DB dann neue UIDs anlegen ? Beste Grüße JD. Sent: Tuesday, November 03, 2020 at 3:22 PM From: "Daniel Lauckner" To: "volkszaehler.org - users" Subject: Re: [vz-users] Bevorstehender Kartencrash (?) Hallo, am Dienstag, 3. November 2020 um 15:16 hat John Doe geschrieben: > [Oct 15 21:33:16][d0] read timed out!, context: 1, bytes read: 0, last byte 0x2f Das sind Lesefehler auf der Schnittstelle zum Zähler. Kein Problem mit der SD. Ursache könnte ein verrutschter Lesekopf oder nachlassende Elektronik sein. mfg Daniel
Re: [vz-users] Bevorstehender Kartencrash (?)
Hallo, am Dienstag, 3. November 2020 um 15:16 hat John Doe geschrieben: > [Oct 15 21:33:16][d0] read timed out!, context: 1, bytes read: 0, last > byte 0x2f Das sind Lesefehler auf der Schnittstelle zum Zähler. Kein Problem mit der SD. Ursache könnte ein verrutschter Lesekopf oder nachlassende Elektronik sein. mfg Daniel
[vz-users] Bevorstehender Kartencrash (?)
Hallo zusammen, bei meinem bis vorgestern problemlos laufenden VZ auf einem RPi3 stellen sich zunehmend Aussetzer dergestalt ein, dass im Frontend keine Daten mehr ankommen. Im /var/log/vzlogger.log steht vermehrt das Folgende: [Oct 15 21:32:48][main] vzlogger v0.7.0 based on heads/master-0-g12e74ddd43 from Sun, 2 Jun 2019 20:48:14 +0200 started. [Oct 15 21:32:49][main] log level is 0 [Oct 15 21:33:16][d0] read timed out!, context: 1, bytes read: 0, last byte 0x2f [Oct 15 21:33:17][d0] read timed out!, context: 1, bytes read: 0, last byte 0x2f [Nov 01 13:41:35][main] vzlogger v0.7.0 based on heads/master-0-g12e74ddd43 from Sun, 2 Jun 2019 20:48:14 +0200 started. [Nov 01 13:41:35][main] log level is 0 [Nov 03 15:06:56][d0] read timed out!, context: 1, bytes read: 0, last byte 0x2f [Nov 03 15:06:57][d0] read timed out!, context: 1, bytes read: 0, last byte 0x2f Kündigt sich da ein neuerlicher Kartencrash an und sollte ich mich um Neuinstallation bemühen ? Ich habe eine Sicherung der lauffähigen vzlogger.conf und der Datenbank bis gestern. Schlusshinweis: Ein update/upgrade liefert das Folgende: Unpacking raspberrypi-kernel (1.20201022-1) over (1.20200902-1) ... dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing archive /tmp/apt-dpkg-install-lTa17a/14-raspberrypi-kernel_1.20201022-1_armhf.deb (--unpack): cannot copy extracted data for './lib/modules/5.4.72-v7+/kernel/drivers/staging/rtl8188eu/r8188eu.ko' to '/lib/modules/5.4.72-v7+/kernel/drivers/staging/rtl8188eu/r8188eu.ko.dpkg-new': unexpected end of file or stream run-parts: executing /etc/kernel/postrm.d/initramfs-tools 5.4.72+ /boot/kernel.img run-parts: executing /etc/kernel/postrm.d/initramfs-tools 5.4.72-v7+ /boot/kernel7.img run-parts: executing /etc/kernel/postrm.d/initramfs-tools 5.4.72-v7l+ /boot/kernel7l.img run-parts: executing /etc/kernel/postrm.d/initramfs-tools 5.4.72-v8+ /boot/kernel8.img You do not have enough space in /boot to install this package. Skipping Pi 4 support Unpacking raspberrypi-bootloader (1.20201022-1) over (1.20200902-1) ... Preparing to unpack .../18-libx11-data_2%3a1.6.7-1+deb10u1_all.deb ... Unpacking libx11-data (2:1.6.7-1+deb10u1) over (2:1.6.7-1) ... dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing archive /tmp/apt-dpkg-install-lTa17a/18-libx11-data_2%3a1.6.7-1+deb10u1_all.deb (--unpack): cannot copy extracted data for './usr/share/X11/XErrorDB' to '/usr/share/X11/XErrorDB.dpkg-new': unexpected end of file or stream Preparing to unpack .../19-libx11-6_2%3a1.6.7-1+deb10u1_armhf.deb ... Unpacking libx11-6:armhf (2:1.6.7-1+deb10u1) over (2:1.6.7-1) ... dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing archive /tmp/apt-dpkg-install-lTa17a/19-libx11-6_2%3a1.6.7-1+deb10u1_armhf.deb (--unpack): cannot copy extracted data for './usr/lib/arm-linux-gnueabihf/libX11.so.6.3.0' to '/usr/lib/arm-linux-gnueabihf/libX11.so.6.3.0.dpkg-new': unexpected end of file or stream Preparing to unpack .../20-mariadb-client_1%3a10.3.25-0+deb10u1_all.deb ... Unpacking mariadb-client (1:10.3.25-0+deb10u1) over (1:10.3.23-0+deb10u1) ... dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing archive /tmp/apt-dpkg-install-lTa17a/20-mariadb-client_1%3a10.3.25-0+deb10u1_all.deb (--unpack): cannot copy extracted data for './usr/share/doc/mariadb-client/changelog.Debian.gz' to '/usr/share/doc/mariadb-client/changelog.Debian.gz.dpkg-new': unexpected end of file or stream Preparing to unpack .../21-mariadb-server_1%3a10.3.25-0+deb10u1_all.deb ... Unpacking mariadb-server (1:10.3.25-0+deb10u1) over (1:10.3.23-0+deb10u1) ... dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing archive /tmp/apt-dpkg-install-lTa17a/21-mariadb-server_1%3a10.3.25-0+deb10u1_all.deb (--unpack): cannot copy extracted data for './usr/share/doc/mariadb-server/changelog.Debian.gz' to '/usr/share/doc/mariadb-server/changelog.Debian.gz.dpkg-new': unexpected end of file or stream Preparing to unpack .../22-raspberrypi-sys-mods_20201026_armhf.deb ... Unpacking raspberrypi-sys-mods (20201026) over (20200812) ... Preparing to unpack .../23-raspi-config_20201027_all.deb ... Unpacking raspi-config (20201027) over (20200902) ... Preparing to unpack .../24-rpi-eeprom_10.2-1_armhf.deb ... Unpacking rpi-eeprom (10.2-1) over (9.0-1) ... Errors were encountered while processing: /tmp/apt-dpkg-install-lTa17a/14-raspberrypi-kernel_1.20201022-1_armhf.deb /tmp/apt
[vz-users] Datenbank auf NAS verlagern
Hallo, nachdem es mir mit Hilfe einiger Nutzer dieser Liste gelungen ist eine Kopie der DB auf meiner Synology Diskstation anzulegen und mittels täglichem Cronjob aktuell zu halten, erwäge ich nun die Middleware direkt in die DB auf dem NAS schreiben zu lassen. Für mich erkennbare Vorteile liegen in einer Verringerung der Zugriffe auf die SD-Karte des Raspberry und einer damit einhergehenden längeren Lebensdauer. Weiter habe ich auf dem NAS durch Spiegelung auf eine zweite HDD zwar kein Backup aber zumindest eine Sicherung für den Fall eines HDD Ausfalls. Dem entgegen steht das die Festplatten auf dem NAS bedingt durch kontinuierliche Zugriffe der Middleware auf die DB permanent laufen. Aktuell habe ich die Synology so konfiguriert, dass die Festplatten bei Inaktivität abgeschaltet werden (längere Lebensdauer?, geringere Gesamtstromaufnahme des NAS). Bei der aktuellen Nutzung des NAS sind die HDDs tatsächlich über lange Zeit aus. Die verbauten HDDs sind WD red für 24/7 Betrieb. Ich bin unsicher, was hier Sinn macht und wäre an Rückmeldungen interessiert. Grüße Micha
