Fehlerbehebung

Prüfen Sie, ob Ihre Frage oder das Problem bereits auf einer der folgenden Seiten beantwortet wurde:

Folgende Themen werden auf dieser Seite behandelt:

Sicherung und Wiederherstellung

Problem Fehlerbehebung
Der Status des aktuellen Vorgangs wird nicht angezeigt. Die Google Cloud Console meldet erfolgreiche oder fehlgeschlagene Vorgänge nur, wenn diese abgeschlossen sind. Es werden keine Warnungen oder andere Updates angezeigt.

Führen Sie den Befehl gcloud sql operations list aus, um alle Vorgänge für die angegebene Cloud SQL-Instanz aufzulisten.
Sie möchten wissen, wer einen On-Demand-Sicherungsvorgang ausgelöst hat. Auf der Benutzeroberfläche wird nicht der Nutzer angezeigt, der einen Vorgang gestartet hat.

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:

  • cloudsql.googleapis.com/postgres.log
  • Wenn Cloud-Audit-Logs aktiviert ist und Sie die erforderlichen Berechtigungen zum Aufrufen von Logs haben, ist möglicherweise auch cloudaudit.googleapis.com/activity verfügbar.
Nachdem eine Instanz gelöscht wurde, können Sie keine Sicherung der Instanz erstellen.

Nachdem eine Instanz dauerhaft gelöscht wurde, ist keine Datenwiederherstellung mehr möglich. Wenn die Instanz jedoch wiederhergestellt wird, werden auch ihre Sicherungen wiederhergestellt. Weitere Informationen zum Wiederherstellen einer gelöschten Instanz finden Sie unter Wiederherstellungssicherungen.

Wenn Sie einen Exportvorgang durchgeführt haben, können Sie eine neue Instanz erstellen und dann mit einem Importvorgang die Datenbank neu erstellen. Exporte werden in Cloud Storage geschrieben und Importe werden von dort gelesen.
Eine automatische Sicherung bleibt viele Stunden hängen und kann nicht abgebrochen werden. Sicherungen können je nach Datenbankgröße sehr lange dauern.

Wenn Sie den Vorgang wirklich abbrechen müssen, können Sie den Kundensupport bitten, einen Neustart der Instanz zu erzwingen (force restart).
Ein Wiederherstellungsvorgang kann fehlschlagen, wenn ein oder mehrere Nutzer, auf die in der SQL-Dumpdatei verwiesen wird, nicht vorhanden sind. Vor dem Wiederherstellen eines SQL-Dumps müssen alle Datenbanknutzer, die Inhaber von Objekten in der Dumpdatenbank sind oder Berechtigungen dafür haben, in der Zieldatenbank vorhanden sein. Andernfalls kann der Wiederherstellungsvorgang die Objekte nicht mit den ursprünglichen Eigentumsrechten oder Berechtigungen neu erstellen.

Erstellen Sie die Datenbanknutzer, bevor Sie den SQL-Dump wiederherstellen.
Sie möchten die Anzahl der Tage für die Aufbewahrung automatischer Sicherungen von sieben auf 30 Tage oder länger erhöhen. Sie können die Anzahl der beizubehaltenden automatisierten Sicherungen auf 1 bis 365 festlegen. Automatische Sicherungen werden basierend auf dem konfigurierten Aufbewahrungswert regelmäßig entfernt. Leider bedeutet dies, dass die jeweils aktuell sichtbaren Sicherungen die einzigen automatischen Sicherungen sind, aus denen Sie wiederherstellen können.

Wenn Sie Sicherungen unbegrenzt aufbewahren möchten, können Sie 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 bis die Instanz gelöscht wird, zu der sie gehören. Da diese Art der Sicherung nicht automatisch gelöscht wird, kann sich dies auf die Abrechnung auswirken.
Eine automatische Sicherung ist fehlgeschlagen und Sie haben keine E-Mail-Benachrichtigung erhalten. Damit Cloud SQL Sie über den Status der Sicherung benachrichtigt, konfigurieren Sie eine logbasierte Benachrichtigung.
Eine Instanz löst wiederholt einen Fehler aus, weil der Status zwischen "Fehler" und "Sicherung wiederherstellen" wechselt. Versuche, nach der Wiederherstellung eine Verbindung zur Datenbank herzustellen und diese zu verwenden, schlagen fehl.
  • Möglicherweise sind zu viele offene Verbindungen vorhanden. Zu viele Verbindungen können durch Fehler verursacht werden, die bei einer Verbindung auftreten, wenn keine autovacuum-Einstellungen zum Bereinigen inaktiver Verbindungen vorhanden sind.
  • Ein Wechsel kann auftreten, wenn benutzerdefinierter Code Wiederholungslogik verwendet, die nach einigen Fehlern nicht beendet wird.
  • Möglicherweise ist zu viel Traffic vorhanden. Verwenden Sie Verbindungs-Pooling und andere Best Practices für Verbindungen.

