Foutmelding na herinstallatie + restore

svdo commented 4 years ago

Hallo! Enorm bedankt voor dsmrreader, ik ben er heel erg blij mee!!! Ik heb een probleempje:

Wat gebruik je?

DSMR-reader versie (rechtsbovenin applicatie zichtbaar): v2.9
Hardware (RaspberryPi 3, 4 of iets anders): RaspberryPi 3b+
DSMR-protocol slimme meter (v2, v4 of v5): v5 (denk ik?)

Bij fouten

Ik gebruik sinds begin dit jaar dsmrreader. Ik had wat problemen met de SD kaart van mijn Raspberry, dus ik heb van de week de boel opnieuw geïnstalleerd op een externe harddisk. Ik heb een backup teruggezet. Twee vragen:

Ik heb een aantal backup files. Ik heb degene met de meeste regels gebruikt, en die importeerde goed. De dag- en uurstatistieken waren echter leeg. Het lijkt erop dat dsmrreader die nu langzaam maar zeker weer aan het herberekenen is, kan dat kloppen?
Als ik de web client open, zie ik een paar 'spinners': de rood en groen rechtsboven (actuele waarde als ik me niet vergis), en ook onder de knop 'display current month'. Ik zie ook onderstaande foutmelding in /var/log/supervisor/dsmr_datalogger-stderr---supervisor-rkb79j.log. Is dit iets om me zorgen over te maken, kan ik het oplossen?

[2019-10-27 08:31:02,590] ERROR     [!] Exception raised in run(): Traceback (most recent call last):
  File "/home/dsmr/dsmr-reader/dsmr_backend/mixins.py", line 79, in run_once
    self.run(data=self.data, **options)
  File "/home/dsmr/dsmr-reader/dsmr_datalogger/management/commands/dsmr_datalogger.py", line 26, in run
    dsmr_datalogger.services.telegram_to_reading(data=telegram)
  File "/home/dsmr/dsmr-reader/dsmr_datalogger/services.py", line 260, in telegram_to_reading
    new_reading = DsmrReading.objects.create(**reading_kwargs)
  File "/home/dsmr/.virtualenvs/dsmrreader/lib/python3.7/site-packages/django/db/models/manager.py", line 82, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/home/dsmr/.virtualenvs/dsmrreader/lib/python3.7/site-packages/django/db/models/query.py", line 422, in create
    obj.save(force_insert=True, using=self.db)
  File "/home/dsmr/.virtualenvs/dsmrreader/lib/python3.7/site-packages/django/db/models/base.py", line 741, in save
    force_update=force_update, update_fields=update_fields)
  File "/home/dsmr/.virtualenvs/dsmrreader/lib/python3.7/site-packages/django/db/models/base.py", line 790, in save_base
    update_fields=update_fields, raw=raw, using=using,
  File "/home/dsmr/.virtualenvs/dsmrreader/lib/python3.7/site-packages/django/dispatch/dispatcher.py", line 175, in send
    for receiver in self._live_receivers(sender)
  File "/home/dsmr/.virtualenvs/dsmrreader/lib/python3.7/site-packages/django/dispatch/dispatcher.py", line 175, in <listcomp>
    for receiver in self._live_receivers(sender)
  File "/home/dsmr/dsmr-reader/dsmr_mqtt/apps.py", line 67, in _on_dsmrreading_created_signal
    instance = DsmrReading.objects.get(pk=instance.pk)
  File "/home/dsmr/.virtualenvs/dsmrreader/lib/python3.7/site-packages/django/db/models/manager.py", line 82, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/home/dsmr/.virtualenvs/dsmrreader/lib/python3.7/site-packages/django/db/models/query.py", line 412, in get
    (self.model._meta.object_name, num)
dsmr_datalogger.models.reading.DsmrReading.MultipleObjectsReturned: get() returned more than one DsmrReading -- it returned 2!

svdo commented 4 years ago

Ik weet inmiddels wat het probleem is, alleen nog niet hoe ik het op moet lossen. De ids die worden gebruikt om in dsmr_datalogger_dsmrreading te schrijven zijn namelijk verkeerd. Blijkbaar is 'ie weer vooraan begonnen, in plaats van verder te gaan waar 'ie was gebleven met ids.

Bijvoorbeeld deze query geeft twee resultaten:

select * from dsmr_datalogger_dsmrreading where id=1100;

svdo commented 4 years ago

Ik heb besloten om de tabel te repareren door zelf de id's te veranderen zodat ze weer uniek oplopend zijn. Heb ok de public.dsmr_datalogger_dsmrreading_id_seq sequence goed gezet. Statistiektabellen voor day en hours leeggemaakt en id_seqs teruggezet op 1, zojuist de boel weer gestart. 🤞

dennissiemensma commented 4 years ago

Bedankt voor je melding. Begrijp ik het goed dat je het inmiddels zelf hebt kunnen oplossen?

svdo commented 4 years ago

