Fehlerbehebung bei Cloud SQL for PostgreSQL

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. Benachrichtigungen werden bei Sicherungsfehlern nicht unterstützt. Prüfen Sie den Status einer Sicherung unter Einsatz der REST API oder der gcloud-Befehle.
Der Status der Instanz wechselt zwischen "Fehler" und "Sicherung wiederherstellen" Zu viel Traffic oder zu viele offene Verbindungen. Prüfen Sie die autovacuum-Einstellungen und die Wiederholungslogik.
In einer Sicherung fehlen Daten. Nicht geloggte Tabellen werden nicht aus der Sicherung wiederhergestellt. Hinweise zu nicht geloggten Tabellen.

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:

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


Nicht genügend Speicherplatz während der automatischen Sicherung

Folgende Fehlermeldung wird angezeigt: [ERROR] InnoDB: Write to file ./ibtmp1 failed at offset XXXX, YYYY bytes should have been written, only 0 were written..

Mögliche Ursache

Die Instanz hat während einer automatischen Sicherung ein festes Limit erreicht. Während einer Sicherung können temporäre Dateien ein Volumen erreichen, das den verfügbaren Speicherplatz überschreitet.

Lösungsvorschlag

Prüfen Sie, ob das Laufwerk voll oder das Laufwerkskontingent aufgebraucht ist. Sie können die Laufwerkgröße manuell erhöhen oder die automatische Speichererweiterung aktivieren.


Nach dem 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 ihre Speichergröße zu erhöhen.


Der Status der Instanz wechselt zwischen "Fehler" und "Sicherung wiederherstellen"

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ögliche Ursache

  • 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.

Lösungsvorschlag

  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.

In einer Sicherung fehlen Daten

Sie stellen fest, dass Daten fehlen, wenn Sie einen Sicherungs-/Wiederherstellungsvorgang durchführen.

Mögliche Ursache

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.

Lösungsvorschlag

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.


Anzahl der Tage erhöhen, für die automatische Sicherungen aufbewahrt werden

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 erreicht.

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 E-Mail-Benachrichtigung erhalten.

Mögliche Ursache

Benachrichtigungen werden bei Sicherungsfehlern nicht unterstützt.

Wenn eine automatische Sicherung fehlschlägt, wird auf der Seite Details der Cloud SQL-Instanz die Meldung Operation error angezeigt.

Lösungsvorschlag

Sie können den Status einer Sicherung mit den Befehlen REST API oder gcloud ermitteln. Listen Sie beispielsweise zuerst die Sicherungen für eine Instanz auf und beschreiben Sie dann eine bestimmte Sicherung anhand ihrer ID:

gcloud sql --project=PROJECT_ID backups list --instance=INSTANCE_ID
gcloud sql --project=PROJECT_ID backups describe BACKUP-ID --instance=INSTANCE_ID

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
FATAL: database 'user' does not exist. gcloud sql connect --user funktioniert nur mit dem standadmäßigen "postgres"-Nutzer. Stellen Sie eine Verbindung mit dem Standardnutzer her und wechseln Sie die Nutzer.
SSL error: invalid padding. Serverzertifikatfehler. Erstellen Sie ein neues Serverzertifikat und rotieren Sie es.
Sie möchten wissen, wer verbunden ist. Folgen Sie diesem Link.
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. Das Service Networking-Dienstkonto ist nicht an die Rolle servicenetworking.serviceAgent gebunden. Binden Sie das Service Networking-Dienstkonto an die Rolle servicenetworking.serviceAgent.
error x509: certificate is not valid for any names, but wanted to match project-name:db-name. Bekanntes Problem: Der Cloud SQL-Proxy-Dialer ist derzeit nicht mit Go 1.15 kompatibel. Bis zur Behebung dieses Problems finden Sie in dieser Diskussion auf GitHub eine Problemumgehung.
Auf einigen Betriebssystemen können keine Zertifikate geparst werden. Clients, die x509-Bibliotheken von mac OS 11.0 (Big Sur) verwenden, können möglicherweise einige Zertifikate von Postgres-Instanzen nicht parsen. Dem Client kann dies als allgemeiner Fehler wie „Abgebrochen“ angezeigt werden. Dieses Problem lässt sich durch Rotieren des Serverzertifikats und Neuerstellen der Clientzertifikate umgehen.
Cannot modify allocated ranges in CreateConnection. Please use UpdateConnection. Die VPC-Peerings wurden nicht aktualisiert, nachdem ein zugewiesener Bereich geändert oder entfernt wurde. Weitere Informationen zu VPC-Peering-Updates finden Sie unter Lösungsvorschlag.
Allocated IP range not found in network. Die VPC-Peerings wurden nicht aktualisiert, nachdem ein zugewiesener Bereich geändert oder entfernt wurde. Weitere Informationen zu VPC-Peering-Updates finden Sie unter Lösungsvorschlag.
ERROR: (gcloud.sql.connect) It seems your client does not have ipv6 connectivity and the database instance does not have an ipv4 address. Please request an ipv4 address for this database instance.. Sie versuchen, eine Verbindung zu Ihrer privaten IP-Instanz mithilfe von Cloud Shell herzustellen. Das Herstellen einer Verbindung von Cloud Shell zu einer Instanz mit nur einer privaten IP-Adresse wird derzeit nicht unterstützt.

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.


