Fehlerbehebung für Cloud SQL für MySQL

Folgende Themen werden auf dieser Seite behandelt:

Auf der Seite Fehlermeldungen finden Sie Informationen zu spezifischen Fehlermeldungen.

Sicherung und Wiederherstellung

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

Führen Sie den Befehl gcloud sql operations list aus, um alle Vorgänge für die angegebene Cloud SQL-Instanz aufzulisten.

Sie möchten wissen, wer einen On-Demand-Sicherungsvorgang ausgelöst hat. Auf der Benutzeroberfläche wird nicht der Nutzer angezeigt, der einen Vorgang gestartet hat.

Suchen Sie in den Logs und filtern Sie nach Text, um den Nutzer zu finden. Möglicherweise müssen Sie Audit-Logs für private Informationen verwenden. Zu den relevanten Logdateien gehören:

  • cloudsql.googlapis.com/mysql-general.log
  • cloudsql.googleapis.com/mysql.err
  • Wenn Cloud-Audit-Logs aktiviert ist und Sie die erforderlichen Berechtigungen zum Aufrufen von Logs haben, ist möglicherweise auch cloudaudit.googleapis.com/activity verfügbar.
Nach dem Löschen einer Instanz können Sie keine Sicherung mehr vornehmen. Der Kulanzzeitraum für eine Cloud SQL-Instanzbereinigung beträgt vier Tage, mit Ausnahme von Lesereplikaten, die sofort gelöscht werden. 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 Exportvorgang durchgeführt haben, können Sie eine neue Instanz erstellen und dann mit einem Importvorgang die Datenbank neu erstellen. Exporte werden in Cloud Storage geschrieben und Importe werden von dort gelesen.

Eine automatische Sicherung bleibt viele Stunden hängen und kann nicht abgebrochen werden. Sicherungen können je nach Datenbankgröße sehr lange dauern.

Wenn Sie den Vorgang wirklich abbrechen müssen, können Sie den Kundensupport bitten, einen Neustart der Instanz zu erzwingen (force restart).

Ein Wiederherstellungsvorgang kann fehlschlagen, wenn ein oder mehrere Nutzer, auf die in der SQL-Dumpdatei verwiesen wird, nicht vorhanden sind. Vor dem Wiederherstellen eines SQL-Dumps müssen alle Datenbanknutzer, die Inhaber von Objekten in der Dumpdatenbank sind oder Berechtigungen dafür haben, in der Zieldatenbank vorhanden sein. Andernfalls kann der Wiederherstellungsvorgang die Objekte nicht mit den ursprünglichen Eigentumsrechten oder Berechtigungen neu erstellen.

Erstellen Sie die Datenbanknutzer, bevor Sie den SQL-Dump wiederherstellen.

Sie möchten die Anzahl der Tage für die Aufbewahrung automatischer Sicherungen von sieben auf 30 Tage oder länger erhöhen. 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.

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

Eine Sicherung ist fehlgeschlagen und die Meldung Unknown error wird angezeigt. Beim Sicherungsvorgang ist möglicherweise eine Zeitüberschreitung aufgetreten.

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.

Eine automatische Sicherung ist fehlgeschlagen und Sie haben keine E-Mail-Benachrichtigung erhalten. 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.

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 backups list \
--project=PROJECT_ID \
--instance=INSTANCE_ID
   

gcloud sql backups describe BACKUP-ID \
--instance=INSTANCE_ID
    

Wird geklont…

Problem Fehlerbehebung
Der Klonvorgang schlägt mit dem Fehler constraints/sql.restrictAuthorizedNetworks fehl. Der Klonvorgang wird durch die Authorized Networks-Konfiguration blockiert. Authorized Networks sind für öffentliche IP-Adressen im Bereich "Verbindung" der Google Cloud Console konfiguriert und das Klonen ist aufgrund von Sicherheitsaspekten nicht zulässig.