Geen idee eigenlijk. De foutmelding MultipleObjectsReturned is weg, maar ik zie nog steeds die spinners. De dagelijks en "uurlijkse" statistiektabellen blijven (vooralsnog?) leeg. En als ik bv de statuspagina probeer te openen krijg ik een timeout. Hij lijkt ergens druk mee bezig, maar ik heb geen idee of 'ie het goede aan het doen is.

Heb je enig idee wat er gaande kan zijn, of hoe ik daar achter kan komen? Misschien op de command line?
Zouden die statistieken automatisch opnieuw opgebouwd moeten worden, of werkt het niet zo?

svdo commented 4 years ago

Het valt me trouwens ook op dat de laatste DsmrReadings wel in de database staan, maar dat de grafieken van de afgelopen 24 uur in de UI (die verschijnen wel) zo'n 20 uur achter lopen.

dennissiemensma commented 4 years ago

Je kunt het beste even in de logs kijken van dsmr_backend. https://dsmr-reader.readthedocs.io/nl/v2/troubleshooting.html

svdo commented 4 years ago

Ik heb in settings.py debug logging aangezet en post-deploy.sh gedraaid en ook met supervisorctl alles herstart. Ik zie log files in /var/log/supervisor' en in~dsmr/dsmr-reader/logs. Die laatste lijken niet gebruikt te worden? Die in/var/log/supervisor` laten nu idd ook de telegrams zien. Verder zie ik:

==> dsmr_backend.log <==
[2019-10-30 07:52:53,322] DEBUG     - Processed reading: 12566521 @ 2019-10-27 21:27:47+01:00

Dat lijkt raar, de datum is nu 30 oktober, maar hij verwerkt één telegram van 27 oktober. Als ik /status op probeer te vragen, krijg ik een timeout maar verder geen enkele extra logging.

Heb je nog ideeën waar ik naar kan kijken?

Als het niet meer te repareren is, is het dan als een soort van "last resort" mogelijk om een nieuwe installatie "from scratch" te doen en daarin alleen alle readings te importeren en dan DSMR Reader alle statistieken opnieuw te laten berekenen of zo? Dat zou ik natuurlijk liever vermijden...

svdo commented 4 years ago

Overigens zitten er nu meer dan 11.6 miljoen rijen in in mijn dsmr_datalogger_dsmrreading. Ik vraag me af of ik niet gewoon tegen performance problemen aan zit te kijken...

svdo commented 4 years ago

Update:

Ik heb twee indexen aangemaakt:

alter table dsmr_datalogger_dsmrreading add primary key(id);
create index on dsmr_datalogger_dsmrreading (timestamp);

Nu heeft 'ie in een paar uur tijd 64 dagstatistieken en 1536 uurstatistieken aangemaakt, waar 'ie eerder nog geen handvol had gemaakt in een paar dagen tijd. Ik krijg ook weer zinnige grafieken te zien. Ik zal hier updates blijven posten, maar ik denk dat er dus wel een performance probleem is.

dennissiemensma commented 4 years ago

Bedankt voor je terugkoppeling. Dat verklaart een hoop. Het is raar dat er indexes missen, ik heb dat 1x eerder gehoord van een gebruiker.

Ik heb zelf geen DSMR-v5 meter, maar een Pi 3 zou het doorgaans wel aan moeten kunnen.

Een advies wat ik je nog kan geven, is om de sleep voor de datalogger (DSMRREADER_DATALOGGER_SLEEP) op bijvoorbeeld 5 seconden te zetten: https://dsmr-reader.readthedocs.io/en/latest/settings.html#dsmrreader-datalogger-sleep Hiermee krijg je niet elke seconde een telegram, maar elke 5 seconde. Het is meer dan nauwkeurig genoeg voor alleen de meterstand.

Mocht je echter waarde hechten aan elk telegram per seconde, dan kun je het uiteraard laten staan. Het kost je wel wat performance en op termijn schijfruimte, maar dat is vanzelfsprekend een persoonlijke keuze voor jezelf.

svdo commented 4 years ago

Bedankt voor je reactie @dennissiemensma. Ik vind het zelf ook raar. Is er een manier waarop ik kan controleren of de rest van het database schema wel klopt? Misschien ontbreken er meer indexen of andere objecten...

dennissiemensma commented 4 years ago

Je kunt de indexes opvragen met:

sudo su - postgres
psql dsmrreader

\di dsmr_*

dennissiemensma commented 4 years ago

Ter referentie, dit is mijn omgeving:

                                                                List of relations
 Schema |                              Name                               | Type  |   Owner    |                      Table                      
--------+-----------------------------------------------------------------+-------+------------+-------------------------------------------------
 public | dsmr_api_apisettings_pkey                                       | index | dsmrreader | dsmr_api_apisettings
 public | dsmr_backend_backendsettings_pkey                               | index | dsmrreader | dsmr_backend_backendsettings
 public | dsmr_backend_emailsettings_pkey                                 | index | dsmrreader | dsmr_backend_emailsettings
 public | dsmr_backend_scheduledcall_module_path_d8a435fb_like            | index | dsmrreader | dsmr_backend_scheduledcall
 public | dsmr_backend_scheduledcall_module_path_key                      | index | dsmrreader | dsmr_backend_scheduledcall
 public | dsmr_backend_scheduledcall_next_call_349e681c                   | index | dsmrreader | dsmr_backend_scheduledcall
 public | dsmr_backend_scheduledcall_pkey                                 | index | dsmrreader | dsmr_backend_scheduledcall
 public | dsmr_backend_scheduledprocess_module_55cb894b_like              | index | dsmrreader | dsmr_backend_scheduledprocess
 public | dsmr_backend_scheduledprocess_module_key                        | index | dsmrreader | dsmr_backend_scheduledprocess
 public | dsmr_backend_scheduledprocess_pkey                              | index | dsmrreader | dsmr_backend_scheduledprocess
 public | dsmr_backup_backupsettings_pkey                                 | index | dsmrreader | dsmr_backup_backupsettings
 public | dsmr_backup_dropboxsettings_pkey                                | index | dsmrreader | dsmr_backup_dropboxsettings
 public | dsmr_backup_emailbackupsettings_pkey                            | index | dsmrreader | dsmr_backup_emailbackupsettings
 public | dsmr_consumption_consumptionsettings_pkey                       | index | dsmrreader | dsmr_consumption_consumptionsettings
 public | dsmr_consumption_electrici_phase_voltage_l1_72e3c8f8            | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_electrici_phase_voltage_l2_917726c7            | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_electrici_phase_voltage_l3_1a9d7c37            | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_electricityc_currently_delivered_5bf9be2d_uniq | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_electricityco_currently_returned_5f91fed7_uniq | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_electricityconsumption_2241f8ee                | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_electricityconsumption_5714c500                | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_electricityconsumption_e90842a6                | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_electricityconsumption_pkey                    | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_electricityconsumption_read_at_key             | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_energysupplierprice_pkey                       | index | dsmrreader | dsmr_consumption_energysupplierprice
 public | dsmr_consumption_energysupplierprice_start_785e8148_uniq        | index | dsmrreader | dsmr_consumption_energysupplierprice
 public | dsmr_consumption_gasconsumption_pkey                            | index | dsmrreader | dsmr_consumption_gasconsumption
 public | dsmr_consumption_gasconsumption_read_at_key                     | index | dsmrreader | dsmr_consumption_gasconsumption
 public | dsmr_datalogger_dataloggersettings_pkey                         | index | dsmrreader | dsmr_datalogger_dataloggersettings
 public | dsmr_datalogger_dsmrreading_9d090a40                            | index | dsmrreader | dsmr_datalogger_dsmrreading
 public | dsmr_datalogger_dsmrreading_pkey                                | index | dsmrreader | dsmr_datalogger_dsmrreading
 public | dsmr_datalogger_dsmrreading_timestamp_1f7020d1_uniq             | index | dsmrreader | dsmr_datalogger_dsmrreading
 public | dsmr_datalogger_meterstatistics_pkey                            | index | dsmrreader | dsmr_datalogger_meterstatistics
 public | dsmr_datalogger_retentionsettings_pkey                          | index | dsmrreader | dsmr_datalogger_retentionsettings
 public | dsmr_frontend_frontendsettings_pkey                             | index | dsmrreader | dsmr_frontend_frontendsettings
 public | dsmr_frontend_notification_pkey                                 | index | dsmrreader | dsmr_frontend_notification
 public | dsmr_mindergas_mindergassettings_pkey                           | index | dsmrreader | dsmr_mindergas_mindergassettings
 public | dsmr_mqtt_jsondaytotalsmqttsettings_pkey                        | index | dsmrreader | dsmr_mqtt_jsondaytotalsmqttsettings
 public | dsmr_mqtt_jsongasconsumptionmqttsettings_pkey                   | index | dsmrreader | dsmr_mqtt_jsongasconsumptionmqttsettings
 public | dsmr_mqtt_jsontelegrammqttsettings_pkey                         | index | dsmrreader | dsmr_mqtt_jsontelegrammqttsettings
 public | dsmr_mqtt_message_pkey                                          | index | dsmrreader | dsmr_mqtt_message
 public | dsmr_mqtt_mqttbrokersettings_pkey                               | index | dsmrreader | dsmr_mqtt_mqttbrokersettings
 public | dsmr_mqtt_rawtelegrammqttsettings_pkey                          | index | dsmrreader | dsmr_mqtt_rawtelegrammqttsettings
 public | dsmr_mqtt_splittopicdaytotalsmqttsettings_pkey                  | index | dsmrreader | dsmr_mqtt_splittopicdaytotalsmqttsettings
 public | dsmr_mqtt_splittopicgasconsumptionmqttsettings_pkey             | index | dsmrreader | dsmr_mqtt_splittopicgasconsumptionmqttsettings
 public | dsmr_mqtt_splittopicmeterstatisticsmqttsettings_pkey            | index | dsmrreader | dsmr_mqtt_splittopicmeterstatisticsmqttsettings
 public | dsmr_mqtt_splittopictelegrammqttsettings_pkey                   | index | dsmrreader | dsmr_mqtt_splittopictelegrammqttsettings
 public | dsmr_notification_notificationsetting_pkey                      | index | dsmrreader | dsmr_notification_notificationsetting
 public | dsmr_notification_statusnotificationsetting_pkey                | index | dsmrreader | dsmr_notification_statusnotificationsetting
 public | dsmr_pvoutput_pvoutputaddstatussettings_pkey                    | index | dsmrreader | dsmr_pvoutput_pvoutputaddstatussettings
 public | dsmr_pvoutput_pvoutputapisettings_pkey                          | index | dsmrreader | dsmr_pvoutput_pvoutputapisettings
 public | dsmr_stats_daystatistics_day_key                                | index | dsmrreader | dsmr_stats_daystatistics
 public | dsmr_stats_daystatistics_pkey                                   | index | dsmrreader | dsmr_stats_daystatistics
 public | dsmr_stats_electricitystatistics_pkey                           | index | dsmrreader | dsmr_stats_electricitystatistics
 public | dsmr_stats_hourstatistics_hour_start_key                        | index | dsmrreader | dsmr_stats_hourstatistics
 public | dsmr_stats_hourstatistics_pkey                                  | index | dsmrreader | dsmr_stats_hourstatistics
 public | dsmr_stats_note_day_83d05681_uniq                               | index | dsmrreader | dsmr_stats_note
 public | dsmr_stats_note_pkey                                            | index | dsmrreader | dsmr_stats_note
 public | dsmr_weather_temperaturereading_pkey                            | index | dsmrreader | dsmr_weather_temperaturereading
 public | dsmr_weather_temperaturereading_read_at_key                     | index | dsmrreader | dsmr_weather_temperaturereading
 public | dsmr_weather_weathersettings_pkey                               | index | dsmrreader | dsmr_weather_weathersettings
