Foutmelding na herinstallatie + restore #762
Comments
|
Ik weet inmiddels wat het probleem is, alleen nog niet hoe ik het op moet lossen. De Bijvoorbeeld deze query geeft twee resultaten: |
|
Ik heb besloten om de tabel te repareren door zelf de id's te veranderen zodat ze weer uniek oplopend zijn. Heb ok de |
|
Bedankt voor je melding. Begrijp ik het goed dat je het inmiddels zelf hebt kunnen oplossen? |
|
Geen idee eigenlijk. De foutmelding
|
|
Het valt me trouwens ook op dat de laatste |
|
Je kunt het beste even in de logs kijken van |
|
Ik heb in Dat lijkt raar, de datum is nu 30 oktober, maar hij verwerkt één telegram van 27 oktober. Als ik 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... |
|
Overigens zitten er nu meer dan 11.6 miljoen rijen in in mijn |
|
Update: Ik heb twee indexen aangemaakt: 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. |
|
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 ( 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. |
|
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... |
|
Je kunt de indexes opvragen met: |
|
Ter referentie, dit is mijn omgeving: |
|
En voor detail-info over een tabel (bijvoorbeeld |
|
Voorbeeld: |
|
Bovendien is er nog een probleem: de status pagina doet het nog steeds niet... (geeft timeout) |
|
Dank, ik ga het controleren! Ik zie dat 'ie nu bij mij om de halve seconde slaapt... Die |
|
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 |
|
Voor de status-pagina kun je het beste even kijken of er een foutmelding staat in de logfile van de webinterface.
|
|
Helaas niet in die log: |
|
Ik vermoed trouwens dat je meer indexes mist dan. De status-pagina vraagt aan de database hoeveel dsmrreadings er zijn met Kijk even of de middelste index aanwezig is, uit mijn eerdere voorbeeld hierboven: |
|
Indexen: Da's nie goe... |
|
Is er ergens iets van een script om de database te "fixen"? |
|
Ik denk dat er iets mis is gegaan met de backups dan. Wat je kunt proberen is twee backups maken:
|
|
Klinkt als een goed plan. Is die éne tabel, |
|
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. Volledige dump:
Data-only:
|
|
Check even of je qua disk space het redt trouwens. En of de backups inhoudelijk ook data hebben. |
|
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! |
|
Yep komt goed, dank je! |
|
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: Kan dat kloppen? Is er ergens een instelling / timestamp waar 'ie naar kijkt die ik nog goed moet zetten? Dank je! |
|
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. 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: |
|
Ah ja |
|
@dennissiemensma Vandaag zag ik dat eindelijk alles weer opnieuw "processed" was. Ik merkte alleen dat de index op Ik vind het wel nog gek dat |
|
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 |
|
Ja die pagina had ik inderdaad ook gevonden. Ik heb even wat experimentjes gedaan: Maar dit is natuurlijk wel testen van de koude grond, zonder rekening te houden met caching en dat soort dingen. Een Raar dat die tweede 10 seconden langer duurt dan de eerste... Misschien is het gebruik van schattingen een optie? |
|
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. |
|
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? |
|
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) |
|
Werkt het inmiddels weer? |
|
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. 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. |
|
@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 😉 |
|
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 😉 |
|
@pa1pdr bedankt voor je terugkoppeling. Ik heb in dat geval wel iets meer informatie nodig van wat er precies speelt. |
|
@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. |
|
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! 😉 |
|
@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. |
|
@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? |
|
@pa1pdr je bent daar zelf helemaal vrij in.
Bij het initialiseren van DSMR-reader heb je ergens een |
|
Duidelijk, dank! |
De statistieken zijn niet terug: er is niet meer teruggezet dan de eerste (Feb 2019 en 1 dag in Maart) en die van de laatste metingen. Heb je tips hoe ik de tussenliggende statistieken terug kan halen? |
|
Klinkt als |
|
Dat heb ik in den beginne al 2 keer gedaan met exact hetzelfde resultaat, dus ergens stopt het statistiek proces, terwiil alle telegrammen wel zijn verwerkt. |
|
> Verder @pa1pdr ter info: het herstellen van alle statistieken duurde bij mij twee weken, dus wees gewaarschuwd 😉
Daarom heb ik ook maar even gewacht na het re-processen van de telegrammen, maar meer dan Feb en 2 dagen van Maart heb ik niet gekregen, ook niet na 2 weken.. |
|
@pa1pdr je kunt eens kijken hoeveel unieke dagen je uberhaupt nog in je data hebt: |
|
dag
------------------------
2019-12-03 00:00:00+00
2019-12-02 00:00:00+00
2019-12-01 00:00:00+00
2019-11-30 00:00:00+00
2019-11-29 00:00:00+00
2019-11-28 00:00:00+00
2019-11-27 00:00:00+00
2019-11-26 00:00:00+00
2019-11-25 00:00:00+00
2019-11-24 00:00:00+00
2019-11-23 00:00:00+00
2019-11-22 00:00:00+00
2019-11-21 00:00:00+00
2019-11-20 00:00:00+00
2019-11-19 00:00:00+00
2019-11-18 00:00:00+00
2019-11-17 00:00:00+00
2019-08-12 00:00:00+01
2019-04-06 00:00:00+01
2019-03-28 00:00:00+00
2019-03-22 00:00:00+00
2019-03-16 00:00:00+00
2019-03-11 00:00:00+00
2019-03-08 00:00:00+00
2019-03-04 00:00:00+00
2019-03-02 00:00:00+00
2019-02-28 00:00:00+00
2019-02-27 00:00:00+00
2019-02-26 00:00:00+00
2019-02-25 00:00:00+00
2019-02-24 00:00:00+00
2019-02-23 00:00:00+00
2019-02-22 00:00:00+00
2019-02-21 00:00:00+00
2019-02-20 00:00:00+00
(35 rows)
en
dag
------------------------
2019-12-03 00:00:00+00
2019-12-02 00:00:00+00
2019-12-01 00:00:00+00
2019-11-30 00:00:00+00
2019-11-29 00:00:00+00
2019-11-28 00:00:00+00
2019-11-27 00:00:00+00
2019-11-26 00:00:00+00
2019-11-25 00:00:00+00
2019-11-24 00:00:00+00
2019-11-23 00:00:00+00
2019-11-22 00:00:00+00
2019-11-21 00:00:00+00
2019-11-20 00:00:00+00
2019-11-19 00:00:00+00
2019-11-18 00:00:00+00
2019-11-17 00:00:00+00
2019-08-12 00:00:00+01
2019-04-06 00:00:00+01
2019-03-28 00:00:00+00
2019-03-22 00:00:00+00
2019-03-16 00:00:00+00
2019-03-11 00:00:00+00
2019-03-08 00:00:00+00
2019-03-04 00:00:00+00
2019-03-02 00:00:00+00
2019-02-28 00:00:00+00
2019-02-27 00:00:00+00
2019-02-26 00:00:00+00
2019-02-25 00:00:00+00
2019-02-24 00:00:00+00
2019-02-23 00:00:00+00
2019-02-22 00:00:00+00
2019-02-21 00:00:00+00
2019-02-20 00:00:00+00
(35 rows)
… On 3 Dec 2019, at 22:13, Dennis Siemensma ***@***.***> wrote:
select date_trunc('day', timestamp) as dag from dsmr_datalogger_dsmrreading group by dag order by dag desc;
|
|
Het lijkt er op dat er niet meer dagen in je database staan en dus komen die statistieken er ook niet. Je zou nog kunnen spitten in je initiele database-backup, door die terug te zetten op een aparte database. En dan daar bovenstaande query in uitvoeren om te kijken of er meer in staat. Als het dezelfde bron is als voor je eerdere |
Hallo! Enorm bedankt voor dsmrreader, ik ben er heel erg blij mee!!! Ik heb een probleempje:
Wat gebruik je?
v2.9RaspberryPi 3b+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:
/var/log/supervisor/dsmr_datalogger-stderr---supervisor-rkb79j.log. Is dit iets om me zorgen over te maken, kan ik het oplossen?The text was updated successfully, but these errors were encountered: