Also…an alle anderen… Das Teil läuft super. Und hat die Probleme der DB wohl erst sichtbar werden lassen.
In meinem konkreten Fall muss wohl irgendetwas quer gehangen haben und ich habe jetzt eine komplett neue DB angelegt…
Sprich - Dienst gestoppt - DB gelöscht - und Dienst gestartet…was automatisch zu einer neuen Logging DB führt.
Sicherlich gab es in der Vergangenheit Situationen wo mal die DB hart geschlossen wurde. Nur ging es danach immer wieder ohne Probleme weiter.
auch das passt ins Bild: solange die bereits geloggten Daten nur gelesen werden (und nur das passiert im Regelbetrieb), fällt es nicht auf.
Ich hätte allerdings riesen Bauschmerzen, die alten Daten weg zu werfen ;). Vielleicht hast Du ja Muße, ein Backup raus zu holen und reparieren zu lassen. Würde mich mal interessieren, was dabei raus kommt.
Ich war auch mal einer der 10%. Auch hier merkte ich im Normalbetrieb nicht, dass die DB schon länger korrupt war. Erst durch das Tool von Rakete wurde das Problem deutlich.
Schweren Herzens entschied ich mich für Löschung und Neuaufbau.
Seit dieser Erfahrung habe ich die gleiche Auffassung über das Thema wie Bernhard. Ich schau mir die Daten doch maximal noch wenige Wochen rückwirkend an.
Ich hatte das selbe, oder zumindest ein ähnliches Problem:
leider null Reaktion…
Die Lösung ist ganz einfach, man muss nur den ganzen Dreck der in der Datenbank steht löschen
eine Reparatur, wie in der FAQ hilft nicht, meine Datenbank hatte 0 Fehler, war aber trotzdem
vom 900MB auf 8GB angeschwollen.
Geholfen hat dann das tool:
damit konnte ich die 8 GB Datenbank öffnen, in Handarbeit den ganzen Müll löschen
gelassen habe ich nur die eigentlichen Daten , danach mit dem Script
" Automatische Reaggregation aller geloggten Variablen" durchlaufen lassen, dauerte dann leider über eine Woche.
und die Datenbank hatte wieder die normale grösse, und alle Daten waren vorhanden.
Sie lauft seit dem Problemlos.
wenn eine genauere Beschreibung zum löschen gebraucht wird, mache ich ein paar Screenshots.
Die alte 8GB Datenbank habe ich noch aufgehoben.
Aber dafür ist man selbst verantwortlich.
Man muss sich schon entscheiden, welche Daten es wert sind zu loggen um sie auswerten zu wollen.
Überall das „Häkchen“ zu setzen macht keinen Sinn.
ne , so ist das durchaus nicht, ich schrieb , das alle Daten nach wie vor da sind.
ich habe also die eigentlichen Daten nicht gelöscht.
die Datenbank hatte einen Fehler, und ist innerhalb von Stunden auf ein vielfaches angewachsen.
innerhalb eines tages von 3,7Gb auf 7,8Gb einfach mal meinen Post vom 3.2.2013 lesen.
wenn du das tool mal benutzt, und deine Datenbank damit öffnest, wirst du unter ips_float Daten finden.
und unter ips_float_day auch welche , natürlich wesentlich weniger Einträge.
bei mir war das aber andersherum.
10mio. Einträge unter ips_float und 27mio. unter ips_float_hour
stellt sich die frage wie 27mio Einträge da reinkommen.
bei meiner heilen Datenbank ist das anders , inzwischen 13mio. unter ips_float und 1,4mio. unter ips_float_hour.
Jeder der das selbe Problem hat, braucht nur alle werte zu löschen, nur die werte unter ips_float ips_boolean/integer müssen stehen bleiben, alles unter day/hour/month/week/year muss man löschen.
dann Datenbank komprimieren und mit ips den besagten scipt durchlaufen lassen.
so bleiben alle Daten erhalten und es lauft seit dem prima.
achja , ich finde toll einfach zu sehen wie viel die Heizung die letzten Jahre gebraucht hat, wenn ich die Datenbank neu gemacht hätte
würde das nicht gehen.
Was ich wirklich vermisse , ist das man die älteren Daten nachträglich ausdünnen kann.
hehe, wie ich am 2.3.13 das letzte mal versucht habe darüber was zu finden, gab es dein Programm noch nicht.
werde ich morgen mal versuchen, jetzt muss ich erst zur arbeit
Nach einem Stromausfall kam mein IPS nicht mehr richtig ins Laufen. Der Dienst startete nicht mehr vollständig durch. Die Hauptfunktionen von IPS liefen, das Fenster (IPS wird gestartet) verschwand aber nicht. Auch mit der Console kam ich auf IPS. Dort war aber zu sehen das keiner der Webserver gestartet war.
Nach etlichen Versuchen mit gesicherten Settings wusste ich nicht mehr weiter und spielte Stück für Stück Backups der kompletten IPS-Sicherungen ein, außer…
… natürlich der logging.db, man will ja keine Daten verlieren.
Als ich schon paresy anpingte ging ich nochmals alle Verzeichnisse durch und siehe da, die DB hatte sich um Faktor 3 vergrößert. Nichts leichter als das dachte ich und spielte ein Backup ein das ca. 12 Stunden alt war.
Juhuuuuu. IPS lief wieder.
Am nächsten Tag betrachtete ich routinemäßig meine Highcharts-Graphen. Die aktuellen Werte aller FLOAT-Variablen waren nicht mehr konsistent.
Also ging die Fehlersuche weiter.
[ul]
[li]Integritätscheck der aktuellen DB. Fehler drin.
[/li][li]Integritätscheck der DB vor dem Absturz. Fehler drin.
[/li][li]Integritätscheck 1 Monat zurück. Wie sollte es auch anderes sein. Fehler drin.
[/li][/ul]
Letztendlich half nur ein DUMP der Datenbank nach Anleitung von IPS.
Ich denke wir sollten langsam wieder die Diskussion beginnen wie es mit der DB weiter geht. Es kann nicht angehen immer wieder einen manuellen Integritätscheck machen zu müssen um Daten, egal wie lange und wie viele, nicht zu verlieren.
Hallo
Hast du die defekte Datenbank noch ? mich würde mal interessieren, ob es genau das selbe Problem ist wie bei mir.
Teste doch mal ob eine Reparatur nach meiner Anleitung auch bei dir zum Erfolg führt.
Ich sag nur RRD…
Und alle diese Probleme mit GByte großen Monstern würds nicht geben.
Stunden/Tages/Wochen/sonstwas Mittelwerte gäbs automatisch, reorganisation und das - ach so böse- löschen von unnütze Einzeldaten auch. Alles on the fly.
Leider hat mich damals niemand von euch unterstützt als der native RRD Support von IPS eingestellt wurde.
von RRD war ich gefühlt auch nie begeistert und hatte seinerzeit auch einige Probleme damit.
Das Konzept für eine neue Datenbasis hat paresy bereits im Betaforum vorgestellt und diesen Ansatz finde ich wirklich praktikabel da für jeden einfach zu verstehen, leichte Backupstrategie und vor allen Dingen, sollte einmal ein Fehler eingeschlichen haben, für jeden korrigierbar.
