Lösung für das versehentliche Löschen von Daten in MySQL und Kill-Anweisungsprinzip

mysql hat versehentlich Daten gelöscht

• Verwenden der Delete-Anweisung zum versehentlichen Löschen einer Datenzeile
• Verwenden Sie Drop Table oder Truncate Table, um versehentlich eine Datentabelle zu löschen
• Versehentliches Löschen einer Datenbank mit der Anweisung „Drop Database“
• Verwenden von RM zum versehentlichen Löschen der gesamten MySQL-Instanz
  

Für versehentlich gelöschte Zeilen

• Verwenden Sie das Flashback-Tool zum Flashback und zur Wiederherstellung der Daten. Das Prinzip besteht darin, den Inhalt des Binlogs zu ändern und ihn zur Wiedergabe aus der Originaldatenbank abzurufen. Sie müssen sicherstellen, dass binlog_format=row und binlog_row_imsge=Full
  
• Spezifische Erholungszeit
  
  • Wenn es sich um eine Einfügung handelt, ändern Sie den Binärprotokoll-Ereignistyp vom Ereignis „write_rows“ in das Ereignis „delete_rows“.
  • Beim Löschen ist das Gegenteil der Fall.
  • Handelt es sich um ein Update, enthält das Binlog die Werte vor und nach der Änderung der Daten. Vertausche einfach diese beiden Zeilen.
• Auch Mehrfachausführungen erfolgen nach den oben genannten Grundsätzen in umgekehrter Reihenfolge.
• Vorbeugung: Setzen Sie den Parameter sql_safe_updates auf „on“. Wenn wir also vergessen, die Where-Bedingung in die Lösch- oder Aktualisierungsanweisung zu schreiben, oder die Where-Bedingung das Indexfeld nicht enthält, wird bei der Ausführung dieser Anweisung ein Fehler gemeldet.
  

Für versehentlich gelöschte Datenbanken/Tabellen

Sie müssen eine vollständige Sicherung und inkrementelle Protokolle verwenden. Ist es erforderlich, regelmäßig vollständige Online-Sicherungen durchzuführen und das Binlog in Echtzeit zu sichern?

Wenn jemand versehentlich um 12 Uhr mittags eine Datenbank löscht, läuft die Wiederherstellung der Daten wie folgt ab:

Führen Sie die letzte vollständige Sicherung durch. Gehen Sie davon aus, dass die Datenbank einmal täglich gesichert wird und die letzte Sicherung am selben Tag um 0:00 Uhr erfolgte.

Stellen Sie eine temporäre Bibliothek aus der Sicherung wieder her.

Aus der Log-Sicherung die Logs nach 0:00 Uhr entnehmen

Wenden Sie alle diese Protokolle, mit Ausnahme von Anweisungen, die versehentlich Daten löschen, auf die temporäre Datenbank an.

Beachten:

Um die Datenwiederherstellung zu beschleunigen, können Sie, wenn sich in dieser temporären Bibliothek mehrere Datenbanken befinden, bei Verwendung des Befehls mysqlbinlog einen Parameter –database hinzufügen, um die Bibliothek anzugeben, in der sich die versehentlich gelöschte Tabelle befindet. Dadurch wird die Notwendigkeit vermieden, beim Wiederherstellen von Daten andere Bibliotheksprotokolle anzuwenden.

Beim Anwenden von Protokollen müssen Sie das Binärprotokoll der Anweisung mit der fehlerhaften Operation um 12 Uhr überspringen:

Methode zur Beschleunigung der Wiederherstellung: Legen Sie nach dem Sichern und Wiederherstellen einer temporären Instanz diese temporäre Instanz als Slave-Datenbank der Online-Sicherungsdatenbank fest.

Es ist für ein System unmöglich, eine unbegrenzte Anzahl von Protokollen zu sichern. Sie müssen außerdem die Anzahl der Tage festlegen, für die Protokolle basierend auf Kosten und Speicherplatzressourcen aufbewahrt werden sollen. Wenn Ihr DBA-Team Ihnen mitteilt, dass es garantieren kann, dass eine Instanz innerhalb eines halben Monats zu einem beliebigen Zeitpunkt wiederhergestellt werden kann, bedeutet dies, dass das Sicherungssystem die Protokolle mindestens einen halben Monat lang aufbewahrt.

Auch wenn „niemand möchte, dass so etwas passiert“, können Sie im Falle einer versehentlichen Löschung die Daten schnell wiederherstellen und die Verluste minimieren, sodass Sie nicht weglaufen müssen. Wenn Sie jedoch in Eile manuelle Vorgänge durchführen und dabei Fehler machen, die Ihrem Unternehmen schaden, wäre das nicht akzeptabel.

Verzögerte Replikation der Standby-Datenbank

• Wenn die Sicherung einer Datenbank besonders umfangreich ist oder zwischen dem fehlerhaften Vorgang und der letzten vollständigen Sicherung viel Zeit vergeht, z. B. wenn in einer Instanz mit wöchentlicher Sicherung am sechsten Tag nach der Sicherung ein fehlerhafter Vorgang auftritt, müssen 6 Tage Protokolle wiederhergestellt werden und die Wiederherstellungszeit kann auf täglicher Basis berechnet werden.
• Eine Standbydatenbank mit verzögerter Replikation ist eine spezielle Standbydatenbank. Mit dem Befehl CHANGE MASTER TO MASTER_DELAY = N können Sie angeben, dass die Standbydatenbank eine Verzögerung von N Sekunden gegenüber der Masterdatenbank aufrechterhält.
• Wenn Sie beispielsweise N auf 3600 setzen, bedeutet dies, dass, wenn Daten in der primären Datenbank versehentlich gelöscht werden und der fehlerhafte Operationsbefehl innerhalb einer Stunde entdeckt wird, der Befehl noch nicht in der Standbydatenbank mit verzögerter Replikation ausgeführt wurde. Führen Sie zu diesem Zeitpunkt Stopslave in der Standby-Datenbank aus und überspringen Sie dann mit der zuvor eingeführten Methode den fehlerhaften Operationsbefehl, um die erforderlichen Daten wiederherzustellen.

So löschen Sie Daten mit rm

Sofern nicht der gesamte Cluster böswillig gelöscht wird und nur die Daten eines der Knoten gelöscht werden, nimmt das HA-System seine Arbeit auf und wählt eine neue Masterdatenbank aus, um den normalen Betrieb des gesamten Clusters sicherzustellen. An diesem Punkt müssen Sie nur noch die Daten auf diesem Knoten wiederherstellen und ihn dann mit dem gesamten Cluster verbinden.

Natürlich verfügen mittlerweile nicht nur DBAs über automatisierte Systeme, sondern auch SAs (Systemadministratoren), sodass möglicherweise eine Operation, bei der Maschinen stapelweise offline genommen werden, alle Knoten in Ihrem gesamten MySQL-Cluster löscht. Um mit dieser Situation umzugehen, kann ich Ihnen nur raten, Ihre Backups über verschiedene Rechenzentren oder vorzugsweise über verschiedene Städte hinweg zu speichern. Kill-SQL-Anweisung

Beendet Sitzung B den Thread direkt und wird beendet, ohne etwas zu tun? Das wird offensichtlich nicht funktionieren.

Beim Hinzufügen, Löschen, Ändern oder Abfragen einer Tabelle wird der Tabelle eine MDL-Lesesperre hinzugefügt. Obwohl Sitzung B blockiert ist, verfügt sie daher noch immer über eine MDL-Lesesperre. Wenn der Thread beendet wird, wird er direkt beendet und die MDL-Lesesperre kann nicht mehr freigegeben werden.

Kill bedeutet nicht, sofort zu stoppen, sondern dem Ausführungsthread mitzuteilen, dass diese Anweisung nicht mehr ausgeführt werden muss und er die „Ausführungsstopplogik“ starten kann.

Tatsächlich führt der Thread, der den Kill-Befehl in MySQL verarbeitet, beim Ausführen der Kill-Abfrage thread_id_b Folgendes aus:

• Ändern Sie den Ausführungsstatus von Sitzung B in THD::KILL_QUERY
• Ein Signal wird an den Ausführungsthread von Sitzung B gesendet.

Denn in unserem Beispiel in Abbildung 1 befindet sich Sitzung B im Sperrwartezustand. Wenn wir den Thread-Status von Sitzung B einfach auf
THD::KILL_QUERY, Thread B ist sich dieser Statusänderung nicht bewusst und wartet weiter. Der Zweck des Sendens eines Signals besteht darin, Sitzung B aus dem Wartezustand zu veranlassen, um den Zustand THD::KILL_QUERY zu verarbeiten.

Das Obige hat drei Bedeutungen:

• Während der Ausführung einer Anweisung gibt es mehrere Einbettungspunkte. Der Thread-Status wird an diesen "Einbettungspunkten" bestimmt. Wenn der Thread-Status gefunden wird
• Es ist THD::KILL_QUERY, das die Anweisungsbeendigungslogik startet;
• Wenn es sich in einem Wartezustand befindet, muss es ein Wartezustand sein, der geweckt werden kann, sonst wird es überhaupt nicht bis zum "vergrabenen Punkt" ausgeführt.
• Es gibt einen Prozess vom Beginn einer Anweisung, die in die Beendigungslogik eintritt, bis zur Vervollständigung der Beendigungslogik.

Ein Beispiel für einen Kill

Führen Sie „set global innodb_thread_concurrency=2“ aus, um die Obergrenze gleichzeitiger InnoDB-Threads auf 2 festzulegen; führen Sie dann die folgende Sequenz aus:

Sie können sehen:

Sitzung C wurde während der Ausführung blockiert;

Der von Sitzung D ausgeführte Befehl „kill Query C“ hat jedoch keine Wirkung.

