Probleme diagnostizieren

Diese Seite enthält eine Liste der häufigsten Probleme, denen Sie bei der Arbeit mit Cloud SQL-Instanzen begegnen können, sowie Maßnahmen, die Sie zur Problemlösung ergreifen können. Beachten Sie auch die Seiten Bekannte Probleme und Fehlerbehebung sowie die Supportseite.

Logs ansehen

Informationen über kürzlich ausgeführte Vorgänge finden Sie in den Vorgangslogs der Cloud SQL-Instanz oder in den MySQL-Fehlerlogs.

Instanz reagiert nicht

Wenn Ihre Instanz nicht mehr auf Verbindungen reagiert oder die Leistung beeinträchtigt ist, achten Sie darauf, dass sie den Betriebsrichtlinien entspricht. Wenn sie diesen Richtlinien nicht entspricht, ist sie nicht vom Cloud SQL-SLA abgedeckt.

Verbindungsprobleme

Hilfe bei Verbindungsproblemen finden Sie auf der Seite Verbindungsprobleme beheben oder im Abschnitt Verbindungen.

Instanzprobleme

Sicherungen

Die beste Leistung für Sicherungen erzielen Sie, wenn Sie die Anzahl der Tabellen auf eine angemessene Zahl begrenzen.

Informationen zu anderen Sicherungsproblemen finden Sie auf der Seite zur Fehlerbehebung im Abschnitt Sicherungen.

Import und Export

Importe und Exporte in Cloud SQL erfolgen auf die gleiche Weise wie mit dem Dienstprogramm mysqldump. Der einzige Unterschied besteht darin, dass beim Import-/Exportfeature von Cloud SQL die Daten mithilfe eines Cloud Storage-Buckets übertragen werden.

Importe in Cloud SQL und Exporte aus Cloud SQL können je nach Größe 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 Aspekte, die beim Import beachtet werden sollten:

  • Ein Fehlschlagen des Importvorgangs kann auf einen OOM-Fehler (Out-of-Memory) zurückzuführen sein. In diesem Fall können Sie versuchen, die Parameter --extended-insert=FALSE --complete-insert direkt mit MySQL-Befehlen hinzuzufügen. Diese Parameter verringern die Geschwindigkeit Ihres Imports, aber auch den für den Import erforderlichen Arbeitsspeicher.

Weitere Informationen zu Import- und Exportproblemen finden Sie auf der Seite zur Fehlerbehebung im Abschnitt Import und Export.

Speicherplatz

Wenn Ihre Instanz die maximal zulässige Speichermenge erreicht hat, schlagen Schreibbefehle an die Datenbank fehl. Wenn Sie Daten entfernen, beispielsweise, indem Sie eine Tabelle löschen, wird der so frei gewordene Speicherplatz unter Belegter Speicherplatz der Instanz nicht angezeigt. Eine Erläuterung dieses Verhaltens finden Sie in den FAQ unter Wie kann ich den Speicherplatz zurückerhalten, den eine gelöschte Tabelle belegt hat?.

Das Erreichen des maximalen Speicherlimits kann auch dazu führen, dass die Instanz beim Neustart hängen bleibt.

Datenkorruption vermeiden

Generierte Spalten vermeiden

Aufgrund eines Problems in MySQL können durch die Verwendung generierter Spalten Daten beschädigt werden. Weitere Informationen finden Sie unter MySQL-Fehler 82736.

Korrektes Herunterfahren

Wenn Cloud SQL eine Instanz herunterfährt (z. B. für Wartungsaufgaben), werden keine neuen Verbindungsanfragen an die Instanz gesendet und bestehende Verbindungen werden getrennt. Die Zeit, in der "mysqld" herunterfahren muss, ist auf 1 Minute beschränkt. Wenn das Herunterfahren in dieser Zeit nicht abgeschlossen ist, wird der mysqld-Prozess zwangsweise beendet. Dies kann dazu führen, dass Schreibprozesse auf der Festplatte unvollständig abgebrochen werden.

Datenbankmodule

InnoDB ist die einzige unterstützte Speicher-Engine für MySQL-Instanzen, da sie weniger anfällig für Tabellenfehler ist als andere MySQL-Speicher-Engines wie MyISAM.