Versuchen Sie Folgendes:

  1. Prüfen Sie, ob die Datenbank für autovacuum eingerichtet ist.
  2. Prüfen Sie, ob im benutzerdefinierten Code eine Verbindungswiederholungslogik eingerichtet ist.
  3. Reduzieren Sie den Traffic, bis die Datenbank wiederhergestellt ist, und erhöhen Sie ihn dann langsam wieder.
Sie stellen fest, dass Daten fehlen, wenn Sie einen Sicherungs-/Wiederherstellungsvorgang durchführen. Tabellen wurden als nicht geloggt erstellt. Beispiel:

CREATE UNLOGGED TABLE ....

Diese Tabellen sind nicht in einer Wiederherstellung aus einer Sicherung enthalten:

  • Die Inhalte nicht geloggter Tabellen haben bei einer HA-Instanz keinen Failover.
  • Nicht geloggte Tabellen überstehen keine Postgres-Abstürze.
  • Nicht geloggte Tabellen werden nicht in Lesereplikate repliziert.
  • Nicht geloggte Tabellen werden während der Sicherungswiederherstellung automatisch gelöscht.

Die Lösung besteht darin, keine nicht geloggten Tabellen zu verwenden, wenn Sie diese Tabellen über eine Sicherung wiederherstellen möchten. Bei der Wiederherstellung aus einer Datenbank, die bereits nicht geloggte Tabellen enthält, können Sie die Datenbank in einer Datei speichern und die Daten aktualisieren, nachdem Sie die Dumpdatei in ALTER TABLE bis SET LOGGED in diesen Tabellen geändert haben.

Import und Export abbrechen

Problem Fehlerbehebung
Fehlermeldung: You can't cancel operation [operation-ID] because this operation isn't in progress.

Sie versuchen, einen Import- oder Exportvorgang abzubrechen, der abgeschlossen, fehlgeschlagen oder abgebrochen ist. Wenn der Vorgang ausgeführt wird, können Sie ihn abbrechen.
Fehlermeldung: You can't cancel operation [operation-ID] because Cloud SQL doesn't support the cancellation of an [operation-type] operation.

Cloud SQL unterstützt nicht das Abbrechen des Vorgangs, da es einen anderen Vorgangstyp als IMPORT oder EXPORT hat.
Fehlermeldung: The [operation-type] operation isn't cancelled. Wait and retry in a few seconds.

Cloud SQL kann den Import- oder Exportvorgang derzeit nicht abbrechen. Bitte versuch es in ein paar Sekunden noch einmal. Wenn das Problem weiterhin besteht, wenden Sie sich an den Google Cloud Support.

Klonen

Problem Fehlerbehebung
Der Klonvorgang schlägt mit dem Fehler constraints/sql.restrictAuthorizedNetworks fehl. 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.

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.
Fehlermeldung: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Help Token: [help-token-id].

Sie versuchen, die Google Cloud Console zu verwenden, um eine Instanz mit einer privaten IP-Adresse zu klonen, aber Sie haben den zugewiesenen IP-Bereich, den Sie verwenden möchten, nicht angegeben, und die Quellinstanz wird nicht mit dem angegebenen Bereich erstellt. Dadurch wird die geklonte Instanz in einem zufälligen Bereich erstellt.

Klonen Sie mit gcloud die Instanz und geben Sie einen Wert für den
Parameter --allocated-ip-range-name an. Weitere Informationen finden Sie unter Instanz mit einer privaten IP-Adresse klonen.

Verbinden

Problem Fehlerbehebung
Aborted connection. 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.

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 muss die Anwendung einen Wiederholungsversuch ausführen oder ordnungsgemäß fehlschlagen.

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

  1. Exponentielle Backoffs. 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.
Certificate verify failed

Die Clientzertifikate sind abgelaufen oder der Pfad zu den Zertifikaten ist nicht korrekt.

Erstellen Sie die Zertifikate neu, indem Sie sie neu erstellen.
FATAL: database 'user' does not exist gcloud sql connect --user funktioniert nur mit dem standardmäßigen postgres-Nutzer.

Stellen Sie eine Verbindung mit dem Standardnutzer her und wechseln Sie die Nutzer.
Sie möchten wissen, wer verbunden ist. Melden Sie sich in der Datenbank an und führen Sie den folgenden Befehl aus:


SELECT datname,
usename,
application_name as appname,
client_addr,
state,
now() - backend_start as conn_age,
now() - state_change as last_activity_age
FROM pg_stat_activity
WHERE backend_type = 'client backend'
ORDER BY 6 DESC
LIMIT 20

