Fehlerbehebung für Cloud SQL für MySQL

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, indem Sie die REST API oder gcloud-Befehle verwenden.

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.googlapis.com/mysql-general.log
  • cloudsql.googleapis.com/mysql.err
  • 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.


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

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

Mögliche Ursache

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

Lösungsvorschlag

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


Unbekannter Fehler bei fehlgeschlagener Sicherung

Die Sicherung ist fehlgeschlagen und es wird Unknown error angezeigt.

Mögliche Ursache

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

Lösungsvorschlag

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

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

Keine Benachrichtigung über Sicherungsfehler

Eine automatische Sicherung ist fehlgeschlagen und Sie haben keine 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
Aborted connection. Fehler beim Lesen der Pakete oder Verbindung abgebrochen. 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 macOS 11.0 (Big Sur) verwenden, können möglicherweise einige Zertifikate von mysql-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 über 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.


Keine Autorisierung für Verbindung

Folgende Fehlermeldung ist zu sehen: Unauthorized to connect.

Mögliche Ursache

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

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

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

    Cloud SQL erkennt standardmäßig keine Subnetzrouten außerhalb des RFC 1918-Bereichs von Ihrer VPC. Sie müssen deshalb das Netzwerk-Peering auf Cloud SQL aktualisieren, um alle Routen außerhalb des RFC 1918-Bereichs exportieren zu können. Beispiel:

    gcloud compute networks peerings update cloudsql-mysql-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 MySQL-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

Eine private Dienstverbindung wurde geändert. Wenn beispielsweise ein Bereich reserviert war und dann entfernt wurde, wird die private Verbindung ebenfalls entfernt. Dieser Fehler tritt auf, wenn Sie versuchen, eine Verbindung zu einem anderen reservierten Bereich herzustellen, ohne zuvor die private Verbindung neu zu erstellen. Der zweite Fehler wird angezeigt, wenn der zugewiesene Bereich geändert wurde, aber vpc-peerings nicht aktualisiert wurde.

Lösungsvorschlag

In diesem Fall müssen Sie die private Verbindung neu erstellen oder aktualisieren. 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.

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.

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.

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.

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]

Externe primäre Instanz

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

Problem Mögliche Ursache Lösungsvorschlag
Specified key was too long; max key length is 767 bytes. Für die externe primäre Instanz ist möglicherweise die Variable innodb_large_prefix festgelegt. Setzen Sie das Flag innodb_large_prefix beim Erstellen des Replikats auf ON oder aktualisieren Sie das vorhandene Replikat mit dem Flag.
Table definition has changed. Während des Dumpprozesses wurden DDL-Änderungen (Data Definition Language, Datendefinitionssprache) vorgenommen. Vermeiden Sie DDL-Änderungen während des Dumpprozesses.
Fehlermeldung: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. Unter Umständen wird DEFINER von einer Ansicht, Funktion oder Prozedur in der Quelldatenbank auf eine Weise referenziert, die von Cloud SQL nicht unterstützt wird. Lesen Sie weitere Informationen zur DEFINER-Nutzung in Cloud SQL.
Fehlermeldung: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost In der Quelldatenbank ist ein DEFINER vorhanden, den es im Replikat nicht gibt. Weitere Informationen zur DEFINER-Nutzung in Cloud SQL finden Sie in diesem Artikel.
Lost connection to MySQL server during query when dumping table. Die Quelle war möglicherweise nicht mehr verfügbar oder der Dump enthielt zu große Pakete. Sorgen Sie dafür, dass die externe primäre Instanz zur Verbindungsherstellung verfügbar ist oder verwenden Sie „mysqldump“ mit der Option max_allowed_packet.
Got packet bigger than 'max_allowed_packet' bytes when dumping table. Das Paket war größer als der eingestellte zulässige Wert. Verwenden Sie „mysqldump“ mit der Option max_allowed_packet.
Die erste Datenmigration war erfolgreich, es werden jedoch keine Daten repliziert. Möglicherweise gibt es in Konflikt stehende Replikations-Flags. Prüfen Sie diese Flag-Einstellungen.
Die erste Datenmigration war erfolgreich, aber die Datenreplikation funktioniert nach einer Weile nicht mehr. Dafür gibt es viele Gründe. Probieren Sie diese Lösungsvorschläge aus.
mysqld check failed: data disk is full. Das Datenlaufwerk der Replikatinstanz ist voll. Erhöhen Sie die Laufwerkgröße der Replikatinstanz. Sie können die Laufwerkgröße manuell erhöhen oder die automatische Speichererweiterung aktivieren.

Der angegebene Schlüssel war zu lang. Die maximale Schlüssellänge beträgt 767 Byte.

Der Fehler Specified key was too long; max key length is 767 bytes. wird angezeigt.

Mögliche Ursache

Für die externe primäre Instanz ist möglicherweise die Variable innodb_large_prefix festgelegt. Dadurch können Indexschlüsselpräfixe länger als 767 Byte sein. Der Standardwert für MySQL 5.6 ist OFF.

Lösungsvorschlag

Setzen Sie das Flag innodb_large_prefix beim Erstellen des Replikats auf ON oder aktualisieren Sie das vorhandene Replikat mit dem Flag.


Tabellendefinition hat sich geändert

Der Fehler Table definition has changed wird angezeigt.

Mögliche Ursache

Während des Dumpprozesses wurden DDL-Änderungen vorgenommen.

Lösungsvorschlag

Ändern Sie während des Dumpprozesses keine Tabellen und nehmen Sie keine anderen DDL-Änderungen vor.


Zugriff verweigert. Sie benötigen für diesen Vorgang mindestens eine der SUPER-Berechtigungen

Der Fehler Access denied; you need (at least one of) the SUPER privilege(s) for this operation wird angezeigt.

Mögliche Ursache

Dies könnte daran liegen, dass der Kunde VIEW/FUNCTION/PROCEDURE hat und DEFINER superuser@localhost verwendet (z. B. root@localhost). Dies wird von Cloud SQL nicht unterstützt.

Lösungsvorschlag

Das Problem lässt sich dadurch umgehen, dass Sie den DEFINER in den externen Datenbanken aktualisieren, z. B. von root@localhost auf root@% oder einen Nicht-Superuser. Weitere Informationen finden Sie unter Stored Object Access Control.


ERROR 1045 (28000) in Zeile xxx: Zugriff verweigert für Nutzer „cloudsqlimport'@'localhost“

Der Fehler ERROR 1045 (28000) at line xxx: Access denied for user 'cloudsqlimport'@'localhost wird angezeigt.

Mögliche Ursache

Ein Nutzer in der Quelldatenbank mit der Klausel DEFINER existiert nicht in der Replikatdatenbank, und auf diesen Nutzer wird in den Objektdefinitionen der Quelldatenbank verwiesen.

Lösungsvorschlag

Nutzer werden nicht mit den Daten migriert. Erstellen Sie vor der Replikation die Quelldatenbanknutzer in der Replikatdatenbank.


Die Verbindung zu MySQL-Server wurde während der Abfrage beim Auslesen der Tabelle in eine Dumpdatei getrennt.

Der Fehler Lost connection to MySQL server during query when dumping table wird angezeigt.

Mögliche Ursache

  • Die Quelle ist möglicherweise nicht mehr verfügbar, sodass das Replikat keine Verbindung zu ihr herstellen kann.

  • Möglicherweise enthält die Quelldatenbank Tabellen mit großen Blobs oder langen Strings, für die max_allowed_packet auf eine größere Zahl in der Quelldatenbank festgelegt werden muss.

Lösungsvorschlag

  • Führen Sie einen Neustart aus und prüfen Sie, ob die externe primäre Instanz zur Verbindungsherstellung verfügbar ist.

  • Verwenden Sie „mysqldump“ mit der Option max_allowed_packet, um die Daten in eine Dumpdatei auszulesen und mit dieser zu migrieren.


Beim Auslesen der Tabelle in eine Dumpdatei war ein Paket erhalten, das den Wert von „max_allowed_packet“' überschritten hat.

Der Fehler Got packet bigger than 'max_allowed_packet' bytes when dumping table wird angezeigt.

Mögliche Ursache

Das Paket war größer als der eingestellte zulässige Wert.

Lösungsvorschlag

Verwenden Sie „mysqldump“ mit der Option max_allowed_packet, um die Daten in eine Dumpdatei auszulesen und mit dieser zu migrieren.


Es werden keine Daten repliziert.