Datenbanktabellen für Cloud SQL werden standardmäßig mit der Speicher-Engine InnoDB erstellt. Wenn die CREATE TABLE-Syntax eine ENGINE-Option enthält, die ein anderes Speichermodul als InnoDB angibt, z. B. ENGINE = MyISAM, wird die Tabelle nicht erstellt und Sie erhalten Fehlermeldungen wie im folgenden Beispiel:

ERROR 3161 (HY000): Storage engine MyISAM is disabled (Table creation is disallowed).

Sie können diesen Fehler vermeiden, indem Sie die Option ENGINE = MyISAM aus dem Befehl CREATE TABLE entfernen. Auf diese Weise wird die Tabelle mit dem Speichermodul InnoDB erstellt.

Änderungen an Systemtabellen

Für MySQL-Systemtabellen, einschließlich aller Tabellen der mysql-Datenbank wie mysql.user und mysql.db, wird das Speichermodul MyISAM verwendet. Diese Tabellen können bei nicht korrektem Herunterfahren beschädigt werden. Führen Sie den Befehl FLUSH CHANGES aus, nachdem Sie Änderungen an diesen Tabellen vorgenommen haben. Wenn MyISAM beschädigt wird, können Sie mit CHECK TABLE und REPAIR TABLE den Normalstatus wiederherstellen (aber nicht die Daten speichern).

Global Transaction Identifier (GTID)

Bei allen MySQL-Instanzen ist GTID automatisch aktiviert. Die Aktivierung von GTID schützt vor Datenverlust bei der Erstellung von Replikaten und bei Failover. Außerdem erhöht sie die Stabilität der Replikation. Allerdings unterliegt GTID einigen Einschränkungen durch MySQL. Weitere Informationen hierzu finden Sie in der MySQL-Dokumentation. Folgende transaktional unsicheren Vorgänge können mit einem MySQL-Server mit aktiviertem GTID nicht ausgeführt werden:

  • CREATE TABLE ... SELECT-Anweisungen
  • CREATE TEMPORARY TABLE-Anweisungen innerhalb von Transaktionen
  • Transaktionen oder Anweisungen, die sowohl transaktionale als auch nicht transaktionale Tabellen betreffen

Wenn Sie eine transaktional unsichere Transaktion ausführen, wird eine Fehlermeldung wie im folgenden Beispiel angezeigt:

 Exception: SQLSTATE[HY000]: General error: 1786
 CREATE TABLE ... SELECT is forbidden when @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1.

Mit Triggern und gespeicherten Funktionen arbeiten

Wenn binäres Logging für die Instanz aktiviert ist und Sie mit Triggern oder gespeicherten Funktionen arbeiten möchten, muss das Flag log_bin_trust_function_creators in der Instanz auf on gesetzt sein.

Gesperrter Zustand

Cloud SQL kann eine Instanz aus verschiedenen Gründen sperren, zum Beispiel:

  • Abrechnungsprobleme

    Wenn zum Beispiel die Kreditkarte für das Abrechnungskonto des Projekts abgelaufen ist, kann die Instanz gesperrt werden. Sie können die Abrechnungsinformationen für ein Projekt auf der Abrechnungsseite der Google Cloud Console überprüfen, indem Sie das Projekt auswählen und die Abrechnungskontoinformationen aufrufen, die für das Projekt verwendet werden. Nachdem das Abrechnungsproblem behoben wurde, wird die Instanz innerhalb weniger Stunden in einen ausführbaren Status versetzt.

  • Probleme mit dem KMS-Schlüssel

    Wenn beispielsweise keine KMS-Schlüsselversion vorhanden ist, die zum Entschlüsseln der Nutzerdaten in der Cloud SQL-Instanz verwendet wird, oder wenn sie deaktiviert oder gelöscht wurde. Weitere Informationen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) verwenden.

  • Rechtliche Probleme

    Beispielsweise kann ein Verstoß gegen die Richtlinie zur fairen Nutzung von Google Cloud dazu führen, dass die Instanz gesperrt wird. Weitere Informationen finden Sie in den Google Cloud-Nutzungsbedingungen unter "Sperrung und Entfernung".

  • Betriebliche Probleme

    Wenn beispielsweise eine Instanz in einer Absturzschleife festhängt, also beim Starten oder kurz danach abstürzt, wird sie von Cloud SQL möglicherweise gesperrt.

