So kopieren Sie eine MySQL-Tabelle

1.mysqldump

Ausführungsprozess:

1. Exportieren Sie die Daten als SQL-Datei.

mysqldump -h$host -P$port -u$user --add-locks=0 --no-create-info --single-transaction --set-gtid-purged=OFF db1 t --where="a>900" --result-file=/client_tmp/t.sql

Exportieren Sie die Daten in eine SQL-Datei und speichern Sie sie. Die Bedeutungen der obigen Parameter sind:

1. Die Funktion von –single-transaction besteht darin, dass beim Exportieren von Daten die Tabelle db1.t nicht gesperrt werden muss, sondern die Methode START TRANSACTION WITH CONSISTENT SNAPSHOT verwendet werden kann.

2. –add-locks ist auf 0 gesetzt, was bedeutet, dass „LOCK TABLES t WRITE;“ nicht zum Ausgabedateiergebnis hinzugefügt wird;

3. –no-create-info bedeutet, dass die Tabellenstruktur nicht exportiert werden muss;

4. –set-gtid-purged=off bedeutet, dass keine GTID-bezogenen Informationen ausgegeben werden;

5. –result-file gibt den Pfad der Ausgabedatei an, wobei „Client“ bedeutet, dass sich die generierte Datei auf dem Client-Computer befindet.

2. Führen Sie die Datei aus und fügen Sie sie der Tabelle hinzu

mysql -h127.0.0.1 -P13000 -uroot db2 -e "Quelle /client_tmp/t.sql"

Quelle ist keine SQL-Anweisung, sondern ein Client-Befehl. Das heißt, der Server führt die SQL-Anweisungen in der Datei nacheinander aus, sodass das Binärprotokoll das spezifische SQL aufzeichnet.

Merkmale

1. Die generierte SQL-Datei wird auf dem Client gespeichert

2. Die Standardmethode zum Speichern von Daten sind mehrere Datensatzpaare, wie im folgenden Format dargestellt

Wenn Sie nur einen Datensatz als eine Anweisung speichern möchten, können Sie den Parameter –skip-extended-insert hinzufügen.

2. CSV-Datei exportieren (am flexibelsten)

Ausführungsprozess

1. In CSV-Datei exportieren

Wählen Sie * aus db1.t, wobei a>900 in die Ausgabedatei „/server_tmp/t.csv“;

Beachten:

1. „into outfile“ gibt den Speicherort an, an dem die Datei generiert wird (/server_tmp/), der durch den Parameter „secure_file_priv“ eingeschränkt werden muss.

Die optionalen Werte und Funktionen des Parameters secure_file_priv sind:

1) Wenn es auf leer gesetzt ist, bedeutet dies, dass es keine Beschränkung für den Speicherort gibt, an dem die Datei generiert wird. Dies ist eine unsichere Einstellung.

2) Wenn es auf eine Zeichenfolge gesetzt ist, die einen Pfad darstellt, kann die generierte Datei nur im angegebenen Verzeichnis oder dessen Unterverzeichnis abgelegt werden.

3) Wenn der Wert auf NULL gesetzt ist, bedeutet dies, dass die Operation „Select ... into outfile“ auf dieser MySQL-Instanz verboten ist.

2. Wenn sich im selben Verzeichnis eine Datei mit demselben Namen befindet, wird ein Fehler gemeldet

3. Im Allgemeinen entspricht ein Datensatz einer Zeile in einer CSV-Datei. Wenn ein Feldwert jedoch „Newline- oder Tabulatorzeichen“ enthält, wird dieser ebenfalls in die Datei aufgenommen und mit „\“ maskiert.

2. Daten importieren

Daten aus der Datei „/server_tmp/t.csv“ in die Tabelle db2.t laden;

Verfahren:

1. Öffnen Sie die Datei /server_tmp/t.csv, verwenden Sie das Tabulatorzeichen (\t) als Trennzeichen zwischen Feldern und das Zeilenvorschubzeichen (\n) als Trennzeichen zwischen Datensätzen und lesen Sie die Daten;

2. Starten Sie die Transaktion.

3. Bestimmen Sie, ob die Anzahl der Felder in jeder Zeile mit der Anzahl in der Tabelle db2.t übereinstimmt:

1) Wenn sie unterschiedlich sind, wird direkt ein Fehler gemeldet und die Transaktion zurückgesetzt.

2) Wenn sie gleich sind, konstruieren Sie eine Zeile, rufen Sie die Schnittstelle der InnoDB-Engine auf und schreiben Sie sie in die Tabelle.

4. Wiederholen Sie Schritt 3, bis die gesamte Datei /server_tmp/t.csv eingelesen ist, und bestätigen Sie die Transaktion.

Merkmale

1. Die Datei wird auf dem Server gespeichert

2. Bezüglich Binlog-Datensätzen ist der Prozess wie folgt:

1) Nachdem die Hauptdatenbank ausgeführt wurde, wird der Inhalt der Datei /server_tmp/t.csv direkt in die Binlog-Datei geschrieben.

2) Schreiben Sie die Anweisung „load data local infile '/tmp/SQL_LOAD_MB-1-0' INTO TABLE `db2`.`t`“ in die Binlog-Datei.

3) Übertragen Sie das Binärprotokoll in die Standby-Datenbank.

4) Wenn der Apply-Thread der Standby-Datenbank dieses Transaktionsprotokoll ausführt:

a. Lesen Sie zunächst den Inhalt der Datei t.csv im Binärprotokoll und schreiben Sie ihn in das lokale temporäre Verzeichnis /tmp/SQL_LOAD_MB-1-0.