Hostname/IP does not match certificate's altnames: Host: localhost. is not in the cert's altnames.

Die Hostadresse stimmt nicht mit der Adresse in den alternativen Namen des Serverzertifikats überein.

Wenn Sie Node.js mit verify-full oder einem Äquivalent nutzen, verwenden Sie bitte den DNS-Namen für den Parameter servername. Den DNS-Namen finden Sie im Serverzertifikat mit openssl. Beispiel: openssl x509 -in server-cert.pem -noout -text |grep 'DNS:'.


 ssl: {
  rejectUnauthorized: true,
  ca: fs.readFileSync("/path/to/server/CA"),
  servername: 'N-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx.us-central1.sql.goog'
}

Instanzen erstellen

Problem Fehlerbehebung
Fehlermeldung: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Im zugewiesenen IP-Bereich sind keine weiteren Adressen verfügbar. Es gibt dazu mehrere mögliche Ursachen:

  • Die Größe des zugewiesenen IP-Bereichs für die private Dienstverbindung ist kleiner als /24.
  • Die zugewiesene IP-Adresse für die private Dienstverbindung ist für die Anzahl der Cloud SQL-Instanzen zu klein.
  • Die Anforderungen bezüglich der Größe des zugewiesenen IP-Bereichs sind höher, wenn Instanzen in mehreren Regionen erstellt werden. Siehe Größe des zugewiesenen Bereichs.

Zur Behebung dieses Problems können Sie entweder den vorhandenen zugewiesenen IP-Bereich erweitern oder der privaten Dienstverbindung einen zusätzlichen IP-Bereich zuweisen. Weitere Informationen finden Sie unter IP-Adressbereich zuweisen.

Wenn Sie beim Erstellen der Cloud SQL-Instanz das Flag --allocated-ip-range-name verwendet haben, können Sie nur den angegebenen IP-Bereich erweitern.

Achten Sie beim Zuweisen eines neuen Bereichs darauf, dass sich die Zuweisung nicht mit vorhandenen Zuweisungen überschneidet.

Nachdem Sie einen neuen IP-Bereich erstellt haben, aktualisieren Sie das VPC-Peering mit folgendem Befehl:


gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=OLD_RESERVED_RANGE_NAME,NEW_RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID \
--force

Wenn Sie eine bestehende Zuweisung erweitern, müssen Sie darauf achten, dass der Zuweisungsbereich nur vergrößert und nicht verkleinert wird. Wenn die ursprüngliche Zuweisung beispielsweise 10.0.10.0/24 war, sollte die neue Zuweisung mindestens 10.0.10.0/23 lauten.

Wenn Sie von einer /24-Zuweisung ausgehen, ist es im Allgemeinen eine gute Faustregel, /mask für jede Bedingung (zusätzliche Instanztypgruppe, zusätzliche Region) um 1 zu verringern. Wenn Sie beispielsweise versuchen, beide Instanztypgruppen mit derselben Zuweisung zu erstellen, reicht es aus, von /24 zu /23 zu wechseln.

Aktualisieren Sie nach dem Erweitern eines vorhandenen IP-Bereichs das VPC-Peering mit folgendem Befehl:


gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
Fehlermeldung: Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID]. Versuchen Sie noch einmal, die Cloud SQL-Instanz zu erstellen.
Fehlermeldung: Failed to create subnetwork. Required 'compute.projects.get' permission for PROJECT_ID. Wenn Sie eine Instanz mithilfe einer privaten IP-Adresse erstellen, wird mit der Service Networking API zur richtigen Zeit ein Dienstkonto erstellt. Wenn Sie die Service Networking API erst kürzlich aktiviert haben, wird das Dienstkonto möglicherweise nicht erstellt und die Instanzerstellung schlägt fehl. In diesem Fall müssen Sie warten, bis das Dienstkonto im gesamten System angewendet wurde, oder es manuell mit den erforderlichen Berechtigungen hinzufügen.

Exportieren

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.
Fehler beim Erstellen der Erweiterung. Die Dumpdatei enthält Verweise auf eine nicht unterstützte Erweiterung.

Bearbeiten Sie zum Entfernen der Referenzen die Dumpdatei.
Fehler beim Verwenden von pg_dumpall. Für die Verwendung des Dienstprogramms pg_dumpall mit dem Flag --global ist die Rolle „Superuser“ erforderlich. Diese Rolle wird in Cloud SQL for PostgreSQL jedoch nicht unterstützt. Verwenden Sie das Flag --no-role-passwords, um Fehler bei der Ausführung von Exportvorgängen mit Nutzernamen zu vermeiden.
Beim Exportvorgang tritt vor dem Export eine Zeitüberschreitung auf und Sie sehen die Fehlermeldung Could not receive data from client: Connection reset by peer.. Wenn Cloud Storage innerhalb eines bestimmten Zeitraums keine Daten empfängt, in der Regel innerhalb etwa sieben Minuten, wird die Verbindung zurückgesetzt. Es kann sein, dass die Ausführung der ersten Exportabfrage zu lange dauert.

