Bekannte Probleme

MySQL   |  PostgreSQL   |  SQL Server

Auf dieser Seite werden bekannte Probleme mit Cloud SQL für PostgreSQL sowie Möglichkeiten zur Vermeidung oder Behebung dieser Probleme aufgelistet.

Wenn Probleme in Verbindung mit Ihrer Instanz auftreten, sehen Sie sich die Informationen unter Fehlerdiagnose an.

Probleme mit der Instanzverbindung

• Abgelaufene SSL/TLS-Zertifikate

  Rufen Sie in der Google Cloud console die Seite Cloud SQL-Instanzen auf und öffnen Sie die Instanz, wenn Ihre Instanz für die Verwendung von SSL konfiguriert ist. Rufen Sie die Seite Verbindungen auf, wählen Sie den Tab Sicherheit aus 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.

• Version des Cloud SQL Auth-Proxys

  Wenn Sie die Verbindung zum Cloud SQL Auth-Proxy herstellen, achten Sie darauf, dass Sie die neueste Version verwenden. Weitere Informationen finden Sie unter Cloud SQL Auth-Proxy auf dem aktuellen Stand halten.

• Keine Berechtigung zum Herstellen einer Verbindung

  Wenn Sie eine Verbindung zu einer Instanz herstellen, die in diesem Projekt nicht vorhanden ist, besagt die Fehlermeldung nur, dass Sie keine Zugriffsberechtigung für diese Instanz haben.

• Kann keine Cloud SQL-Instanz erstellen

  Wenn die Fehlermeldung Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID] angezeigt wird, versuchen Sie noch einmal, die Cloud SQL-Instanz zu erstellen.

• Folgendes funktioniert nur mit dem Standardnutzer ("postgres"): gcloud sql connect --user

  Wenn Sie diesen Befehl mit einem anderen Nutzer verwenden, wird die Fehlermeldung FATAL: database 'user' does not exist ausgegeben. Um dieses Problem zu umgehen, stellen Sie eine Verbindung mit dem Standardnutzer ("postgres") her und führen Sie dann den psql-Befehl "\c" aus, um die Verbindung noch einmal mit einem anderen Nutzer herzustellen.

• PostgreSQL-Verbindungen hängen, wenn die IAM-Datenbank-Proxy-Authentifizierung aktiviert ist.

  Wenn der Cloud SQL-Authentifizierungsproxy mit TCP-Sockets gestartet wird und mit dem Flag -enable_iam_login, dann hängt ein PostgreSQL-Client während der TCP-Verbindung. Eine Problemumgehung besteht darin, sslmode=disable im PostgreSQL-Verbindungsstring zu verwenden. Beispiele:

  psql "host=127.0.0.1 dbname=postgres user=[e-mail] sslmode=disable"

  Eine weitere Problemumgehung besteht darin, den Cloud SQL Auth-Proxy mit Unix-Sockets zu starten. Damit wird die PostgreSQL-SSL-Verschlüsselung deaktiviert und stattdessen die SSL-Verschlüsselung vom Cloud SQL Auth-Proxy vorgenommen.

Administrative Probleme

• Auf einer Instanz kann jeweils nur ein Import- oder Exportvorgang für Cloud SQL mit langer Ausführungszeit ausgeführt werden. Achten Sie beim Starten eines Vorgangs darauf, dass Sie keine weiteren Vorgänge auf der Instanz ausführen müssen. Wenn Sie den Vorgang starten, können Sie ihn auch abbrechen.

  Die Importe von PostgreSQL werden in einer einzigen Transaktion importiert. Wenn Sie den Importvorgang abbrechen, speichert Cloud SQL daher keine Daten aus dem Import.

Probleme beim Importieren und Exportieren von Daten

• Wenn Ihre Cloud SQL-Instanz PostgreSQL 17 verwendet, Ihre Datenbanken aber PostgreSQL 16 oder früher, können Sie diese Datenbanken nicht mit Cloud SQL in Ihre Instanz importieren. Verwenden Sie dazu den Database Migration Service.

• Wenn Sie mit dem Database Migration Service eine PostgreSQL 17-Datenbank in Cloud SQL importieren, wird sie als PostgreSQL 16-Datenbank importiert.

• Wenn bei PostgreSQL 15 und höher die Zieldatenbank aus template0 erstellt wird, kann das Importieren von Daten fehlschlagen und Sie erhalten möglicherweise die Fehlermeldung permission denied for schema public. Zum Beheben dieses Problems erteilen Sie dem Nutzer cloudsqlsuperuser öffentliche Schemaberechtigungen mit dem SQL-Befehl GRANT ALL ON SCHEMA public TO cloudsqlsuperuser.

• Wenn viele große Objekte exportiert werden, reagiert die Instanz nicht mehr

  Wenn Ihre Datenbank viele große Objekte (Blobs) enthält, kann das Exportieren der Datenbank so viel Speicher belegen, dass die Instanz nicht mehr reagiert. Dies kann auch passieren, wenn die Blobs leer sind.

• Cloud SQL unterstützt keine benutzerdefinierten Tablespaces, aber die Datenmigration von benutzerdefinierten Tablespaces zum Standard-Tablespace pg_default in der Zielinstanz. Wenn Sie beispielsweise einen Tablespace namens dbspace haben, der sich in /home/data befindet, werden nach der Migration alle Daten innerhalb von dbspace zu pg_default migriert. Cloud SQL erstellt aber auf seinem Laufwerk keinen Tablespace namens „dbspace“.

• Wenn Sie versuchen, Daten aus einer großen Datenbank zu importieren und zu exportieren, z. B. eine Datenbank mit mindestens 500 GB, können die Import- und Exportvorgänge sehr lange dauern. Darüber hinaus stehen Ihnen andere Vorgänge (z. B. der Sicherungsvorgang) während des Imports oder Exports nicht zur Verfügung. Eine Möglichkeit zur Verbesserung der Leistung des Import- und Exportvorgangs ist die Wiederherstellung einer vorherigen Sicherung mit gcloud oder der API.

• Cloud Storage unterstützt einzelne Objekte mit einer Größe von bis zu 5 Tebibyte (5 TiB). Da Cloud SQL Daten komprimiert, bevor sie in Cloud Storage hochgeladen werden, schlägt ein Exportvorgang nur fehl, wenn die komprimierte Größe einer Exportdatei 5 TiB überschreitet.

  Das Komprimierungsverhältnis hängt von den Datentypen in der Datenbank ab. Text lässt sich beispielsweise besser komprimieren als Binärdaten wie BLOBs. Daher kann es sein, dass ein Export bei einer Datenbank- oder Tabellengröße von mehr als 5 TiB nicht fehlschlägt, wenn die Daten stark komprimierbar sind. Bei unkomprimierten Daten, die sich 5 TiB nähern, kann der Export jedoch fehlschlagen.

  Wenn Sie einen Standardexportvorgang ausführen, erstellt Cloud SQL in der Regel eine einzelne Exportdatei. Wenn Sie den parallelen Export verwenden, erstellt Cloud SQL mehrere Exportdateien, in der Regel eine für jede Tabelle. Bei dieser Art von Export schlägt der Exportvorgang fehl, wenn eine Tabelle so groß ist, dass ihre komprimierte Exportdatei 5 TiB überschreitet.

  Wenn der Export aufgrund des Limits von 5 TiB fehlschlägt, müssen Sie den Export in kleinere Segmente unterteilen. Wenn Sie einen Standardexport verwenden und dieses Limit erreichen, sollten Sie zum parallelen Export wechseln.

  Wenn Sie bereits den parallelen Export verwenden und das Limit von 5 TiB erreichen, ist eine Ihrer Tabellen zu groß, um sie zu exportieren, selbst wenn sie allein exportiert wird. In diesem Fall können Sie alternativ eine Verbindung von einer Compute Engine-Instanz herstellen und das Dienstprogramm pg_dump verwenden, um die Tabelle zu exportieren.

Transaktionslogs und Laufwerkwachstum