Die erste Datenmigration war erfolgreich, aber es werden keine Daten repliziert.

Mögliche Ursache

Dies kann daran liegen, dass in der Quelldatenbank bestimmte Replikations-Flags definiert sind, die die Replikation von manchen oder allen Datenbankänderungen verhindern.

Lösungsvorschlag

Achten Sie darauf, dass Replikations-Flags wie binlog-do-db, binlog-ignore-db, replicate-do-db und replicate-ignore-db nicht so festgelegt sind, dass sie Konflikte verursachen.

Führen Sie den Befehl show master status in der primären Instanz aus, um die aktuellen Einstellungen aufzurufen.


Die erste Datenmigration war erfolgreich, aber die Datenreplikation funktioniert nach einer Weile nicht mehr.

Die Datenmigration verlief anfangs erfolgreich, danach jedoch nicht mehr.

Mögliche Ursache

Dieses Problem kann viele Ursachen haben.

Lösungsvorschlag

  • Prüfen Sie die Replikationsmesswerte für Ihre Replikatinstanz in der Cloud Monitoring-UI.

  • Die Fehler aus dem MySQL-E/A-Thread oder dem SQL-Thread finden Sie in Cloud Logging in den mysql.err-Logdateien.

  • Dieser Fehler kann auch auftreten, wenn eine Verbindung zur Replikatinstanz hergestellt wird. Führen Sie den Befehl SHOW SLAVE STATUS aus und suchen Sie in der Ausgabe nach folgenden Feldern:

    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error

mysqld-Prüfung fehlgeschlagen: Das Datenlaufwerk ist voll.

Der Fehler mysqld check failed: data disk is full wird angezeigt.

Mögliche Ursache

Wenn dieser Fehler bei einem DRAIN-Vorgang auftritt, ist das Datenlaufwerk der Replikatinstanz voll.

Lösungsvorschlag

Erhöhen Sie die Laufwerkgröße der Replikatinstanz.

Externes Replikat

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

Problem Mögliche Ursache Lösungsvorschlag
Fehlermeldung: The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires. Das Replikat weiß nicht, wo die Logs gelesen werden sollen. Erstellen Sie eine neue Dumpdatei mit den entsprechenden Flag-Einstellungen und konfigurieren Sie das externe Replikat mithilfe dieser Datei.

Binäre Logs gelöscht, die GTIDs enthalten

Sie erhalten die folgende Fehlermeldung in MySQL: The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires.

Mögliche Ursache

Die primäre Cloud SQL-Instanz umfasst automatische Sicherungen und binäre Logs. Außerdem wird die Wiederherstellung zu einem bestimmten Zeitpunkt aktiviert. Sie sollte deshalb genügend Logs haben, damit das Replikat aufholen kann. In diesem Fall weiß das Replikat jedoch nicht, aus welcher Zeile das Lesen beginnen soll, obwohl die Binärlogs vorhanden sind.

Lösungsvorschlag

Erstellen Sie eine neue Dumpdatei mit den richtigen Flag-Einstellungen und konfigurieren Sie das externe Replikat mithilfe dieser Datei.

  1. Stellen Sie über eine Compute Engine-Instanz eine Verbindung zum MySQL-Client her.
  2. Führen Sie mysqldump aus und verwenden Sie die Flags --master-data=1 und --flush-privileges.

    Wichtig: Fügen Sie nicht das Flag --set-gtid-purged=OFF ein.

    Weitere Informationen.

  3. Prüfen Sie, ob die soeben erstellte Dumpdatei die Zeile SET @@GLOBAL.GTID_PURGED='...' enthält.
  4. Laden Sie die Dumpdatei in einen Cloud Storage-Bucket hoch und konfigurieren Sie das Replikat mit der Dumpdatei.

Flags

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

