Best Practices zum Importieren und Exportieren von Daten

Auf dieser Seite finden Sie Best Practices zum Importieren und Exportieren von Daten mit Cloud SQL. Eine Schritt-für-Schritt-Anleitung zum Importieren von Daten in Cloud SQL finden Sie unter Daten importieren.

Informationen zum Exportieren von Daten aus Cloud SQL zur Verwendung in einer von Ihnen verwalteten MySQL-Instanz finden Sie unter Mithilfe von SQL-Dumpdateien exportieren und importieren oder Mithilfe von CSV-Dateien exportieren und importieren.

Best Practices für den Import und Export

Die folgenden Best Practices sollten beim Importieren und Exportieren von Daten berücksichtigt werden:

Denselben SQL-Modus für Import und Export verwenden

Die Einstellung "SQL-Modus" wirkt sich darauf aus, wie Cloud SQL SQL-Abfragen interpretiert. Wenn Sie beispielsweise Daten aus einer Datenbank exportieren, in der Strict SQL nicht aktiviert ist, und diese dann nach Cloud SQL importieren möchten, wo Strict SQL standardmäßig aktiviert ist, kann der Import fehlschlagen. Es empfiehlt sich, beim Import denselben SQL-Modus zu verwenden, den Sie für den Export verwendet haben.

Prüfen Sie den SQL-Modus der Quell- und der Zieldatenbank auf deren Kompatibilität. Achten Sie dabei besonders auf die Flags, die den Strict SQL-Modus aktivieren. Wenn Strict SQL NICHT für Ihre Datenbank festgelegt ist, sollten Sie das Flag in Cloud SQL entfernen. Wenn Sie Strict SQL entfernen, müssen Sie ein anderes Flag festlegen.

Wenn Sie prüfen möchten, ob für Ihre Cloud SQL-Instanz der gewünschte Modus festgelegt ist, führen Sie SELECT @@GLOBAL.sql_mode; aus.

Keine Cloud Storage-Buckets "Anforderer bezahlt" verwenden

Sie können keinen Cloud Storage-Bucket verwenden, für den Anforderer bezahlt für Importe und Exporte aus Cloud SQL aktiviert ist.

Mit serverlosem Export den Exportvorgang von der primären Instanz auslagern

Bei einem Standardexport aus Cloud SQL wird der Export ausgeführt, während die Datenbank online ist. Wenn die zu exportierenden Datenbanken kleiner sind, ist die Auswirkung wahrscheinlich minimal. Falls Datenbanken jedoch groß sind oder große Objekte wie BLOBs enthalten, besteht die Möglichkeit, dass der Export die Datenbankleistung beeinträchtigt. Dies kann sich auf die Dauer von Datenbankabfragen und -vorgängen auswirken, die für die Datenbank ausgeführt werden. Sobald Sie einen Export gestartet haben, kann er nicht mehr abgebrochen werden, wenn die Datenbank langsam reagiert.

Mit dem serverlosen Export können Sie langsame Antworten während eines Exports vermeiden. Beim serverlosen Export erstellt Cloud SQL eine separate temporäre Instanz, um den Exportvorgang auszulagern. Damit können Datenbanken auf der primären Instanz weiterhin Abfragen verarbeiten und Vorgänge mit der üblichen Leistungsrate ausführen. Wenn der Datenexport abgeschlossen ist, wird die temporäre Instanz automatisch gelöscht.

Verwenden Sie die gcloud- oder Rest API Exportfunktionen mit dem Flag offload, um einen serverlosen Exportvorgang auszuführen.

Während eines serverlosen Exportvorgangs können Sie verschiedene andere Vorgänge ausführen, z. B. Instanzbearbeitung, Import und Failover. Wenn Sie allerdings delete auswählen, wird der Exportvorgang einige Zeit nach dem Löschen der Instanz beendet und es werden keine Daten exportiert.

Ein serverloser Export dauert länger als ein Standardexport, da das Erstellen der temporären Instanz einige Zeit in Anspruch nimmt. Er kann mindestens fünf Minuten länger dauern, bei größeren Datenbanken allerdings noch länger. Berücksichtigen Sie die Auswirkungen auf Zeit und Leistung, bevor Sie den zu verwendenden Exporttyp bestimmen.

Sie können den serverlosen Export auf einer primären Instanz oder einem Lesereplikat ausführen.

Beim Erstellen einer SQL-Dumpdatei die korrekten Flags verwenden

Wenn Sie beim Exportieren Ihrer Daten in eine SQL-Dumpdatei nicht die richtigen Flags verwenden, kann der Import fehlschlagen. Informationen zum Erstellen einer SQL-Dumpdatei für den Import in Cloud SQL finden Sie unter SQL-Dumpdatei erstellen.

Daten komprimieren, um Kosten zu sparen

Cloud SQL unterstützt den Import und Export sowohl komprimierter als auch unkomprimierter Dateien. Durch die Komprimierung können Sie insbesondere beim Exportieren großer Instanzen viel Speicherplatz in Cloud Storage und somit Speicherkosten einsparen.

Verwenden Sie beim Exportieren einer SQL-Dumpdatei oder einer CSV-Datei die Dateiendung .gz, um die Daten zu komprimieren. Beim Importieren einer Datei mit der Erweiterung .gz wird die Datei automatisch dekomprimiert.

Lang andauernde Import- und Exportprozesse reduzieren

Importe in und Exporte aus Cloud SQL mithilfe der Importfunktion (mit einem Cloud Storage-Bucket) können je nach Größe der Datenbank sehr viel Zeit beanspruchen. Dies kann folgende Auswirkungen haben:

  • Sie können einen Cloud SQL-Instanzvorgang mit langer Ausführungszeit nicht beenden.
  • Sie können jeweils nur einen Import- oder Exportvorgang für jede Instanz ausführen.

Sie können den Zeitaufwand für die Ausführung der einzelnen Vorgänge verringern, indem Sie die Import- oder -Exportfunktion von Cloud SQL mit kleineren Datensätzen verwenden.

Bei Exporten können Sie den serverlosen Export verwenden, um die Auswirkungen auf die Datenbankleistung zu minimieren und die Ausführung anderer Vorgänge auf Ihrer Instanz während des Exports zu ermöglichen.

Weitere Tipps finden Sie unter Fehlerdiagnose bei Cloud SQL-Instanzen.

InnoDB verwenden

InnoDB ist die einzige unterstützte Speicher-Engine für MySQL-Instanzen.

Sie können Ihre Tabellen von MyISAM zu InnoDB konvertieren. Dazu leiten Sie die Ausgabe von mysqldump so über eine Pipe durch ein sed-Skript:

mysqldump --databases [DATABASE_NAME] \
-h [INSTANCE_IP] -u [USERNAME] -p [PASSWORD] \
--hex-blob --default-character-set=utf8mb4 | sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' > [DATABASE_FILE].sql

MySQL-Import- und -Migrationsjobs mit Metadaten mit DEFINER-Klausel

Da bei einem MySQL-Import- oder Migrationsjob keine Nutzerdaten migriert werden, können Quell- und Dumpdateien, die von Nutzern mit der DEFINER-Klausel definierte Metadaten enthalten, nicht importiert oder migriert werden, da hier noch keine Nutzer vorhanden sind.

Um festzustellen, welche DEFINER-Werte in Ihren Metadaten vorhanden sind, verwenden Sie die folgenden Abfragen oder suchen Sie in Ihrer Dumpdatei. Prüfen Sie, ob es Einträge für root%localhost oder für Nutzer gibt, die in der Zielinstanz nicht vorhanden sind.

SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.EVENTS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.ROUTINES;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.TRIGGERS;
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.VIEWS;

Um einen Import- oder Migrationsjob von einer Quelle auszuführen, die solche Metadaten enthält, haben Sie folgende Möglichkeiten:

  • Erstellen Sie die Nutzer in Ihrer Cloud SQL-Zielinstanz, bevor Sie den Import- oder Migrationsjob starten.
  • Aktualisieren Sie die DEFINER-Klausel auf INVOKER für die Quell-MySQL-Instanz oder die Dumpdatei, bevor Sie mit dem Import- oder Migrationsjob beginnen.

Importierte Datenbank prüfen

Stellen Sie nach Abschluss eines Importvorgangs eine Verbindung zu Ihrer Datenbank her und führen Sie die entsprechenden Datenbankbefehle aus, um sicherzustellen, dass der Inhalt korrekt ist. Beispiel: Stellen Sie ein Verbindung her und listen Sie die Datenbanken, Tabellen und spezifischen Einträge auf.

Bekannte Einschränkungen

Eine Liste bekannter Einschränkungen finden Sie unter Probleme beim Importieren und Exportieren von Daten.

Exportvorgänge automatisieren