Entfernen Sie nach Möglichkeit alle Authorized Networks-Einträge aus der Cloud SQL-Instanz. Erstellen Sie andernfalls ein Replikat ohne Authorized Networks-Einträge.

Verbindung

Problem Fehlerbehebung
Aborted connection. Mögliche Ursache:
  • Netzwerk instabil.
  • Keine Antwort auf TCP-Keep-Alive-Befehle (entweder der Client oder der Server reagiert nicht, möglicherweise überlastet).
  • Die Verbindungsdauer des Datenbankmoduls wurde überschritten und der Server hat die Verbindung beendet.

Anwendungen sollten Netzwerkfehler tolerieren und gemäß den Best Practices mit Verbindungs-Pooling und Wiederholungsversuchen arbeiten. Die meisten Verbindungs-Pooler erfassen diese Fehler nach Möglichkeit. Andernfalls muss die Anwendung einen Wiederholungsversuch ausführen oder ordnungsgemäß fehlschlagen.

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

  1. Exponentielle Backoffs. Erhöhen Sie das Zeitintervall zwischen den einzelnen Wiederholungen exponentiell.
  2. Fügen Sie auch einen zufälligen Backoff hinzu.

Durch die Kombination dieser Methoden wird die Drosselung reduziert.

Instanzen erstellen

Problem Fehlerbehebung
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. Im zugewiesenen IP-Bereich sind keine weiteren Adressen verfügbar. Es gibt dazu mehrere mögliche Ursachen:

  • Die Größe des zugewiesenen IP-Bereichs für die private Dienstverbindung ist kleiner als /24.
  • Die zugewiesene IP-Adresse für die private Dienstverbindung ist für die Anzahl der Cloud SQL-Instanzen zu klein.
  • 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.

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

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

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

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


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

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

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

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


gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
    

Export

Problem Fehlerbehebung
CSV-Export funktioniert, SQL-Export schlägt jedoch fehl. Die Formate CSV und SQL werden unterschiedlich exportiert. Im SQL-Format wird die gesamte Datenbank exportiert, was wahrscheinlich länger dauert. Mit dem CSV-Format können Sie festlegen, welche Elemente der Datenbank in den Export einbezogen werden sollen.

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

Export dauert zu lange. Cloud SQL unterstützt keine gleichzeitigen synchronen Vorgänge.

Verwenden Sie die Exportauslagerung. Im Allgemeinen startet Cloud SQL bei der Exportauslagerung eine Auslagerungsinstanz zum Ausführen des Exports, anstatt einen Export für die Quellinstanz auszuführen. Die Exportauslagerung hat mehrere Vorteile, darunter eine höhere Leistung der Quellinstanz und die Aufhebung von Verwaltungsvorgängen, während der Export ausgeführt wird. Bei der Exportauslagerung kann sich die Gesamtlatenz um die Zeit erhöhen, die zum Erstellen der Auslagerungsinstanz erforderlich ist. Bei Exporten in angemessener Größe ist die Latenz im Allgemeinen nicht von Belang. Wenn der Export jedoch klein genug ist, können Sie einen Anstieg der Latenz feststellen.

Sie möchten Exporte automatisieren. Cloud SQL bietet keine Möglichkeit, Exporte zu automatisieren.

Sie können Ihr eigenes automatisiertes Exportsystem mit Google Cloud-Produkten wie Cloud Scheduler, Pub/Sub und Cloud Functions erstellen, ähnlich wie in diesem Artikel zur Automatisierung von Sicherungen.

Externe primäre Instanz

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

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

Weitere Informationen zur Verwendung von mysqldump-Flags für die verwaltete Importmigration finden Sie unter Zulässige und standardmäßige Flags für die erste Synchronisierung.

Die erste Datenmigration war erfolgreich, aber es werden keine Daten repliziert. Dies kann daran liegen, dass in der Quelldatenbank bestimmte Replikations-Flags definiert sind, die die Replikation von manchen oder allen Datenbankänderungen verhindern.

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 Datenmigration verlief anfangs erfolgreich, danach jedoch nicht mehr. Versuchen Sie Folgendes:

  • Prüfen Sie die Replikationsmesswerte für Ihre Replikatinstanz im Bereich "Cloud Monitoring" der Google Cloud Console.
  • Die Fehler aus dem MySQL-E/A-Thread oder dem SQL-Thread finden Sie unter Cloud Logging in den mysql.err log-Dateien.
  • 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 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.

Externes Replikat

Problem Fehlerbehebung
Fehlermeldung: The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires. 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, ab welcher Zeile mit dem Lesen begonnen werden soll, obwohl die Binärlogs vorhanden sind.

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

Problem Fehlerbehebung
Nach dem Aktivieren eines Flags wechselt die Instanz zwischen einer Panik und einem Absturz. 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.
Beim Festlegen eines Flags wird die Fehlermeldung Bad syntax for dict arg angezeigt. Komplexe Parameterwerte wie durch Kommas getrennte Listen erfordern eine besondere Behandlung, wenn sie mit gcloud-Befehlen verwendet werden.
Die Zeitzone wird nicht automatisch geändert Die automatische Änderung der Zeitzone wird in Cloud SQL for MySQL nicht unterstützt und muss manuell vorgenommen werden. Sie wird nicht nach String, sondern nach Zeitzonenversatzwert angegeben.

Bearbeiten Sie die Instanz und ändern Sie das Flag default_time_zone. Namensbereiche werden nicht unterstützt. Beispiel:

Europe/LondonLondon liegt in der UTC-Zeitzone. Der unterstützte Wert für das Flag default_time_zone ist dann +00:00.

Hochverfügbarkeit

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

Bearbeiten Sie die Instanz, um ein Upgrade auf einen Rechner mit höherer Kapazität durchzuführen, sodass mehr CPUs und Speicherplatz verfügbar sind.

Import

Problem Fehlerbehebung
Der Importvorgang dauert zu lange. Zu viele aktive Verbindungen können Importvorgänge beeinträchtigen.

Schließen Sie nicht verwendete Vorgänge. Prüfen Sie die CPU- und Arbeitsspeichernutzung Ihrer Cloud SQL-Instanz, um dafür zu sorgen, dass genügend Ressourcen verfügbar sind. Die beste Methode, um maximale Ressourcen für den Import zu gewährleisten, ist ein Neustart der Instanz vor Beginn des Vorgangs.

Ein Neustart

  • beendet alle Verbindungen und
  • beendet alle Aufgaben, die möglicherweise Ressourcen nutzen.
Ein Importvorgang kann fehlschlagen, wenn ein oder mehrere Nutzer, auf die in der Dumpdatei verwiesen wird, nicht vorhanden sind. Vor dem Importieren einer Dumpdatei müssen alle Datenbanknutzer, die Inhaber von Objekten sind oder Berechtigungen für Objekte in der Dumpdatenbank erhalten haben, in der Zieldatenbank vorhanden sein. Andernfalls kann der Importvorgang die Objekte nicht mit den ursprünglichen Eigentumsrechten oder Berechtigungen neu erstellen.

Erstellen Sie die Datenbanknutzer vor dem Import.

Ein Importvorgang schlägt mit der Fehlermeldung fehl, dass keine Tabelle vorhanden ist. 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.

Versuchen Sie Folgendes:

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.

Logging

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

Das Flag log_statement kann auf "none" und das Flag logging_collector auf "off" gesetzt werden. Wenn das Problem mit Logging weiterhin auftritt, können andere logbezogene Flags angepasst werden. Sie können die Instanz bearbeiten und diese Flags ändern.

Audit-Logs wurden nicht gefunden. Logs zum Datenzugriff werden nur geschrieben, wenn der Vorgang ein authentifizierter, nutzergesteuerter API-Aufruf ist, der von Nutzern erstellte Daten erstellt, ändert oder liest, oder wenn der Vorgang auf Konfigurationsdateien oder Metadaten von Ressourcen zugreift.
Vorgangsinformationen wurden nicht in Logs gefunden. Sie möchten weitere Informationen zu einem Vorgang erhalten.

