Fehlerbehebung für Cloud SQL

Auf dieser Seite finden Sie einige Tipps zur Behebung von Fehlern in Cloud SQL, die nicht für ein bestimmtes Datenbankmodul spezifisch sind.

Folgende Themen werden auf dieser Seite behandelt:

Sicherung und Wiederherstellung

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Problem Mögliche Ursache Lösungsvorschlag
Aktueller Vorgangsstatus wird nicht angezeigt. Auf der Benutzeroberfläche wird nur Erfolg oder Fehler angezeigt. Verwenden Sie diese Datenbankbefehle, um mehr zu erfahren.
Der Urheber des Vorgangs kann nicht gefunden werden. Auf der Benutzeroberfläche wird nicht angezeigt, wer einen Vorgang gestartet hat. Verwenden Sie hierzu das Audit-Logging.
Nicht genügend Speicherplatz während der automatischen Sicherung. Die Instanz schöpft die Speicherkapazität des Laufwerks aus. Prüfen Sie die Größe des Dateisystems und das Kontingent.
Nach dem Löschen der Instanz kann keine Sicherung durchgeführt werden. Instanz wurde gelöscht. Erstellen Sie die Instanz neu aus einem Export oder wenden Sie sich an den Kundensupport innerhalb des Kulanzzeitraums.
Die automatische Sicherung scheint hängen geblieben zu sein. Die Sicherungszeit hängt von der Datenbankgröße ab. Wenden Sie sich an den Kundensupport, wenn Sie den Vorgang wirklich abbrechen müssen.
Die Wiederherstellung schlägt fehl. Die Dumpdatei kann Datenbanknutzer enthalten, die noch nicht vorhanden sind. Erstellen Sie vor der Wiederherstellung die Datenbanknutzer.
Vorgang ist für diese Instanz nicht gültig. Die Größe der Zielinstanz ist kleiner als die Quelle. Vergrößern Sie die Zielinstanz.
Erhöhen Sie die Anzahl der Tage für die Aufbewahrung automatischer Sicherungen. Nur sieben automatische Sicherungen werden aufbewahrt. Verwalten Sie Ihre eigenen manuellen Sicherungen.
Unbekannter Fehler bei fehlgeschlagener Sicherung. Mögliche Zeitüberschreitung bei der Sicherung. Prüfen Sie diese Flags.
Keine Benachrichtigung über Sicherungsfehler. Es ist keine Standardbenachrichtigung vorhanden. Richten Sie benutzerdefinierte Benachrichtigungen ein.

Aktueller Vorgangsstatus wird nicht angezeigt

Der Status eines Vorgangs wird in der Google Cloud Console nicht angezeigt.

Mögliche Ursache

Die Google Cloud Console meldet nur erfolgreiche oder fehlgeschlagene Vorgänge und gibt keine Warnungen zurück.

Lösungsvorschlag

Stellen Sie eine Verbindung zur Datenbank her und führen Sie SHOW WARNINGS aus.


Der Urheber des Vorgangs kann nicht gefunden werden

Sie möchten wissen, wer einen On-Demand-Sicherungsvorgang ausgelöst hat.

Mögliche Ursache

Auf der Seite "Instanzvorgänge" in der Google Cloud Console wird nicht angezeigt, wer einen Vorgang initiiert hat.

Lösungsvorschlag

Suchen Sie in den Logs und filtern Sie nach Text, um den Nutzer zu finden. Möglicherweise müssen Sie Audit-Logs für private Informationen verwenden. Zu den relevanten Logdateien gehören:

  • cloudaudit.googleapis.com/activity ist möglicherweise ebenfalls verfügbar, wenn Cloud-Audit-Logs aktiviert sind.


Nach Löschen der Instanz kann keine Sicherung durchgeführt werden

Nach dem Löschen der Instanz können Sie keine Sicherung mehr vornehmen.

Mögliche Ursache

Instanz wurde gelöscht.

Lösungsvorschlag

  • Der Kulanzzeitraum für eine Cloud SQL-Instanzbereinigung beträgt vier Tage. Während dieser Zeit kann der Kundensupport die Instanz neu erstellen. Nachdem die Instanzen dauerhaft gelöscht wurden, ist keine Datenwiederherstellung mehr möglich.
  • Wenn Sie einen Export durchgeführt haben, können Sie eine neue Instanz erstellen und dann die Daten importieren, um die Datenbank neu zu erstellen. Exporte werden in Cloud Storage geschrieben und Importe werden von dort gelesen.

Die automatische Sicherung ist hängen geblieben

Die automatische Sicherung bleibt viele Stunden hängen und kann nicht abgebrochen werden.

Mögliche Ursache

Sicherungen können je nach Datenbankgröße sehr lange dauern.

Lösungsvorschlag

Wenn Sie den Vorgang wirklich abbrechen müssen, können Sie den Kundensupport bitten, einen Neustart der Instanz zu erzwingen (force restart).


Die Wiederherstellung aus der Sicherung schlägt fehl

Ein Wiederherstellungsvorgang kann fehlschlagen, wenn ein oder mehrere Nutzer, auf die in der SQL-Dumpdatei verwiesen wird, nicht vorhanden sind.

Mögliche Ursache

Vor dem Wiederherstellen eines SQL-Dumps müssen alle Datenbanknutzer vorhanden sein, die Inhaber von Objekten sind oder Berechtigungen für Objekte in der gespeicherten Datenbank erhalten haben. Andernfalls werden die Objekte mit den ursprünglichen Inhaberrechten und/oder Berechtigungen nicht wiederhergestellt.

Lösungsvorschlag

Erstellen Sie die Datenbanknutzer vor der Wiederherstellung aus dem SQL-Dump.


Der Vorgang ist für diese Instanz nicht gültig

Ein API-Aufruf an instances.restoreBackup führt zu der Fehlermeldung HTTP Error 400: This operation isn't valid for this instance.

Mögliche Ursache

Sie können keine Wiederherstellung aus einer Sicherung einer Instanz vornehmen, deren Speichergröße (XX GB) kleiner als die Sicherungsgröße (YY GB) ist.

Lösungsvorschlag

Bearbeiten Sie die Zielinstanz, um ihren Speicherplatz zu erhöhen.


Erhöhen Sie die Anzahl der Tage für die Aufbewahrung automatischer Sicherungen

Sie möchten die Anzahl der Tage für die Aufbewahrung automatischer Sicherungen von sieben auf 30 Tage oder länger erhöhen.

Mögliche Ursache

Es werden nur sieben Sicherungen aufbewahrt. Sicherungen werden aufgrund ihrer Größe und der Aufbewahrungskosten regelmäßig gelöscht. Leider bedeutet dies, dass die jeweils aktuell sichtbaren Sicherungen die einzigen automatischen Sicherungen sind, aus denen Sie wiederherstellen können.

Lösungsvorschlag

Wenn Sie Sicherungen unbegrenzt aufbewahren möchten, können Sie selbst eine On-Demand-Sicherung erstellen, da diese nicht auf dieselbe Weise wie automatische Sicherungen gelöscht wird. On-Demand-Sicherungen werden für unbegrenzte Zeit aufbewahrt. Das heißt, sie bleiben so lange erhalten, bis sie gelöscht werden oder die Instanz, zu der sie gehören, gelöscht wird. Da diese Art der Sicherung nicht automatisch gelöscht wird, kann sich dies auf die Abrechnung auswirken.


Unbekannter Fehler bei fehlgeschlagener Sicherung

Die Sicherung ist fehlgeschlagen und es wird Unknown error angezeigt.

Mögliche Ursache

Bei der Erstellung der Sicherung wurde das Zeitlimit von zehn Minuten erreicht. Für die automatische Sicherung ist ein Zeitlimit von zehn Minuten festgelegt und die Sicherung sollte in dieser Zeit abgeschlossen werden.

Lösungsvorschlag

Es gibt zwei Flags, die sich auf die Erstellung der Sicherung auswirken: checkpoint_timeout und checkpoint_completion_target. Zu Beginn der Sicherung wird der Prüfpunkt slow ausgeführt, der checkpoint_completion_target mit checkpoint_timeout multipliziert.

z. B. 900 sec * 0.9 sec = 810 sec = 13.5 min Aus diesem Grund tritt eine Zeitüberschreitung auf. Wenn Sie den Wert von checkpoint_completion_target verringern, wird das Problem in diesem Fall behoben.

Keine Benachrichtigung über Sicherungsfehler

Eine automatische Sicherung ist fehlgeschlagen und Sie haben keine Benachrichtigung erhalten.

Mögliche Ursache

Wenn eine automatische Sicherung fehlschlägt, wird auf der Seite Details der Cloud SQL-Instanz die Meldung Operation error angezeigt. Bei einem Sicherungsfehler werden keine E-Mail-Benachrichtigungen gesendet.

Lösungsvorschlag

Sie können eine Monitoring-Benachrichtigung erstellen oder über Error Reporting-Benachrichtigungen spezielle benutzerdefinierte Benachrichtigungen einrichten.

Klonen

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Problem Mögliche Ursache Lösungsvorschlag
Der Klonvorgang schlägt mit dem Fehler constraints/sql.restrictAuthorizedNetworks fehl. Aufgrund der Konfiguration von autorisierten Netzwerken blockiert. Sie haben folgende Möglichkeiten:

Klonvorgang schlägt mit dem Fehler constraints/sql.restrictAuthorizedNetworks fehl

Der Klonvorgang schlägt mit dem Fehler constraints/sql.restrictAuthorizedNetworks fehl.

Mögliche Ursache

Der Klonvorgang wird durch die Authorized Networks-Konfiguration blockiert. Authorized Networks sind für öffentliche IP-Adressen im Bereich "Verbindung" der Google Cloud Console konfiguriert und das Klonen ist aufgrund von Sicherheitsaspekten nicht zulässig.

Lösungsvorschlag

Entfernen Sie nach Möglichkeit alle Authorized Networks-Einträge aus der Cloud SQL-Instanz. Erstellen Sie andernfalls ein Replikat ohne Authorized Networks-Einträge.

Verbindung

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Problem Mögliche Ursache Lösungsvorschlag
Fehler vom Typ Unauthorized to connect. Dies kann viele Ursachen haben. Folgen Sie diesem Link.
Netzwerkzuordnung fehlgeschlagen. Service Networking API ist im Projekt nicht aktiviert. Aktivieren Sie Service Networking API im Projekt.
Remaining connection slots are reserved. Die maximale Anzahl von Verbindungen wurde erreicht. Erhöhen Sie den Wert des Flags max_connections.
Set Service Networking service account as servicenetworking.serviceAgent role on consumer project. Netzwerkberechtigungen für das Dienstkonto fehlen oder sind falsch. Deaktivieren Sie die Service Networking API und aktivieren Sie sie wieder.

Verbindung abgebrochen

Sie sehen die Fehlermeldung Got an error reading communication packets oder Aborted connection xxx to db: DB_NAME.

Mögliche Ursache

  • Netzwerk instabil.
  • Keine Antwort auf TCP-Keep-Alive-Befehle (entweder der Client oder der Server reagiert nicht, möglicherweise überlastet).
  • Die Verbindungsdauer des Datenbankmoduls wurde überschritten und der Server hat die Verbindung beendet.

Lösungsvorschlag

Anwendungen sollten Netzwerkfehler tolerieren und gemäß den Best Practices mit Verbindungs-Pooling und Wiederholungsversuchen arbeiten. Die meisten Verbindungs-Pooler erfassen diese Fehler nach Möglichkeit. Andernfalls sollte die Anwendung einen Wiederholungsversuch ausführen oder ordnungsgemäß fehlschlagen.

Für den erneuten Verbindungsversuch empfehlen wir die folgenden Methoden:

  1. Exponentieller Backoff. Erhöhen Sie das Zeitintervall zwischen den einzelnen Wiederholungen exponentiell.
  2. Fügen Sie auch einen zufälligen Backoff hinzu.
Durch die Kombination dieser Methoden wird die Drosselung reduziert.


Keine Autorisierung für Verbindung

Folgende Fehlermeldung ist zu sehen: Unauthorized to connect.

Mögliche Ursache

Da die Autorisierung auf mehreren Ebenen erfolgt, kann dies verschiedene Ursachen haben.

  • Auf Datenbankebene muss der Datenbanknutzer vorhanden sein und sein Passwort muss übereinstimmen.
  • Auf Projektebene fehlen dem Nutzer möglicherweise die richtigen IAM-Berechtigungen.
  • Auf Cloud SQL-Ebene kann die Ursache davon abhängen, wie Sie eine Verbindung zu Ihrer Instanz herstellen. Wenn Sie über die öffentliche IP-Adresse eine direkte Verbindung zu einer Instanz herstellen, muss sich die Quell-IP-Adresse der Verbindung im autorisierten Netzwerk der Instanz befinden.

    Private IP-Verbindungen sind standardmäßig zulässig, es sei denn, Sie stellen eine Verbindung von einer Adresse außerhalb des RFC 1918-Bereichs her. Clientadressen außerhalb des RFC 1918-Bereichs müssen als autorisierte Netzwerke konfiguriert sein.

    Cloud SQL erkennt 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/postgres]-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
    

    Wenn Sie eine Verbindung über den Cloud SQL Proxy herstellen, sollten Sie darauf achten, dass die IAM-Berechtigungen korrekt festgelegt sind.

  • Wenn die Cloud SQL-Instanz auf Netzwerkebene öffentliche IP-Adressen verwendet, muss sich die Quell-IP-Adresse der Verbindung in einem autorisierten Netzwerk befinden.

Lösungsvorschlag

  • Prüfen Sie das Passwort und den Nutzernamen.
  • Prüfen Sie die IAM-Rollen und -Berechtigungen des Nutzers.
  • Wenn Sie eine öffentliche IP-Adresse verwenden, achten Sie darauf, dass sich die Quelle in den autorisierten Netzwerken befindet.

Netzwerkzuordnung fehlgeschlagen

Sie sehen die Fehlermeldung Error: Network association failed due to the following error: Weisen Sie dem Dienstnetzwerk-Dienstkonto die Rolle servicenetworking.serviceAgent für das Nutzerprojekt zu.

Mögliche Ursache

Die Service Networking API ist im Projekt nicht aktiviert.

Lösungsvorschlag

Aktivieren Sie die Service Networking API in Ihrem Projekt. Ist dieser Fehler zu sehen, wenn Sie einer Cloud SQL-Instanz eine private IP-Adresse zuweisen und eine freigegebene VPC verwenden, müssen Sie auch die Service Networking API für das Hostprojekt aktivieren.


Verbleibende Verbindungsslots sind reserviert

Folgende Fehlermeldung ist zu sehen: FATAL: remaining connection slots are reserved for non-replication superuser connections.

Mögliche Ursache

Die maximale Anzahl von Verbindungen wurde erreicht.

Lösungsvorschlag

Bearbeiten Sie den Wert des Flags max_connections. Wenn Sie max_connections über einen bestimmten Wert hinaus erhöhen, kann die SLA-Unterstützung verloren gehen.


Dem Dienstnetzwerk-Dienstkonto die Rolle "servicenetworking.serviceAgent" für das Nutzerprojekt zuweisen

Die Fehlermeldung set Service Networking service account as servicenetworking.serviceAgent role on consumer project. wird angezeigt.

Mögliche Ursache

Nutzer- oder Dienstkontoberechtigungen sind nicht korrekt. Dies kann bei automatisierten Einrichtungsskripts wie einem Terraform-Konfigurationsskript geschehen.

Lösungsvorschlag

Deaktivieren Sie zum Reparieren von Dienstberechtigungen die Service Networking API, warten Sie fünf Minuten und aktivieren Sie sie dann wieder.

Instanzen erstellen

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Problem Mögliche Ursache Lösungsvorschlag
Internal error. Dienstnetzwerk-Dienstkonto fehlt. Deaktivieren Sie die Service Networking API und aktivieren Sie sie noch einmal.
Die Terraform-Instanz konnte nicht erstellt werden. Terraform-Konfigurationsfehler. Prüfen und reparieren Sie die Terraform-Konfigurationsdatei.
HTTP Error 409 im Terraform-Skript. Es wird bereits ein anderer Vorgang ausgeführt. Korrigieren Sie das Terraform-Skript so, dass es auf den Abschluss jedes Vorgangs wartet.
Unknown error Es wird versucht, eine Instanz mit dem Namen einer kürzlich gelöschten Instanz zu erstellen. Oder es wird versucht, gleichzeitig mehrere Instanzen mit einem neuen privaten IP-Bereich anzulegen. Verwenden Sie einen anderen Namen für die Instanz oder warten Sie, bis das Löschen der Instanz eine Woche zurückliegt. Erstellen Sie die fehlerhaften Instanzen nacheinander neu und verwenden Sie andere Namen.

Interner Fehler

Folgende Fehlermeldung ist zu sehen: {"ResourceType":"sqladmin.v1beta4.instance", "ResourceErrorCode":"INTERNAL_ERROR","ResourceErrorMessage":null}.

Mögliche Ursache

Im Dienstprojekt fehlt wahrscheinlich das Dienstnetzwerk-Dienstkonto, das für dieses Feature erforderlich ist.

Lösungsvorschlag

Deaktivieren Sie zum Reparieren von Dienstberechtigungen die Service Networking API, warten Sie fünf Minuten und aktivieren Sie sie dann wieder.


Terraform-Instanz konnte nicht erstellt werden

Die Terraform-Instanz konnte nicht erstellt werden.

Mögliche Ursache

Dies ist normalerweise ein Problem im Terraform-Skript selbst.

Lösungsvorschlag

Prüfen und reparieren Sie die Terraform-Konfigurationsdatei.


Fehler 409 im Terraform-Skript

In Terraform-Skripts ist die Fehlermeldung HTTP Error 409 zu sehen.

Mögliche Ursache

Operation failed because another operation was already in progress

Lösungsvorschlag

Überarbeiten Sie das Skript so, dass die Ausführung angehalten wird, bis jeder Instanzvorgang abgeschlossen ist. Lassen Sie das Skript abfragen und warten Sie, bis für die vorherige Vorgangs-ID der Wert 200 zurückgegeben wird, bevor Sie mit dem nächsten Schritt fortfahren.


Unbekannter Fehler

Beim Erstellen einer Instanz ist eine Fehlermeldung wie Cloud SQL creation failed, error UNKNOWN zu sehen.

Mögliche Ursache

Höchstwahrscheinlich versuchen Sie, den Namen einer kürzlich gelöschten Instanz wiederzuverwenden. Instanznamen können nach dem Löschen eine Woche lang nicht wiederverwendet werden. Wenn nur die erste Instanz erstellt wird und andere mit Unknown error fehlschlagen, kann es auch sein, dass Sie versuchen, mehrere Instanzen gleichzeitig mit einem neuen privaten IP-Bereich anzulegen.

Lösungsvorschlag

Verwenden Sie entweder einen anderen Namen für die Instanz oder warten Sie eine Woche, um eine neue Instanz mit diesem Namen zu erstellen. Erstellen Sie mehrere Instanzen nacheinander und nicht gleichzeitig.

Hochverfügbarkeit

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Problem Mögliche Ursache Lösungsvorschlag
Messwerte für manuelles Failover können nicht gefunden werden. Nur automatische Failovers fließen in die Messwerte ein.
CPU und RAM sind fast zu 100 % ausgelastet. Die Rechnerkapazitäten der Instanz reichen für die Arbeitslast nicht aus. Aktualisieren Sie die Rechnerkapazitäten der Instanz.

Messwerte für manuelles Failover können nicht gefunden werden

Sie haben ein manuelles Failover durchgeführt und können im Metrics Explorer unter den automatischen Failover-Messwerten keinen entsprechenden Eintrag finden.

Mögliche Ursache

Nur automatische Failovers werden in den Messwerten aufgenommen. Manuell ausgelöste Failovers werden nicht berücksichtigt.

Lösungsvorschlag


CPU und RAM sind fast zu 100 % ausgelastet

Cloud SQL-Instanzressourcen (CPU und RAM) sind zu fast 100 % ausgelastet, wodurch die Hochverfügbarkeitsinstanz abstürzt.

Mögliche Ursache

Die Rechnerkapazitäten der Instanz reichen für die Arbeitslast nicht aus.

Lösungsvorschlag

Bearbeiten Sie die Instanz, um ein Upgrade auf einen Rechner mit höherer Kapazität durchzuführen, sodass mehr CPUs und Speicherplatz verfügbar sind.

Import und Export

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Problem Mögliche Ursache Lösungsvorschlag
Der Status des Vorgangs wird nicht angezeigt. Auf der Benutzeroberfläche wird nur Erfolg oder Fehler angezeigt. Verwenden Sie diese Datenbankbefehle, um mehr zu erfahren.
Export dauert zu lange. Cloud SQL unterstützt keine gleichzeitigen synchronen Vorgänge. Verwenden Sie die Exportauslagerung. Weitere Informationen
Import dauert zu lange. Zu viele aktive Verbindungen können Importvorgänge beeinträchtigen. Schließen Sie nicht verwendete Verbindungen oder starten Sie die Cloud SQL-Instanz neu, bevor Sie einen Importvorgang starten.
Import schlägt fehl. Die exportierte Datei kann Datenbanknutzer enthalten, die noch nicht vorhanden sind. Erstellen Sie die Datenbanknutzer, bevor Sie den Import ausführen.
Verbindung während des Exportvorgangs getrennt. Die Abfrage muss innerhalb der ersten sieben Minuten Daten liefern. Testen Sie die Abfrage manuell. Weitere Informationen
Unbekannter Fehler beim Export. Mögliches Bandbreitenproblem. Die Instanz und der Cloud Storage-Bucket müssen sich in derselben Region befinden.
Sie möchten Exporte automatisieren. Cloud SQL bietet keine Möglichkeit, Exporte zu automatisieren. Erstellen Sie Ihre eigene Pipeline, um diese Funktion zu nutzen. Weitere Informationen
ERROR_RDBMS: system error occurred. Cloud Storage-Berechtigungen oder nicht vorhandene Tabelle. Prüfen Sie die Berechtigungen ODER ob die Tabelle vorhanden ist.

Der Status des Vorgangs wird nicht angezeigt

Sie können den Status eines laufenden Vorgangs nicht sehen.

Mögliche Ursache

Die Google Cloud Console meldet nur erfolgreiche oder fehlgeschlagene Vorgänge und gibt keine Warnungen zurück.

Lösungsvorschlag

Stellen Sie eine Verbindung zur Datenbank her und führen Sie SHOW WARNINGS aus.


Export dauert zu lange

Der Export dauert zu lange und andere Vorgänge werden blockiert.

Mögliche Ursache

Cloud SQL unterstützt keine gleichzeitigen synchronen Vorgänge.

Lösungsvorschlag

Versuchen Sie, kleinere Datasets nacheinander zu exportieren.


Import dauert zu lange

Der Import dauert zu lange und blockiert andere Vorgänge.

Mögliche Ursache

Zu viele aktive Verbindungen können Importvorgänge beeinträchtigen. Verbindungen beanspruchen CPU und Arbeitsspeicher, was die verfügbaren Ressourcen begrenzt.

Lösungsvorschlag

Schließen Sie nicht verwendete Vorgänge. Prüfen Sie die CPU- und Arbeitsspeichernutzung, um dafür zu sorgen, dass genügend Ressourcen verfügbar sind. Der beste Weg, maximale Ressourcen für den Importvorgang 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.


Import schlägt fehl

Der Import schlägt fehl, wenn ein oder mehrere Nutzer, auf die in der exportierten SQL-Dumpdatei verwiesen wird, nicht vorhanden sind.

Mögliche Ursache

Vor dem Import eines SQL-Dumps müssen alle Datenbanknutzer vorhanden sein, die Inhaber von Objekten sind oder Berechtigungen für Objekte in der gespeicherten Datenbank erhalten haben. Andernfalls werden die Objekte mit den ursprünglichen Inhaberrechten und/oder Berechtigungen nicht wiederhergestellt.

Lösungsvorschlag

Erstellen Sie die Datenbanknutzer, bevor Sie den SQL-Dump importieren.


Verbindung während des Exportvorgangs getrennt

Die Verbindung wurde während des Exportvorgangs getrennt.

Mögliche Ursache

Bei der Verbindung zu Cloud Storage kann es zu einer Zeitüberschreitung kommen, da die im Export ausgeführte Abfrage innerhalb der ersten sieben Minuten nach dem Start des Exports keine Daten erzeugt.

Lösungsvorschlag

Testen Sie die Abfrage manuell. Stellen Sie dazu eine Verbindung von einem beliebigen Client aus her und senden Sie die Ausgabe der Abfrage mit dem folgenden Befehl an STDOUT:

COPY (INSERT_YOUR_QUERY_HERE) TO STDOUT WITH ( FORMAT csv, DELIMITER ',', ENCODING 'UTF8', QUOTE '"', ESCAPE '"' )

Dies ist das erwartete Verhalten, da der Client sofort nach dem Start des Exports mit dem Senden von Daten beginnen soll. Werden keine Daten gesendet, wird die Verbindung getrennt. Dies führt dazu, dass der Export fehlschlägt und der Vorgang in einem unsicheren Zustand bleibt. Dies ist auch in der Fehlermeldung von gcloud zu sehen:

operation is taking longer than expected


Unbekannter Fehler beim Export

Beim Exportieren einer Datenbank in einen Cloud Storage-Bucket ist die Fehlermeldung Unknown error zu sehen.

Mögliche Ursache

Die Übertragung kann aufgrund eines Bandbreitenproblems fehlschlagen.

Lösungsvorschlag

Die Cloud SQL-Instanz befindet sich möglicherweise in einer anderen Region als der Cloud Storage-Bucket. Das Lesen und Schreiben von Daten von einem Kontinent auf einen anderen verursacht eine hohe Netzwerkauslastung, wodurch zeitweise Probleme wie diese auftreten können. Prüfen Sie die Regionen Ihrer Instanz und Ihres Buckets.


Sie möchten Exporte automatisieren

Sie möchten Exporte automatisieren.

Mögliche Ursache

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

Lösungsvorschlag

Sie können Ihr eigenes automatisiertes Exportsystem mit Google Cloud-Produkten wie Cloud Scheduler, Pub/Sub und Cloud Functions erstellen. Eine Beschreibung finden Sie hier.


Systemfehler "ERROR_RDBMS"

Folgende Fehlermeldung ist zu sehen: [ERROR_RDBMS] system error occurred.

Mögliche Ursache

  • Der Nutzer hat eventuell nicht alle erforderlichen Cloud Storage-Berechtigungen.
  • Die Datenbanktabelle ist möglicherweise nicht vorhanden.

Lösungsvorschlag

  1. Prüfen Sie, ob Sie mindestens die WRITER-Berechtigungen für den Bucket und READER-Berechtigungen für die Exportdatei haben. Weitere Informationen zum Konfigurieren der Zugriffssteuerung in Cloud Storage finden Sie unter Access Control Lists (ACLs) erstellen und verwalten.
  2. Prüfen Sie, ob die Tabelle vorhanden ist. Falls die Tabelle vorhanden ist, sollten Sie nachsehen, ob Sie die richtigen Berechtigungen für den Bucket haben.

Logging

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Problem Mögliche Ursache Lösungsvorschlag
Logging beansprucht viel CPU und Speicher. Das Logging muss optimiert werden. Versuchen Sie, die Logging-Ressourcennutzung zu optimieren.
Audit-Logs wurden nicht gefunden. Nutzerauthentifizierung. Prüfen Sie die Nutzerrollen und Berechtigungen.
Vorgangsinformationen wurden nicht in Logs gefunden. Audit-Logs sind nicht aktiviert. Aktivieren Sie das Audit-Logging.

Logging beansprucht viel CPU und Speicher

Das Logging beansprucht viel CPU und Speicher.

Mögliche Ursache

Die Logging-Nutzung muss optimiert werden.

Lösungsvorschlag

Das Flag log_statement kann auf "none" und das Flag logging_collector auf "off" gesetzt werden. Wenn das Problem mit Logging weiterhin auftritt, können andere logbezogene Flags angepasst werden. Sie können die Instanz bearbeiten und diese Flags ändern.


Audit-Logging

Sie haben das Audit-Logging für Cloud SQL aktiviert, können jedoch keine Audit-Logs in Cloud Logging finden.

Mögliche Ursache

Logs zum Datenzugriff werden nur geschrieben, wenn der Vorgang ein authentifizierter, nutzergesteuerter API-Aufruf ist, der von Nutzern erstellte Daten erstellt, ändert oder liest, oder wenn der Vorgang auf Konfigurationsdateien oder Metadaten von Ressourcen zugreift.

Lösungsvorschlag

Prüfen Sie die Rollen und Berechtigungen des Nutzers, der die Vorgänge ausführt.


Vorgangsinformationen wurden nicht in Logs gefunden

Sie möchten weitere Informationen zu einem Vorgang erhalten. Beispiel: Ein Nutzer wurde gelöscht, aber Sie können nicht sehen, wer ihn gelöscht hat. Die Logs zeigen den gestarteten Vorgang an, enthalten jedoch keine weiteren Informationen.

Mögliche Ursache

Für die Erfassung detaillierter und personenidentifizierbarer Informationen wie diesen müssen Sie Audit-Logging aktivieren.

Lösungsvorschlag

Aktivieren Sie Audit-Logging in Ihrem Projekt.

Instanzen verwalten

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Problem Mögliche Ursache Lösungsvorschlag
Automatischer Speicher wurde durch temporären Speicher erhöht. Der automatische Speicher ist aktiviert. Durch den Neustart werden die temporären Dateien gelöscht, der Speicherplatz wird jedoch nicht reduziert. Nur der Kundensupport kann die Instanzgröße zurücksetzen. Weitere Informationen
Daten werden automatisch gelöscht. Dazu wird irgendwo in der Umgebung ein Skript ausgeführt. Versuchen Sie, das Skript zu finden.
Instanz kann nicht gelöscht werden. Dies kann mehrere Ursachen haben. Hier sind mehrere Lösungen möglich.
Instanz bleibt aufgrund großer temporärer Datenmengen hängen. Es wurden zu viele temporäre Tabellen gleichzeitig erstellt. Starten Sie die Instanz neu und probieren Sie diese Abhilfemaßnahme aus.
Schwerwiegender Fehler beim Upgrade. Dafür gibt es viele Gründe. Möglicherweise finden Sie weitere Informationen in den Logs. Vielleicht müssen Sie sich aber auch an den Kundensupport wenden, um einen Neustart zu erzwingen.
Instanz bleibt beim Neustart hängen, nachdem der Speicherplatz ausgeschöpft ist. Die automatische Speichererweiterung ist nicht aktiviert. Aktivieren Sie die automatische Speichererweiterung.
Langsames Herunterfahren beim Neustart. Ausstehende Verbindungen, die nach 60 Sekunden nicht beendet werden, können ein nicht ordnungsgemäßes Herunterfahren verursachen. Verwenden Sie nur Verbindungen, die weniger als 60 Sekunden dauern.
Access denied for user. Nutzerauthentifizierung oder möglicherweise abgelaufene SSL/TLS-Zertifikate. Prüfen Sie die Status von Nutzer und Zertifikat.
Nutzer kann nicht gelöscht werden. Möglicherweise ist der Nutzer Inhaber von Objekten in der Datenbank. Möglicherweise müssen Sie Objekte löschen oder neu zuweisen.
Einer vorhandenen Instanz in einer freigegebenen VPC kann keine private IP-Adresse zugewiesen werden. Instanzadressen sind beim Erstellen mit ihren Projekten verknüpft. Erstellen Sie eine neue Cloud SQL-Instanz, um die vorhandene zu ersetzen.
Bestimmte Abfragen werden langsam ausgeführt. Datenbankspezifische Probleme oder Netzwerklatenz. Sehen Sie sich diese Vorschläge an.
Es wird angegeben, dass nicht genügend Arbeitsspeicher vorhanden ist, aber in Monitoring-Diagrammen wird dies nicht angezeigt. Ein Teil des RAM wird möglicherweise von internen Overhead-Prozessen verwendet. Achten Sie darauf, dass die Instanz genügend Overhead für Ihre Arbeitslast hat.


Automatischer Speicher durch temporären Speicher erhöht

Temporäre Tabellen erhöhen die Speichernutzung und der automatische Speicher wurde erweitert.

Mögliche Ursache

Der automatische Speicher ist aktiviert.

Lösungsvorschlag

Durch einen Neustart zum Löschen temporärer Tabellen wird die automatisch erweiterte Speichergröße nicht reduziert.


Daten werden automatisch gelöscht

Sie stellen fest, dass Daten in regelmäßigen Abständen automatisch gelöscht werden.

Mögliche Ursache

Höchstwahrscheinlich wird irgendwo in Ihrer Umgebung ein Skript ausgeführt.

Lösungsvorschlag

Sehen Sie in den Logs zur Zeit des Löschvorgangs nach, ob ein schädliches Skript über ein Dashboard oder einen anderen automatisierten Prozess ausgeführt wird.


Instanz kann nicht gelöscht werden

Sie sehen die Fehlermeldung ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request oder die Instanz hat möglicherweise den Flag-Status INSTANCE_RISKY_FLAG_CONFIG.

Mögliche Ursache

  1. Ein anderer Vorgang ist in Bearbeitung.
  2. Die Warnung INSTANCE_RISKY_FLAG_CONFIG wird immer dann ausgelöst, wenn mindestens ein Flag beta verwendet wird.

Lösungsvorschlag

  1. Cloud SQL-Vorgänge werden nicht gleichzeitig ausgeführt. Warten Sie, bis der andere Vorgang abgeschlossen ist.
  2. Entfernen Sie die Einstellungen für das risikobehaftete Flag und starten Sie die Instanz neu.

System bleibt aufgrund großer temporärer Datenmengen hängen

Das System bleibt aufgrund großer temporärer Datenmengen hängen.

Mögliche Ursache

Abhängig von den Abfragen und der Auslastung kann das System viele temporäre Tabellen gleichzeitig erstellen.

Lösungsvorschlag

Leider können Sie die ibtmp1-Datei nur durch einen Neustart des Dienstes verkleinern.

Eine Möglichkeit, das Problem zu beheben, besteht darin, die temporäre Tabelle mit ROW_FORMAT=COMPRESSED zu erstellen, sodass sie in Tablespaces für Dateien im temporären Dateiverzeichnis gespeichert wird. Allerdings sind mit dem Erstellen und Entfernen eines Tablespace für jede temporäre Tabelle Leistungskosten verbunden.


Schwerwiegender Fehler beim Upgrade

Beim Upgrade von Ressourcen auf der Instanz ist folgende Fehlermeldung zu sehen: ERROR_INTERNAL_FATAL.

Mögliche Ursache

Dafür gibt es viele mögliche Gründe.

Lösungsvorschlag

Die Logs enthalten möglicherweise mehr Informationen. Sie benötigen jedoch wahrscheinlich in jedem Fall Hilfe vom Kundensupport, um die Neuerstellung der Instanz zu erzwingen.


Instanz bleibt beim Neustart hängen, nachdem der Speicherplatz ausgeschöpft ist

Die Instanz bleibt beim Neustart hängen, nachdem der Speicherplatz ausgeschöpft ist.

Mögliche Ursache

Die automatische Speichererweiterung ist nicht aktiviert.

Lösungsvorschlag

Wenn Ihre Instanz keinen Speicherplatz mehr hat und die automatische Speichererweiterung nicht aktiviert ist, geht Ihre Instanz offline. Dies können Sie vermeiden, wenn Sie die Instanz bearbeiten und die automatische Speichererweiterung aktivieren.



Langsames Herunterfahren beim Neustart

Langsames Herunterfahren beim Neustart.

Mögliche Ursache

Beim Herunterfahren einer Instanz können alle ausstehenden Verbindungen, die nicht innerhalb von 60 Sekunden beendet werden, ein nicht ordnungsgemäßes Herunterfahren verursachen.

Lösungsvorschlag

Verwenden Sie nur Verbindungen von weniger als 60 Sekunden, so kann in den meisten Fällen das nicht ordnungsgemäße Herunterfahren vermieden werden. Dies gilt auch für Verbindungen, die über die Eingabeaufforderung der Datenbank hergestellt werden. Wenn Sie diese Verbindungen mehrere Stunden oder Tage lang geöffnet lassen, kann dies das Herunterfahren beeinträchtigen.


Zugriff für Nutzer verweigert

Folgende Fehlermeldung ist zu sehen: Access denied for user 'XXX'@'XXX' (using password: XXX).

Mögliche Ursache

Dies kann mehrere Ursachen haben:

  • Der Nutzername (oder das Passwort) ist falsch.
  • Der Nutzer stellt eine Verbindung von einem anderen Ort als von @XXX her.
  • Der Nutzer hat nicht die richtigen Berechtigungen für die Datenbank, zu der er eine Verbindung herstellen möchte.

Lösungsvorschlag

  • Prüfen Sie den Nutzernamen und das zugehörige Passwort.
  • Prüfen Sie den Ursprung der Verbindung, um festzustellen, ob sie mit der Zugriffsberechtigung des Nutzers übereinstimmt.
  • Prüfen Sie die Berechtigungen des Nutzers in der Datenbank.

Nutzer kann nicht gelöscht werden

Sie können einen Datenbanknutzer nicht löschen.

Mögliche Ursache

Der Nutzer ist Inhaber von Objekten in der Datenbank, die davon abhängig sind. Zuerst müssen Sie diese Objekte löschen oder diese einem anderen Nutzer zuweisen.

Lösungsvorschlag

Finden Sie heraus, welche Objekte vom Nutzer abhängig sind, löschen Sie diese Objekte oder weisen Sie sie einem anderen Nutzer zu.


Einer vorhandenen Instanz in einer freigegebenen VPC kann keine private IP-Adresse zugewiesen werden

Sie können einer vorhandenen Instanz in einer freigegebenen VPC keine private IP-Adresse zuweisen.

Mögliche Ursache

Der Grund dafür ist, dass eine Cloud SQL-Instanz beim Erstellen automatisch mit einem Mandantenprojekt verknüpft wird. Dies gilt auch für alle Cloud SQL-Instanzen innerhalb dieses Projekts. Wenn die erstellte Instanz jedoch eine private IP-Adresse in einer freigegebenen VPC verwendet, wird sie mit dem Mandantenprojekt verknüpft, das dem Hostprojekt der freigegebenen VPC zugeordnet ist.

Lösungsvorschlag

Sie können eine neue Cloud SQL-Instanz erstellen, die die vorhandene ersetzt.


Bestimmte Abfragen werden langsam ausgeführt

Die CPU-Auslastung ist durchgehend hoch.

Mögliche Ursache

Abfragen können aus vielen Gründen langsam sein, hauptsächlich aufgrund bestimmter Aspekte der Datenbank. Ein Grund, der sich auf Cloud SQL auswirken kann, ist die Netzwerklatenz, wenn sich die Quellressource (Autor oder Leser) und die Zielressource (Cloud SQL) in verschiedenen Regionen befinden.

Lösungsvorschlag

Lesen Sie unter Allgemeine Leistungstipps nach. Beachten Sie dabei insbesondere folgende Punkte:

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 Lantenzzeiten.
  • Prüfen Sie den Ausgangsort des Lesebefehls auf den Standort der Datenbank – längere Latenzzeiten beeinträchtigen die Leseleistung noch mehr als die Schreibleistung.
Für eine möglichst geringe Latenz sollten sich die Quell- und Zielressourcen in derselben Region befinden.


Es wird angegeben, dass nicht genügend Arbeitsspeicher vorhanden ist, aber in Monitoring-Diagrammen wird dies nicht angezeigt

Eine Instanz schlägt fehl und meldet Out of memory, aber die Diagramme der Konsole oder von {monitoring_name} zeigen, dass noch Arbeitsspeicher vorhanden ist.

Mögliche Ursache

Neben der Arbeitslast gibt es weitere Faktoren, die sich auf die Speichernutzung auswirken können, z. B. die Anzahl der aktiven Verbindungen und internen Overhead-Prozesse. Diese werden nicht immer in den Monitoring-Diagrammen widergespiegelt.

Lösungsvorschlag

Die Instanz muss genügend Kapazität für die Arbeitslast und zusätzlichen Overhead haben.

Replikation

Klicken Sie auf die Links in der Tabelle, um weitere Informationen zu erhalten:

Problem Mögliche Ursache Lösungsvorschlag
Beim Erstellen hat das Lesereplikat nicht repliziert. Nachdem das Binärlogging aktiviert wurde, muss mindestens eine Sicherung erstellt worden sein. Warten Sie, bis mindestens eine Sicherung erstellt wurde, nachdem Sie binäre Logs aktiviert haben.
Lesereplikat kann nicht erstellt werden – unbekannter Fehler. Dies kann viele Ursachen haben. Weitere Informationen finden Sie in den Logs.
Laufwerk ist voll. Der Speicherplatz des Laufwerks der primären Instanz kann während der Replikaterstellung erschöpft werden. Aktualisieren Sie die primäre Instanz mit einem größeren Laufwerk.
Replikatinstanz verwendet zu viel Arbeitsspeicher. Replikate können häufig angeforderte Lesevorgänge im Cache speichern. Starten Sie die Replikatinstanz neu, um den temporären Speicherplatz freizugeben.
Replikation gestoppt. Der maximale Speicherplatz wurde erreicht und die automatische Speichererweiterung ist nicht aktiviert. Aktivieren Sie die automatische Speichererweiterung.
Replikationsverzögerung ist durchgehend hoch. Die kann viele verschiedene Ursachen haben. Erhöhen Sie die Instanzgröße des Replikats oder reduzieren Sie die Last auf die Datenbank.

Beim Erstellen hat das Lesereplikat nicht repliziert

Beim Erstellen hat das Lesereplikat nicht repliziert.

Mögliche Ursache

Die primäre Instanz muss Bin-Logs von mindestens einer Woche haben, andernfalls können Replikate nicht repliziert werden.

Lösungsvorschlag

Warten Sie, bis genügend Bin-Logs vorhanden sind.


Lesereplikat kann nicht erstellt werden – unbekannter Fehler

Das Lesereplikat kann nicht erstellt werden – unknown error.

Mögliche Ursache

Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler.

Lösungsvorschlag

Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden. Lautet der Fehler set Service Networking service account as servicenetworking.serviceAgent role on consumer project, deaktivieren Sie die Service Networking API und aktivieren Sie sie dann wieder. Dadurch wird das Dienstkonto erstellt, das erforderlich ist, um den Prozess fortzusetzen.


Laufwerk ist voll

error: disk is full

Mögliche Ursache

Das Laufwerk der primären Instanz kann während der Replikaterstellung zu voll werden.

Lösungsvorschlag

Bearbeiten Sie die primäre Instanz, um sie auf ein größeres Laufwerk zu aktualisieren.


Replikatinstanz verwendet zu viel Arbeitsspeicher

Die Replikatinstanz verwendet zu viel Arbeitsspeicher.

Mögliche Ursache

Das Replikat verwendet temporären Speicher zum Speichern häufig angeforderter Lesevorgänge im Cache, was dazu führen kann, dass es mehr Speicher als die primäre Instanz verwendet.

Lösungsvorschlag

Starten Sie die Replikatinstanz neu, um den temporären Speicherplatz freizugeben.


Replikation gestoppt

Die Replikation wurde gestoppt.

Mögliche Ursache

Das maximale Speicherlimit wurde erreicht und >automatic storage increase is disabled.

Lösungsvorschlag

Bearbeiten Sie die Instanz, um automatic storage increase zu aktivieren.


Replikationsverzögerung ist durchgehend hoch

Die Replikationsverzögerung ist durchgehend hoch.

Mögliche Ursache

Die Schreiblast ist für das Replikat zu hoch. Die Replikationsverzögerung tritt auf, wenn der SQL-Thread auf einem Replikat nicht mit dem E/A-Thread Schritt halten kann. Einige Arten von Abfragen oder Arbeitslasten können vorübergehend oder dauerhaft zu einer hohen Replikationsverzögerung für ein bestimmtes Schema führen. Typische Ursachen für Replikationsverzögerungen sind:

  • Alle Tabellen müssen einen eindeutigen Schlüssel/Primärschlüssel haben. Jede Aktualisierung einer solchen Tabelle ohne eindeutigen bzw. Primärschlüssel führt zu vollständigen Tabellenscans auf dem Replikat.
  • Abfragen wie DELETE ... WHERE field < 50000000 führen bei der zeilenbasierten Replikation zu einer Replikationsverzögerung, da sich eine große Anzahl von Aktualisierungen auf dem Replikat ansammelt.

Lösungsvorschlag

Bearbeiten Sie die Instanz, um die Größe des Replikats zu erhöhen, oder verringern Sie die Last auf der Datenbank.