Fehler beheben

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

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.

Nachdem eine Instanz dauerhaft gelöscht wurde, ist keine Datenwiederherstellung mehr möglich. Wenn die Instanz jedoch wiederhergestellt wird, werden auch ihre Sicherungen wiederhergestellt. Weitere Informationen zum Wiederherstellen einer gelöschten Instanz finden Sie unter Wiederherstellungssicherungen.

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.

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

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

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.

Sie versuchen, einen Import- oder Exportvorgang abzubrechen, der abgeschlossen, fehlgeschlagen oder abgebrochen ist. Wenn der Vorgang ausgeführt wird, können Sie ihn abbrechen.

Cloud SQL unterstützt nicht das Abbrechen des Vorgangs, da es einen anderen Vorgangstyp als IMPORT oder EXPORT hat.

Cloud SQL kann den Import- oder Exportvorgang derzeit nicht abbrechen. Bitte versuch es in ein paar Sekunden noch einmal. Wenn das Problem weiterhin besteht, wenden Sie sich an den Google Cloud Support.

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.

Sie versuchen, die Google Cloud Console zu verwenden, um eine Instanz mit einer privaten IP-Adresse zu klonen, aber Sie haben den zugewiesenen IP-Bereich, den Sie verwenden möchten, nicht angegeben, und die Quellinstanz wird nicht mit dem angegebenen Bereich erstellt. Dadurch wird die geklonte Instanz in einem zufälligen Bereich erstellt.

Klonen Sie mit gcloud die Instanz und geben Sie einen Wert für den
Parameter --allocated-ip-range-name an. Weitere Informationen finden Sie unter Instanz mit einer privaten IP-Adresse klonen.

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

Die Clientzertifikate sind abgelaufen oder der Pfad zu den Zertifikaten ist nicht korrekt.

Generieren Sie die Zertifikate neu, indem Sie sie neu erstellen.

• 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.
• Die Anforderungen bezüglich der Größe des zugewiesenen IP-Bereichs sind höher, wenn Instanzen in mehreren Regionen erstellt werden. Siehe Größe des zugewiesenen Bereichs.

Zur Behebung dieses Problems können Sie entweder den vorhandenen zugewiesenen IP-Bereich erweitern oder der privaten Dienstverbindung einen zusätzlichen IP-Bereich zuweisen. Weitere Informationen finden Sie unter IP-Adressbereich 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
    

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

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

Sorgen Sie dafür, dass die externe primäre Instanz für die Verbindungsherstellung verfügbar ist. Sie können die Werte der Flags net_read_timeout und net_write_timeout auf der Quellinstanz auch ändern, um den Fehler zu beenden. Weitere Informationen zu den zulässigen Werten für diese Flags finden Sie unter Datenbank-Flags konfigurieren.

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.

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.

• 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

Erhöhen Sie die Laufwerkgröße der Replikatinstanz. Sie können die Laufwerkgröße manuell erhöhen oder die automatische Speichererweiterung aktivieren.

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.

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.

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.

Erstellen Sie die Datenbanknutzer vor dem Import.

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.

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.

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;
    

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 als TEXT 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"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
--order=asc
> downloaded-log.txt
   

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:

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

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.

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

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;

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

1. Prüfen Sie den Status des Endpunkts.

   gcloud

   Verwenden Sie zum Prüfen des Status den Befehl
   gcloud compute forwarding-rules describe.

   gcloud compute forwarding-rules describe ENDPOINT_NAME \
   --project=PROJECT_ID \
   --region=REGION_NAME \
   | grep pscConnectionStatus

   Ersetzen Sie die folgenden Werte:

   • ENDPOINT_NAME: der Name des Endpunkts.
   • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das den Endpunkt enthält
   • REGION_NAME: der Name der Region für den Endpunkt.

   REST

   Ersetzen Sie diese Werte in den folgenden Anfragedaten:

   • PROJECT_ID: die ID oder Projektnummer des Google Cloud-Projekts, das den Private Service Connect-Endpunkt enthält
   • REGION_NAME: der Name der Region
   • ENDPOINT_NAME: der Name des Endpunkts.

   HTTP-Methode und URL:

   GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME

   Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

   curl (Linux, macOS oder Cloud Shell)

   Führen Sie folgenden Befehl aus:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME"

   PowerShell (Windows)

   Führen Sie folgenden Befehl aus:

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME" | Select-Object -Expand Content

   Sie sollten in etwa folgende JSON-Antwort erhalten:

   {
     "kind": "compute#forwardingRule",
     "id": "ENDPOINT_ID",
     "creationTimestamp": "2024-05-09T12:03:21.383-07:00",
     "name": "ENDPOINT_NAME",
     "region": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME",
     "IPAddress": "IP_ADDRESS",
     "target": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/serviceAttachments/SERVICE_ATTACHMENT_NAME",
     "selfLink": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME",
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
     "serviceDirectoryRegistrations": [
       {
         "namespace": "goog-psc-default"
       }
     ],
     "networkTier": "PREMIUM",
     "labelFingerprint": "LABEL_FINGERPRINT_ID",
     "fingerprint": "FINGERPRINT_ID",
     "pscConnectionId": "CONNECTION_ID",
     "pscConnectionStatus": "ACCEPTED",
     "allowPscGlobalAccess": true
   }
   

2. Prüfen Sie, ob der Status des Endpunkts ACCEPTED lautet. Wenn der Status PENDING lautet, lässt die Instanz das Google Cloud-Projekt, das den Endpunkt enthält, nicht zu. Achten Sie darauf, dass das Netzwerkprojekt, in dem der Endpunkt erstellt wird, zugelassen wird. Weitere Informationen finden Sie unter Instanz mit aktiviertem Private Service Connect bearbeiten.

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.

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.

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

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

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

• Parallele Replikation konfigurieren
• Setzen Sie das Flag innodb_flush_log_at_trx_commit für das Lesereplikat auf 2.

  Unter Tipps zum Arbeiten mit Flags finden Sie weitere Informationen zu diesem Flag.

• Bearbeiten Sie die Instanz, um die Größe des Replikats zu erhöhen.
• Reduzieren Sie die Belastung der Datenbank.
• Senden Sie Lesetraffic an das Lesereplikat.
• Indexieren Sie die Tabellen.
• Ermitteln und beheben Sie Probleme mit langsamen Schreibabfragen.
• Erstellen Sie das Replikat neu.

So vermeiden Sie lange Transaktionen z. B.:

• Teilen Sie die Transaktion in mehrere kleine Transaktionen auf
• Teilen Sie eine einzelne große Schreibabfrage in kleinere Batches auf
• Versuchen Sie, lange SELECT-Abfragen von einer mit DML-Daten gemischten Transaktion zu trennen

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

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