FATAL: Datenbank "user" existiert nicht

Wenn Sie versuchen, über gcloud sql connect --user eine Verbindung zu einer PostgreSQL-Instanz herzustellen, wird die Fehlermeldung FATAL: database 'user' does not exist angezeigt.

Mögliche Ursache

Der Befehl gcloud sql connect --user funktioniert nur mit dem Standardnutzer (postgres).

Lösungsvorschlag

Verwenden Sie die folgende Anweisung, um eine Verbindung mit dem Standardnutzer herzustellen und verwenden Sie dann den "\c" psql-Befehl, um die Verbindung wieder herzustellen.


SSL-Fehler: Ungültiges Padding

Wenn Sie versuchen, über SSL eine Verbindung zu einer PostgreSQL-Instanz herzustellen, wird die Fehlermeldung SSL error: invalid padding angezeigt.

Mögliche Ursache

Möglicherweise liegt ein Problem mit dem Server-CA-Zertifikat vor.

Lösungsvorschlag

Erstellen Sie ein neues Server-CA-Zertifikat und rotieren Sie die Serverzertifikate.


Sie möchten wissen, wer verbunden ist

Sie möchten herausfinden, wer wie lange verbunden ist.

Mögliche Ursache

Lösungsvorschlag

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</code>


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

    Wenn Sie eine Verbindung über den Cloud SQL Auth-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.


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

Das Service Networking-Dienstkonto ist nicht an die Rolle servicenetworking.serviceAgent gebunden.

Lösungsvorschlag

Versuchen Sie, dieses Problem zu beheben. Verwenden Sie dazu die folgenden gcloud-Befehle, um das Service Networking-Dienstkonto an die Rolle servicenetworking.serviceAgent zu binden.

gcloud beta services identity create --service=servicenetworking.googleapis.com --project=PROJECT_ID
gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:service-PROJECT_NUMBER@service-networking.iam.gserviceaccount.com" --role="roles/servicenetworking.serviceAgent"

Fehler x509: certificate is not valid for any names

Die Fehlermeldung error x509: certificate is not valid for any names, but wanted to match project-name:db-name wird angezeigt.

Mögliche Ursache

Bekanntes Problem: Der Cloud SQL-Proxy-Dialer ist derzeit nicht mit Go 1.15 kompatibel.

Lösungsvorschlag

Bis zur Behebung dieses Fehlers finden Sie in dieser Diskussion auf GitHub eine Problemumgehung.


Auf einigen Betriebssystemen können keine Zertifikate geparst werden.

Wenn Sie x509-Bibliotheken von mac OS 11.0 (Big-Sur) verwenden, können die Zertifikate von Postgres-Instanzen möglicherweise nicht geparst werden. Dies kann als allgemeiner Fehler zu sehen sein, wie z. B. „Abgebrochen“.

Lösungsvorschlag

Der Fehler ist behoben und bei neuen Instanzen tritt dieses Problem nicht auf. Wenn dieses Problem bei alten Instanzen auftritt, rotieren Sie das Serverzertifikat und erstellen Sie die Clientzertifikate neu.


Die zugewiesenen Bereiche können in CreateConnection nicht geändert werden. Verwenden Sie UpdateConnection

Sie sehen die Fehlermeldung Cannot modify allocated ranges in CreateConnection. Please use UpdateConnection oder The operation "operations/1234" resulted in a failure "Allocated IP range 'xyz' not found in network.

Mögliche Ursache

Der erste Fehler wird angezeigt, wenn Sie versuchen, eine Verbindung mit einem anderen reservierten Bereich wieder herzustellen.

Der zweite Fehler wird angezeigt, wenn der zugewiesene Bereich geändert wurde, aber vpc-peerings nicht aktualisiert wurde.

Lösungsvorschlag

Sie müssen die private Verbindung ändern. Verwenden Sie dazu den folgenden Befehl mit dem Argument --force:

gcloud services vpc-peerings update --network=VPC_NETWORK --ranges=ALLOCATED_RANGES --service=servicenetworking.googleapis.com --force

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

Die Service Networking API ist möglicherweise nicht aktiviert.

Möglicherweise versuchen Sie, eine Instanz mit demselben Namen wie eine kürzlich gelöschte zu erstellen.

Möglicherweise versuchen Sie, mehrere Instanzen gleichzeitig zu erstellen.

Die Subnetzerstellung ist möglicherweise fehlgeschlagen, wenn im IP-Bereich keine weiteren Adressen verfügbar waren.

Aktivieren Sie die Service Networking API.

Verwenden Sie einen anderen Namen für die Instanz oder warten Sie, bis das Löschen der Instanz eine Woche zurückliegt.

Erstellen Sie Instanzen nacheinander.

Sehen Sie sich andere Meldungen des Typs Unbekannter Fehler an, wenn dies nicht Ihrem Fall entspricht.

Weisen Sie neue Bereiche zu.

Failed to create subnetwork. Es sind keine weiteren verfügbaren Adressen im IP-Bereich vorhanden. Weisen Sie neue Bereiche zu.

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

  • Die Service Networking API ist möglicherweise nicht aktiviert.
  • Möglicherweise versuchen Sie, den Namen einer kürzlich gelöschten Instanz wiederzuverwenden. Instanznamen können nach dem Löschen eine Woche lang nicht wiederverwendet werden.
  • Möglicherweise versuchen Sie, mehrere Instanzen gleichzeitig zu erstellen. In diesem Fall wird nur die erste Instanz erstellt und die anderen schlagen mit Unknown error fehl. Es kann immer nur ein Erstellungsvorgang ausgeführt werden.
  • Ihre Subnetzerstellung ist möglicherweise fehlgeschlagen, wenn keine weiteren Adressen im IP-Bereich verfügbar waren.

Lösungsvorschlag

  • Aktivieren Sie die Service Networking API.
  • 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.
  • Weitere Informationen finden Sie im Abschnitt Subnetzwerk konnte nicht erstellt werden weiter unten.

Subnetz konnte nicht erstellt werden

Folgende Fehlermeldung wird angezeigt: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider..

Mögliche Ursache

Im zugewiesenen IP-Bereich sind keine weiteren Adressen verfügbar.

Tritt dieser Fehler auf, wenn Sie eine Cloud SQL-Instanz mit privater IP-Adresse für ein freigegebenes VPC-Netzwerk mit privaten Dienstverbindungen erstellen möchten, gibt es fünf mögliche Szenarien:

  • 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.
  • Sie versuchen, MySQL- oder SQL Server- und PostgreSQL-Instanzen für dieselbe private Dienstverbindung im VPC-Hostprojekt zu erstellen. MySQL und SQL Server können dieselbe Dienstverbindung gemeinsam nutzen. PostgreSQL erfordert eine eigene Dienstverbindung.
  • Sie versuchen, Instanzen für dieselbe private Dienstverbindung in verschiedenen Regionen zu erstellen. Dies wird nicht unterstützt.

Lösungsvorschlag

Für jedes der oben genannten Szenarien können Sie entweder den vorhandenen Bereich erweitern oder der privaten Dienstverbindung einen zusätzlichen IP-Bereich zuweisen.

Wenn Sie einen neuen Bereich zuweisen, müssen Sie darauf achten, dass keine Zuweisung erstellt wird, die sich 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 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-Zuordnung 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 Zuordnung 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]

Flags

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

