Fehlerbehebung bei MySQL-Datenverlust

Vorwort

Kürzlich kontaktierte mich plötzlich ein Freund über WeChat und teilte mir mit, dass MySQL Daten verloren habe. Für einen DBA ist das zweifellos die stressigste Sache, daran besteht kein Zweifel. Nachdem ich die Neuigkeiten gehört hatte, begann ich sofort mit der Behebung des Problems.

Untersuchung vor Ort

Als ich die Nachricht hörte, war ich natürlich sehr nervös, beruhigte mich jedoch schnell und begann, der Sache auf den Grund zu gehen:

(1) Ist der Status der Instanz normal? --Nach der Bestätigung ist der Instanzstatus normal

(2) Welches ist die Wirtschaftsbibliothek? Gibt es das noch? Wurde es gelöscht? --Es wurde bestätigt, dass der Geschäftsbestand

(3) Auf welche Tabelle hat das Unternehmen bei der Fehlermeldung zugegriffen? Existiert die Tabelle? Wurde es gelöscht? --Nach der Bestätigung existiert die Geschäftstabelle

(4) Sind die Berechtigungen der Anwendungsbenutzer normal? --Es wurde bestätigt, dass der Anwendungsbenutzer über alle Berechtigungen der Geschäftsbibliothek verfügt

(5) Welche Fehlermeldung wird beim Firmenzugriff gemeldet? --Nach der Bestätigung meldet die Geschäftsseite Fehler beim Zugriff auf bestimmte Seiten

(6) An diesem Punkt der Untersuchung vermuten wir einerseits, ob es eine Anomalie in der Anwendung gibt, und andererseits, ob einige Datensätze verloren gegangen sind. Die Entwicklungsseite und die Betriebs- und Wartungsseite untersuchen dies gleichzeitig. Die Idee für die Betriebs- und Wartungsseite, hier zu untersuchen, ist, ob die Geschäftstabelle einen Primärschlüssel hat. Welche Übereinstimmung besteht zwischen geschäftsseitigen Zugriffsfehlern und Geschäftstabellen? Können Sie die entsprechenden Datensätze finden?

(7) Eine weitere Analyse ergab, dass die Geschäftstabelle einen Primärschlüssel hatte und die Entwicklungsseite auch einen Abfragedatensatz bereitstellte. Nach der Überprüfung war der Datensatz vorhanden und wurde nicht versehentlich gelöscht. Die Entwicklungsseite überprüfte die Anwendung und das Protokoll druckte die Fehlerinformationen nicht klar aus.

(8) In diesem Fall können Sie lediglich fragen, ob an dem Abend Änderungen/Freigaben vorgenommen wurden? --Es wurde bestätigt, dass in dieser Nacht einige DDL-Änderungen an der Tabelle vorgenommen wurden

Bei der weiteren Untersuchung stellten wir fest, dass die DDL-Änderung in dieser Nacht Operationen an der Geschäftstabelle betraf. Die Änderung bestand darin, die Feldlänge zu ändern, ähnlich wie bei „alter table xxx modify column xxx char(x). An diesem Punkt begannen wir, uns Gedanken über das Problem zu machen. Als Nächstes begannen wir, die sql_mode-Konfiguration zu überprüfen und die entsprechenden vollständigen Zeilendatensätze zur Bestätigung durch den Entwickler abzufragen. Schließlich bestätigten wir, dass die DDL-Änderung dazu führte, dass das Feld abgeschnitten wurde. Am Ende konnten wir es nur durch ein Backup wiederherstellen und das Problem war endlich gelöst.

Gehäusereproduktion

Nachdem Sie gerade den Fehlerbehebungsprozess gelesen haben, werden sich viele von Ihnen vermutlich fragen: Warum führt das Ändern der Feldlänge dazu, dass die Daten abgeschnitten werden? Führt MySQL keine Datenvalidierung durch? Schauen wir weiterhin nach unten.

(1) Szenario 1

mysql> wähle * von sbtest2 Limit 1;
+----+---------+---------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------+
| Ich würde | k | c | Pad |
+----+---------+---------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------+
| 1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 63188288836-92351140030-06390587585-66802097351-49282961843 |
+----+---------+---------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------+
1 Zeile im Satz (0,00 Sek.)

mysql> alter table sbtest2 modify column pad char(1);
FEHLER 1265 (01000): Daten für Spalte „Pad“ in Zeile 1 abgeschnitten

mysql> wähle * von sbtest2 Limit 1;
+----+---------+---------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------+
| Ich würde | k | c | Pad |
+----+---------+---------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------+
| 1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 63188288836-92351140030-06390587585-66802097351-49282961843 |
+----+---------+---------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------+
1 Zeile im Satz (0,00 Sek.)

(2) Szenario 2

mysql> wähle * von sbtest2 Limit 1;
+----+---------+---------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------+
| Ich würde | k | c | Pad |
+----+---------+---------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------+
| 1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 63188288836-92351140030-06390587585-66802097351-49282961843 |
+----+---------+---------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------+
1 Zeile im Satz (0,00 Sek.)

mysql> alter table sbtest2 modify column pad char(1); Abfrage OK, 100 Zeilen betroffen, 100 Warnungen (0,06 Sek.)
Datensätze: 100 Duplikate: 0 Warnungen: 100

mysql> wähle * von sbtest2 Limit 1;
+----+---------+---------------------------------------------------------------------------------------------------------------------------+---------+
| Ich würde | k | c | Pad |
+----+---------+---------------------------------------------------------------------------------------------------------------------------+---------+
| 1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 6 |
+----+---------+---------------------------------------------------------------------------------------------------------------------------+---------+
1 Zeile im Satz (0,00 Sek.)

Szenario 1 entspricht eher unseren Erwartungen und meldet direkt den Fehler „Daten abgeschnitten“. Szenario 2 wird erfolgreich ausgeführt, was zu einem „teilweisen Datenverlust“ führt. Führt MySQL dann keine Datenüberprüfung durch? Tatsächlich verfügt MySQL über eine Datenvalidierung. In Szenario 2 verhinderte MySQL jedoch aufgrund des Problems mit der SQL_Mode-Konfiguration und des Fehlers beim Festlegen von STRICT_TRANS_TABLES nicht die Ausführung des Vorgangs, was zur Tragödie des „Datenverlusts“ führte.

Zusammenfassen

An diesem Punkt kann die Tragödie des „Datenverlusts“ ein Ende haben. Die Grundursache ist, dass sql_mode STRICT_TRANS_TABLES nicht festlegt. Dieser Fall erinnert uns auch daran, dass sql_mode eine sehr kritische Konfiguration ist und nicht leichtfertig festgelegt oder geändert werden darf. Weitere Informationen zu sql_mode werden im nächsten Artikel mit Ihnen geteilt.

Oben finden Sie Einzelheiten zur Fehlerbehebung bei MySQL-Datenverlust. Weitere Informationen zur Fehlerbehebung bei MySQL-Datenverlust finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!