Führen Sie einen manuellen Export mit dem pg_dump-Tool durch.
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.

Flags

Problem Fehlerbehebung
Sie legen die Zeitzone für eine Sitzung fest, die aber beim Abmelden abläuft.

Stellen Sie eine Verbindung zur Datenbank her und legen Sie die Datenbankzeitzone auf die gewünschte Zeitzone pro Nutzer oder Datenbank fest.

In Cloud SQL for PostgreSQL können Sie Folgendes angeben: Diese Einstellungen bleiben nach dem Schließen einer Sitzung erhalten. Dadurch wird eine .conf-Konfiguration imitiert:


ALTER DATABASE dbname SET TIMEZONE TO 'timezone';
ALTER USER username SET TIMEZONE TO 'timezone';

Diese Einstellungen gelten nur für neue Verbindungen zur Datenbank. Wenn Sie die Änderung der Zeitzone sehen möchten, trennen Sie die Verbindung zur Instanz und stellen Sie dann die Verbindung wieder her.

Hochverfügbarkeit

Problem Fehlerbehebung
Sie können die Messwerte für ein manuelles Failover nicht finden. Nur automatische Failovers werden in den Messwerten aufgenommen.
Cloud SQL-Instanzressourcen (CPU und RAM) sind zu fast 100 % ausgelastet, wodurch die Hochverfügbarkeitsinstanz abstürzt. Die Rechnerkapazitäten der Instanz reichen für die Arbeitslast nicht aus.

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

Problem Fehlerbehebung
Fehlermeldung: permission denied for schema public Wenn bei PostgreSQL 15 und höher die Zieldatenbank aus template0 erstellt wird, kann der Import von Daten fehlschlagen. Zum Beheben dieses Problems erteilen Sie dem Nutzer cloudsqlsuperuser öffentliche Schemaberechtigungen mit dem SQL-Befehl GRANT ALL ON SCHEMA public TO cloudsqlsuperuser.
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.
Nach dem Import von Daten ist die Nutzung Ihres Datenlaufwerks viel höher.

Nach dem Import der Daten kann es zu einer unerwarteten Laufwerksnutzung kommen. Diese Nutzung kann auf die Wiederherstellung zu einem bestimmten Zeitpunkt zurückzuführen sein.

Wenn Sie dieses Problem beheben möchten, deaktivieren Sie nach dem Import der Daten die Wiederherstellung zu einem bestimmten Zeitpunkt, wenn Sie Logs löschen und Speicherplatz wiederherstellen möchten. Beachten Sie, dass die Verringerung des verwendeten Speicherplatzes nicht die Größe des für die Instanz bereitgestellten Speichers reduziert.
Fehlermeldung: GRANT stderr: ERROR: must be member of role ROLE_NAME

Diese Fehlermeldung wird angezeigt, wenn Sie versuchen, eine in Cloud Storage hochgeladene SQL-Dumpdatei in eine Cloud SQL-Datenbank zu importieren, und der Importjob etwa vier Tage lang ausgeführt wurde.

ROLE_NAME ist eine benutzerdefinierte Datenbankrolle, die in der PostgreSQL-Quelldatenbank definiert ist. Der cloudsqlsuperuser-Standardnutzer importiert die SQL-Dumpdatei. Dieser Nutzer gehört jedoch möglicherweise nicht zur Rolle ROLE_NAME.

So beheben Sie das Problem:

  1. Erstellen Sie die Rolle ROLE_NAME in der Zieldatenbank, in die Sie die SQL-Dumpdatei importieren.

  2. Verwenden Sie den Nutzer cloudsqlsuperuser nicht zum Importieren der Datei. Geben Sie stattdessen in der Zieldatenbank einen Nutzer an, der Mitglied der Rolle ROLE_NAME ist. Führen Sie den folgenden Befehl aus, um den Nutzer anzugeben:

    gcloud sql import sql INSTANCE URI [--async]
    [--database=DATABASE, -d DATABASE] [--user=USER] [GCLOUD_WIDE_FLAG …]

In Vertex AI einbinden