(61 rows)

dennissiemensma commented 4 years ago

En voor detail-info over een tabel (bijvoorbeeld dsmr_datalogger_dsmrreading):

sudo su - postgres
psql dsmrreader

\dS dsmr_datalogger_dsmrreading

dennissiemensma commented 4 years ago

Voorbeeld:

                                                 Table "public.dsmr_datalogger_dsmrreading"
             Column              |           Type           | Collation | Nullable |                         Default                         
---------------------------------+--------------------------+-----------+----------+---------------------------------------------------------
 id                              | integer                  |           | not null | nextval('dsmr_datalogger_dsmrreading_id_seq'::regclass)
 timestamp                       | timestamp with time zone |           | not null | 
 electricity_delivered_1         | numeric(9,3)             |           | not null | 
 electricity_returned_1          | numeric(9,3)             |           | not null | 
 electricity_delivered_2         | numeric(9,3)             |           | not null | 
 electricity_returned_2          | numeric(9,3)             |           | not null | 
 electricity_currently_delivered | numeric(9,3)             |           | not null | 
 electricity_currently_returned  | numeric(9,3)             |           | not null | 
 extra_device_timestamp          | timestamp with time zone |           |          | 
 extra_device_delivered          | numeric(9,3)             |           |          | 
 processed                       | boolean                  |           | not null | 
 phase_currently_delivered_l1    | numeric(9,3)             |           |          | 
 phase_currently_delivered_l2    | numeric(9,3)             |           |          | 
 phase_currently_delivered_l3    | numeric(9,3)             |           |          | 
 phase_currently_returned_l1     | numeric(9,3)             |           |          | 
 phase_currently_returned_l2     | numeric(9,3)             |           |          | 
 phase_currently_returned_l3     | numeric(9,3)             |           |          | 
 phase_voltage_l1                | numeric(4,1)             |           |          | 
 phase_voltage_l2                | numeric(4,1)             |           |          | 
 phase_voltage_l3                | numeric(4,1)             |           |          | 
Indexes:
    "dsmr_datalogger_dsmrreading_pkey" PRIMARY KEY, btree (id)
    "dsmr_datalogger_dsmrreading_9d090a40" btree (processed)
    "dsmr_datalogger_dsmrreading_timestamp_1f7020d1_uniq" btree ("timestamp")

svdo commented 4 years ago

Bovendien is er nog een probleem: de status pagina doet het nog steeds niet... (geeft timeout)

svdo commented 4 years ago

Dank, ik ga het controleren! Ik zie dat 'ie nu bij mij om de halve seconde slaapt... Die DSMRREADER_DATALOGGER_SLEEP moet in settings.py?

dennissiemensma commented 4 years ago

Ja, ik had even mogen vermelden dat de instructies bovenaan eerdergenoemde pagina staan: https://dsmr-reader.readthedocs.io/en/latest/settings.html#dsmrreader-datalogger-sleep

dennissiemensma commented 4 years ago

