ich habe hier ein mehr oder weniger heftiges problem: meine mysql-db verliert permanent datensätze. ohne jegliche delete- oder update-anweisungen sind einzelne datensätze weg.
das durchforsten der bin-log brachte auch kein ergebnis.
also das ist eine webapplikation die permanent läuft.
es geht um eine tabelle mit bestellpositionen (ca. 1.000.000 datensätze), ca. 300 sind verschwunden.
in der mysql-log sehe ich keinerlei deletes oder so - lediglich die korrekten inserts...
problem ist, dass ich von mysql keine projekterfahrungen habe, da ich bei meinen ex-arbeitgebern nur mit oracle/db2 gearbeitet habe... daher kann ich nicht sagen wie stabil mysql laufen soll...
sehr unwahrscheinlich ist, zumindest in deinem Anwendungsfall, dass mySQL per Prozess-kill beendet wurde (unter Win dass kreuzchen oben in der Ecke oder Strg-Alt-Entf). In diesem Fall gehen alle Daten, die bisher nur im Arbetsspeicher sin verloren. mySQL speichert, soweit ich weiß, erstmal alles im AS und kopiert auf Festplatte, wenn es ordnungsgemäß beendet wird ODER grade nichts besseres zu tun hat bzw. der AS voll ist.
wahrscheinlicher ist, dass ein UPDATE oderso Daten überschreibt. beispiel:
Code:
UPDATE `user` SET `name`='neu' WHERE `id`='10';
hierbei habe ich mal denn WHERE-Clause vergessen, und etwa 64 Datensätze beschädigt... Das tückische ist, dass es auf den ersten Blick richtig aussieht, schließlich wird der datensatz der geändert werden soll geändert, nur halt ALLE anderen auch....Beim Testen übersieht man das leicht Wenn nur 300 andere geändert wurden, könnte ich mir vorstellen, dass in einem WHERE-Clause was fehlt z.B.
Code:
UPDATE `user` SET `name`='neu' WHERE `nachname`='mueller'
statt
Code:
UPDATE `user` SET `name`='neu' WHERE `nachname`='mueller' AND `auftragssumme`='300'
Ich denke dass ganze läuft auf php, wie steht die max_execution_time? Wenn der Skript wegen Zeitüberschreitung abgebrochen wird, sieht der Client dass nicht unbedingt, der mySQL-Server kriegt auch nichts mit, aber ein am ende des Skripts stehender Query wird eventl. nicht ausgeführt, sehen kann man dass, wenn z.B. die INSERT-Querys auch nicht im Log sind...
also problem ist, dass datensätze einfach flöten gehen.
auftrag wurde z.b. am 01.01.2001 korrekt verschickt und nie wieder angepackt. plötzlich sind bestellpositionen weg.
bin den db-code, log4j-output und mysql-log durchgegangen und da passiert nichts mit dem auftrag. die positionen sind trotzdem weg - von heute auf morgen...
>>also problem ist, dass datensätze einfach flöten gehen.
soweit waren wir schon
>>auftrag wurde z.b. am 01.01.2001 korrekt verschickt
was heisst verschickt? wurden die Positionen mit INSERT eingetragen (mit den richtigen Foreign keys) und hast du per SELECT SUM() deine Bindingung bestellwert aus auftrags-table = positionenwert geprüft und war das an dieser stelle in der datenbank OK?
>>und nie wieder angepackt.
was heisst angepackt?
>>plötzlich sind bestellpositionen weg.
soweit waren wir schon
>>bin den db-code,
>>log4j-output und mysql-log
>>durchgegangen und da passiert nichts mit dem auftrag.
bleibt die Frage, ob den die Positionen (Versand) wirklich mit INSERT eingetragen wurden (als Kopie der Positionen Bestellung?)
>>bestellwert aus
>>auftrags-table != positionenwert in positionen-table
nur weil diese beiden Summen verschieden sind, heisst das doch noch lange nicht, dass irgendwelche Zeilen verlorengegangen sind
am 01.01.2005 hatte auftrag x einen gesamtwert von 500 aus 5 positionen zu je 100.
auftrag x wurde dann nicht mehr aufgerufen/bearbeitet etc.
am 01.03.2005 hat auftrag x einen gesamtwert von 500, aber nur noch 4 positionen zu je 100.
da die kalkulation vom gesamtwert nur berechnet wird, wenn der auftrag aufgerufen wird, ist eine position weg > datensatz weg.
auftrag wurde definitiv nicht bearbeitet (lt. log4j+mysql-log). ferner sind abgeschlossene aufträge sowieso nicht zu bearbeiten.
die sätze wurden per insert eingefügt und waren nachweislich vorhanden (rechnungen wurden ja gedruckt). hinterher ist z.b. an stelle y (autoincrement) kein satz mehr vorhanden.
bzgl. foreign keys:
ich habe die mysql-db vom ex-entwickler übernommen. die besagten tabellen sind vom typ myisam. habe nun gelesen, dass myisam für größere tabellen ungeeignet sei und man auf innodb umsteigen soll.
kann das der grund allen übels sein?
ich komme eher aus der oracle/db2-welt, daher bin ich mit der mysql-geschichte etwas überfragt was wiese problematik angeht bzw. musste mich sonst nie um db-administration kümmern
was noch eigenartig ist: es werden zig-tausende aufträge so abgewickelt und seit kurzem haben ca. 5 aufträge am tag o.g. problem - absolut willkürlich :roll: wenn mein code schrott wäre, müssten ja alle aufträge gegen die wand laufen...
bullshit, wenn er berechnet wird und nur 4 datensätze a 100 da sind, dann wäre ja der gesamtwert 400
gibt es eine auftragstabelle? gibt es eine positionentabelle - da wären fk mit innodb natürlich angebracht
trotzdem wette ich drauf, dass
-> entweder ein anzeigefehler vorliegt
-> oder jemand mit delete die position gelöscht hat
-> ein multithreading problem
-> ein transaktionsproblem (ausdruck der rechnung zu früh?)