Beispiel: Ein Nutzer wurde gelöscht, aber Sie können nicht sehen, wer ihn gelöscht hat. Die Logs zeigen den gestarteten Vorgang an, enthalten jedoch keine weiteren Informationen. Für die Erfassung detaillierter und personenidentifizierbarer Informationen wie diesen müssen Sie Audit-Logging aktivieren.

Einige Logs werden aus dem Log error.log einer Cloud SQL for SQL Server-Instanz gefiltert. Gefilterte Logs inkludieren AD-Logs ohne Zeitstempel und umfassen: Login failed for user 'x'. Reason: Token-based server access validation failed with an infrastructure error. Login lacks connect endpoint permission. [CLIENT: 127.0.0.1]. Diese Logs werden gefiltert, da sie möglicherweise zu Verwirrung führen.
Logging beansprucht viel Speicherplatz. Es gibt drei Arten von Logdateien, die Speicherplatz belegen: Redo-Logs, allgemeine Logs und binäre Logs.

Stellen Sie eine Verbindung zur Datenbank her und führen Sie die folgenden Befehle aus, um Details zu den einzelnen Arten 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. Sie können die Logs alternativ im JSON- oder Textformat aufrufen. Sie können zum Herunterladen der Logs den Befehl gcloud logging read zusammen mit Linux-Nachbearbeitungsbefehlen verwenden.

So laden Sie die Logs im JSON-Format herunter:


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

So laden Sie die Logs im TEXT-Format herunter:


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

Instanzen verwalten

Problem Fehlerbehebung
Beeinträchtigte Leistung nach dem Neustart von MySQL. 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.
Langsame Wiederherstellung nach einem Absturz. Möglicherweise hat sich ein großes general_log angesammelt. 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;
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. Der Großteil des Speicherplatzes, der nicht von Tabellen belegt wird, wird von binären Logs und/oder temporären Dateien genutzt.

Versuchen Sie Folgendes:

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

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.

Sie können binäre Logs nicht manuell löschen. Binäre Logs können nicht manuell gelöscht werden. Sie werden automatisch mit der zugehörigen automatischen Sicherung gelöscht. Dies erfolgt grundsätzlich nach ca. sieben Tagen.
Sie möchten Informationen zu temporären Dateien finden. Die Datei ibtmp1 wird zum Speichern temporärer Daten verwendet. Diese Datei wird beim Neustart der Datenbank zurückgesetzt. Um Informationen zur Nutzung temporärer Dateien zu erhalten, stellen Sie eine Verbindung zur Datenbank her und führen Sie die folgende Abfrage aus:

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

Sie möchten mehr über Tabellengrößen erfahren. Diese Informationen sind in der Datenbank verfügbar.

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 das Signal 11. Die Instanz ist wahrscheinlich abgestürzt, weil durch Abfragen zu viele Verbindungen hergestellt werden.

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

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

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

Automatischer Speicher wurde durch temporären Speicher erhöht. Der automatische Speicher ist aktiviert.

Durch den Neustart werden die temporären Dateien gelöscht, der Speicherplatz wird jedoch nicht reduziert. Nur der Kundensupport kann die Instanzgröße zurücksetzen.

Daten werden automatisch gelöscht. Höchstwahrscheinlich wird irgendwo in Ihrer Umgebung ein Skript ausgeführt.

Sehen Sie in den Logs zur Zeit des Löschvorgangs nach, ob ein schädliches Skript über ein Dashboard oder einen anderen automatisierten Prozess ausgeführt wird.

Instanz kann nicht gelöscht werden. Sie sehen möglicherweise die Fehlermeldung ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request oder die Instanz hat möglicherweise den Flag-Status INSTANCE_RISKY_FLAG_CONFIG.

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

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

Sie können die ibtmp1-Datei nur durch einen Neustart des Dienstes verkleinern.

Eine Möglichkeit, das Problem zu beheben, besteht darin, die temporäre Tabelle mit ROW_FORMAT=COMPRESSED zu erstellen, sodass sie in Tablespaces für Dateien im temporären Dateiverzeichnis gespeichert wird. Allerdings sind mit dem Erstellen und Entfernen eines Tablespace für jede temporäre Tabelle Leistungskosten verbunden.

Schwerwiegender Fehler beim Upgrade. Die Logs enthalten zwar möglicherweise weitere Informationen, aber wahrscheinlich benötigen Sie Hilfe vom Kundensupport, um die Neuerstellung der Instanz zu erzwingen.
Instanz bleibt beim Neustart hängen, nachdem der Speicherplatz ausgeschöpft ist. Die automatische Speichererweiterung ist nicht aktiviert.

Wenn der Speicherplatz Ihrer Instanz aufgebraucht ist und die automatische Speichererweiterung nicht aktiviert ist, wird die Instanz offline geschaltet. Dies können Sie vermeiden, wenn Sie die Instanz bearbeiten und die automatische Speichererweiterung aktivieren.

Die lokale primäre Instanz bleibt hängen Google Cloud bietet für Instanzen, die nicht in Cloud SQL enthalten sind, keine Unterstützung.
Langsames Herunterfahren beim Neustart. Beim Herunterfahren einer Instanz können alle ausstehenden Verbindungen, die nicht innerhalb von 60 Sekunden beendet werden, ein nicht ordnungsgemäßes Herunterfahren verursachen.

Wenn Sie Verbindungen von weniger als 60 Sekunden verwenden, kann in den meisten Fällen das nicht ordnungsgemäße Herunterfahren vermieden werden. Dies gilt auch für Verbindungen, die über die Eingabeaufforderung der Datenbank hergestellt werden. Wenn Sie diese Verbindungen mehrere Stunden oder Tage geöffnet lassen, kann dies das Herunterfahren beeinträchtigen.

Nutzer kann nicht gelöscht werden. Der Nutzer ist wahrscheinlich Inhaber von Objekten in der Datenbank, die davon abhängig sind. Sie müssen diese Objekte löschen oder einem anderen Nutzer zuweisen.

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

In diesem Artikel wird erläutert, wie Sie die Objekte finden, deren Eigentümer der Nutzer ist.
Bestimmte Abfragen werden langsam ausgeführt. Abfragen können aus vielen Gründen langsam sein, hauptsächlich aufgrund bestimmter Aspekte der Datenbank. Ein Grund, der sich auf Cloud SQL auswirken kann, ist die Netzwerklatenz, wenn sich die Quellressource (Autor oder Leser) und die Zielressource (Cloud SQL) in verschiedenen Regionen befinden.

Lesen Sie insbesondere die Informationen unter Allgemeine Leistungstipps.

Wenn Datenbankeinträge, Aktualisierungen oder Löschvorgänge sehr langsam sind, probieren Sie Folgendes:

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

Neben der Arbeitslast gibt es weitere Faktoren, die sich auf die Speichernutzung auswirken können, z. B. die Anzahl der aktiven Verbindungen und internen Overhead-Prozesse. Diese werden nicht immer in den Monitoring-Diagrammen widergespiegelt.

Die Instanz muss genügend Kapazität für die Arbeitslast und zusätzlichen Overhead haben.

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

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

Die Rolle "Cloud SQL-Administrator" enthält die Berechtigung zum Löschen der Instanz. Gewähren Sie diese Rolle nur, wenn nötig, um ein versehentliches Löschen zu vermeiden.

Sie möchten eine vorhandene Cloud SQL-Instanz umbenennen. Das Umbenennen einer vorhandenen Instanz wird nicht unterstützt.

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

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