Voor de status-pagina kun je het beste even kijken of er een foutmelding staat in de logfile van de webinterface.

/var/log/supervisor/dsmr_webinterface.log

svdo commented 4 years ago

Helaas niet in die log:

[2019-10-30 14:14:53 +0100] [10304] [INFO] Booting worker with pid: 10304
[2019-10-30 14:16:16 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:10304)
[2019-10-30 14:16:17 +0100] [10440] [INFO] Booting worker with pid: 10440
[2019-10-30 14:22:50 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:10440)
[2019-10-30 14:22:51 +0100] [11019] [INFO] Booting worker with pid: 11019
[2019-10-30 14:24:56 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:11019)
[2019-10-30 14:24:58 +0100] [11186] [INFO] Booting worker with pid: 11186
[2019-10-30 21:53:19 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:11186)
[2019-10-30 21:53:21 +0100] [1123] [INFO] Booting worker with pid: 1123
[2019-10-30 21:55:06 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:1123)
[2019-10-30 21:55:07 +0100] [1359] [INFO] Booting worker with pid: 1359
[2019-10-31 20:08:10 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:1359)
[2019-10-31 20:08:12 +0100] [1815] [INFO] Booting worker with pid: 1815

dennissiemensma commented 4 years ago

Ik vermoed trouwens dat je meer indexes mist dan. De status-pagina vraagt aan de database hoeveel dsmrreadings er zijn met processed=False. Als daar geen index op staat, is die taak onmogelijk (met jouw hoeveelheid data) binnen de timeout.

Kijk even of de middelste index aanwezig is, uit mijn eerdere voorbeeld hierboven:

Indexes:
    "dsmr_datalogger_dsmrreading_pkey" PRIMARY KEY, btree (id)
    "dsmr_datalogger_dsmrreading_9d090a40" btree (processed)
    "dsmr_datalogger_dsmrreading_timestamp_1f7020d1_uniq" btree ("timestamp")

svdo commented 4 years ago

Indexen:

 Schema |                         Name                         | Type  |   Owner    |                     Table
--------+------------------------------------------------------+-------+------------+------------------------------------------------
 public | dsmr_backend_backendsettings_pkey                    | index | dsmrreader | dsmr_backend_backendsettings
 public | dsmr_backend_emailsettings_pkey                      | index | dsmrreader | dsmr_backend_emailsettings
 public | dsmr_backend_scheduledprocess_module_55cb894b_like   | index | dsmrreader | dsmr_backend_scheduledprocess
 public | dsmr_backend_scheduledprocess_module_key             | index | dsmrreader | dsmr_backend_scheduledprocess
 public | dsmr_backend_scheduledprocess_pkey                   | index | dsmrreader | dsmr_backend_scheduledprocess
 public | dsmr_backup_emailbackupsettings_pkey                 | index | dsmrreader | dsmr_backup_emailbackupsettings
 public | dsmr_consumption_electrici_phase_voltage_l1_72e3c8f8 | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_electrici_phase_voltage_l2_917726c7 | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_consumption_electrici_phase_voltage_l3_1a9d7c37 | index | dsmrreader | dsmr_consumption_electricityconsumption
 public | dsmr_datalogger_dsmrreading_pkey                     | index | dsmrreader | dsmr_datalogger_dsmrreading
 public | dsmr_datalogger_dsmrreading_timestamp_idx            | index | dsmrreader | dsmr_datalogger_dsmrreading
 public | dsmr_mqtt_jsongasconsumptionmqttsettings_pkey        | index | dsmrreader | dsmr_mqtt_jsongasconsumptionmqttsettings
 public | dsmr_mqtt_splittopicgasconsumptionmqttsettings_pkey  | index | dsmrreader | dsmr_mqtt_splittopicgasconsumptionmqttsettings
(13 rows)

Da's nie goe...

svdo commented 4 years ago

Is er ergens iets van een script om de database te "fixen"?

dennissiemensma commented 4 years ago

Ik denk dat er iets mis is gegaan met de backups dan.

Wat je kunt proberen is twee backups maken:

Eentje van alles, voor het geval onderstaande niet goed gaat.
Eentje met alleen alle data van alle metingen. Je importeert die dan in een schone DSMR-reader database waar geen data in staat.

svdo commented 4 years ago

Klinkt als een goed plan. Is die éne tabel, dsmr_datalogger_dsmrreading, voldoende voor de variant "alleen alle data van alle metingen"?

dennissiemensma commented 4 years ago

Ja in principe wel, want de enige data die binnenkomt, komt direct in je dsmr_datalogger_dsmrreading-tabel en vanuit daar komt consumption en later dag/uur-statistieken.

sudo su - postgres

Volledige dump:

pg_dump -d dsmrreader | gzip --fast > dsmr-reader-full.sql.gz

Data-only:

pg_dump -d dsmrreader --data-only -t dsmr_datalogger_dsmrreading | gzip --fast > dsmr_datalogger_dsmrreading-data.sql.gz

dennissiemensma commented 4 years ago

Check even of je qua disk space het redt trouwens. En of de backups inhoudelijk ook data hebben.

svdo commented 4 years ago

Cool ik ga het doen Dennis. Zal niet meer vandaag worden, maar ik zal nog laten weten wat het resultaat is. Bedankt voor het meedenken en je hulp!

dennissiemensma commented 4 years ago

Als je dit hebt gedaan en zeker weet dat de oude DB weg kan:

sudo supervisorctl stop all

sudo su - postgres

# !!! weg = weg!
dropdb dsmrreader
createdb -O dsmrreader dsmrreader

logout
sudo su - dsmr

# DB schema via migraties
./manage.py migrate

logout
sudo su - postgres

# Data inlezen
zcat dsmr_datalogger_dsmrreading-data.sql.gz | psql -d dsmrreader

logout
sudo supervisorctl start all

Uit mn hoofd dan, maar ik heb het idee dat je technisch genoeg bent om je ermee te redden.

svdo commented 4 years ago

Yep komt goed, dank je!

svdo commented 4 years ago

Hoi @dennissiemensma, ik heb de data-only restore gedaan en dat lijkt grotendeels te werken. Nu is het probleem alleen dat de statistieken van de oude data niet meer worden opgebouwd. Het lijkt wel of 'ie niet verder terug in de tijd kijkt dan het moment dat ik 'm heb geïnstalleerd:

dsmrreader=> select id,hour_start from dsmr_stats_hourstatistics;
 id |       hour_start
----+------------------------
  1 | 2019-11-01 06:00:00+01
  2 | 2019-11-01 07:00:00+01
  3 | 2019-11-01 08:00:00+01
  4 | 2019-11-01 09:00:00+01
  5 | 2019-11-01 10:00:00+01
  6 | 2019-11-01 11:00:00+01
  7 | 2019-11-01 12:00:00+01
  8 | 2019-11-01 13:00:00+01
  9 | 2019-11-01 14:00:00+01
 10 | 2019-11-01 15:00:00+01
 11 | 2019-11-01 16:00:00+01
 12 | 2019-11-01 17:00:00+01
 13 | 2019-11-01 18:00:00+01
 14 | 2019-11-01 19:00:00+01
 15 | 2019-11-01 20:00:00+01
 16 | 2019-11-01 21:00:00+01
 17 | 2019-11-01 22:00:00+01
 18 | 2019-11-01 23:00:00+01
 19 | 2019-11-02 00:00:00+01
(19 rows)

Kan dat kloppen? Is er ergens een instelling / timestamp waar 'ie naar kijkt die ik nog goed moet zetten? Dank je!

dennissiemensma commented 4 years ago

Je kunt de applicatie even stoppen, alle statistieken weggooien, alle consumptie weggooien en dan alle telegrammen op onverwerkt zetten. Hij zou dan alles van dag 0 opnieuw moeten berekenen.

Doe dit uiteraard alleen als je een extra backup hebt, gezien ik niet weet in welke staat de dataset exact is en je anders verder van huis bent.

sudo supervisorctl stop dsmr_backend

sudo su - postgres
psql dsmrreader

truncate dsmr_stats_daystatistics;
truncate dsmr_stats_hourstatistics;
truncate dsmr_consumption_electricityconsumption;
truncate dsmr_consumption_gasconsumption;
update dsmr_datalogger_dsmrreading set processed = false where processed = true;

CTRL+D
logout

sudo supervisorctl start dsmr_backend

Als het goed is is nu alles leeg en probeert die op de achtergrond allees opnieuw te berekenen.

Je kunt af en toe even in de DB kijken of het aantal onverwerkte telegrammen terugloopt:

select count(id) from dsmr_datalogger_dsmrreading where processed = false;

svdo commented 4 years ago

Ah ja processed kolom klinkt logisch. Ga 't proberen! 👍

svdo commented 4 years ago

@dennissiemensma Vandaag zag ik dat eindelijk alles weer opnieuw "processed" was. Ik merkte alleen dat de index op processed op dsmr_datalogger_dsmrreading heel traag was. Uiteindelijk reindex database dsmrreader gedaan. Dat helpt voor de processed index, maar de statuspagina is nog steeds zo traag dat 'ie een timeout geeft. Nog enig idee waar ik naar kan kijken? De rest van de applicatie lijkt nu wel goed te werken.

Ik vind het wel nog gek dat select count(id) from dsmr_datalogger_dsmrreading erg lang duurt ondanks de primary key index trouwens.

dsmrreader=> explain select count(id) from dsmr_datalogger_dsmrreading;
                                                                          QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize Aggregate  (cost=318284.18..318284.19 rows=1 width=8)
   ->  Gather  (cost=318283.97..318284.18 rows=2 width=8)
         Workers Planned: 2
         ->  Partial Aggregate  (cost=317283.97..317283.98 rows=1 width=8)
               ->  Parallel Index Only Scan using dsmr_datalogger_dsmrreading_pkey on dsmr_datalogger_dsmrreading  (cost=0.43..304400.48 rows=5153395 width=4)
