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.

Auswirkungen von Exporten auf die Leistung minimieren

Bei einem Standardexport aus Cloud SQL wird der Export ausgeführt, während die Datenbank online ist. Wenn die zu exportierenden Daten weniger umfangreich sind, sind Auswirkungen 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. Nachdem Sie einen Export gestartet haben, kann er nicht mehr angehalten werden, wenn die Datenbank langsam reagiert.

So verhindern Sie langsame Antworten während eines Exports:

  1. Exportieren Sie ein Lesereplikat. Dies kann eine gute Option sein, wenn Sie häufig Exporte ausführen (täglich oder häufiger), die zu exportierende Datenmenge jedoch klein ist. Um einen Export aus einem Lesereplikat durchzuführen, verwenden Sie die Exportfunktionen der Google Cloud Console, von gcloud oder der REST API auf Ihrer Lesereplikatinstanz. Weitere Informationen zum Erstellen und Verwalten von Lesereplikaten finden Sie unter Lesereplikate erstellen.

  2. Verwenden Sie den serverlosen Export. 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. Dies kann eine gute Option sein, wenn Sie einen einmaligen Export einer großen Datenbank durchführen. Verwenden Sie die Exportfunktionen der Google Cloud Console, von gcloud oder der REST API 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.

    In der folgenden Tabelle werden die Vorgänge aufgelistet, die während eines serverlosen Exportvorgangs blockiert werden können:
    Aktueller Vorgang Neuer Vorgang Blockiert?
    Beliebiger Vorgang Serverloser Export Ja
    Serverloser Export Alle Vorgänge außer serverlosem Export Nein
    Alle Vorgänge außer serverlosem Export Alle Vorgänge außer serverlosem Export Ja

    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, Leistung und Kosten, bevor Sie den zu verwendenden Exporttyp bestimmen.

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.

Lange andauernde Import- und Exportvorgänge reduzieren

Importe in Cloud SQL und Exporte aus Cloud SQL können je nach Menge der zu verarbeitenden Daten lange dauern. Dies kann folgende Auswirkungen haben:

  • Sie können einen lange andauernden Cloud SQL-Instanzvorgang nicht anhalten.
  • Sie können jeweils nur einen Import- oder Exportvorgang für jede Instanz ausführen. Ein lange andauernder Import oder Export blockiert andere Vorgänge wie tägliche automatische Sicherungen. Mit serverlosen Exporten können Sie weitere Vorgänge ausführen, z. B. die Bearbeitung von Instanzen, Import, Failover und die Freigabe täglicher automatischer Sicherungen.

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

Sie können Exporte aus einem Lesereplikat durchführen oder den serverlosen Export verwenden, um die Auswirkungen auf die Datenbankleistung zu minimieren und die Ausführung anderer Vorgänge auf der Instanz zu ermöglichen, während ein Export ausgeführt wird.

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
HTTP Error 409: Operation failed because another operation was already in progress. Für Ihre Instanz steht bereits ein Vorgang aus. Es ist jeweils nur ein Vorgang zulässig. Senden Sie Ihre Anfrage, nachdem der aktuelle Vorgang abgeschlossen ist.
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
HTTP Error 409: Operation failed because another operation was already in progress. Für Ihre Instanz steht bereits ein Vorgang aus. Es ist jeweils nur ein Vorgang zulässig. Senden Sie Ihre Anfrage, nachdem der aktuelle Vorgang abgeschlossen ist.
HTTP Error 403: The service account does not have the required permissions for the bucket. Prüfen Sie, ob der Bucket vorhanden ist und das Dienstkonto für die Cloud SQL-Instanz (die den Export durchführt) die Rolle Storage Object Creator (roles/storage.objectCreator) hat, um den Export in den Bucket zu ermöglichen. Siehe IAM-Rollen für Cloud Storage.
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