Solange eine Instanz gesperrt ist, können Sie weiterhin Informationen dazu abrufen oder löschen, sofern die Sperrung durch ein Abrechnungsproblem ausgelöst wurde.

Cloud SQL-Nutzer mit Supportpaketen Platin, Gold oder Silber können bei Sperrung einer Instanz direkt unser Support-Team kontaktieren. Alle Nutzer können die vorstehende Anleitung zusammen mit dem Forum google-cloud-sql verwenden.

Leistung

Übersicht

Cloud SQL unterstützt Arbeitslasten mit hohem Leistungsbedarf mit bis zu 60.000 IOPS, ohne dass zusätzliche IO-Kosten entstehen. * Die IOPS- und Durchsatzleistung ist neben anderen Faktoren von der Laufwerkgröße, der Anzahl der Instanz-vCPUs und der E/A-Blockgröße abhängig.

Die Leistung Ihrer Instanz hängt auch von der Auswahl des Speichertyps und der Arbeitslast ab.

Mehr zu folgenden Themen:

Abfragelogs aktivieren

Sie können Cloud SQL so konfigurieren, dass langsame Anfragen geloggt werden, um die Leistung Ihrer Anfragen zu steuern. Dazu fügen Sie Ihrer Instanz die Datenbank-Flags --log_output='FILE' und --slow_query_log=on hinzu. Dadurch wird die Log-Ausgabe in der Log-Anzeige der Google Cloud Console verfügbar gemacht. Beachten Sie, dass Gebühren für das Google Cloud Observability-Logging anfallen.

Setzen Sie log_output nicht auf TABLE. Dies kann zu Verbindungsproblemen führen, wie in Tipps zum Arbeiten mit Flags beschrieben.

In dieser Anleitung finden Sie eine Anleitung, wie Sie langsame Abfragen in Cloud SQL for MySQL mithilfe von Cloud Logging und Monitoring protokollieren und überwachen.

Sperrungsmonitoring aktivieren

Die Überwachungsfunktion von InnoDB liefert Informationen über den internen Status der Speicher-Engine InnoDB, die Sie nutzen können, um die Leistung zu optimieren.

Greifen Sie über den MySQL-Client auf die Instanz zu und fordern Sie ein On-Demand-Überwachungsprotokoll an:

SHOW ENGINE INNODB STATUS\G

Erläuterungen zu den einzelnen Bereichen des Überwachungsprotokolls finden Sie unter Ausgaben der InnoDB Standardüberwachung und Sperrungsüberwachung.

Sie können die Überwachungsfunktionen von InnoDB so konfigurieren, dass die Ergebnisse regelmäßig in einer Datei oder Tabelle gespeichert werden, was allerdings die Leistung beeinträchtigt. Weitere Informationen finden Sie unter InnoDB-Überwachung aktivieren.

Leistungsschema verwenden

Das MySQL-Leistungsschema ist ein Feature zum Monitoring der MySQL-Serverausführung auf niedriger Ebene. Am einfachsten lassen sich die in performance_schema generierten Statistiken über die Funktion MySQL Workbench-Leistungsberichte nutzen.

Anzahl der Datenbanktabellen zweckmäßig halten

Datenbanktabellen beanspruchen Systemressourcen. Eine hohe Anzahl kann die Leistung und Verfügbarkeit einer Instanz beeinträchtigen und dazu führen, dass die Instanz nicht mehr vom zugehörigen SLA abgedeckt ist. Weitere Informationen

Allgemeine Leistungstipps

. Wenn Datenbankeinträge, Aktualisierungen oder Löschvorgänge sehr langsam sind, probieren Sie Folgendes:
  • Prüfen Sie den Ausgangsort des Schreibbefehls in Bezug zum Standort der Datenbank. Werden Daten über weite Strecken übertragen, führt dies zu längeren Latenzzeiten.