Problem Fehlerbehebung
Fehlermeldung: Google ML integration API is supported only on Postgres version 12 or above. Zum Aktivieren der Vertex AI-Einbindung in Cloud SQL benötigen Sie die Cloud SQL for PostgreSQL-Datenbank Version 12 oder höher. Informationen zum Upgrade Ihrer Datenbank auf diese Version finden Sie unter Direkte Datenbankaktualisierung durchführen.
Fehlermeldung: Google ML Integration API is not supported on shared core instance. Please upsize your machine type. Wenn Sie für den Maschinentyp Ihrer Instanz einen freigegebenen Kern ausgewählt haben, können Sie die Vertex AI-Einbindung nicht in Cloud SQL aktivieren. Führen Sie ein Upgrade Ihres Maschinentyps auf einen dedizierten Kern durch. Weitere Informationen finden Sie unter Maschinentyp.
Fehlermeldung: Google ML Integration is unsupported for this maintenance version. Please follow https://cloud.google.com/sql/docs/postgres/self-service-maintenance to update the maintenance version of the instance. Zum Aktivieren der Vertex AI-Einbindung in Cloud SQL muss die Wartungsversion Ihrer Instanz R20240130 oder höher sein. Informationen zum Upgrade Ihrer Instanz auf diese Version finden Sie unter Self-Service-Wartung.
Fehlermeldung: Cannot invoke ml_predict_row if 'cloudsql.enable_google_ml_integration' is off. Das Datenbank-Flag cloudsql.enable_google_ml_integration ist deaktiviert. Cloud SQL kann nicht in Vertex AI eingebunden werden.

Verwenden Sie zum Aktivieren dieses Flags den Befehl gcloud sql instances patch:

gcloud sql instances patch INSTANCE_NAME --database-flags cloudsql.enable_google_ml_integration=on

Ersetzen Sie INSTANCE_NAME durch den Namen der primären Cloud SQL-Instanz.
Fehlermeldung: Failed to connect to remote host: Connection refused. Die Einbindung zwischen Cloud SQL und Vertex AI ist nicht aktiviert. Verwenden Sie zum Aktivieren dieser Einbindung den gcloud sql instances patch-Befehl:

gcloud sql instances patch INSTANCE_NAME
--enable-google-ml-integration

Ersetzen Sie INSTANCE_NAME durch den Namen der primären Cloud SQL-Instanz.
Fehlermeldung: Vertex AI API has not been used in project PROJECT_ID before or it is disabled. Enable it by visiting /apis/api/aiplatform.googleapis.com/overview?project=PROJECT_ID then retry. Die Vertex AI-API ist nicht aktiviert. Weitere Informationen zum Aktivieren dieser API finden Sie unter Datenbankeinbindung mit Vertex AI aktivieren.
Fehlermeldung: Permission 'aiplatform.endpoints.predict' denied on resource. Vertex AI-Berechtigungen werden dem Cloud SQL-Dienstkonto für das Projekt, in dem sich die Cloud SQL-Instanz befindet, nicht hinzugefügt. Weitere Informationen zum Hinzufügen dieser Berechtigungen zum Dienstkonto finden Sie unter Datenbankeinbindung mit Vertex AI aktivieren.
Fehlermeldung: Publisher Model `projects/PROJECT_ID/locations/REGION_NAME/publishers/google/models/MODEL_NAME` not found. Das ML-Modell oder das LLM sind in Vertex AI nicht vorhanden.
Fehlermeldung: Resource exhausted: grpc: received message larger than max. Die Größe der Anfrage, die Cloud SQL an Vertex AI übergibt, überschreitet das gRPC-Limit von 4 MB pro Anfrage.
Fehlermeldung: Cloud SQL attempts to send a request to Vertex AI. However, the instance is in the %s region, but the Vertex AI endpoint is in the %s region. Make sure the instance and endpoint are in the same region. Cloud SQL versucht, eine Anfrage an Vertex AI zu senden. Die Instanz befindet sich jedoch in einer, der Vertex AI-Endpunkt in einer anderen Region. Zur Behebung dieses Problems müssen sich sowohl die Instanz als auch der Endpunkt in derselben Region befinden.
Fehlermeldung: The Vertex AI endpoint isn't formatted properly. Der Vertex AI-Endpunkt ist nicht richtig formatiert. Weitere Informationen finden Sie unter Private Endpunkte für Onlinevorhersagen verwenden.
Fehlermeldung: Quota exceeded for aiplatform.googleapis.com/online_prediction_requests_per_base_model with base model: textembedding-gecko. Die Anzahl der Anfragen, die Cloud SQL an Vertex AI übergibt, überschreitet das Limit von 1.500 Anfragen pro Minute, Region, Modell und Projekt.

Logging

Problem Fehlerbehebung
Logging beansprucht viel CPU-Leistung und Arbeitsspeicher auf Ihrer Cloud SQL-Instanz. Das Logging muss optimiert werden.

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-Logs wurden nicht gefunden. 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.
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. Für die Erfassung detaillierter und personenidentifizierbarer Informationen wie diesen müssen Sie Audit-Logging aktivieren.
Logdateien sind schwer zu lesen. Sie können die Logs alternativ im JSON- oder Textformat aufrufen. Sie können zum Herunterladen der Logs den Befehl gcloud logging read zusammen mit Linux-Nachbearbeitungsbefehlen verwenden.

So laden Sie die Logs im JSON-Format herunter:


gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d" \
> downloaded-log.json

So laden Sie die Logs als TEXT herunter:


gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
--order=asc
> downloaded-log.txt
Es wurden keine Abfragelogs in PostgreSQL-Logs gefunden. Sie müssen die pgaudit-Flags aktivieren.
  1. Stellen Sie von einem Terminal eine Verbindung zu Ihrer Datenbank her: 
    
gcloud sql connect INSTANCE_NAME
  2. Führen Sie folgenden Befehl aus, um die Erweiterung zu erstellen: 
    
CREATE EXTENSION pgaudit;
  3. Beenden Sie die Datenbank und führen Sie von einem Terminal folgenden Befehl aus: 
    
gcloud sql instances patch INSTANCE_NAME \
--database-flags=cloudsql.enable_pgaudit=on,pgaudit.log=all

Instanzen verwalten

Problem Fehlerbehebung
Sie möchten herausfinden, welche Abfragen gerade ausgeführt werden. Stellen Sie eine Verbindung zur Datenbank her und führen Sie die folgende Abfrage aus:

SELECT datname, usename, application_name as appname, client_addr, state, now() - backend_start as conn_age, now() - xact_start as xact_age, now() - query_start as query_age, now() - state_change as last_activity_age, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY 8 DESC LIMIT 20;

Sie möchten herausfinden, welche Einheiten für ein bestimmtes Feld verwendet werden. Stellen Sie eine Verbindung zur Datenbank her und führen Sie die folgende Abfrage (mit Ihrem eigenen FIELD_NAME) aus:

SELECT name, setting, unit FROM pg_settings WHERE name = 'FIELD_NAME'.
Sie möchten den aktuellen Wert einer Datenbankeinstellung ermitteln. Stellen Sie eine Verbindung zur Datenbank her und führen Sie die folgende Abfrage (mit Ihrem eigenen SETTING_NAME) aus:

SHOW SETTING_NAME;

Führen Sie SHOW ALL; aus, um alle Einstellungen zu sehen.
Sie möchten einen blockierten Hintergrundprozess beenden. Der Nutzer muss die Rolle pg_signal_backend haben.

Führen Sie folgende Befehle aus:

  1. 
      GRANT pg_signal_backend TO USERNAME;
  2. Suchen Sie nach der Prozess-ID des blockierten oder hängenden Prozesses: 
    
      SELECT pid, usename, state, query FROM pg_stat_activity;
  3. Beenden Sie einen laufenden oder inaktiven Prozess mit den folgenden Befehlen: 
    
      SELECT pg_cancel_backend(pid)
            FROM pg_stat_activity
            WHERE usename = 'USERNAME';
      
      
    
      SELECT pg_terminate_backend(pid)
            FROM pg_stat_activity
            WHERE usename = 'USERNAME';
Die Instanz nutzt fast 100 % der Transaktions-IDs. Das interne Monitoring warnt, dass die Instanz fast 100 % der Transaktions-IDs verbraucht. Sie sollten einen transaktionalen Wraparound vermeiden, der Schreibvorgänge blockieren kann.

Der Job "Autovacuum" wird unter Umständen blockiert oder die Transaktions-IDs werden nicht schnell genug zurück eingereicht, um mit der Arbeitslast Schritt zu halten.

Lesen Sie diese Self-Service-Tipps zum Umgang mit TXID-Wraparound, um Ausfälle aufgrund von Transaktions-Wraparound-Problemen zu vermeiden.

Allgemeine Hinweise zur Abstimmung finden Sie unter VACUUM-Vorgänge in PostgreSQL optimieren, überwachen und korrigieren.
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.
Daten werden automatisch gelöscht. Höchstwahrscheinlich wird irgendwo in Ihrer Umgebung ein Skript ausgeführt.

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 möglicherweise 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.

Im Folgenden sind einige mögliche Erklärungen aufgeführt:

  • Ein anderer Vorgang ist in Bearbeitung. Cloud SQL-Vorgänge werden nicht gleichzeitig ausgeführt. Warten Sie, bis der andere Vorgang abgeschlossen ist.
  • Die Warnung INSTANCE_RISKY_FLAG_CONFIG wird immer dann ausgelöst, wenn mindestens ein Flag beta verwendet wird. Entfernen Sie die Einstellungen für das risikobehaftete Flag und starten Sie die Instanz neu.
Instanz bleibt aufgrund großer temporärer Datenmengen hängen. Abhängig von den Abfragen und der Auslastung kann das System viele temporäre Tabellen gleichzeitig erstellen.

Sie können 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. Die Logs enthalten zwar möglicherweise weitere Informationen, aber wahrscheinlich benötigen Sie Hilfe vom Kundensupport, um die Neuerstellung der Instanz zu erzwingen.
Instanz bleibt beim Neustart hängen, nachdem der Speicherplatz ausgeschöpft ist. Die automatische Speichererweiterung ist nicht aktiviert.

Wenn der Speicherplatz Ihrer Instanz aufgebraucht ist und die automatische Speichererweiterung nicht aktiviert ist, wird die Instanz offline geschaltet. Dies können Sie vermeiden, wenn Sie die Instanz bearbeiten und die automatische Speichererweiterung aktivieren.
Die lokale primäre Instanz bleibt hängen Google Cloud bietet für Instanzen, die nicht in Cloud SQL enthalten sind, keine Unterstützung.
Langsames Herunterfahren beim Neustart. Beim Herunterfahren einer Instanz können alle ausstehenden Verbindungen, die nicht innerhalb von 60 Sekunden beendet werden, ein nicht ordnungsgemäßes Herunterfahren verursachen.

Wenn Sie Verbindungen von weniger als 60 Sekunden verwenden, 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 geöffnet lassen, kann dies das Herunterfahren beeinträchtigen.
Nutzer kann nicht gelöscht werden. Der Nutzer ist wahrscheinlich Inhaber von Objekten in der Datenbank, die davon abhängig sind. Sie müssen diese Objekte löschen oder einem anderen Nutzer zuweisen.

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

In diesem Thread zu Stack Exchange wird besprochen, wie Sie die Objekte finden, deren Inhaber der Nutzer ist.
Bestimmte Abfragen werden langsam ausgeführt. 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.

Lesen Sie insbesondere die Informationen unter 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.
  • 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 kann fehlschlagen und Out of memory melden, aber in den Google Cloud Console- oder Cloud Monitoring-Diagrammen wird angezeigt, dass noch Arbeitsspeicher vorhanden ist.

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.

Die Instanz muss genügend Kapazität für die Arbeitslast und zusätzlichen Overhead haben.
Gelöschte Instanz wiederherstellen Alle Daten einer Instanz, einschließlich Sicherungen, werden beim Löschen der Instanz dauerhaft entfernt.

Wenn Sie die Daten beibehalten möchten, exportieren Sie diese in Cloud Storage, bevor Sie eine Instanz löschen.

Die Rolle "Cloud SQL-Administrator" enthält die Berechtigung zum Löschen der Instanz. Gewähren Sie diese Rolle nur, wenn nötig, um ein versehentliches Löschen zu vermeiden.
Sie möchten eine vorhandene Cloud SQL-Instanz umbenennen. Das Umbenennen einer vorhandenen Instanz wird nicht unterstützt.

Es gibt noch andere Möglichkeiten, das Ziel zu erreichen, indem eine neue Instanz erstellt wird.

  • Sie können die Instanz klonen, die Sie umbenennen möchten, und einen neuen Namen für die geklonte Instanz festlegen. Auf diese Weise können Sie die neue Instanz erstellen, ohne Daten manuell importieren zu müssen. Wie bei der Erstellung einer neuen Instanz hat die geklonte Instanz eine neue IP-Adresse.
  • Sie können Daten aus Ihrer Instanz in einen Cloud Storage-Bucket exportieren, eine neue Instanz mit dem gewünschten Namen erstellen und anschließend Daten in die neue Instanz importen.

In beiden Fällen können Sie Ihre alte Instanz löschen, nachdem der Vorgang abgeschlossen wurde. Es wird empfohlen, das Klonen zu verwenden, da dies keine Beeinträchtigung der Leistung nach sich zieht und Sie die Einstellungen der Instanzkonfiguration zu Flags, Maschinentyp, Speichergröße und Arbeitsspeicher nicht noch einmal festlegen müssen.
Fehler beim Löschen einer Instanz. Wenn der Löschschutz für eine Instanz aktiviert ist, bestätigen Sie Ihre Pläne, die Instanz zu löschen. Deaktivieren Sie dann den Löschschutz, bevor Sie die Instanz löschen.

Replikation

Problem Fehlerbehebung
Beim Erstellen hat das Lesereplikat nicht repliziert. Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler. Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.
Lesereplikat kann nicht erstellt werden – invalidFlagValue-Fehler Eines der Flags in der Anfrage ist ungültig. Dies kann ein Flag sein, das Sie explizit angegeben haben, oder ein Flag, für das ein Standardwert festgelegt wurde.

Prüfen Sie als Erstes, ob der Wert des Flags max_connections größer oder gleich dem Wert auf der primären Instanz ist.

Wenn das Flag max_connections korrekt festgelegt ist, prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.
Lesereplikat kann nicht erstellt werden – unbekannter Fehler. Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler. 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. Das Laufwerk der primären Instanz kann während der Replikaterstellung zu voll werden. Bearbeiten Sie die primäre Instanz, um sie auf ein größeres Laufwerk zu aktualisieren.
Der Speicherplatz wird erheblich erhöht. Ein Slot, der nicht aktiv zum Erfassen von Daten verwendet wird, führt dazu, dass PostgreSQL unbegrenzt auf WAL-Segmente hält. Dadurch wird der Speicherplatz auf unbestimmte Zeit größer. Wenn Sie die Funktionen zur logischen Replikation und Decodierung in Cloud SQL verwenden, werden Replikationsslots automatisch erstellt und gelöscht. Nicht verwendete Replikationsslots können durch Abfrage der Systemansicht pg_replication_slots und Filterung der Spalte active erkannt werden. Nicht verwendete Slots können verworfen werden, um WAL-Segmente mit dem pg_drop_replication_slot-Befehl zu entfernen.
Die Replikatinstanz verwendet zu viel Arbeitsspeicher. 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.

Starten Sie die Replikatinstanz neu, um den temporären Speicherplatz freizugeben.
Replikation gestoppt. Das maximale Speicherlimit wurde erreicht und die automatische Speichererweiterung ist nicht aktiviert.

Bearbeiten Sie die Instanz, um automatic storage increase zu aktivieren.
Replikationsverzögerung ist durchgehend hoch. 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:
  • Langsame Abfragen des Replikats. Suchen Sie diese und korrigieren Sie sie.
  • 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.

Hier einige mögliche Lösungen:

  • Bearbeiten Sie die Instanz, um die Größe des Replikats zu erhöhen.
  • Reduzieren Sie die Belastung der Datenbank.
  • Senden Sie Lesetraffic an das Lesereplikat.
  • Indexieren Sie die Tabellen.
  • Ermitteln und beheben Sie Probleme mit langsamen Schreibabfragen.
  • Erstellen Sie das Replikat neu.
Fehler beim Neuerstellen von Indexen in PostgreSQL 9.6. Sie erhalten von PostgreSQL einen Fehler, der Sie darüber informiert, dass Sie einen bestimmten Index neu erstellen müssen. Dies kann nur auf der primären Instanz durchgeführt werden. Wenn Sie eine neue Replikatinstanz erstellen, erhalten Sie bald wieder denselben Fehler. Hashindexe werden in PostgreSQL-Versionen unter 10 nicht an Replikate weitergegeben.

Wenn Sie Hashindexe verwenden müssen, führen Sie ein Upgrade auf PostgreSQL 10 oder höher durch. Wenn Sie allerdings ebenfalls Replikate verwenden möchten, verwenden Sie in PostgreSQL 9.6 keine Hashindexe.
Die Abfrage der primären Instanz wird immer ausgeführt. Nach dem Erstellen eines Replikats wird die Abfrage SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' voraussichtlich auf Ihrer primären Instanz ausgeführt.
Die Replikaterstellung schlägt bei Zeitüberschreitung fehl. Langlaufende Transaktionen ohne Commit auf der primären Instanz können dazu führen, dass die Lesereplikaterstellung fehlschlägt.

Erstellen Sie das Replikat neu, nachdem alle laufenden Abfragen beendet sind.
Wenn die primäre Instanz und das Replikat unterschiedliche vCPU-Größen haben, kann es zu Problemen bei der Abfrageleistung kommen, da die Abfrageoptimierung die vCPU-Größen berücksichtigt.

So beheben Sie das Problem:

  1. Aktivieren Sie das Flag log_duration und setzen Sie den Parameter log_statement auf ddl. Dadurch erhalten Sie sowohl die Abfragen als auch die Laufzeit für die Datenbank. Je nach Arbeitslast kann dies jedoch zu Leistungsproblemen führen.
  2. Führen Sie sowohl auf der primären Instanz als auch auf dem Lesereplikat explain analyze für die Abfragen aus.
  3. Vergleichen Sie den Abfrageplan und prüfen Sie, ob Unterschiede vorliegen.

Wenn dies eine bestimmte Abfrage ist, ändern Sie diese. Sie können beispielsweise die Reihenfolge der Joins ändern, um zu sehen, ob Sie eine bessere Leistung erzielen.