Die Logs werden einmal täglich, nicht kontinuierlich gelöscht. Wenn die Anzahl der Tage für die Logaufbewahrung so konfiguriert ist, dass sie der Anzahl der Sicherungen entspricht, kann ein Tag für das Logging verloren gehen, je nachdem, wann die Sicherung erstellt wird. Wenn Sie beispielsweise die Logaufbewahrung auf sieben Tage und die Sicherungsaufbewahrung auf sieben Sicherungen festlegen, werden Logs von sechs bis sieben Tagen aufbewahrt.

Wir empfehlen, die Anzahl der Sicherungen mindestens auf eine mehr als die Anzahl von Tagen der Logaufbewahrung festzulegen, um eine Mindestanzahl von festgelegten Tagen für die Logaufbewahrung sicherzustellen.

Hinweis: Bei Replikatinstanzen kommt es zu einer Speichererhöhung, wenn die Replikation ausgesetzt und später fortgesetzt wird. Die Erhöhung passiert, wenn die primäre Instanz dem Replikat die Transaktionslogs für den Zeitraum sendet, in dem der Replikationsvorgang angehalten wurde. Die Transaktionslogs aktualisieren das Replikat auf den aktuellen Stand der primären Instanz.

Probleme im Zusammenhang mit Cloud Monitoring oder Cloud Logging

Instanzen mit den folgenden Regionsnamen werden in bestimmten Kontexten falsch angezeigt:

• us-central1 wird als us-central angezeigt.
• europe-west1 wird als europe angezeigt.
• asia-east1 wird als asia angezeigt.

Dieses Problem tritt in folgenden Kontexten auf:

• Benachrichtigungen in Cloud Monitoring
• Metrics Explorer
• Cloud Logging

Mithilfe von Ressourcenmetadatenlabels können Sie das Problem bei Benachrichtigungen in Cloud Monitoring und im Metrics Explorer minimieren. Verwenden Sie das Systemmetadatenlabel region anstelle des cloudsql_database überwachten Ressourcenlabels region.

Problem beim Löschen einer PostgreSQL-Datenbank

Wenn Sie eine in der Google Cloud console erstellte Datenbank mit Ihrem psql Client löschen, wird möglicherweise der folgende Fehler angezeigt:

ERROR: must be owner of database [DATABASE_NAME]

Dies ist ein Berechtigungsfehler, da der Inhaber einer mit einem psql-Client erstellten Datenbank keine Cloud SQL-superuser-Attribute hat. Datenbanken, die mit der Google Cloud console erstellt wurden, gehören cloudsqlsuperuser. Datenbanken, die mit einem psql Client erstellt wurden, gehören Nutzern, die mit dieser Datenbank verbunden sind. Da Cloud SQL ein verwalteter Dienst ist, können Kunden keine Nutzer mit superuser-Attributen erstellen oder darauf zugreifen. Weitere Informationen finden Sie unter Einschränkungen und Berechtigungen für Superuser.

Aufgrund dieser Einschränkung können Datenbanken, die mit der Google Cloud console erstellt wurden, nur mit der Google Cloud console gelöscht werden. Datenbanken, die mit einem psql Client erstellt wurden, können nur gelöscht werden, wenn Sie als Inhaber der Datenbank eine Verbindung herstellen.

Verwenden Sie den folgenden Befehl, um den Inhaber einer Datenbank zu ermitteln:

SELECT d.datname as Name,
pg_catalog.pg_get_userbyid(d.datdba) as Owner
FROM pg_catalog.pg_database d
WHERE d.datname = 'DATABASE_NAME';

Ersetzen Sie Folgendes:

• DATABASE_NAME: der Name der Datenbank, für die Sie Informationen zum Inhaber suchen möchten.

Wenn der Inhaber Ihrer Datenbank cloudsqlsuperuser ist, löschen Sie die Datenbank mit der Google Cloud console. Wenn der Inhaber der Datenbank ein psql-Client-Datenbanknutzer ist, stellen Sie eine Verbindung als Datenbankinhaber her und führen Sie den Befehl DROP DATABASE aus.