2015-05-07 12 views
7

Ich habe mehrere DDBB auf InnoDB (MySQL 5.5.7. -FreeBSD). Seit 5 Jahren habe ich keine Probleme. Ich realisiere regelmäßig Prüftabellen, Optimierung, ...Nach 5 Jahren verschwanden mehrere Zeilen aus mySQL innoDB Tabelle

Mysteriöserweise hat eine Tabelle von einem der DB 20 Zeilen von 70 (DELETE!) Verloren. Diese Zeilen wurden vor einigen Jahren eingefügt. Keine Beziehung zwischen ihnen (zufällige IDs). Es ist ein sehr kleiner Tisch.

Ich habe die Ursache nach mehreren Stunden der Forschung (und Google) nicht gefunden. Ich habe die Informationen durch das letzte Backup wiederhergestellt.

Ich checkte:

WEB APP:

1) Die Anwendung hat keine DELETE-Anweisung, nur SELECT oder UPDATE.

2) Nein DELETE ON CASCADE, kein Fremdschlüssel.

2) Geschütztes SQL INJECT.

3) Es gibt keine Anwendungsverwaltungstabellen (wie phpMysqlAdmin).

4) Meine App Log Nicks versuchen während dieser Stunden anzugreifen oder zuzugreifen.

MYSQL:

1) Alle Überprüfungen der Zeilen wurden ohne Verwendung des APP direkt in der mysql-Konsole gemacht.

2) mysqlcheck: kein Fehler in der betroffenen Tabelle.

3) Mysqldump: keine dump die Zeilen verschwinden, nur die verbleibenden Zeilen.

4) Fehlerprotokoll: kein registrierter Fehler.

5) Die Datei table.idb enthält die verlorenen Datensätze, nur die verbleibenden Zeilen.

6) mysql Benutzer ist nur lokal (per IP) erreichbar.

SERVER:

1) Wer hat den Server zugegriffen.

2) Auf der Festplatte oder auf der Steuerung sind keine Fehler aufgetreten.

3) Ich sehe keine Vorfälle in den Systemprotokollen.

Scheinbar ist alles in Ordnung. Ich weiß nicht was passiert ist.

Ich denke an zwei Möglichkeiten:

1) Ein Fehler in MySQL 5.5.7 ???

2) In den Stunden, die die Datensätze verloren gingen, machte ich einen Import (auf andere Datenbank) von Millionen von INSERT und DELETE. Ich glaube nicht, dass dieser intensive Prozess eine andere Tabelle in einer anderen Datenbank (ohne eine Spur) beschädigt hat.

Ich mache mir Sorgen, wenn es wieder passiert!

Danke!

UPDATE 1 @pala_ hat mir empfohlen, das bin-log (ich nicht gesehen hatte!) Zu konsultieren.

Dort im bin-log 20 Abfragen mit dem berühmten DELETE!

ich fügen Sie den bin-log:

(...) 
BEGIN 
/*!*/; 
# at 83069675 
# at 83069772 
# at 83070746 
# at 83071672 
# at 83072677 
#150505 12:29:18 server id 168291 end_log_pos 83069772   Table_map: `affected_database`.`affected_table` mapped to number 583255 
#150505 12:29:18 server id 168291 end_log_pos 83070746   Delete_rows: table id 583255 
#150505 12:29:18 server id 168291 end_log_pos 83071672   Delete_rows: table id 583255 
#150505 12:29:18 server id 168291 end_log_pos 83072677   Delete_rows: table id 583255 
#150505 12:29:18 server id 168291 end_log_pos 83073123   Delete_rows: table id 583255 flags: STMT_END_F 
### DELETE FROM affected_database.affected_table 
### WHERE 
### @1=xxxxxxx 
### @2=xxxxxxxx 
### @3=xxxxxxxxxx 
### @4=xxxxxxxxx 
### @5=xxxxxxxxx 
### @6=xxxxxxxxx 
### @7=xxxxxxxxxx 
### @8=xxxxxxxxx 
### @9=xxxxxxxxxx 
### @10=xxxxxxxxxxxx 
### @11=xxxxxxxxxxx 
### @12=xxxxxxxxxxx 
### @13=xxxxxxxxxxx 
### @14=xxxxxxxxxxx 
### @15=xxxxxxxxxxx 
### @16=xxxxxxxxxxx 
### @17=xxxxxxxxxxx 
### @18=xxxxxxxxxxx 
### @19=xxxxxxxxxxx 
### @20=xxxxxxxxxxx 
### @21=xxxxxxxxxxx 
### @22=xxxxxxxxxxx 
### @23=xxxxxxxxxxx 
### @24=xxxxxxxxxxx 
### DELETE FROM affected_database.affected_table 
### WHERE 
(...) x20 

Wie es funktioniert hat?

Dank

+1

sql-server ist eine andere Datenbank zu mysql - markieren Sie sie nicht, wenn Sie sie nicht brauchen. Ist die binäre Protokollierung aktiviert? Wenn ja, prüfen Sie, ob die Zeilen tatsächlich über eine Abfrage gelöscht wurden –

+0

Sie sind schnell! Ich habe bearbeitet, um das Tag zu entfernen, da ich auf Microsoft SQL Server verweisen gesehen habe. Danke! – BeAsT

+1

Denken Sie daran, dass die REPLACE INTO-Anweisung Zeilen löschen kann, wenn sie mit den neuen Werten in Konflikt stehen [replace-in-think-twice] (http://code.openark.org/blog/mysql/replace-into-think-twice) Bitte geben Sie die Struktur der Tabelle an (falls vorhanden). – houssam

Antwort

0

Die DELETE scheinen nach Ihnen wurden bin-log tatsächlich ausgeführt werden. Die eher zufälligen Optionen (Fehler in MySQL, Ausgabe während eines unabhängigen Importes (wenn es tatsächlich nicht zusammenhängt) scheinen daher unwahrscheinlich.

Uns bleiben 2 Möglichkeiten übrig: 1. "autorisiert" aber unbekannt, z.B. Es gibt eine Löschmethode in Ihrer Codebase, aber Sie haben sie einfach nicht gefunden oder jemand mit einer gültigen Anmeldung hat einen Befehl ausgeführt (Sie brauchen dafür keine Anwendung, aber Sie benötigen Zugriff auf einen Server, der sich anmeldet zu Ihrer Datenbank) 2. nicht autorisiert: Jemand hat Zugang zu Ihrem System (und aufgeräumt), oder jemand fand eine sql-Einspritzung

Es ist wirklich schwer zu sagen, welches ist das wahrscheinlichste. Von den Überprüfungen, die du gemacht hast, ist es schwer zu sagen, wie gründlich du warst, aber sowohl der Zugang zum System (keine Vorfälle) als auch die Probleme mit dem Code (Schutz vor der Injektion) sind schwierig herauszufinden. Auf der anderen Seite, wenn es eine Menge Leute mit möglichem Zugang zum System gibt, ist es wirklich schwer, das zu vereiteln.

Wenn Sie das Gefühl haben, dass dies wieder passieren könnte, sollten Sie wahrscheinlich die general query log aktivieren. Das würde dir einen Hinweis auf die Quelle geben. Du kannst es jeden Tag ansehen und drehen, damit es nicht zu groß wird.

Wenn Paranoia-Probleme mit Ihrem Server auftreten, können Sie versuchen, Ihre Protokolle extern zu speichern, und zwar an einem Ort, auf den Sie nur Zugriff haben: Auf diese Weise würden alle Manipulationen verhindert. So weit würde ich noch nicht gehen.