(5 rows)

dennissiemensma commented 4 years ago

Ik kan me herinneren dat PostgreSQL sowieso traag is met counts op datasets zonder where condition: https://wiki.postgresql.org/wiki/Slow_Counting

Wellicht moet ik eens kijken of ik er een conditionele count van kan maken. Je kunt eens proberen of het groot verschil maakt door een count te doen met processed = true.

svdo commented 4 years ago

Ja die pagina had ik inderdaad ook gevonden. Ik heb even wat experimentjes gedaan:

dsmrreader=> select count(*) from dsmr_datalogger_dsmrreading;
  count
----------
 12407415
(1 row)

Time: 29287.462 ms (00:29.287)
dsmrreader=> select count(*) from dsmr_datalogger_dsmrreading where processed=true;;
  count
----------
 12407425
(1 row)

Time: 24510.569 ms (00:24.511)
Time: 0.538 ms
dsmrreader=> select count(id) from dsmr_datalogger_dsmrreading;
  count
----------
 12407556
(1 row)

Time: 34030.089 ms (00:34.030)
dsmrreader=> select count(processed) from dsmr_datalogger_dsmrreading;
  count
----------
 12407604
(1 row)

Time: 13135.208 ms (00:13.135)
dsmrreader=> create index dsmr_datalogger_dsmrreading_id on dsmr_datalogger_dsmrreading(id);
CREATE INDEX
Time: 206516.333 ms (03:26.516)
dsmrreader=> select count(id) from dsmr_datalogger_dsmrreading;
  count
----------
 12407645
(1 row)

Time: 38060.619 ms (00:38.061)
dsmrreader=> select count(*) from dsmr_datalogger_dsmrreading;
  count
----------
 12407668
(1 row)

Time: 14342.425 ms (00:14.342)

Maar dit is natuurlijk wel testen van de koude grond, zonder rekening te houden met caching en dat soort dingen. Een where clause lijkt trouwens in dit geval niet veel effect te hebben:

dsmrreader=> select count(processed) from dsmr_datalogger_dsmrreading;
  count
----------
 12407744
(1 row)

Time: 21168.233 ms (00:21.168)
dsmrreader=> select count(processed) from dsmr_datalogger_dsmrreading;
  count
----------
 12407757
(1 row)

Time: 30329.372 ms (00:30.329)
dsmrreader=> select count(processed) from dsmr_datalogger_dsmrreading where processed=true;
  count
----------
 12407772
(1 row)

Time: 31235.176 ms (00:31.235)

Raar dat die tweede 10 seconden langer duurt dan de eerste...

Misschien is het gebruik van schattingen een optie?

dsmrreader=> select count(*) from dsmr_datalogger_dsmrreading;
  count
----------
 12407988
(1 row)

Time: 24374.681 ms (00:24.375)
dsmrreader=> SELECT reltuples::BIGINT AS approximate_row_count FROM pg_class WHERE relname = 'dsmr_datalogger_dsmrreading';
 approximate_row_count
-----------------------
              12407963
(1 row)

Time: 21.774 ms

