Datenverlust bei Zeos & MySQL?

[MmVisual]

Hallo,

Ich habe ein Problem mit Datenverlust bei MySQL.

Wie kann es passieren, dass wenn man Daten eingibt, die gespeichert werden und dann am nächsten Tag doch nicht mehr da sind?
Ich dachte, bei Post wird der Datensatz geschrieben?

Bei TZDBConnection ist TransactIsolationLevel = tiNone gesetzt, also Standard. Ansonsten habe ich keine Einstellmöglichkeiten gefunden.

Eine extra Transaction habe ich nicht gestartet, und das wird somit automatisch von Zeos verwaltet, bzw. direkt geschrieben.

Verwendet wird die Zeos Komponente und MySQL.

Vielen Dank für eure Hilfe und Abregungen, was ich da wohl falsch haben könnte.

Grüße Markus.

PS: Der Fehler tritt sehr selten auf, aber kann vorkommen. Ich habe leider keine Ahnung bei welcher Konstellation das auftritt und auch nicht wie ich diesen Fehler / das Fehlverhalten feststellen / aufzeichnen kann.

[hde]

@MmVisual
Mit Zeos hab ich bisher nur Erfahrungen aus meinen Tests, also keine wirklichen.
Bei SQLdb (und auch andere Sprachen/Komponenten brauchen zusätzlich "ApplyUpdates" o-ä.
Manchmal werden Posts auch gecached
Bei meinen laufenden Projektenarbeite ich grundsätzlich mit Transaction und Commit.
Hast du bei Zeos Autocommit eingestellt?
hde

[MmVisual]

Ja, AutoCommit ist TRUE.

Ich arbeite auch mit mehreren Rechner, wenn auf dem einen was geändert wird, dann brauche ich bei dem anderen nur ein Refresh ausführen und die geänderten Daten sind sichtbar.
Also in der Regel werden die Daten in die DB und sofort für alle sichtbar geschrieben.
Wieso das hin und wieder nicht klappt kann ich nicht sagen. Ist aber zum Glück nur sehr selten, aber kommt leider vor. (1x im Monat oder so um mal einen Zeithorizont zu nennen.)

[hde]

Auch das wäre mir viel zu oft.
Datenverlust einer SQL-DB ist tötlich und darf niemals vorkommen.
D.h. ich werde noch vorsichtiger und gründlicher testen.
kannst du kein Monitoring oder Logging einschalten?
Ich denke, so einen Fehler muss man finden .. oder Komponente oder DB wechseln.
hde

[MmVisual]

Ich habe eine Log-Funktion in der meine eigenen SQL Befehle geloggt werden, darin sieht man nichts.
Das nächste Problem ist, man weiß nur noch, dass man doch mal irgend ein Datensatz irgend wann einmal geändert hat und stellt x Tage später fest, dass da was nicht passt. Denn man kontrolliert das auch nicht jedes mal nach (Exe schließen, neu Starten).
Wenn ich jetzt die DB loggen würde, dann hätte ich mehrere MB Log jeden Tag, und ich stünde vor einem Datensalat wo ich auch nur schwer weiter komme.
Meine EXE kann sogar jeden Funktionsaufruf loggen, die ich selbst geproggt habe, ich habe das auch schon genutzt um Fehler zu finden. Nur komme da gleich mal 100 Zeilen Log innerhalb weniger Sekunden zusammen und somit eignet sich das nur um eine definierte Fehlfunktion zu lokalisieren.

Aber an den Fehler muss ich irgendwie anders bei kommen.

Die Zeos Kompo hat doch sicher auch eine Monitor / Log Funktion, ich habe die bisher noch nicht genutzt, weißt Du wie das geht?

[hde]

hab ich gesehen und versucht zu nutzen um den Fehler "64bit-mySQL" zu finden, Dabei wurde nichts gelogged, aber es lief ja auch keine Funktion bis zu Ende.
Aber solche Fehler, von denen man nicht weiß ob es wirklich Fehler sind, nerven. Es kann ja auch sein, man "wollte" ändern, oder hat beim Ändern den Post-Button vergessen, oder der PC ist abgeschmiert oder die exe wurde gekillt oder das Programm meldete einen Fehler den man übersehen hat. Das kann auch der Rechner sein auf dem der DB-Server lief. Auch der cached. Ich würde versuchen zu klären, ob ein Rechner am Tag der Änderunge Auffälligkeiten hatte bzw. ob der "Fehler" wirklich ein Fehler ist. Ich habe meist Logging mit laufen, ok, viele MB groß. Und falls man suchen muss, viele, viele Stunden.
Aber es gibt auch automatische Rollbacks wenn die Datenlogik nicht stimmt, z.B. ein ID doppelt ist.
Ich werde mal nach "Löchern" suchen.
hde

[MmVisual]

Es kann ja auch sein, man "wollte" ändern, oder hat beim Ändern den Post-Button vergessen, oder der PC ist abgeschmiert oder die exe wurde gekillt oder das Programm meldete einen Fehler den man übersehen hat.

- Meine EXE durchsucht bei Destroy alle TDataSets und prüft auf dsEdit, dsInsert und Postet die ggf jede Query einzeln.

Code: Alles auswählen

for i := 0 to ComponentCount - 1 do // Alle ungespeicherten Queries Posten
      begin
        if Components[i] is TZQuery then ...

- Beim Wechsel vom Datensatz, z.B. im Grid wird auch immer gepostet.
- Beim Event BeforeClose wird auch ggf gepostet.
- Die EXE wurde in den Fällen auch nicht gekillt und hat sich immer ordentlich beendet.

Aber es gibt auch automatische Rollbacks wenn die Datenlogik nicht stimmt, z.B. ein ID doppelt ist.

Ja, aber ich hatte schon Fehler beobachtet (meine Vermutung) in der eine Menge einfach nicht stimmte obwohl ich einige Tage/Wochen zuvor den Lagerbestand richtig gestellt hatte. Somit war der Datensatz schon vorher vorhanden und der Update hat nicht geklappt.

Das kann auch der Rechner sein auf dem der DB-Server lief. Auch der cached.

Früher war mein Server der Laptop und den hatte ich immer wieder in Standby geschickt.
Jetzt ist mein Server ein Stromsparender Mini-PC, der hängt jetzt (über Sicherung) direkt an 2000Ah Akkus, die nie leer werden und der PC ist immer an.
Seither konnte ich das nicht mehr so direkt feststellen. Es ist somit schon möglich, dass dem MySQL Server der Standby nicht gefallen hat (obwohl alle Clients schon vorher garantiert zu waren).

Ich werde wohl noch ein paar Wochen warten müssen um genauere Aussagen treffen zu können.

[hde]

Das Aufwachen nach einem Standby funktioniert nicht immer. Z.B. läuft dann (nur gelegentlich!) Outlook ohne die Überwachung durch den Spamfilter. Dann hilft nur Neustart von Outlook und alles läuft wieder sauber.
Auch ein DB-Server der über ODBC angesteuert wird ist (manchmal) nach einem Standby nicht mehr erreichbar. Auch da hilft ein Neustart.
Und ob Windows einen evtl noch im Cache (oder auch Windows- oder Plattencache) befindlichen Datensatz beim Standby wirklich sichert würde ich stark bezweifeln. Wirklich auf die Hardware geschrieben wird nur bei einem Commit nach Transaction oder einem Flush.
Ich hab an meinem Schreibtisch 2 bis 3 Rechner laufen und die Kollegen/innen weitere im Netzverbund. Mein Haupttestrechner läuft unter Linux (Ubuntuabart) und alle Testsysteme, Win32, Win64, Mac, Linux usw. fahre ich parallel auf VMs. da ich ständig mind. 4 VMs aktiv laufen habe, schicke ich diesen Rechner auch nur ins Standby und starte ihn selten neu. Aber alle evtl. laufenden Datenbankverbindungen werden gecancelt und alle Datenbanken gehen Shutdown. Die VMs starte alle wieder sauber auch mit laufenden Anwendungen (ohne DB-Server). Nur bei den Macs bockt schon mal einer in 10 - 14 Tagen.
Generell .. Clients dürfen in Standby, Datenbankserver bei uns grundsätzlich nie. Entweder shutdown oder ständig aktiv und die Energieverwaltung abgeschaltet.
Das ist meine Erfahrung, bin gespannt was bei dir rauskommt.
hde

[MmVisual]

Bei meinem Server, WinXP, schaltet nur nach 5 Minuten der Bildschirm aus, Disc usw. bleibt alles an.

[hde]

dann sollte es daran nicht liegen. Bildschirm dunkel ist noch kein Standby. Bist du sicher, dass nur der Bildschirm abschaltet? Ich hab hier einen Laptop von Dell Win7-64 der lässt sich kaum bremsen standby zu gehn, und zwar voll.

[Christian]

Ich bezweifel fast wlle theorien hier. Slbst sqlite macht sich wahnsinnig gedanken um den plattencache um solche fälle zu vermeiden. Ich hab sowas bei einer db noch nie erlebt verwende zwar kein mysql aber aus meiner erfhrung sind solche fehler meisst eigene fehler.

[EgonHugeist]

@MMVisual

http://www.lazarusforum.de/viewtopic.php?f=17&t=5884" onclick="window.open(this.href);return false;

Alle Antworten liegen ganz klar auf deinem Formular und nirgendwo anders, haben auch nix mit großen Mengen zu tun. Bsp. von mir und einer meiner kleinen Firmen: ca. 300.000 lese und Schreibaktionen/Tag importe von 10.000 MasterRows mit diversen Child-Tables mit joins usw. jeden Morgen. Mit allem was man da halt so braucht. Habe auch da Zeos7 im Einsatz... Habe da schon diverse Server geschaft (alle 100.000 DS mal ein sleep(10000) damit der Luft holen kann, warum auch immer), aber Zeos noch nicht.

Verwende ebenfalls dezeit MySQL. Datenverlust 0.0%. Langzeiterfahrung 2Jahre + Zeos7.

Habe bei MySQL aber eben manchmal die Erscheinung: 'Can not retrieve Resultset'. Welches eine eingebaute Fehlermeldung von Zeos ist. Diese wird aber nur geraised wird, wenn die Datenbank nix mehr zum Vorschein bring. Geb ich dem Server 10sec Pause zum "Luft holen" und ballere ihn dann weiter mit Statements voll (das Fehlgeschlagene auch nochmal -> ist gültige, bevor du miir die Frage stellst), ist es 'ne ech tolle Sache. Hatte ich aber derzeit nur bei MySQL.

Wird daher eher irgdwas am Progamm sein..

[MmVisual]

Jetzt habe ich ja die neue 7er Kompo drin und somit ist das ganze ohnehin hinfällig.

Ich vermute mal stark es lag an dem Standby gehen vom MySQL Server (Laptop). Jetzt habe ich einen anderen Server der 24/7 an ist.