Problem Mögliche Ursache Lösungsvorschlag
Es ist kein Flag zur Festlegung der Zeitzone vorhanden. Zeitzonen-Flags werden nicht unterstützt. Es sind einige Problemumgehungen vorhanden.

Es ist kein Flag zur Festlegung der Zeitzone vorhanden

PostgreSQL und SQL Server for Cloud SQL unterstützen kein Zeitzonen-Flag, um die Zeitzone an die Anforderungen von Nutzern anzupassen.

Mögliche Ursache

Zeitzonen-Flags werden nicht unterstützt.

Lösungsvorschlag

Sie können die Zeitzone pro Sitzung festlegen. Diese läuft aber ab, wenn Sie sich abmelden. Eine bessere Lösung besteht darin, eine Verbindung zur Datenbank herzustellen und als Datenbankzeitzone die gewünschte Zeitzone pro Nutzer oder Datenbank festzulegen:

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

Diese Einstellungen bleiben auch nach dem Schließen der Sitzung erhalten. Dadurch wird die .conf-Konfiguration imitiert.

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 nicht gefunden

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 größeren Maschinentyp durchzuführen, sodass mehr CPUs und Speicherplatz verfügbar sind.

Import

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

Problem Mögliche Ursache Lösungsvorschlag
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. Bereinigen Sie die fehlgeschlagene Datenbank, bevor Sie den Import wiederholen. Erstellen Sie die Datenbanknutzer, bevor Sie den Import ausführen.

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. Die beste Methode, 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

Bereinigen Sie die fehlgeschlagene Datenbank, bevor Sie den Import wiederholen. Erstellen Sie die Datenbanknutzer, bevor Sie den SQL-Dump importieren.


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.
408 Error (Timeout) beim Exportieren. Der SQL-Export kann je nach Datenbankgröße und Exportinhalt lange dauern. Verwenden Sie mehrere CSV-Exporte, um die Größe der einzelnen Vorgänge zu reduzieren.
CSV-Export funktioniert, SQL-Export schlägt jedoch fehl. Beim SQL-Export treten mit größerer Wahrscheinlichkeit Kompatibilitätsprobleme mit Cloud SQL auf. 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. Weitere Informationen
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 das Tool ist eine Superuser-Rolle erforderlich. Die Superuser-Rolle wird nicht unterstützt.
Beim Exportvorgang tritt vor dem Export eine Zeitüberschreitung auf. Die Abfrage muss innerhalb der ersten sieben Minuten Daten liefern. Führen Sie einen manuellen Export mit dem pg_dump-Tool durch.
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. Mehr erfahren

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.


Fehler 408: (Zeitüberschreitung) beim Export

Beim Ausführen eines Exportjobs in Cloud SQL ist die Fehlermeldung 408 Error (Timeout) zu sehen.

Mögliche Ursache

CSV- und SQL-Formate werden auf unterschiedliche Weise 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.

Lösungsvorschlag

Verwenden Sie das CSV-Format und führen Sie mehrere kleinere Exportjobs aus, um die Größe und Länge der einzelnen Vorgänge zu reduzieren.


CSV-Export funktioniert, SQL-Export schlägt jedoch fehl

Der CSV-Export funktioniert, der SQL-Export schlägt jedoch fehl.

Mögliche Ursache

CSV- und SQL-Formate werden auf unterschiedliche Weise 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.

Lösungsvorschlag

Verwenden Sie CSV-Exporte, um nur das zu exportieren, was Sie benötigen.


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.



Fehler beim Verwenden von pg_dumpall

Sie erhalten eine Fehlermeldung, wenn Sie versuchen, das externe pg_dumpall-Befehlszeilentool zu verwenden.

Mögliche Ursache

Für dieses Tool ist die Rolle "Superuser" erforderlich.

Lösungsvorschlag

Cloud SQL ist ein verwalteter Dienst und gewährt Nutzern keine Superuser-Rollen oder -Berechtigungen.


Verbindung wurde von einem anderen Computer zurückgesetzt

Beim Export wird eine Zeitüberschreitung festgestellt, bevor etwas exportiert wird. Folgende Fehlermeldung ist zu sehen: Could not receive data from client: Connection reset by peer..

Mögliche Ursache