Obwohl Cloud SQL keine integrierte Möglichkeit zum Automatisieren von Datenbankexporten bietet, können Sie Ihr eigenes Automatisierungstool mithilfe mehrerer Google Cloud-Komponenten erstellen. Weitere Informationen finden Sie in dieser Anleitung.

Fehlerbehebung

Fehlerbehebung bei Importvorgängen

Problem Fehlerbehebung
Der Importvorgang dauert zu lange. Zu viele aktive Verbindungen können Importvorgänge beeinträchtigen.

Schließen Sie nicht verwendete Vorgänge. Prüfen Sie die CPU- und Arbeitsspeichernutzung Ihrer Cloud SQL-Instanz, um dafür zu sorgen, dass genügend Ressourcen verfügbar sind. Die beste Methode, um maximale Ressourcen für den Import zu gewährleisten, ist ein Neustart der Instanz vor Beginn des Vorgangs.

Ein Neustart

  • beendet alle Verbindungen und
  • beendet alle Aufgaben, die möglicherweise Ressourcen nutzen.
Ein Importvorgang kann fehlschlagen, wenn ein oder mehrere Nutzer, auf die in der Dumpdatei verwiesen wird, nicht vorhanden sind. Vor dem Importieren einer Dumpdatei müssen alle Datenbanknutzer, die Inhaber von Objekten sind oder Berechtigungen für Objekte in der Dumpdatenbank erhalten haben, in der Zieldatenbank vorhanden sein. Andernfalls kann der Importvorgang die Objekte nicht mit den ursprünglichen Eigentumsrechten oder Berechtigungen neu erstellen.

Erstellen Sie die Datenbanknutzer vor dem Import.

Ein Importvorgang schlägt mit der Fehlermeldung fehl, dass keine Tabelle vorhanden ist. Tabellen können Fremdschlüsselabhängigkeiten von anderen Tabellen haben. Abhängig von der Reihenfolge der Vorgänge kann eine oder mehrere dieser Tabellen während des Importvorgangs noch nicht vorhanden sein.

Versuchen Sie Folgendes:

Fügen Sie am Anfang der Dumpdatei die folgende Zeile hinzu:


SET FOREIGN_KEY_CHECKS=0;
  

Fügen Sie außerdem am Ende der Dumpdatei die folgende Zeile hinzu:


SET FOREIGN_KEY_CHECKS=1;
  

Mit diesen Einstellungen werden Datenintegritätsprüfungen während des Importvorgangs deaktiviert und nach dem Laden der Daten wieder aktiviert. Dies wirkt sich nicht auf die Integrität der Daten in der Datenbank aus, da die Daten bereits beim Erstellen der Dumpdatei validiert wurden.

Fehlerbehebung bei Exportvorgängen

Problem Fehlerbehebung
CSV-Export funktioniert, SQL-Export schlägt jedoch fehl. Die Formate CSV und SQL werden unterschiedlich exportiert. Im SQL-Format wird die gesamte Datenbank exportiert, was wahrscheinlich länger dauert. Mit dem CSV-Format können Sie festlegen, welche Elemente der Datenbank in den Export einbezogen werden sollen.

Verwenden Sie CSV-Exporte, um nur das zu exportieren, was Sie benötigen.

Export dauert zu lange. Cloud SQL unterstützt keine gleichzeitigen synchronen Vorgänge.

Verwenden Sie die Exportauslagerung. Im Allgemeinen startet Cloud SQL bei der Exportauslagerung eine Auslagerungsinstanz zum Ausführen des Exports, anstatt einen Export für die Quellinstanz auszuführen. Die Exportauslagerung hat mehrere Vorteile, darunter eine höhere Leistung der Quellinstanz und die Aufhebung von Verwaltungsvorgängen, während der Export ausgeführt wird. Bei der Exportauslagerung kann sich die Gesamtlatenz um die Zeit erhöhen, die zum Erstellen der Auslagerungsinstanz erforderlich ist. Bei Exporten in angemessener Größe ist die Latenz im Allgemeinen nicht von Belang. Wenn der Export jedoch klein genug ist, können Sie einen Anstieg der Latenz feststellen.

Sie möchten Exporte automatisieren. Cloud SQL bietet keine Möglichkeit, Exporte zu automatisieren.

Sie können Ihr eigenes automatisiertes Exportsystem mit Google Cloud-Produkten wie Cloud Scheduler, Pub/Sub und Cloud Functions erstellen, ähnlich wie in diesem Artikel zur Automatisierung von Sicherungen.

Nächste Schritte