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.

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

  Probleme beim Importieren und Exportieren von Daten

  • Wenn in Ihrer Cloud SQL-Instanz PostgreSQL 17 verwendet wird, Ihre Datenbanken aber PostgreSQL 16 oder eine niedrigere Version, können Sie diese Datenbanken nicht mit Cloud SQL in Ihre Instanz importieren. Verwenden Sie dazu den Database Migration Service.

  • Wenn Sie eine PostgreSQL 17-Datenbank mit Database Migration Service 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 Terabyte. Wenn Sie Datenbanken haben, die größer als 5 TB sind, schlägt der Exportvorgang nach Cloud Storage fehl. In diesem Fall müssen Sie die Exportdateien in kleinere Segmente unterteilen.

  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 überwachten cloudsql_database-Ressourcenlabels region.