Erst wenn Sitzung E den Befehl „Kill Connection“ ausführt, wird die Verbindung zu Sitzung C getrennt und die Meldung „Verbindung zum MySQL-Server während der Abfrage verloren“ angezeigt.

Wenn Sie jetzt jedoch „show processlist“ in Sitzung E ausführen, wird das folgende Bild angezeigt:

Die Spalte „Commnad“ des Threads mit der ID=12 zeigt „Killed“ an. Mit anderen Worten: Obwohl die Verbindung zum Client getrennt ist, wird die Anweisung weiterhin auf dem Server ausgeführt.

In diesem Beispiel sieht die Wartelogik von Thread 12 folgendermaßen aus: Alle 10 Millisekunden wird geprüft, ob er in die InnoDB-Ausführung eintreten kann.
Wenn dies fehlschlägt, rufen Sie die Nanosleep-Funktion auf, um in den Ruhezustand zu wechseln.

Das heißt, obwohl der Status von Thread 12 auf KILL_QUERY gesetzt wurde, wird der Status des Threads während der Schleife, in der auf den Eintritt in InnoDB gewartet wird, nicht beurteilt, sodass die Phase der Beendigungslogik überhaupt nicht betreten wird.

Wenn Sitzung E den Befehl „Kill Connection“ ausführt, geschieht Folgendes:

• Setzen Sie den Status von Thread 12 auf KILL_CONNECTION;
• Schließen Sie die Netzwerkverbindung von Thread 12. Aufgrund dieses Vorgangs sehen Sie, dass Sitzung C eine Aufforderung zur Trennung erhält.

Warum wird die Spalte „Befehl“ beim Ausführen von „show processlist“ als „beendet“ angezeigt? Tatsächlich liegt dies daran, dass bei der Ausführung von show processlist eine spezielle Logik gilt:

Wenn der Status eines Threads KILL_CONNECTION ist, wird in der Spalte „Befehl“ „Killed“ angezeigt.

Auch wenn der Client beendet wird, ist der Status dieses Threads also immer noch „Warten“. Nur wenn die Bedingungen zum Aufrufen von InnoDB erfüllt sind und die Abfrageanweisung der Sitzung C weiterhin ausgeführt wird, kann festgestellt werden, dass der Thread-Status KILL_QUERY oder KILL_CONNECTION geworden ist, und dann kann in die Phase der Beendigungslogik eingetreten werden.

Der erste Typ von Situation, in der „Kill“ ungültig ist, liegt vor, wenn der Thread die Logik zur Bestimmung des Thread-Status nicht ausführt. Es ist auch möglich, dass die Lese- und Schreib-E/A-Funktionen aufgrund übermäßigen E/A-Drucks nicht zurückkehren können, was dazu führt, dass der Thread-Status nicht rechtzeitig bestimmt werden kann.

• Im zweiten Fall dauert die Beendigungslogik lange
• Eine sehr große Transaktion wurde während der Ausführung abgebrochen und der Rollback-Vorgang dauerte lange.
• Bei umfangreichen Rollvorgängen, wie z. B. bei der Generierung großer temporärer Dateien während des Abfragevorgangs, muss darauf gewartet werden, dass die IO-Ressourcen die temporären Dateien löschen. Dies ist sehr zeitaufwändig.
• Wenn der DDL bis zur letzten Phase ausgeführt und beendet wird, müssen temporäre Dateien im mittleren Prozess gelöscht werden, was ebenfalls IO-Ressourcen erfordert.

Strg+C, MySQL startet tatsächlich einen Verbindungsprozess und sendet den Befehl „Kill Query“.

Missverständnisse über langsame Clientverbindungen

Wenn die Datenbank viele Tabellen enthält, ist die Verbindung langsam. Wenn beispielsweise eine Bibliothek mit Zehntausenden von Tabellen vorhanden ist, stellt MySQL bei der Verbindung mit Standardparametern eine Funktion zur Vervollständigung des lokalen Bibliotheksnamens und des Tabellennamens bereit:

• Ausführen von „show databases“
• Wechseln Sie zu db1 und führen Sie „show tables“ aus.
• Die Ergebnisse dieser beiden Befehle werden zum Erstellen einer lokalen Hash-Tabelle verwendet.

Der dritte Schritt ist ein zeitaufwändiger Vorgang, was bedeutet, dass die von uns wahrgenommene Langsamkeit nicht auf eine vollständige Verbindung oder einen langsamen Server, sondern auf einen langsamen Client zurückzuführen ist. Wenn Sie diesem Link -A hinzufügen, können Sie die Autovervollständigungsfunktion abbrechen und schnell zurückkehren.

Die automatische Vervollständigung bewirkt, dass bei der Eingabe eines Bibliotheks- oder Tabellennamens das Präfix eingegeben wird und Sie mit der Tabulatortaste automatisch vervollständigen oder eine Eingabeaufforderung anzeigen können. Wenn Sie die automatische Vervollständigung nicht sehr oft verwenden, können Sie bei jeder Verwendung -A hinzufügen.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.