(https://wiki.postgresql.org/wiki/Count_estimate)

dennissiemensma commented 4 years ago

Bedankt voor je onderzoek. Opzich zou dat kunnen, al gebruik ik liever het ORM van Django ipv hardcoded queries te doen.

Wellicht dat ik dan beter de count helemaal weg kan halen en de status bepalen op basis van tijdsinterval sinds laatste verwerking oid.

pa1pdr commented 4 years ago

Hi Dennis/Stefan,

ik heb exact hetzelfde probleem (logger gebruikt dezelfde id's na terugzetten DB, dus foutmelding 'dsmr_datalogger.models.reading.DsmrReading.MultipleObjectsReturned: get() returned more than one DsmrReading -- it returned 2!').

Mijn SD kaartje was corrupt, dus nieuwe installatie, database teruggezet volgens instructies en nu wodt er dus niet meer gelogd. Wat zijn de stappen naar een werkende DSMR met behoud van data?

pa1pdr commented 4 years ago

OK, ik heb de 'data-only' restore gedaan en alle telegrammen worden weer geprocessed. Niet alle settings uit de backup zijn overgekomen (i.i.g niet de MQTT & Weer instellingen)

dennissiemensma commented 4 years ago

Werkt het inmiddels weer?

pa1pdr commented 4 years ago

Ik denk het: ik heb alleen nog geen daily stats, die komen vannacht nog hoop ik. Overigens gaat het denk ik fout als de telegrammen (ik had er 650.000) verwerkt worden tijdens de nachtelijke daily stats run. Ik had in elk geval maar een handvol daily stats. Ik heb daarom nog maar eens het hele proces herhaald. Alle telegrammen zijn verwerkt, alleen de statistieken zijn allemaal nog weg. Die hoop ik vannacht terug te krijgen...

Mijn vertrouwen in de data backup/restore is enorm gedaald: het merendeel van de instellingen is niet teruggezet, alle notes zijn verdwenen. 't is op dit moment zeker niet zo simpel als gedocumenteerd.

svdo commented 4 years ago

@pa1pdr Dat van die onvolledige backup had ik ook, maar eerlijk is eerlijk, dat komt natuurlijk ook door de corrupte SD kaart. Je kan wel je vraagtekens zetten bij het nut van roterende "laatste 7 dagen" backups. @dennissiemensma Misschien een lichtere variant van zoiets maken? https://serverfault.com/a/575169

Verder @pa1pdr ter info: het herstellen van alle statistieken duurde bij mij twee weken, dus wees gewaarschuwd 😉

pa1pdr commented 4 years ago

Ik had verwacht dat de backups volledig zouden zijn, anders had ik wel een bacula backup teruggezet. Die zijn nu eenmaal wat ouder (1 week) dan de dagelijkse die DSMR maakt. Dank voor de statistiek tip, anders had ik het al vrij snel opgegeven: ik ben niet zo'n geduldig tiep 😉

dennissiemensma commented 4 years ago

@pa1pdr bedankt voor je terugkoppeling. Ik heb in dat geval wel iets meer informatie nodig van wat er precies speelt. Als je een oncorrupte, volledige backup hebt, staat daar alles in wat nodig is en dan zou het terugzetten zeker net zo makkelijk moeten zijn als in de documentatie. Het is daarnaast belangrijk dat je in ieder geval DSMR-reader niet initialiseert (migraties draait) of start totdat je de backup hebt teruggezet, want anders krijg je sowieso dubbele records en fouten. Wellicht kun je in die hoek nog wat zoeken.

dennissiemensma commented 4 years ago

@svdo Het omzeilen van corrupte data is een vrij complexe taak geworden en dus waag ik mij er niet meer aan.

Ik denk dat het uiteindelijk een kwestie gaat zijn van voorlichting naar gebruikers toe dat ze er zelf voor moeten zorgen dat de backup's ergens veilig staan. Daarbij is het uiteraard mijn verantwoordelijkheid om genoeg opties uit te werken of te wijzen op alternatieven.

svdo commented 4 years ago

Ja dat is inderdaad een moeras. Het was alleen wel zo dat ik nu ook op het verkeerde been was gezet, ik had een beetje zo'n gevoel van "hij doet backups dus het zal wel goed zijn". Ik had ook al eerder gezien dat dat alleen de laatste paar dagen is, dus ik reken je wat dat betreft helemaal niks aan hoor :) Maar het is inderdaad wellicht wel slim om daar in de interface en documentatie wat explicieter over te zijn. Ik zou zelfs overwegen om het standaard UIT te zetten en in de interface een waarschuwing te tonen: "let op: backups zijn nog niet geconfigureerd". Het probleem is namelijk ook een beetje dat de backups zelf ook weer bijdragen aan extra snelle slijtage van de SD kaart (hoewel ik geen idee heb hoeveel). Geen kritiek hè, ik probeer alleen mee te denken! 😉

pa1pdr commented 4 years ago

@svdo Hetzelfde hier: ik dacht, ik heb tenminste 5 dagen backups van DSMR + wekelijks van bacula, dus dat moet goed gaan. Het terugzetten van een volledige DSMR backup (na supervisor stop all) leverde de MultipleObjects fout op (na starten datalogger). Dus ik denk dat er iets mis is gegaan met de waarde van dsmr_datalogger_dsmrreading_id_seq....

De verdere instructie om 'pg_dump -d dsmrreader --data-only -t dsmr_datalogger_dsmrreading' in te lezen levert natuurlijk alleen een lege database met readings op, dus zo gek is het achteraf niet dat alle andere tabellen leeg zijn: works as designed.

pa1pdr commented 4 years ago

@dennissiemensma : je hebt instructies hoe je postgres naar een andere directory // mounted disk kunt laten schrijven, dit om wear leveling op de SD kaartjes tegen te gaan. Is het ook mogelijk dat DSMR met een postgres op een andere server (ipv locaal) communiceert? Scheelt een hoop writes schat ik...

dennissiemensma commented 4 years ago

@pa1pdr je bent daar zelf helemaal vrij in.

Je kunt de applicatie op een andere server zetten en alleen een datalogger op je Pi.
Je kunt de applicatie en database in docker containers draaien.
Je kunt zowel de applicatie als database totaal ergens anders hosten.

Bij het initialiseren van DSMR-reader heb je ergens een dsmrreader/settings.py aangemaakt. De waarden daarin kun je rustig aanpassen qua database. Houd er wel rekening mee dat doorgaans database en applicatie op dezelfde machine staan, maar dat is dus geen vereiste hier.

pa1pdr commented 4 years ago

Duidelijk, dank!

dsmrreader / dsmr-reader

Foutmelding na herinstallatie + restore #762

Wat gebruik je?

Bij fouten