b. Führen Sie die Anweisung „Load Data“ erneut aus, um dieselben Daten wie in der Primärdatenbank in die Tabelle db2.t der Standbydatenbank einzufügen.

Über "lokal":

1) Ohne „local“ wird die serverseitige Datei gelesen. Diese Datei muss sich im durch secure_file_priv angegebenen Verzeichnis oder Unterverzeichnis befinden;

2) Fügen Sie „local“ hinzu, um die Datei des Clients zu lesen, solange der MySQL-Client über die Berechtigung zum Zugriff auf die Datei verfügt. Zu diesem Zeitpunkt überträgt der MySQL-Client zuerst die lokale Datei auf den Server (Vorgänge, die an anderen Sitzungen beteiligt sind) und führt dann den oben genannten Datenladevorgang aus.

3. Der obige Exportvorgang exportiert nicht die Tabellenstruktur. Wenn Sie also die Tabellenstruktur exportieren möchten, können Sie mysqldump verwenden, um CSV und Tabellenstruktur gleichzeitig zu exportieren.

mysqldump -h$host -P$port -u$user --single-transaction --set-gtid-purged=OFF db1 t --where="a>900" --tab=$secure_file_priv

Zum Speichern der Anweisung zur Tabellenerstellung wird eine t.sql-Datei im durch „$secure_file_priv“ definierten Verzeichnis erstellt. Zum Speichern der CSV-Daten wird eine t.txt-Datei erstellt.

3. Physische Kopie (am schnellsten)

Vor 5.6 ist es nicht möglich, die .frm- und .ibd-Dateien direkt in das gewünschte Verzeichnis zu kopieren, da zusätzlich zu diesen beiden Dateien eine Innodb-Tabelle im Datenwörterbuch registriert werden muss. Dieses Problem kann jedoch ab 5.6 gelöst werden. In 5.6 wurde transportierbarer Speicherplatz eingeführt und das Kopieren kann durch Exportieren + Importieren von Tablespaces erreicht werden.

Verfahren

Angenommen, unser aktuelles Ziel besteht darin, eine Tabelle r zu kopieren, die mit der Tabelle t in der Datenbank db1 identisch ist. Die spezifischen Ausführungsschritte sind wie folgt:

1. Führen Sie „create table r like t“ aus, um eine leere Tabelle mit derselben Tabellenstruktur zu erstellen.

2. Führen Sie „alter table r discard tablespace“ aus. Die Datei r.ibd wird gelöscht.

3. Führen Sie zum Exportieren das Leeren der Tabelle t aus. Im Verzeichnis db1 wird eine Datei t.cfg generiert.

4. Führen Sie die folgenden Befehle im Verzeichnis db1 aus: cp t.cfg r.cfg; cp t.ibd r.ibd. (Beachten Sie, dass der MySQL-Prozess Lese- und Schreibberechtigungen für die beiden kopierten Dateien haben muss.)

5. Führen Sie „Entsperren der Tabellen“ aus, und die Datei t.cfg wird gelöscht.

6. Führen Sie „alter table r import tablespace“ aus und verwenden Sie die Datei r.ibd als neuen Tablespace für Tabelle r. Da der Dateninhalt dieser Datei mit dem von t.ibd identisch ist, enthält Tabelle r dieselben Daten wie Tabelle t.

Beachten:

1. Nachdem Sie den Befehl „flsuh table“ in Schritt 3 ausgeführt haben, befindet sich die gesamte Tabelle db1.t im schreibgeschützten Zustand, bis der Befehl „unlock tables“ ausgeführt wird.

2. Beim Ausführen des Import-Tablespace wird die Tablespace-ID von r.ibd so geändert, dass die Tablespace-ID in der Datei mit der im Datenwörterbuch übereinstimmt. Und diese Tabellenbereichs-ID existiert auf jeder Datenseite. Wenn es sich also um eine sehr große Datei handelt (z. B. auf TB-Ebene), muss jede Datenseite geändert werden. Sie werden daher feststellen, dass die Ausführung dieser Importanweisung einige Zeit in Anspruch nimmt. Natürlich nimmt die Importanweisung im Vergleich zur logischen Importmethode sehr wenig Zeit in Anspruch.

Einschränkungen

1. Die gesamte Tabelle muss kopiert werden, keine bedingte Kopie

2. Daten müssen auf den Server kopiert werden. Kann nicht verwendet werden, wenn sich der Benutzer nicht beim Datenbankhost anmelden kann

3. Da es durch das Kopieren physischer Dateien implementiert wird, kann es nur verwendet werden, wenn sowohl die Quelltabelle als auch die Zieltabelle die InnoDB-Engine verwenden.

Zusammenfassen

1. Bei den ersten beiden handelt es sich um logische Backups, das heißt, sie können Engine-übergreifend verwendet werden, beim letzten hingegen nicht.

2. Die ersten beiden können bedingt kopiert werden, die letzte jedoch nicht

3. Die zweite Funktion ist die flexibelste, aber sie ist zeitaufwändig, wenn der Cluster Daten aus der Bibliothek empfängt (die CSV-Dateidaten müssen zuerst in eine lokale temporäre Datei kopiert werden). Die letzte hat die höchste Ausführungseffizienz, kann aber nicht Engines übergreifend ausgeführt werden und kann nur vollständige Kopien erstellen.

Oben finden Sie Einzelheiten zum Kopieren von MySQL-Tabellen. Weitere Informationen zum Kopieren von MySQL-Tabellen finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!