Wenn Cloud Storage innerhalb eines bestimmten Zeitraums keine Daten empfängt, wird die Verbindung zurückgesetzt.

Lösungsvorschlag

Führen Sie einen manuellen Export mit dem pg_dump-Tool durch.


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.


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 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.
Logdateien sind schwer zu lesen. Sie können die Logs alternativ im JSON- oder Textformat aufrufen. Verwenden Sie dazu gcloud logging-Befehle.
Es wurden keine Abfragelogs in PostgreSQL-Logs gefunden. Sie müssen die pgaudit-Flags aktivieren. Verwenden Sie diese gcloud sql-Befehle.

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.


Logdateien sind schwer zu lesen

Die Logs können im Log-Explorer nicht richtig gelesen werden.

Mögliche Ursache

Sie sollten die Logs lokal im JSON- oder Textformat herunterladen.

Versuchen Sie Folgendes:

Sie können zum Herunterladen der Logs den Befehl gcloud logging read zusammen mit Linux-Nachbearbeitungsbefehlen verwenden.

So laden Sie Logs im JSON-Format herunter:

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

So laden Sie Logs im TEXT-Format herunter:

gcloud logging read "resource.type=cloudsql_database AND logName=projects/PROJECT-ID/logs/cloudsql.googleapis.com%2FLOGFILE-NAME" --format json --project=PROJECT-ID--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) | .textPayload' > downloaded-log.txt


Abfragelogs wurden nicht gefunden

Es sind keine Abfragelogs in Cloud Logging für PostgreSQL vorhanden.

Mögliche Ursache

Sie müssen die pgaudit-Flags aktivieren.

Lösungsvorschlag

  1. Stellen Sie von einem Terminal eine Verbindung zu Ihrer Datenbank her:

    gcloud sql connect $INSTANCE_NAME
    

  2. Führen Sie in der Datenbank 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
    

  4. Starten Sie zum Schluss die Cloud SQL-Instanz neu.

Instanzen verwalten

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

Problem Mögliche Ursache Lösungsvorschlag
Sie möchten herausfinden, welche Abfragen gerade ausgeführt werden. Versuchen Sie es mit dieser Datenbankabfrage.
Sie möchten herausfinden, welche Einheiten für ein bestimmtes Feld verwendet werden. Versuchen Sie es mit dieser Datenbankabfrage.
Sie möchten den aktuellen Wert einer Datenbankeinstellung ermitteln. Versuchen Sie es mit diesen Datenbankabfragen.
Sie möchten einen blockierten Hintergrundprozess beenden. Der Nutzer muss die Rolle pg_signal_backend haben. Weisen Sie die Rolle zu und führen Sie diese Befehle aus.
Die Instanz nutzt fast 100 % der Transaktions-IDs. 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. Hier finden Sie Tipps zur Selbsthilfe.
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.
Die lokale primäre Instanz bleibt hängen. Der Cloud SQL-Kundensupport kann bei Instanzen, die nicht in Cloud SQL enthalten sind, nicht helfen.
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.
Gelöschte Instanz wiederherstellen Alle Daten einer Instanz, einschließlich Sicherungen, werden beim Löschen der Instanz dauerhaft entfernt. Verhindern Sie Datenverluste durch Exportieren nach Cloud Storage.
Sie möchten eine vorhandene Cloud SQL-Instanz umbenennen. Das Umbenennen einer vorhandenen Instanz wird nicht unterstützt. Es gibt nun verschiedene Möglichkeiten, um dieses Ziel zu erreichen, indem eine neue Instanz erstellt wird.


Sie möchten wissen, welche Abfragen gerade ausgeführt werden

Sie möchten wissen, welche Abfragen gerade in PostgreSQL ausgeführt werden.

Mögliche Ursache

Lösungsvorschlag

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 wissen, welche Einheiten für ein Feld verwendet werden

Sie möchten herausfinden, welche Einheiten für ein bestimmtes Feld verwendet werden.

Mögliche Ursache

Lösungsvorschlag

Stellen Sie eine Verbindung zur Datenbank her und führen Sie die folgende Abfrage aus (mit Ihrem eigenen FIELD_NAME): SELECT name, setting, unit FROM pg_settings WHERE name = '[FIELD_NAME]'.


Sie möchten den aktuellen Wert einer Einstellung ermitteln

