Detaillierte Erläuterung von Beispielen für mysqldump

Einige Produktionsumgebungen verwenden mysqldump --single-transaction, um nachts eine Datenbanksicherung durchzuführen, und ein Kollege hat während des Sicherungszeitraums zufällig einen Änderungstabellenvorgang durchgeführt. Warum?

Der Test wurde auf MySQL 5.6.36 durchgeführt, es gibt einen Versionsunterschied für dieses Problem!

##====================================== === ===============================##

Erklärung des Einzeltransaktionsparameters in mysqldump Für:

Creates a consistent snapshot by dumping all tables in a
single transaction. Works ONLY for tables stored in
storage engines which support multiversioning (currently
only InnoDB does); the dump is NOT guaranteed to be
consistent for other storage engines.
 While a
--single-transaction dump is in process, to ensure a
valid dump file (correct table contents and binary log
position), no other connection should use the following
statements: ALTER TABLE, DROP TABLE, RENAME TABLE,
TRUNCATE TABLE, as consistent snapshot is not isolated
from them.
 Option automatically turns off --lock-tables.

Der rote Schriftteil ist der entscheidende Punkt, aber er ist etwas verwirrend zu sehen, also probiere ich ihn besser aus.

Gemäß der Einführung von „Exploration of Multiple Main Options of Mysqldump“ entspricht der Befehl mysqldump --single-transaction --master-data, den wir für die Sicherung ausführen, der Ausführung des folgenden Codes:

FLUSH TABLES;
FLUSH TABLES WITH READ LOCK;SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION WITH CONSISTENT SNAPSHOT;
SHOW MASTER STATUS;
UNLOCK TABLES;

SHOW TABLES LIKE 'xxx'SET OPTION SQL_QUOTE_SHOW_CREATE=1SHWO CREATE TABLE 'xxx'SHOW FIELDS FROM 'xxx'SHOW TABLE STATUS LIKE 'xxx'SELECT /*!40001 SQL_NO_CACHE */ * FROM  xxx

QUIT

Szenario 1: Wenn mysqldump gestartet, aber nicht in Tabelle tb001 gesichert wurde, führt eine andere Sitzung eine Änderungsoperation für Tabelle tb001 durch und dann exportiert mysqldump die Tabelle tb001

Der Änderungsvorgang wurde erfolgreich abgeschlossen, aber der mysqldump-Vorgang ist fehlgeschlagen.

Szenario 2: mysqldump startet die Sicherung und schließt den Export von tb001 ab. Während des Exports anderer Tabellen führen andere Sitzungen Änderungsvorgänge für die Tabellen aus

Der Vorgang „Tabelle ändern“ wird blockiert, bis mysqldump abgeschlossen ist oder nach einem Fehler beendet wird.

Wenn Sie mysqldump zum Sichern verwenden und die Umgebung von Szenario 2 simulieren, lautet die Fehlermeldung:

mysqldump: Fehler 1412: Tabellendefinition wurde geändert, bitte wiederholen Sie die Transaktion beim Ausgeben der Tabelle „tb1002“ in Zeile: 0

Sehen Sie sich die Exportdatei an, der endgültige Inhalt ist:

--
-- Dumping data for table `tb1002`--LOCK TABLES `tb1002` WRITE;/*!40000 ALTER TABLE `tb1002` DISABLE KEYS */;

Zusammenfassung:

Einzeltransaktionsparameter Die Datenkonsistenz wird durch mehrere Versionen von Innodb erreicht, aber Vorgänge wie ALTER TABLE, DROP TABLE, RENAME TABLE und TRUNCATE TABLE zerstören die Datenkonsistenz und die beiden Vorgänge können nicht gleichzeitig ausgeführt werden.

Wenn der Tabellenänderungsvorgang innerhalb des Zeitraums „nach dem Öffnen von mysqldump, aber vor dem Exportieren der Änderungstabellendaten“ beginnt, wird der Tabellenänderungsvorgang erfolgreich abgeschlossen, aber mysqldump schlägt fehl; Wenn der Tabellenänderungsvorgang innerhalb des Zeitraums beginnt, in dem „mysqldum die Änderungstabellendaten exportiert, aber den mysqldump-Vorgang noch nicht abgeschlossen hat“, wird der Tabellenänderungsvorgang blockiert und mysqldum kann ihn erfolgreich abschließen. Der Tabellenänderungsvorgang kann ausgeführt werden Normalerweise erst, nachdem der mysqldump-Vorgang abgeschlossen ist.

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung von Beispielen für mysqldump. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Erklärung dieser Website

Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn