Fehlerdiagnose bei Cloud SQL-Instanzen

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.

Häufige Verbindungsprobleme

Prüfen, ob Ihre Anwendung Verbindungen korrekt beendet

Wenn Sie Fehler sehen, die Aborted connection nnnn to db: enthalten, deutet dies normalerweise darauf hin, dass Ihre Anwendung Verbindungen nicht ordnungsgemäß beendet. Auch Netzwerkprobleme können diesen Fehler verursachen. Der Fehler bedeutet nicht, dass Probleme mit der Cloud SQL-Instanz vorliegen.

Beispiele für Best Practices für das Verbindungsmanagement finden Sie unter Verbindungen verwalten.

Prüfen, ob die Zertifikate abgelaufen sind

Rufen Sie in der Cloud Console die Seite Cloud SQL-Instanzen auf und öffnen Sie die Instanz, wenn Ihre Instanz für die Verwendung von SSL konfiguriert ist. Öffnen Sie die Seite Verbindungen und prüfen Sie, ob das Serverzertifikat gültig ist. Wenn es abgelaufen ist, müssen Sie ein neues Zertifikat hinzufügen und zu diesem rotieren. Weitere Informationen

Prüfen, ob Verbindungsaufbau zulässig ist

Wenn Ihre Verbindungen fehlschlagen, prüfen Sie, ob Sie berechtigt sind, eine Verbindung herzustellen:

  • Wenn Sie Schwierigkeiten haben, eine Verbindung über eine bestimmte IP-Adresse herzustellen, beispielsweise eine Verbindung aus Ihrer lokalen Umgebung mit dem MySQL-Client, achten Sie darauf, dass die verwendete IP-Adresse für die Verbindung zur Cloud SQL-Instanz autorisiert ist.

    Verbindungen zu einer Cloud SQL-Instanz mit einer privaten IP-Adresse werden für RFC 1918-Adressbereiche automatisch autorisiert. Auf diese Weise können alle privaten Clients ohne Umleitung über den Proxy auf die Datenbank zugreifen. Adressen außerhalb des RFC 1918-Bereichs müssen als autorisierte Netzwerke konfiguriert sein.

    Cloud SQL lernt standardmäßig keine Subnetzrouten außerhalb des RFC 1918-Bereichs von Ihrer VPC. Sie müssen deshalb das Netzwerk-Peering auf Cloud SQL aktualisieren, um alle Routen außerhalb des RFC 1918-Bereichs exportieren zu können. Beispiel:

    gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
    
  • Hier finden Sie Ihre aktuelle IP-Adresse.

  • Führen Sie den Befehl gcloud sql connect aus, um eine Verbindung zur Instanz herzustellen. Mit diesem Befehl autorisieren Sie die IP-Adresse für kurze Zeit. Sie können diesen Befehl in einer Umgebung ausführen, in der Cloud SDK und der MySQL-Client installiert sind. Sie können diesen Befehl auch in Cloud Shell ausführen. Cloud Shell ist in der Google Cloud Console verfügbar. Das Cloud SDK und der MySQL-Client sind dort bereits vorinstalliert. Cloud Shell bietet eine Compute Engine-Instanz, mit der Sie eine Verbindung zu Cloud SQL herstellen können.
  • Gestatten Sie vorübergehend allen IP-Adressen den Verbindungsaufbau zu einer Instanz. Autorisieren Sie für IPv4 0.0.0.0/0 (und für IPv6 ::/0).

Verbindungsart prüfen

Wenn Sie eine Fehlermeldung wie

ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: NO)

beim Verbindungsaufbau erhalten, prüfen Sie, ob Sie ein Passwort eingegeben haben.

Wenn Sie eine Fehlermeldung wie

ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: YES)

erhalten, prüfen Sie, ob das eingegebene Passwort korrekt ist und ob die Verbindung über SSL hergestellt wird, falls die Instanz dies erfordert.

Informationen zu Verbindungslimits

Es gibt keine Beschränkungen hinsichtlich der Abfragen pro Sekunde (QPS) für Cloud SQL-Instanzen. Allerdings gibt es Beschränkungen für die Anzahl der Verbindungen und die Größe sowie App Engine-spezifische Einschränkungen. Weitere Informationen finden Sie unter Kontingente und Limits.

Datenbankverbindungen verbrauchen Ressourcen des Servers und der Anwendung, von der die Verbindung ausgeht. Daher sollten Sie sich bei der Verbindungsverwaltung immer an Best Practices orientieren. So können Sie die Kosten für die Anwendung minimieren und die Wahrscheinlichkeit senken, dass die Verbindungslimits für Cloud SQL überschritten werden. Weitere Informationen finden Sie unter Datenbankverbindungen verwalten.

Verbindungen, Prozesse und Threads anzeigen lassen

Wenn Sie eine Fehlermeldung erhalten, dass zu viele Verbindungen vorhanden sind, oder die Aktivitäten einer Instanz untersuchen möchten, können Sie die Anzahl der Verbindungen und Threads mit SHOW PROCESSLIST anzeigen lassen.

Führen Sie aus einem MySQL-Client folgenden Befehl aus:

mysql> SHOW PROCESSLIST;

Die Ausgabe sollte in etwa so aussehen:

+----+-----------+--------------+-----------+---------+------+-------+----------------------+
| Id | User      | Host         | db        | Command | Time | State | Info                 |
+----+-----------+--------------+-----------+---------+------+-------+----------------------+
|  3 | user-name | client-IP    | NULL      | Query   |    0 | NULL  | SHOW processlist     |
|  5 | user-name | client-IP    | guestbook | Sleep   |    1 |       | SELECT * from titles |
| 17 | user-name | client-IP    | employees | Query   |    0 | NULL  | SHOW processlist     |
+----+-----------+--------------+-----------+---------+------+-------+----------------------+
3 rows in set (0.09 sec)

Informationen zur Auswertung der von PROCESSLIST zurückgegebenen Spalten finden Sie in der MySQL-Referenz.

Sie können die Anzahl der Threads so abrufen:

mysql> SHOW STATUS WHERE Variable_name = 'Threads_connected';

Die Ausgabe sollte in etwa so aussehen:

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 7     |
+-------------------+-------+
1 row in set (0.08 sec)

Verbindungen, die eine IP-Adresse wie 1.2.3.4 haben, werden über IP hergestellt. Verbindungen mit cloudsqlproxy~1.2.3.4 verwenden den Cloud SQL Auth-Proxy oder stammen von App Engine. Verbindungen von localhost können von einigen internen Cloud SQL-Prozessen verwendet werden.

Zeitlimit für Verbindungen (von Compute Engine)

Bei Verbindungen mit einer Compute Engine-Instanz tritt nach 10 Minuten Inaktivität eine Zeitüberschreitung auf. Dies kann sich auf langlebige, nicht verwendete Verbindungen zwischen Ihrer Compute Engine-Instanz und Ihrer Cloud SQL-Instanz auswirken. Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Netzwerke und Firewalls.

Wenn Sie langlebige ungenutzte Verbindungen aufrechterhalten möchten, können Sie TCP keepalive aktivieren. Mit den folgenden Befehlen kann der TCP keepalive-Wert auf eine Minute gesetzt und dafür gesorgt werden, dass die Konfiguration auch nach Neustarts der Instanz bestehen bleibt.

Rufen Sie den aktuellen Wert für tcp_keepalive_time auf.

cat /proc/sys/net/ipv4/tcp_keepalive_time

Setzen Sie tcp_keepalive_time auf 60 Sekunden und legen Sie fest, dass die Konfiguration auch nach einem Neustart bestehen bleibt.

echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf

Übernehmen Sie die Änderung.

sudo /sbin/sysctl --load=/etc/sysctl.conf

Rufen Sie den Wert tcp_keepalive_time auf, um zu prüfen, ob die Änderung übernommen wurde.

cat /proc/sys/net/ipv4/tcp_keepalive_time

Mit IPv6 verbinden

Wenn Sie beim Verbindungsaufbau eine der folgenden Fehlermeldungen erhalten:

Can't connect to MySQL server on '2001:1234::4321' (10051)
Can't connect to MySQL server on '2001:1234::4321' (101)

haben Sie wahrscheinlich versucht, eine Verbindung zur IPv6-Adresse Ihrer Instanz aufzubauen, während an Ihrer Workstation jedoch kein IPv6 verfügbar ist. Wenn Sie prüfen möchten, ob IPv6 auf Ihrer Workstation aktiv ist, öffnen Sie ipv6.google.com. Lädt die Seite nicht, ist IPv6 nicht verfügbar. Stellen Sie stattdessen eine Verbindung zur IPv4-Adresse oder zu Ihrer Cloud SQL-Instanz her. Möglicherweise müssen Sie Ihrer Instanz zuvor eine IPv4-Adresse hinzufügen.

Gelegentliche Verbindungsfehler (Legacy-HA)

Wenn Cloud SQL eine Instanz aufgrund von Wartungsereignissen neu startet, werden Verbindungen möglicherweise zum Failover-Replikat weitergeleitet. Beim Herstellen einer Verbindung zum Failover-Replikat:

  • Funktionieren Leseanfragen von Clients, die unverschlüsselte Verbindungen verwenden, wie gewohnt. Schlagen Schreibanfragen jedoch fehl und geben eine Fehlermeldung zurück, z. B. "Error 1290: The MySQL server is running with the --read-only option so it cannot execute this statement." (Fehler 1290: Der MySQL-Server wird mit der Option "--read-only" ausgeführt, deshalb kann diese Anweisung nicht ausgeführt werden.)
  • Schlagen Lese- und Schreibanfragen von Clients, die verschlüsselte Verbindungen verwenden, fehl und geben eine Fehlermeldung zurück, z. B. "x509: certificate is valid for master-instance, not failover-instance" (x509: Zertifikat ist für die Masterinstanz gültig, nicht für die Failover-Instanz).

Nach Ablauf des Ereignisses setzt Cloud SQL die Verbindung zurück. Erstellen Sie die Verbindung neu. Es empfiehlt sich, Anwendungen so zu entwickeln, dass sie gelegentliche Fehler beim Verbindungsaufbau verarbeiten können. Hierzu kann eine Fehlerbehandlungsstrategie wie exponentieller Backoff implementiert werden. Weitere Informationen finden Sie unter Anwendungsimplementierung.

Fehlerbehebung für weitere Verbindungsfehler

Informationen zu anderen Verbindungsproblemen finden Sie auf der Seite zur Fehlerbehebung im Abschnitt Verbindung.

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 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 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 anfälliger 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 prüfen. Wählen Sie dazu das Projekt aus und rufen Sie die Abrechnungskontoinformationen für das Projekt auf. 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

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 Logausgabe über die Loganzeige in der Google Cloud Console verfügbar. Beachten Sie, dass Logging-Gebühren für die Operations-Suite von Google Cloud anfallen.

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

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 für weitere Fehler bei Cloud SQL-Instanzen

Informationen zu anderen Problemen mit Cloud SQL-Instanzen finden Sie auf der Seite zur Fehlerbehebung im Abschnitt Instanzen verwalten.

Fehlermeldungen

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

Fehlerbehebung für vom Kunden verwaltete Verschlüsselungsschlüssel (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. Weisen Sie dem Nutzer- oder Dienstkonto die Rolle Organisationsadministrator zu.

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. Weisen Sie Ihrem Nutzer- oder Dienstkonto die Rolle cloudkms.cryptoKeyEncrypterDecrypter zu.

Zur Seite "IAM-Konten"


Wenn Ihrem Konto bereits die Rolle 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.