Problem Mögliche Ursache Lösungsvorschlag
Daten mit dem Zeichensatz utf8mb4. Dieser Zeichensatz wird nicht unterstützt. Filtern Sie utf8mb4-Strings aus Ihren Daten.
Instanz stürzt ab, wenn ein Flag aktiviert wird. Der Wert des Flags max_connections ist möglicherweise zu hoch. Wenden Sie sich an den Kundensupport, um die Entfernung eines Flags anzufordern.
Das Flag performance_schema kann nicht hinzugefügt werden. Die Instanzgröße ist zu klein. Die Google Cloud Console unterstützt die Bearbeitung dieses Flags nicht. Aktualisieren Sie entweder die Instanz auf eine größere Instanz oder ändern Sie den Wert mithilfe der API.
Die Zeitzone wird nicht automatisch geändert. Die automatische Änderung der Zeitzone wird nicht unterstützt. Die Zeit muss manuell geändert werden. Mehr erfahren
Bad syntax for dict arg. Komplexe Parameterwerte erfordern eine besondere Behandlung. Weitere Informationen

Daten mit dem Zeichensatz utf8mb4

Der Import von Daten mit dem Zeichensatz utf8mb4 ist fehlgeschlagen.

Mögliche Ursache

Der Zeichensatz utf8mb4 wird nicht unterstützt, auch wenn dies bisher in der Dokumentation angegeben wurde.

Lösungsvorschlag

Filtern Sie utf8mb4-Strings aus Ihren Daten.


Instanz stürzt ab, wenn ein Flag aktiviert wird

Nach dem Aktivieren eines Flags wechseln die Instanzen zwischen einer Panik und einem Absturz.

Mögliche Ursache

Dieser Fehler tritt auf, wenn Sie den Wert des Flags max_connections zu hoch festlegen.

Lösungsvorschlag

Wenden Sie sich an den Kundensupport, um ein Entfernen des Flags mit anschließendem hard drain anzufordern. Dadurch wird die Instanz auf einem anderen Host mit einer neuen Konfiguration und ohne das Flag bzw. ohne die Einstellung neu gestartet.


Das Flag "performance_schema" kann nicht hinzugefügt werden

Sie können das Flag performance_schema nicht hinzufügen, da es nicht im Drop-down-Menü der unterstützten Flags enthalten ist. Sie müssen die API verwenden, um den Wert zu ändern.

Mögliche Ursache

Das performance_schema und seine Varianten (performance_schema_accounts_size, performance_schema_accounts_size usw.) können nicht auf Instanzen aktiviert werden, die kleiner als db-custom-8-30720 oder db-custom-4-26624 sind.

Lösungsvorschlag

Achten Sie darauf, dass das Flag performance_schema aktiviert ist.

Sie müssen die API verwenden, um den Wert dieses Flags zu ändern. Wenn dieses Flag aktiviert ist, können Sie die Maschine nicht auf eine Größe ändern, die dieses Flag nicht unterstützt. Sie müssen zuerst dieses Flag deaktivieren.

Wenn Sie dieses Flag verwenden müssen, müssen Sie möglicherweise die Instanz bearbeiten.


Die Zeitzone wird nicht automatisch geändert

Die Zeitzone für die Sommerzeit wurde nicht automatisch geändert.

Mögliche Ursache

Automatisierte Zeitzonenänderungen werden in Cloud SQL nicht unterstützt. Änderungen der Zeitzone müssen manuell vorgenommen werden, und zwar nicht per String, sondern per Zeitzonen-Offset-Wert.

Lösungsvorschlag

Bearbeiten Sie die Instanz und ändern Sie das Flag default_time_zone. Benannte Bereiche werden nicht unterstützt. Beispiel: Europe/London London liegt in der UTC-Zeitzone. Der unterstützte Wert für das Flag default_time_zone ist dann +00:00.


Falsche Syntax für dict arg

Beim Festlegen eines Flags wird die Fehlermeldung Bad syntax for dict arg angezeigt.

Mögliche Ursache

Komplexe Parameterwerte wie durch Kommas getrennte Listen erfordern eine besondere Behandlung, wenn sie mit gcloud-Befehlen verwendet werden.

Lösungsvorschlag

Verwenden Sie den gcloud-Parameter --flags-file, der eine YAML- oder JSON-Datei mit einem --flag:value-Wörterbuch angibt, das für komplexe Flag-Werte nützlich ist.

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.
Fehler beim Import: Tabelle ist nicht vorhanden. Eine erforderliche Tabelle ist derzeit nicht vorhanden. Deaktivieren Sie FOREIGN_KEY_CHECKS zu Beginn des Imports.
Fehlermeldung: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost'. In der Dumpdatei ist ein DEFINER vorhanden, den es in der Datenbank nicht gibt. Weitere Informationen zur Verwendung von DEFINER in Cloud SQL und zu möglichen Problemumgehungen finden Sie in diesem Artikel.
Fehlermeldung: Unknown table 'COLUMN_STATISTICS' in information_schema. Dies geschieht, wenn Sie die Binärdatei mysqldump von MySQL 8.0 verwenden, um Daten aus einer MySQL 5.7-Datenbank zu dumpen und in eine MySQL 8.0-Datenbank zu importieren. Wenn Sie Daten aus einer MySQL 5.7-Datenbank ausgeben und in eine MySQL 8.0-Datenbank importieren, müssen Sie die Binärprogramm mysqldump von MySQL 5.7 verwenden. Wenn Sie die Binärprogramm mysqldump von MySQL 8.0 verwenden, müssen Sie das Flag --column-statistics=0 hinzufügen.

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.


Fehler beim Import: Tabelle ist nicht vorhanden

Ein Importvorgang schlägt mit der Fehlermeldung fehl, dass keine Tabelle vorhanden ist.

Mögliche Ursache

Tabellen können Fremdschlüsselabhängigkeiten von anderen Tabellen haben. Abhängig von der Reihenfolge der Vorgänge kann eine oder mehrere dieser Tabellen während des Importvorgangs noch nicht vorhanden sein.

Lösungsvorschlag

Fügen Sie am Anfang der Dumpdatei die folgende Zeile hinzu:

  SET FOREIGN_KEY_CHECKS=0;

Fügen Sie außerdem am Ende der Dumpdatei die folgende Zeile hinzu:

  SET FOREIGN_KEY_CHECKS=1;

Mit diesen Einstellungen werden Datenintegritätsprüfungen während des Importvorgangs deaktiviert und nach dem Laden der Daten wieder aktiviert. Dies wirkt sich nicht auf die Integrität der Daten in der Datenbank aus, da die Daten bereits beim Erstellen der Dumpdatei validiert wurden.


Fehlermeldung: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost'

Der Fehler ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost' wird angezeigt.

Mögliche Ursache

Die Ursache ist, dass ein Nutzer in der Dumpdatei mit der DEFINER-Klausel nicht in der Datenbank vorhanden ist und dass auf diesen Nutzer in den Objektdefinitionen der Datenbank verwiesen wird.

Lösungsvorschlag

Informationen dazu finden Sie in diesem Dokument zum Importieren einer Datenbank mit DEFINER-Klauseln in der Dumpdatei. Möglicherweise müssen Sie zuerst einen oder mehrere Nutzer in der Datenbank erstellen.


Fehlermeldung: Unbekannte Tabelle „COLUMN_STATISTICS“ in information_schema

Die Fehlermeldung Unknown table 'COLUMN_STATISTICS' in information_schema wird angezeigt.

Mögliche Ursache

Dies geschieht, wenn Sie die Binärdatei mysqldump von MySQL 8.0 verwenden, um Daten aus einer MySQL 5.7-Datenbank zu dumpen und in eine MySQL 8.0-Datenbank zu importieren.

Lösungsvorschlag

Wenn Sie Daten aus einer MySQL 5.7-Datenbank ausgeben und in eine MySQL 8.0-Datenbank importieren, müssen Sie die Binärprogramm mysqldump von MySQL 5.7 verwenden. Wenn Sie die Binärprogramm mysqldump von MySQL 8.0 verwenden, müssen Sie das Flag --column-statistics=0 hinzufügen.

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
Error 1412: Table definition has changed. Die Tabelle wurde während des Exports geändert. Entfernen Sie alle Tabellenänderungsanweisungen aus dem Dump-Vorgang.
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
Fehlermeldung: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. Es kann ein Ereignis, eine Ansicht, eine Funktion oder eine Prozedur in der Dumpdatei mit superuser@localhost (wie root@localhost) vorhanden sein. Dies wird von Cloud SQL nicht unterstützt. Weitere Informationen zur Verwendung von DEFINER in Cloud SQL und zu möglichen Problemumgehungen finden Sie in diesem Artikel.

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.


mysqldump: Fehler 1412: Die Tabellendefinition wurde geändert

Die Fehlermeldung mysqldump: Error 1412: Table definition has changed, retry transaction when dumping the table wird angezeigt.

Mögliche Ursache

Während des Exportvorgangs wurde die Tabelle geändert.

Lösungsvorschlag

Die Dump-Transaktion kann fehlschlagen, wenn Sie während des Exportvorgangs die folgenden Anweisungen verwenden:

  • ALTER TABLE
  • CREATE TABLE
  • DROP TABLE
  • RENAME TABLE
  • TRUNCATE TABLE
Entfernen Sie alle diese Anweisungen aus dem Dump-Vorgang.


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.

Zugriff verweigert. Sie benötigen für diesen Vorgang mindestens eine der SUPER-Berechtigungen

Der Fehler Access denied; you need (at least one of) the SUPER privilege(s) for this operation wird angezeigt.

Mögliche Ursache

Es kann ein Ereignis, eine Ansicht, eine Funktion oder eine Prozedur in der Dumpdatei mit superuser@localhost (wie root@localhost) vorhanden sein. Dies wird von Cloud SQL nicht unterstützt.

Lösungsvorschlag

Informationen dazu finden Sie in diesem Dokument zum Importieren einer Datenbank mit DEFINER-Klauseln.

Logging

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

Problem Mögliche Ursache Lösungsvorschlag
Logging beansprucht viel CPU und Speicher. Das Logging muss optimiert werden. Versuchen Sie, die Logging-Ressourcennutzung zu optimieren.
Audit-Logs wurden nicht gefunden. Nutzerauthentifizierung. Prüfen Sie die Nutzerrollen und Berechtigungen.
Vorgangsinformationen wurden nicht in Logs gefunden. Audit-Logs sind nicht aktiviert. Aktivieren Sie das Audit-Logging.
Logging beansprucht viel Speicherplatz. Redo-Logs, binäre Logs und allgemeine Logs belegen Speicherplatz. Führen Sie diese Befehle aus, um Details zur Laufwerknutzung abzurufen.
Logdateien sind schwer zu lesen. Sie können die Logs alternativ im JSON- oder Textformat aufrufen. Verwenden Sie dazu gcloud logging-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.


Logging beansprucht viel Speicherplatz

Sie möchten wissen, wie viel Speicherplatz die MySQL-Logdateien belegen.

Mögliche Ursache

Es gibt drei Arten von Logdateien, die Speicherplatz belegen: Redo-Logs, allgemeine Logs und binäre Logs.

Versuchen Sie Folgendes:

Führen Sie die folgenden Befehle aus, um Details zu den einzelnen Logdateitypen zu erhalten:

SHOW VARIABLES LIKE 'innodb_log_file%';

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2),2) AS GB from mysql.general_log;

SHOW BINARY LOGS;

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


Instanzen verwalten

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

Problem Mögliche Ursache Lösungsvorschlag
Beeinträchtigte Leistung nach dem Neustart von MySQL. Der InnoDB-Cache ist nach dem Neustart leer, sodass für alle Lesevorgänge ein Umlauf zum Back-End erforderlich ist, um Daten abzurufen. Warten Sie, bis alle Daten erfasst wurden.
Langsame Wiederherstellung nach einem Absturz. Möglicherweise hat sich ein großes general_log angesammelt. Verwalten Sie das allgemeine Logging. Weitere Informationen
Sie möchten herausfinden, was Speicherplatz verbraucht. Hauptsächlich sind es entweder Datenbanktabellen, binäre Logs oder temporäre Dateien. Lesen Sie diese Tipps zum Prüfen.
Abfragen werden blockiert. Ein Prozess blockiert alles andere. Suchen Sie den blockierenden Prozess und beenden Sie ihn. Weitere Informationen
Sie können binäre Logs nicht manuell löschen. Binäre Logs können nicht manuell gelöscht werden. Binäre Logs werden mit der zugehörigen automatischen Sicherung automatisch gelöscht. Dies geschieht in der Regel nach etwa sieben Tagen.
Sie möchten Informationen zu temporären Dateien finden. Der Name der temporären Datei lautet ibtmp1. Weitere Informationen finden Sie in dieser Datenbankabfrage.
Sie möchten mehr über Tabellengrößen erfahren. Diese Informationen sind in der Datenbank verfügbar. Weitere Informationen finden Sie in diesen Datenbankabfragen.
mysqld hat das Signal 11. Die Instanz ist abgestürzt, weil Abfragen zu viele Verbindungen herstellen. Refaktorieren Sie Abfragen, um dies zu vermeiden.
InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. Die Seitenbereinigung kann nicht mit der Änderungsrate auf der Instanz Schritt halten. Das Sharding der Instanz kann hilfreich sein.
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.
ERROR 1142 (42000): ANY command denied to user 'root'@'%' for table .../code>. Der Nutzer verfügt nicht über alle für diesen Vorgang erforderlichen Berechtigungen. Melden Sie sich an und führen Sie die hier beschriebenen Befehle aus.

Beeinträchtigte Leistung nach Neustart von MySQL

Langsame Leistung nach Neustart.

Mögliche Ursache

Cloud SQL ermöglicht das Caching von Daten im InnoDB-Pufferpool. Nach einem Neustart ist dieser Cache jedoch immer leer und alle Lesevorgänge erfordern einen Umlauf zum Back-End, um Daten abzurufen. Dies kann dazu führen, dass Abfragen langsamer als erwartet sind, bis der Cache gefüllt ist.

Lösungsvorschlag


Langsame Wiederherstellung nach einem Absturz

Langsame Wiederherstellung nach einem Absturz.

Mögliche Ursache

Möglicherweise hat sich ein großes general_log angesammelt.

Lösungsvorschlag

Sie können die Absturzwiederherstellungszeit reduzieren, wenn Sie darauf achten, dass sich kein großes general_log ansammelt. Wenn Sie general_log aktiviert haben, kürzen Sie die Tabelle und aktivieren Sie general_log nur für kurze Zeit.

Sie können die Größe der allgemeinen Logs ermitteln. Stellen Sie dazu eine Verbindung zur Datenbank her und führen Sie die folgende Abfrage aus: SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;


Was verbraucht Speicherplatz

Sie möchten herausfinden, was Speicherplatz verbraucht. Sie stellen beispielsweise fest, dass Ihre Datenbank nur 3 GB verwendet, aber laut Cloud Storage werden 14 GB Speicherplatz verwendet.

Mögliche Ursache

Der Großteil des Speicherplatzes, der nicht von Tabellen belegt wird, wird von binären Logs und/oder temporären Dateien genutzt.

Lösungsvorschlag

  • Sie können den von binären Logs belegten Speicherplatz mit dem folgenden Befehl in der MySQL-Befehlszeile prüfen: SHOW BINARY LOGS;
  • Temporäre Tabellen belegen möglicherweise auch viel Speicherplatz. Verwenden Sie den folgenden Befehl, um die temporäre Speicherplatznutzung zu prüfen: SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G.
  • Mit dem folgenden Befehl können Sie die Größe des Redo-Logs prüfen: SHOW VARIABLES LIKE 'innodb_log_file%';
  • Mit dem folgenden Befehl können Sie die Größe von general_log prüfen, sofern es aktiviert ist: SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) AS GB from mysql.general_log;
  • Bei Bedarf können Sie Ihre Logtabellen mithilfe der API kürzen. Weitere Informationen finden Sie auf der Referenzseite zu instances.truncateLog.
  • Weitere Informationen zum Festlegen und Konfigurieren von langsamen Abfragelogs

Abfragen werden blockiert

Es ist möglich, dass Abfragen die MySQL-Datenbank sperren, wodurch alle nachfolgenden Abfragen blockiert werden oder eine Zeitüberschreitung auftritt.

Mögliche Ursache

Ein Prozess blockiert alle anderen.

Lösungsvorschlag

Stellen Sie eine Verbindung zur Datenbank her und führen Sie die folgende Abfrage aus: SHOW PROCESSLIST. Das erste Element in der Liste kann das sperrende Element sein, wegen dem die nachfolgenden Elemente warten müssen.

Die Abfrage SHOW INNODB STATUS kann ebenfalls hilfreich sein.


Binäre Logs können nicht manuell gelöscht werden

Sie haben festgestellt, dass Sie binäre Logs nicht manuell löschen können.

Mögliche Ursache

Binäre Logs können nicht manuell gelöscht werden.

Lösungsvorschlag

Binäre Logs werden mit der zugehörigen automatischen Sicherung automatisch gelöscht. Dies geschieht in der Regel nach etwa sieben Tagen.


