Fehlerbehebung bei den Gründen, warum gelöschte MySQL-Datensätze nicht wirksam werden

Ein Datensatz eines Online-MySQL-Transaktionsproblems

Letzten Freitag habe ich eine Operation zum Löschen einer großen Tabelle durchgeführt. Während des Löschvorgangs trat ein kleines Problem auf und ich habe zwei Stunden vergeblich damit verbracht. Ich habe den allgemeinen Vorgang hier aufgezeichnet. Schauen wir uns den Vorgang ohne weitere Umschweife einfach an.

Damals wollte ich es löschen, also testete ich zunächst die Syntax der Löschanweisung und löschte zum Ausprobieren eines wie folgt:

mysql ::>>wähle min(id) aus XXXX_user_login aus;
+---------+
| min(ID) |
+---------+
| |
+---------+
 Zeile im Satz (0,00 Sek.)

mysql ::>>löschen aus XXXX_user_login, wobei ID < ;
Abfrage OK, Zeile betroffen (0,00 Sek.)

mysql ::>>wähle min(id) aus XXXX_user_login aus;         
+---------+
| min(ID) |
+---------+
| |
+---------+
 Zeile im Satz (0,00 Sek.)

Dann habe ich mich erneut über den MySQL-Client angemeldet und ein merkwürdiges Problem festgestellt:

[dba_mysql ~]$ /usr/local/mysql/bin/mysql -udba_admin -p -h127.0.0.1 -P4306
Passwort eingeben: 
XXXXXXXXXXXXXXXXXXXXXX
Geben Sie „help;“ oder „\h“ ein, um Hilfe zu erhalten. Geben Sie „\c“ ein, um die aktuelle Eingabeanweisung zu löschen.

mysql ::>>wähle min(id) aus XXXXX_user_login aus;                  
+---------+
| min(ID) |
+---------+
| |
+---------+
 Zeile im Satz (0,00 Sek.)

Das heißt, der gerade gelöschte Datensatz ist wieder da.

Es ist ziemlich seltsam, darüber nachzudenken. Habe ich es falsch gelöscht? Oder hat die Geschäftsseite die Daten nach dem Löschen erneut eingefügt. Ist das nicht ein Problem? . . Habe es noch ein paarmal probiert, mit dem gleichen Ergebnis.

Dieses Phänomen ist sehr seltsam. Ich habe es noch nie zuvor erlebt. Ich habe zuerst das Skript überprüft und bestätigt, dass das gelöschte Skript korrekt war. Dann habe ich lange nachgeprüft und schließlich einen Durchbruch aus der Richtung der Transaktion gefunden. Ich vermutete, dass dies daran lag, dass die Transaktion nicht übermittelt wurde. Also habe ich mir die Parameter der aktuellen Transaktion wie folgt angesehen:

mysql ::>>Variablen wie „%commit%“ anzeigen;   
+--------------------------------+----------+
| Variablenname | Wert |
+--------------------------------+----------+
| Autocommit | AUS |
| innodb_commit_concurrency | |
| innodb_flush_log_at_trx_commit | |
+--------------------------------+----------+
 Zeilen im Set (0,00 Sek.)

[email protected]:(keine) ::>>
mysql ::>>globale Variablen wie „%commit%“ anzeigen;
+--------------------------------+----------+
| Variablenname | Wert |
+--------------------------------+----------+
| Autocommit | EIN |
| innodb_commit_concurrency | |
| innodb_flush_log_at_trx_commit | |
+--------------------------------+----------+
 Zeilen im Set (0,00 Sek.)

Wenn man das sieht, ist das Problem im Grunde behoben. Es liegt daran, dass das automatische Commit in der aktuellen Sitzung deaktiviert ist, sodass es beim Löschen scheinbar erfolgreich war. Nach dem Neustart wurden diese Transaktionen zurückgesetzt, sodass der Löschvorgang anscheinend „ungültig“ ist.

Nachdem das Problem nun lokalisiert wurde, beginnen wir mit der Suche nach der Grundursache des Problems. Schließlich finden wir die Grundursache in der Konfigurationsdatei wie folgt:

[mysqldump]
schnell
max_allowed_packet = M

[mysql]
kein automatisches Wiederaufwärmen
max_allowed_packet = M
prompt=mysql--\\u@\\h:\\d \\R:\\m:\\s>>
init-command="Interactive_timeout festlegen=28800;Warte_timeout festlegen=28800;Autocommit festlegen=0;"

In der letzten Zeile der Konfigurationsdatei wurde die Autocommit-Konfiguration der MySQL-Clientgruppe auf 0 gesetzt. Natürlich konnte sie nicht automatisch übermittelt werden. Also änderte ich diesen Parameter auf 1 und probierte das Skript erneut aus, stellte jedoch fest, dass das Problem weiterhin bestand. . .

Es scheint, dass die Änderungen noch nicht gründlich sind.

Wir wissen, dass es eine Sequenz gibt, in der MySQL Konfigurationsdateien lädt. Wir können den Befehl mysql --help|grep my.cnf verwenden, um sie anzuzeigen. Nach der Überprüfung liegt es daran, dass die Konfiguration in /etc/my.cnf auch autocommit=0 ist, sodass die Parameter der aktuellen Konfigurationsdatei überschrieben werden. Nachdem Sie schließlich den Inhalt des Autocommit-Parameters in der Datei /etc/my.cnf geändert haben, stellen Sie die Verbindung zum MySQL-Server wieder her und stellen Sie fest, dass das Problem gelöst ist.

Zusammenfassend sind folgende kleine Erkenntnisse festzuhalten:

1. Wenn Sie feststellen, dass die Daten nicht gelöscht werden können, können Sie zunächst überprüfen, ob der Parameter für die Transaktionsübermittlung deaktiviert ist.

2. Verwenden Sie „Variablen anzeigen“ und „Globale Variablen anzeigen“, um die Transaktionsparameter der aktuellen Sitzung bzw. die globalen Variablen anzuzeigen.

3. Die Parameter in der MySQL-Gruppe in der Datei my.cnf werden verwendet, um die Konfiguration des MySQL-Clients zu steuern.

4. Die Datei my.cnf hat eine Ladereihenfolge. Wenn Sie diese ändern, müssen alle geändert werden. Oder stellen Sie sicher, dass nur eine my.cnf-Datei vorhanden ist.

Oben finden Sie ausführliche Informationen zur Fehlerbehebung bei den Gründen, warum gelöschte MySQL-Datensätze nicht wirksam sind. Weitere Informationen zu nicht wirksamen gelöschten MySQL-Datensätzen finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!