Datenübertragung

Die Datenübertragung kopiert Tabellen, Sichten, Prozeduren und Funktionen von einer Datenbank in eine andere — auch zwischen verschiedenen Systemen. Von MySQL nach PostgreSQL, von SQLite nach SQL Server, von der Produktion in eine lokale Kopie.

Öffnen Sie sie über Werkzeuge → Data Transfer oder per Rechtsklick auf eine Datenbank und Data Transfer.

Der Assistent

1. Quelle und Ziel

Wählen Sie auf beiden Seiten Verbindung und Datenbank. NabuSQL zeigt für beide Verbindungstyp, Name, Host, Port und Serverversion, damit Sie bestätigen können, dass Sie dorthin zielen, wo Sie glauben.

2. Objekte auswählen

Der Objektbaum gruppiert alles in Tabellen, Sichten und Funktionen / Prozeduren. Haken Sie an, was mitsoll.

Markieren Sie eine einzelne Tabelle, um sie gesondert einzustellen: ihr Zielobjekt und den Modus — Auto (Struktur und Datensätze) oder Nur DDL (Struktur ohne Daten).

3. Optionen

Tabellenoptionen

Option	Wirkung
Tabellen erstellen	Legt die Zieltabellen an. Aus, wenn sie schon existieren
Indizes einbeziehen	Legt Indizes neu an
Standardwerte einbeziehen	Übernimmt Spaltenstandardwerte
Fremdschlüssel einbeziehen	Legt FK-Constraints neu an
Engine/Tabellentyp einbeziehen	MySQL-Engine, z. B. InnoDB
Zeichensatz einbeziehen	Übernimmt den Zeichensatz
Auto Increment einbeziehen	Behält Auto-Increment-Spalten
Trigger einbeziehen	Kopiert die Trigger der ausgewählten Tabellen — nur bei gleicher Engine, siehe unten
Zielobjekte vor dem Erstellen löschen	Löscht vorher, was da ist
DEFINER an Zielbenutzer anpassen	Schreibt den DEFINER kopierter Sichten, Routinen und Trigger auf das Konto um, unter dem die Übertragung läuft. Standardmäßig an

Datensatzoptionen

Option	Wirkung
Datensätze erstellen	Kopiert die Zeilen, nicht nur die Struktur
Transaktion verwenden	Klammert die Übertragung, ein Fehler rollt alles zurück
Erweiterte INSERT-Anweisungen verwenden	Mehrzeilige INSERTs — deutlich schneller
Bei Fehler fortfahren	Geht über fehlerhafte Zeilen hinweg, statt anzuhalten
Stapelgröße	Zeilen je Stapel

Sonstiges

• Zieldatenbank anlegen, falls nicht vorhanden — erstellt sie, wenn sie fehlt.

4. Ausführen

Der Fortschritt wird je Phase — Schema anlegen, dann kopieren — und je Objekt angezeigt. Das Ergebnis lautet Übertragung abgeschlossen, Mit Fehlern abgeschlossen samt Liste, oder es gibt einen Fehler.

Trigger

Trigger einbeziehen nimmt die Trigger mit, die an den ausgewählten Tabellen hängen — eine eigene Trigger-Gruppe in Schritt 2 gibt es nicht. Zwei Dinge sind wichtig:

• Sie entstehen nach dem Kopieren der Zeilen, als letzte Phase der Tabelle. Vor der Insert-Schleife angelegt, würden sie einmal pro kopierter Zeile feuern und die Daten still verfälschen, statt zu scheitern.
• Nur bei gleicher Engine. Ein Trigger-Rumpf lässt sich nicht zwischen Dialekten übersetzen, deshalb werden Trigger bei einer Übertragung zwischen verschiedenen Engines übersprungen — ohne Fehler und ohne die Übertragung abzubrechen.

DEFINER

MySQL und MariaDB stempeln jede Sicht, Prozedur, Funktion und jeden Trigger mit DEFINER=`benutzer`@`host`, und dieses Konto muss auf dem Zielserver existieren. Kopieren Sie eine Sicht von root@localhost auf einen Server, auf dem Sie als web@% angemeldet sind, dann lässt sie sich entweder nicht anlegen oder sie bricht beim ersten Zugriff.

DEFINER an Zielbenutzer anpassen — standardmäßig an — schreibt den DEFINER jeder kopierten Sicht, Routine und jedes Triggers auf das Konto um, mit dem die Übertragung auf der Zielseite verbunden ist. Lässt sich dieses Konto nicht ermitteln, entfällt die Klausel stattdessen und der Server füllt sie selbst.

Schalten Sie die Option aus, um die Definer wörtlich zu übernehmen — das wollen Sie, wenn Sie einen Server spiegeln, dessen Konten auf beiden Seiten übereinstimmen.

Profile

Profil speichern sichert die gesamte Konfiguration — Quelle, Ziel, Objektauswahl und Optionen. Profil laden holt sie zurück. Lohnt sich für jede Übertragung, die Sie mehr als einmal fahren, etwa das Auffrischen einer Entwicklungsdatenbank aus der Produktion.

Systemwechsel: dies nutzen, keinen Dump

Ein Dump — aus Sicherung und Wiederherstellung oder von mysqldump — ist im SQL des Quellsystems geschrieben und dafür gedacht, auf derselben Art Server wiederhergestellt zu werden. Ihn auf ein anderes System loszulassen scheitert schon an der ersten Anweisung, und die Gründe sind nicht oberflächlich:

• Bezeichner sind auf die Art des Systems gequotet. MySQL-Backticks sind überall sonst ein Syntaxfehler, und sie stehen an jeder Tabelle und jeder Spalte der Datei.
• Typen passen nicht zusammen — int(11), datetime, longtext, eingebettetes ENUM(...).
• Ganze Konstrukte haben kein Gegenstück — AUTO_INCREMENT, ENGINE=InnoDB, DEFAULT CHARSET, KEY-Definitionen innerhalb von CREATE TABLE, LOCK TABLES.
• Das Escaping von Zeichenketten unterscheidet sich. MySQL maskiert ein Anführungszeichen als \'; PostgreSQL liest den Backslash wörtlich, die Zeichenkette endet also zu früh. Das ist der einzige der vier Punkte, der Daten verfälscht statt lautstark zu scheitern, und damit der schlimmste.

Die Datenübertragung umgeht all das, weil sie nie SQL-Text bewegt. Sie liest das Quellschema, erzeugt das DDL für den Ziel-Dialekt neu und kopiert die Zeilen über den Treiber, wobei die Werte als Parameter übergeben und nicht in Anweisungen eingefügt werden.

Als Faustregel:

	Nutzen Sie
Gleiches System, oder mit einer Datei dazwischen	Sicherung und Wiederherstellung
Anderes System	Datenübertragung

Hinweise zu Systemwechseln

Ein Wechsel zwischen Systemen bedeutet, dass Typen abgebildet und nicht kopiert werden. Prüfen Sie das Ergebnis, wenn die Quelle systemspezifische Typen nutzt — MySQL ENUM, PostgreSQL-Arrays, SQL Server UNIQUEIDENTIFIER.

Prozeduren und Funktionen werden als Quelltext kopiert. SQL-Dialekte unterscheiden sich, eine auf MySQL laufende Routine braucht nach der Landung auf PostgreSQL also oft Nacharbeit. Tabellen und Sichten sind der Teil, der sauber reist.

Fangen Sie mit einem Trockenlauf an

Wählen Sie für eine erste Übertragung zwischen unbekannten Servern eine Tabelle, setzen Sie Nur DDL und starten Sie. Sie sehen, wie die Typen abgebildet werden, bevor Sie sich auf eine vollständige Kopie festlegen.

Zwischen MySQL und MariaDB

Beide teilen sich einen Dialekt, Spaltentypen reisen daher normalerweise genau so, wie sie deklariert sind. Die Ausnahme ist ein Typ, den die Zielversion nicht kennt — meist neuere MariaDB-Typen auf dem Weg zu MySQL oder zu einer älteren MariaDB. Solche Spalten werden als einfacher Typ angelegt, der dieselben Werte aufnimmt, und die Vorschau weist darauf hin, bevor irgendetwas läuft:

Typ in der Quelle	Auf einem Ziel ohne diesen Typ
UUID	CHAR(36)
INET4	VARCHAR(15)
INET6	VARCHAR(45)
VECTOR(n)	VARBINARY(4·n) — dieselben Bytes
XMLTYPE	LONGTEXT
JSON (MySQL vor 5.7.8, MariaDB vor 10.2.7)	LONGTEXT

Was das Ziel kennt, wird anhand seiner tatsächlichen Version entschieden — nach denselben Regeln wie die Typliste — und funktioniert daher auch, wenn ein MariaDB-Server als MySQL-Verbindung gespeichert wurde.

Verwandtes

• Sicherung und Wiederherstellung — derselbe Server, mit einer Datei dazwischen.
• Struktur und Daten vergleichen — prüfen, ob beide Seiten übereinstimmen.