Sie möchten Informationen zu temporären Dateien finden

Sie möchten Informationen zu temporären Dateien finden.

Mögliche Ursache

Die Datei ibtmp1 wird zum Speichern temporärer Daten verwendet. Diese Datei wird beim Neustart der Datenbank zurückgesetzt.

Lösungsvorschlag

Um Informationen zur Nutzung temporärer Dateien zu erhalten, stellen Sie eine Verbindung zur Datenbank her und führen Sie diese Abfrage aus:

SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G


Sie möchten mehr über Tabellengrößen erfahren

Sie möchten die Größen der Tabellen in Ihrer Datenbank ermitteln.

Mögliche Ursache

Diese Informationen sind in der Datenbank verfügbar.

Lösungsvorschlag

Stellen Sie eine Verbindung zur Datenbank her und führen Sie die folgende Abfrage aus:

SELECT TABLE_SCHEMA, TABLE_NAME, sum(DATA_LENGTH+INDEX_LENGTH)/pow(1024,2) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA NOT IN ('PERFORMANCE_SCHEMA','INFORMATION_SCHEMA','SYS','MYSQL') GROUP BY TABLE_SCHEMA, TABLE_NAME;


mysqld hat Signal 11 erhalten

Folgender Fehler tritt auf:

mysqld got signal 11.

Mögliche Ursache

Die Instanz ist wahrscheinlich abgestürzt, weil durch Abfragen zu viele Verbindungen hergestellt werden.

Lösungsvorschlag

Refaktorieren Sie die Abfragen so, dass sie nicht so viele Verbindungen erstellen.


InnoDB: page_cleaner

Der Server stürzt immer wieder ab und Sie erhalten einen Fehler wie diesen: InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal.

Mögliche Ursache

Die Seitenbereinigung kann nicht mit der Änderungsrate auf der Instanz Schritt halten. Einmal pro Sekunde prüft die Seitenbereinigung den Pufferpool auf schmutzige Seiten, um sie aus dem Pufferpool zu leeren und auf das Laufwerk zu übertragen. Der angezeigten Warnung können Sie entnehmen, dass viele schmutzige Seiten zu leeren sind und es länger als eine Sekunde dauert, um einen Satz dieser Seiten auf das Laufwerk zu übertragen.

Lösungsvorschlag

Fragmentieren Sie die Instanz nach Möglichkeit. Mehrere kleine Cloud SQL-Instanzen sind oft besser als eine große Instanz.


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 Artikel wird erläutert, 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:

  • Wenn Sie das Flag long_query_time aktivieren, können Sie die Logs auf langsame Abfragen prüfen. Rufen Sie die Seite Log-Explorer für Ihr Projekt auf und führen Sie eine Abfrage wie die folgende aus:
    resource.type="cloudsql_database"
    resource.labels.database_id="INSTANCE-ID"
    log_name="projects/PROJECT-ID/logs/cloudsql.googleapis.com%2Fmysql-slow.log"
        

    Sie können die Logs im JSON- oder TEXT-Format zur lokalen Verarbeitung herunterladen.

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


FEHLER 1142 (42.000): JEDER Befehl verweigert für Nutzer 'root'@'%' für Tabelle...

Unter Verwendung von MySQL 5.7 kann ERROR 1142 (42000): ANY command denied to user 'root'@'%' for table ''" beim Erstellen einer Ansicht mit mehreren Ebenen einer Auswahl auftreten.

Mögliche Ursache

Der Nutzer verfügt nicht über alle für diesen Vorgang erforderlichen Berechtigungen.

Lösungsvorschlag

  1. Verbindung zur Datenbank herstellen (z. B. mit Cloud Shell) und Anmeldung als Root
  2. USE mysql; ausführen
  3. Führen Sie die folgende Zuweisung aus:
    GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE ON . TO 'root' WITH GRANT OPTION;
    
  4. Führen Sie USE 'Database_Name'; aus, wobei Database_Name die Datenbank ist, in der Sie die Ansichten erstellen.
  5. Führen Sie alle Erstellungen der Ansichten in der Sitzung aus und übertragen Sie sie per Commit.

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

UPDATE_DISK_SIZE- oder mysqld: disk is full-Fehler.

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: