MySQL-Schnellwiederherstellungslösung basierend auf dem Zeitpunkt

Der Grund für das Schreiben dieses Artikels ist, dass ich vor ein paar Tagen eines Nachts, als ich gerade Feierabend machen wollte, plötzlich von der Geschäftsseite die Daten in einer Tabelle wiederherstellen musste. Ich fragte nach der damaligen Situation und sie war ungefähr so: Die Geschäftsseite führte versehentlich eine Aktualisierungsoperation in einer Tabelle aus. Vielleicht war die Where-Bedingung nicht richtig geschrieben, was dazu führte, dass die Daten in der Tabelle beschädigt wurden. Die Daten wurden jedoch noch nicht auf die Festplatte geschrieben, nur der Wert im Speicher wurde geändert und jetzt müssen die vorherigen Daten wiederhergestellt werden. Glücklicherweise handelt es sich bei diesen Daten um die Preise bestimmter Produkte auf der Plattform. Grundsätzlich gibt es eine begrenzte Anzahl von Produkten und die Preiswerte sind alle fest. Diese Preisliste wurde zuvor gesichert, sodass die Daten einer neuen Kopie der Preisliste direkt für ihn importiert wurden und dieses Problem gelöst wurde.

Damals habe ich überlegt: Wenn ich kein Backup, sondern nur ein Binärprotokoll habe und dieses Problem beheben muss, gibt es dann eine bessere Möglichkeit? Erstellen Sie eine neue Instanz, stellen Sie die gesamte Datenbank wieder her und wenden Sie dann das gesicherte Binärprotokoll an, wobei Sie es bis zu dem Zeitpunkt zurückverfolgen, als die Daten beschädigt wurden.

Verwenden Sie das Tool mysqlbinlog, um Transaktionen wiederzugeben. Diese Methode birgt viele Fallstricke, wie zum Beispiel:

1. Sie können jeweils nur einen mysqlbinlog-Befehl ausführen, um jeweils eine Binlog-Datei wiederzugeben. Sie können nicht mehrere Befehle parallel ausführen, da beim Wiedergeben eine temporäre Tabelle generiert wird, was zu Konflikten und Fehlern führt.

2. Es ist eine atomare Operation. Wenn der Vorgang mittendrin abbricht, lässt sich nur schwer feststellen, wo der Fehler aufgetreten ist, und es ist schwierig, den Vorgang von einem früheren Zeitpunkt aus neu zu starten. Es gibt viele Gründe für einen Fehler: Wartezeitüberschreitung der InnoDB-Sperre aufgrund einiger gleichzeitiger Transaktionen, unterschiedliche Max_Allowed_Packet-Einstellungen von Server und Client, Verbindungsverlust mit dem MySQL-Server während der Abfrage usw.

Also habe ich Perconas Blog durchgeblättert, eine Methode gefunden, das Wesentliche gelesen und sie grob aufgezeichnet. Ich habe diese Methode noch nicht selbst implementiert, sondern nur hier aufgezeichnet. Wenn ich in Zukunft Zeit habe, kann ich es selbst ausprobieren, um zu sehen, ob ich dieses Problem effizienter lösen kann.

Die allgemeine Idee ist wie folgt:

Zwei zusätzliche Maschinen, die erste wird zum Wiederherstellen der Sicherungsergebnisdaten verwendet, und die andere wird verwendet, um das Binlog des ursprünglichen Masters auf die Instanz zu kopieren und dann den ursprünglichen Master zu simulieren. Dann stellen die erste und die zweite Maschine eine Master-Slave-Beziehung her, ändern den Master auf die zweite Maschine, positionieren das Sicherungsergebnis (Binlog-Name und -Position in xtrabackup_binlog_info), synchronisieren dann mit dem Fehlerbetriebspunkt, exportieren die wiederhergestellte Tabelle und stellen sie dann auf dem ursprünglichen Produktionsmaster wieder her.

Die einzelnen Schritte sind wie folgt:

1. Bereiten Sie eine Maschine vor, um die neuesten Sicherungsergebnisdaten der Instanz zu sichern und wiederherzustellen.

2. Bereiten Sie eine andere Maschine, eine neue Instanz vor, kopieren Sie die Binärprotokolldatei des ursprünglichen Masters in das Datenverzeichnis der Instanz, starten Sie eine leere Instanz (Server-ID ist dieselbe wie die des ursprünglichen Masters, --log_bin=Master-bin – der Name der Binärprotokolldatei bleibt derselbe wie beim ursprünglichen Master;), stoppen Sie sie dann, löschen Sie alle automatisch erstellten Binärprotokolle, dekomprimieren und kopieren Sie alle erforderlichen Binärprotokolle (von der ursprünglichen Produktionsinstanz) in ihr Datenverzeichnis und starten Sie sie dann neu.

Der Speicherort der neuesten Sicherungsdaten:

Wenn der Start normal ist, stellen Sie eine Verbindung zu MySQL her und zeigen Sie die Binärprotokollinformationen an:

3. Stellen Sie eine Synchronisationsbeziehung her und stoppen Sie vor der Position der falschen Operation

 ÄNDERN SIE MASTER IN 

MASTER_HOST='127.0.0.1',

MASTER_PORT=3307,

MASTER_USER='root',

MASTER_PASSWORD='geheim',

MASTER_LOG_FILE='master-bin.000007', MASTER_LOG_POS=1518932;

SLAVE STARTEN BIS 

MASTER_LOG_FILE = 'Protokollname', 

MASTER_LOG_POS = log_pos

oder

STARTEN SIE SLAVE SQL_THREAD BIS

 SQL_AFTER_GTIDS =

 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56

SLAVE-STATUS ANZEIGEN;

Dies entspricht der Verwendung einer weiteren Instanz, wodurch die Nutzungsrate der Binärprotokolle und die Erfolgsrate der Binärprotokollnutzung erhöht werden. Ob diese Methode praktikabel ist, muss noch überprüft werden. Nach der vom Autor im Artikel beschriebenen Idee ist sie besser als die Methode, Binlog auf einer einzelnen Instanz anzuwenden, da, sobald beim Anwenden von Binlog ein Fehler auftritt, schnell der Punkt ermittelt werden kann, an dem der Fehler aufgetreten ist, was uns hilft, das Problem schnell zu lösen.

Oben finden Sie Einzelheiten zur zeitbasierten Schnellwiederherstellungslösung von MySQL. Weitere Informationen zur schnellen MySQL-Wiederherstellung finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!