Wenn die Datenbankauswahl langsam ist, beachten Sie Folgendes:

  • Caching ist wichtig für die Leseleistung. Vergleichen Sie die Größe Ihres Datasets mit der Größe des Arbeitsspeichers Ihrer Instanz. Im Idealfall passt das gesamte Dataset in 70 % des RAM der Instanz. In diesem Fall sind Abfragen nicht auf die E/A-Leistung beschränkt. Ist dies nicht der Fall, sollten Sie den Arbeitsspeicher Ihrer Instanz unter Umständen vergrößern.
  • Beinhaltet Ihre Arbeitslast CPU-intensive Anfragen (Sortieren, reguläre Ausdrücke, andere komplexe Funktionen), kann dies die Instanz verlangsamen. Erhöhen Sie in diesem Fall die vCPU.
  • Prüfen Sie den Ausgangsort des Lesebefehls und den Standort der Datenbank – längere Latenzzeiten beeinträchtigen die Leseleistung noch mehr als die Schreibleistung.
  • Informieren Sie sich über Nicht-Cloud-SQL-spezifische Leistungsverbesserungen, beispielsweise wie Sie einen geeigneten Index hinzufügen, die gescannten Daten reduzieren und unnötigen Datenverkehr vermeiden.

    • Bei unzureichender Leistung während dem Ausführen von Abfragen können Sie EXPLAIN nutzen. EXPLAIN ist eine Anweisung, die Sie anderen Anweisungen wie SELECT hinzufügen, und gibt Informationen darüber zurück, wie MySQL die Anweisung ausführt. Sie funktioniert mit SELECT, DELETE, INSERT, REPLACE und UPDATE. Beispiel: EXPLAIN SELECT * FROM myTable;

    Mit EXPLAIN können Sie herausfinden, wo Folgendes möglich ist:

    • Tabellen um Indexe erweitern können, um die Leistung zu steigern. Achten Sie beispielsweise darauf, dass jedes Feld, das Sie als JOIN-Schlüssel verwenden, auf beiden Tabellen einen Index hat.

    • ORDER BY-Vorgänge verbessern können. Wenn durch EXPLAIN in der Spalte Extra der Ausgabe "Using temporary; Using filesort" angezeigt wird, werden Zwischenergebnisse in einer Datei gespeichert, die anschließend sortiert wird. Die Leistung wird hierdurch in der Regel beeinträchtigt. Führen Sie in diesem Fall einen der folgenden Schritte durch:

      • Verwenden Sie, sofern möglich, Indexe anstelle der Sortierung. Weitere Informationen finden Sie unter ORDER BY optimieren.

      • Erhöhen Sie die Größe der sort_buffer_size-Variable für die Anfragesitzung.

      • Verwenden Sie weniger RAM pro Zeile, indem Sie die Spalten nur so groß wie nötig bemessen.

    Fehlerbehebung

    Informationen zu anderen Cloud SQL-Problemen finden Sie auf der Seite Fehlerbehebung.

    Fehlermeldungen

    Informationen zu bestimmten API-Fehlermeldungen finden Sie auf der Referenzseite zu Fehlermeldungen.

    Fehlerbehebung bei vom Kunden verwalteten Verschlüsselungsschlüsseln (Customer-managed Encryption Keys, CMEK)

    Cloud SQL-Administratorvorgänge wie Erstellen, Klonen oder Aktualisieren können aufgrund von Cloud KMS-Fehlern und fehlenden Rollen oder Berechtigungen fehlschlagen. Häufige Gründe für einen Fehler sind eine fehlende, deaktivierte oder gelöschte Cloud KMS-Schlüsselversion, unzureichende IAM-Berechtigungen für den Zugriff auf die Cloud KMS-Schlüsselversion oder wenn sich die Cloud KMS-Schlüsselversion in einer anderen Region als die Cloud SQL-Instanz befindet. Verwenden Sie die folgende Tabelle zur Fehlerbehebung, um häufige Probleme zu diagnostizieren und zu beheben.

    Tabelle zur Fehlerbehebung für vom Kunden verwaltete Verschlüsselungsschlüssel

    Fehler Das könnte das Problem sein Lösungsvorschlag
    Dienstkonto pro Produkt und Projekt wurde nicht gefunden Der Name des Dienstkontos ist falsch. Sie müssen ein Dienstkonto für das richtige Nutzerprojekt erstellt haben.

    Zur Seite "Dienstkonten"

    Zugriff auf das Dienstkonto kann nicht gewährt werden Das Nutzerkonto ist nicht berechtigt, Zugriff auf diese Schlüsselversion zu gewähren. Fügen Sie dem Nutzer- oder Dienstkonto die Rolle Organisationsadministrator hinzu.

    Zur Seite "IAM-Konten"

    Die Cloud KMS-Schlüsselversion wurde gelöscht. Die Schlüsselversion wurde gelöscht. Wenn die Schlüsselversion gelöscht wurde, können Sie sie nicht zum Verschlüsseln oder Entschlüsseln von Daten verwenden.
    Die Cloud KMS-Schlüsselversion ist deaktiviert. Die Schlüsselversion ist deaktiviert. Aktivieren Sie die Cloud KMS-Schlüsselversion noch einmal.

    Zur Seite "Kryptografische Schlüssel"

    Unzureichende Berechtigung zur Verwendung des Cloud KMS-Schlüssels Die Rolle cloudkms.cryptoKeyEncrypterDecrypter fehlt in dem Nutzer- oder Dienstkonto, das Sie zum Ausführen von Vorgängen auf Cloud SQL-Instanzen verwenden, oder die Cloud KMS-Schlüsselversion ist nicht vorhanden. Fügen Sie in dem Google Cloud-Projekt, das den Schlüssel hostet, Ihrem Nutzer- oder Dienstkonto die Rolle cloudkms.cryptoKeyEncrypterDecrypter hinzu.

    Zur Seite "IAM-Konten"


    Wenn die Rolle Ihrem Konto bereits zugewiesen ist, finden Sie unter Schlüssel erstellen Informationen zum Erstellen einer neuen Schlüsselversion. Siehe Hinweis.
    Cloud KMS-Schlüssel wurde nicht gefunden Die Schlüsselversion ist nicht vorhanden. Erstellen Sie eine neue Schlüsselversion. Schlüssel erstellen Siehe Hinweis.
    Die Cloud SQL-Instanz und die Cloud KMS-Schlüsselversion befinden sich in verschiedenen Regionen. Die Cloud KMS-Schlüsselversion und die Cloud SQL-Instanz müssen sich in derselben Region befinden. Es kommt zu einem Fehler, wenn sich die Cloud KMS-Schlüsselversion in einer globalen Region oder Mehrfachregion befindet. Erstellen Sie eine Schlüsselversion in derselben Region, in der Sie Instanzen erstellen möchten. Schlüssel erstellen Siehe Hinweis.
    Die Cloud KMS-Schlüsselversion wird wiederhergestellt, die Instanz ist jedoch weiterhin gesperrt. Die Schlüsselversion ist deaktiviert oder gewährt nicht die erforderlichen Berechtigungen. Aktivieren Sie die Schlüsselversion wieder und weisen Sie Ihrem Nutzer- oder Dienstkonto in dem Google Cloud-Projekt, das den Schlüssel hostet, die Rolle cloudkms.cryptoKeyEncrypterDecrypter zu.

    Fehlerbehebungstabelle: Erneute Verschlüsselung

    Fehler Das könnte das Problem sein Lösungsvorschlag
    Die erneute Verschlüsselung der CMEK-Ressource ist fehlgeschlagen, da der Cloud KMS-Schlüssel nicht zugänglich ist. Prüfen Sie, ob die primäre Schlüsselversion aktiviert und die Berechtigung korrekt erteilt wurde. Die Schlüsselversion ist deaktiviert oder gewährt nicht die erforderlichen Berechtigungen.

    Aktivieren Sie die Cloud KMS-Schlüsselversion noch einmal:

    ZUR SEITE "KRYPTOSCHLÜSSEL"

    Bestätigen Sie in dem Google Cloud-Projekt, das den Schlüssel hostet, Ihrem Nutzer- oder Dienstkonto die Rolle cloudkms.cryptoKeyEncrypterDecrypter:

    Zur Seite "IAM-Konten"
    Die erneute Verschlüsselung der CMEK-Ressource ist aufgrund eines internen Serverfehlers fehlgeschlagen. Versuchen Sie es später noch einmal. Ein interner Serverfehler ist aufgetreten. Wiederholen Sie die Neuverschlüsselung. Weitere Informationen finden Sie unter Vorhandene CMEK-fähige Instanz oder -Replikat neu verschlüsseln.