In beiden Fällen können Sie Ihre alte Instanz löschen, nachdem der Vorgang abgeschlossen wurde. Es wird empfohlen, das Klonen zu verwenden, da dies keine Beeinträchtigung der Leistung nach sich zieht und Sie die Einstellungen der Instanzkonfiguration zu Flags, Maschinentyp, Speichergröße und Arbeitsspeicher nicht noch einmal festlegen müssen.

Replikation

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

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

Wenn das Flag max_connections korrekt festgelegt ist, prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.

Lesereplikat kann nicht erstellt werden – unbekannter Fehler. Möglicherweise finden Sie in den Logdateien einen spezifischen Fehler. Prüfen Sie die Logs in Cloud Logging, um den tatsächlichen Fehler zu finden.

Lautet der Fehler set Service Networking service account as servicenetworking.serviceAgent role on consumer project, deaktivieren Sie die Service Networking API und aktivieren Sie sie dann wieder. Dadurch wird das Dienstkonto erstellt, das erforderlich ist, um den Prozess fortzusetzen.

Laufwerk ist voll. Das Laufwerk der primären Instanz kann während der Replikaterstellung zu voll werden. Bearbeiten Sie die primäre Instanz, um sie auf ein größeres Laufwerk zu aktualisieren.
Die Replikatinstanz verwendet zu viel Arbeitsspeicher. Das Replikat verwendet temporären Speicher zum Speichern häufig angeforderter Lesevorgänge im Cache, was dazu führen kann, dass es mehr Speicher als die primäre Instanz verwendet.

Starten Sie die Replikatinstanz neu, um den temporären Speicherplatz freizugeben.

Replikation gestoppt. Das maximale Speicherlimit wurde erreicht und die automatische Speichererweiterung ist nicht aktiviert.

Bearbeiten Sie die Instanz, um automatic storage increase zu aktivieren.

Replikationsverzögerung ist durchgehend hoch. Die Schreiblast ist für das Replikat zu hoch. Die Replikationsverzögerung tritt auf, wenn der SQL-Thread auf einem Replikat nicht mit dem E/A-Thread Schritt halten kann. Einige Arten von Abfragen oder Arbeitslasten können vorübergehend oder dauerhaft zu einer hohen Replikationsverzögerung für ein bestimmtes Schema führen. Typische Ursachen für Replikationsverzögerungen sind:
  • Langsame Abfragen des Replikats. Suchen Sie diese und korrigieren Sie sie.
  • Alle Tabellen müssen einen eindeutigen Schlüssel/Primärschlüssel haben. Jede Aktualisierung einer solchen Tabelle ohne eindeutigen bzw. Primärschlüssel führt zu vollständigen Tabellenscans auf dem Replikat.
  • Abfragen wie DELETE ... WHERE field < 50000000 führen bei der zeilenbasierten Replikation zu einer Replikationsverzögerung, da sich eine große Anzahl von Aktualisierungen auf dem Replikat ansammelt.

Hier einige mögliche Lösungen:

Das Ändern der Flags für die parallele Replikation führt zu einem Fehler. Für mindestens eines dieser Flags wurde ein falscher Wert festgelegt.

Legen Sie in der primären Instanz, die die Fehlermeldung anzeigt, die Flags für die parallele Replikation fest:

  1. Ändern Sie die Flags binlog_transaction_dependency_tracking und transaction_write_set_extraction:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Fügen Sie das Flag slave_pending_jobs_size_max hinzu:

    slave_pending_jobs_size_max=33554432

  3. Ändern Sie das Flag transaction_write_set_extraction:

    transaction_write_set_extraction=XXHASH64

  4. Ändern Sie das Flag binlog_transaction_dependency_tracking:

    binlog_transaction_dependency_tracking=WRITESET

Die Replikaterstellung schlägt bei Zeitüberschreitung fehl. Langlaufende Transaktionen ohne Commit auf der primären Instanz können dazu führen, dass die Lesereplikaterstellung fehlschlägt.

Erstellen Sie das Replikat neu, nachdem alle laufenden Abfragen beendet sind.