Sie möchten den aktuellen Wert für eine bestimmte Einstellung ermitteln.

Mögliche Ursache

Lösungsvorschlag

Stellen Sie eine Verbindung zur Datenbank her und führen Sie diese Abfrage mit Ihrem eigenen SETTING_NAME aus: SHOW SETTING_NAME; oder SHOW ALL;, um alle Einstellungen anzeigen zu lassen.

Sie möchten einen blockierten Hintergrundprozess beenden

Sie möchten beispielsweise einen blockierten oder hängenden Hintergrundprozess wie „autovacuum“ beenden.

Mögliche Ursache

Ihr Nutzer hat nicht die erforderliche Rolle. Er muss die Rolle pg_signal_backend haben.

Lösungsvorschlag

  1. Stellen Sie eine Verbindung zur Datenbank her und führen Sie den folgenden Befehl aus:
      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';
      
      

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.

Mögliche Ursache

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.

Lösungsvorschlag

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

Allgemeine Hinweise zur Abstimmung finden Sie unter Optimizing, monitoring, and troubleshooting vacuum operations in PostgreSQL.


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.


Die lokale primäre Instanz bleibt hängen

Sie möchten wissen, ob der Cloud SQL-Kundensupport Ihnen helfen kann, wenn eine lokale primäre Instanz hängen bleibt.

Mögliche Ursache

Die Instanz befindet sich nicht in Cloud SQL.

Lösungsvorschlag

Der Cloud SQL-Kundensupport kann bei Instanzen, die nicht in Cloud SQL enthalten sind, nicht helfen.


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. In diesem Thread zu Stack Exchange wird besprochen, wie Sie die Objekte finden, deren Eigentümer der Nutzer ist.


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 Console oder von Cloud Monitoring 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.


Gelöschte Instanz wiederherstellen

Unabhängig davon, ob eine Instanz absichtlich oder versehentlich gelöscht wurde, können Sie sie nicht wiederherstellen.

Mögliche Ursache

Alle Daten einer Instanz, einschließlich Sicherungen, werden beim Löschen der Instanz dauerhaft entfernt.

Lösungsvorschlag

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. Um ein versehentliches Löschen zu vermeiden, gewähren Sie diese Rolle nur, wenn es wirklich nötig ist.


Sie möchten eine vorhandene Cloud SQL-Instanz umbenennen.

Aus geschäftlichen oder anderen Gründen möchten Sie eine vorhandene Cloud SQL-Instanz umbenennen.

Mögliche Ursache

Das Umbenennen einer Instanz wird weder in der Google Cloud Console noch über eine API unterstützt.

Lösungsvorschlag

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

  1. 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.

  2. 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 importieren.

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.

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. Dies kann viele Ursachen haben. Weitere Informationen finden Sie in den Logs.
Lesereplikat kann nicht erstellt werden – invalidFlagValue-Fehler Eines der explizit oder standardmäßig angegebenen Flags ist ungültig. Prüfen Sie Flag-Werte und Logs auf weitere Informationen.
Lesereplikat kann nicht erstellt werden – unbekannter Fehler. Dies kann viele Ursachen haben. Weitere Informationen finden Sie in den Logs.
Laufwerk ist voll. Das Laufwerk der primären Instanz kann während der Replikaterstellung zu voll 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. Hier finden Sie einige Lösungsvorschläge.

Beim Erstellen hat das Lesereplikat nicht repliziert

Beim Erstellen hat das Lesereplikat nicht repliziert.

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.


Lesereplikat kann nicht erstellt werden – invalidFlagValue-Fehler

Das Lesereplikat kann nicht erstellt werden – invalidFlagValue.

Mögliche Ursache

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.

Lösungsvorschlag

Prüfen Sie als Erstes, ob der Wert des Flags max_connections größer oder gleich dem Wert auf der Primärseite 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

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 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:

  • 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.

Lösungsvorschlag

Mögliche Lösungen:

  • Bearbeiten Sie die Instanz, um die Größe des Replikats zu erhöhen.
  • Reduzieren Sie die Belastung der Datenbank.
  • Indexieren Sie die Tabellen.
  • Ermitteln und beheben Sie langsame Abfragen.
  • Erstellen Sie das Replikat neu.