Replikation aus externen Datenbanken mithilfe eines verwalteten Imports einrichten

Auf dieser Seite wird gezeigt, wie Sie einen verwalteten Import für Daten einrichten und anwenden, wenn Sie von einem externen Server zu Cloud SQL replizieren.

Es müssen dafür alle Schritte auf dieser Seite ausgeführt werden. Nach Abschluss können Sie die Quelldarstellungsinstanz auf die gleiche Weise verwalten und überwachen wie jede andere Cloud SQL-Instanz.

Vorbereitung

Führen Sie zuerst die folgenden Schritte aus:

  1. Externen Server konfigurieren

  2. Erstellen Sie die Quelldarstellungsinstanz.

  3. Richten Sie das Cloud SQL-Replikat ein.

Berechtigungen für den Replikationsnutzer aktualisieren

Der Replikationsnutzer auf dem externen Server ist so konfiguriert, dass er Verbindungen von einem beliebigen Host (%) akzeptiert. Aktualisieren Sie dieses Nutzerkonto so, dass es nur mit dem Cloud SQL-Replikat verwendet werden kann.

Erforderliche Berechtigungen

Es gibt vier Arten von Kombinationen aus Migrationen und Dumps.

  • Typ 1: Kontinuierliche Migration und verwalteter Dump
  • Typ 2: Kontinuierliche Migration und manueller Dump
  • Typ 3: Einmalige Migration und verwalteter Dump
  • Typ 4: Einmalige Migration und manueller Dump

Die Berechtigungen für die einzelnen Migrationstypen und Kombinationen mit der Option „Dumb“ sind unten aufgeführt.

Typ 1

Das Nutzerkonto muss die folgenden Berechtigungen haben:

Für MySQL Version 8.0 und höher wird empfohlen, die Berechtigung BACKUP ADMIN zu überspringen, um eine optimale Leistung zu erzielen.

Typ 2

Das Nutzerkonto muss die folgenden Berechtigungen haben:

Typ 3

Das Nutzerkonto muss die folgenden Berechtigungen haben:

Für MySQL Version 8.0 und höher wird empfohlen, die Berechtigung BACKUP ADMIN zu überspringen, um eine optimale Leistung zu erzielen.

Typ 4

Es sind keine Berechtigungen erforderlich.

Berechtigungen aktualisieren

Öffnen Sie ein Terminal auf dem externen Server und geben Sie die folgenden Befehle ein, um Berechtigungen zu aktualisieren.

MYSQL-Client

Für GTID: 

    UPDATE mysql.user
      SET Host='NEW_HOST'
      WHERE Host='OLD_HOST'
      AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION_CLIENT,
    RELOAD ON . TO
    'USERNAME'@'HOST';
    FLUSH PRIVILEGES;

Für binlog: 

    UPDATE mysql.user
    SET Host='NEW_HOST'
    WHERE Host='OLD_HOST'
    AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
    RELOAD ON . TO 'GCP_USERNAME'@'HOST';
    FLUSH PRIVILEGES;

Beispiel 

UPDATE mysql.user
  SET Host='192.0.2.0'
  WHERE Host='%'
  AND User='replicationUser';
GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
RELOAD ON *.* TO 'username'@'host.com';
FLUSH PRIVILEGES;
Attribut Beschreibung
NEW_HOST Geben Sie die ausgehende IP des Cloud SQL-Replikats an.
OLD_HOST Der aktuelle, dem Host zugewiesene Wert, den Sie ändern möchten.
USERNAME Das Nutzerkonto für die Replikation auf dem externen Server.
GCP_USERNAME Der Nutzername für das Nutzerkonto.
HOST Der Hostname für das Nutzerkonto.

Replikationseinstellungen prüfen

Prüfen Sie nach Abschluss der Einrichtung, ob das Cloud SQL-Replikat aus Daten vom externen Server erstellt werden kann.

Die folgenden Einstellungen für die externe Synchronisierung müssen korrekt sein.

  • Verbindung zwischen dem Cloud SQL-Replikat und dem externen Server
  • Berechtigungen für den Replikationsnutzer
  • Versionskompatibilität
  • Das Cloud SQL-Replikat wurde noch nicht repliziert
  • Binäre Logs sind auf dem externen Server aktiviert
  • GTID ist aktiviert, wenn Sie versuchen, eine externe Synchronisierung von einem externen RDS-Server auszuführen und dafür einen Google Cloud-Bucket verwenden

Öffnen Sie zum Prüfen dieser Einstellungen ein Cloud Shell-Terminal und geben Sie die folgenden Befehle ein:

curl 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/verifyExternalSyncSettings

Beispiel 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/myreplica/verifyExternalSyncSettings

Beispiel mit Synchronisierungs-Flags 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/verifyExternalSyncSettings

Diese Aufrufe geben eine Liste vom Typ sql#externalSyncSettingErrorList zurück.

Wenn die Liste leer ist, gibt es keine Fehler. Eine Antwort ohne Fehler wird so angezeigt:

  {
    "kind": "sql#externalSyncSettingErrorList"
  }
Attribut Beschreibung
SYNC_MODE Stellen Sie sicher, dass Sie das Cloud SQL-Replikat und den externen Server nach der Einrichtung der Replikation synchron halten können. Zu den möglichen Synchronisierungsmodi gehören EXTERNAL_SYNC_MODE_UNSPECIFIED, ONLINE und OFFLINE.
SYNC_PARALLEL_LEVEL

Prüfen Sie die Einstellung, über die die Geschwindigkeit der Übertragung von Daten aus Tabellen einer Datenbank gesteuert wird. Folgende Werte sind verfügbar:

  • min: beansprucht die geringste Menge an Rechenressourcen in der Datenbank. Dies ist die niedrigste Geschwindigkeit für die Datenübertragung.
  • optimal: bietet eine ausgewogene Leistung bei optimaler Auslastung der Datenbank.
  • max: bietet die höchste Geschwindigkeit für die Datenübertragung, was jedoch zu einer erhöhten Belastung der Datenbank führen kann.

Hinweis: Der Standardwert für diesen Parameter ist optimal, da diese Einstellung eine gute Geschwindigkeit für die Datenübertragung bietet und angemessene Auswirkungen auf die Datenbank hat. Wir empfehlen, diesen Standardwert zu verwenden.
SYNC_FLAGS Eine Liste der zu prüfenden Flags für die erste Synchronisierung. Wird nur empfohlen, wenn Sie beim Replizieren von der Quelle benutzerdefinierte Synchronisierungs-Flags verwenden möchten. Eine Liste der zulässigen Flags finden Sie unter Flags für die erste Synchronisierung.
PROJECT_ID Die ID Ihres Google Cloud-Projekts.
REPLICA_INSTANCE_ID Die ID des Cloud SQL-Replikats.

Berechtigung zur globalen Lesesperre

Wenn Sie nicht die Berechtigung haben, auf die globale Lesesperre für den externen Server zuzugreifen, wie dies bei Amazon RDS und Amazon Aurora der Fall ist, pausieren Sie die Schreibvorgänge auf Ihrem Server, wie in den folgenden Schritten beschrieben:

  1. Rufen Sie den Log-Explorer auf und wählen Sie aus der Ressourcenliste Ihr Cloud SQL-Replikat aus. Sie sollten eine Liste der neuesten Logs für das Cloud SQL-Replikat sehen. Diese können sie vorerst ignorieren.
  2. Öffnen Sie ein Terminal und geben Sie die Befehle unter Replikation auf dem externen Server starten ein, um eine Replikation vom externen Server durchzuführen.

  3. Kehren Sie zum Log-Explorer zurück. Wenn das Log wie unten angezeigt wird, beenden Sie das Schreiben in die Datenbank auf Ihrem externen Server. In den meisten Fällen ist dies nur wenige Sekunden erforderlich.

       DUMP_IMPORT(START): Start importing data, please pause any write to the
   external primary database.

  4. Wenn Sie den folgenden Logeintrag im Log-Explorer sehen, aktivieren Sie das Schreiben in die Datenbank auf dem externen Server wieder.

       DUMP_IMPORT(SYNC): Consistent state on primary and replica. Writes to the
   external primary may resume.

Replikation auf dem externen Server starten

Nachdem Sie geprüft haben, ob es möglich ist, Daten vom externen Server zu replizieren, starten Sie die Replikation. Die Replikationsgeschwindigkeit beträgt für den ersten Importvorgang bis zu 500 GB pro Stunde. Diese Geschwindigkeit kann jedoch je nach Maschinenstufe, Größe des Datenlaufwerks, Netzwerkdurchsatz und Art der Datenbank variieren.

Führen Sie beim ersten Import keine DDL-Vorgänge auf dem externen Server aus. Dies kann während des Imports zu Inkonsistenzen führen. Nach Abschluss des Importvorgangs wird das Replikat mithilfe der binären Logs auf dem externen Server auf den aktuellen Stand des externen Servers gebracht.

curl 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "skipVerification": "SKIP_VERIFICATION",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/startExternalSync

Beispiel 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync

Beispiel mit Synchronisierungs-Flags 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "skipVerification": false,
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync
Attribut Beschreibung
SYNC_MODE Bestätigen Sie, dass Sie das Cloud SQL-Replikat und den externen Server nach der Einrichtung der Replikation synchron halten können.
SKIP_VERIFICATION Gibt an, ob der integrierte Bestätigungsschritt vor der Synchronisierung der Daten übersprungen wird. Dieser Parameter wird nur empfohlen, wenn Sie Ihre Replikationseinstellungen bereits geprüft haben.
SYNC_PARALLEL_LEVEL

Geben Sie eine Einstellung an, die die Geschwindigkeit steuert, mit der Daten aus Tabellen einer Datenbank übertragen werden. Folgende Werte sind verfügbar:

  • min: beansprucht die geringste Menge an Rechenressourcen in der Datenbank. Dies ist die niedrigste Geschwindigkeit für die Datenübertragung.
  • optimal: bietet eine ausgewogene Leistung bei optimaler Auslastung der Datenbank.
  • max: bietet die höchste Geschwindigkeit für die Datenübertragung, was jedoch zu einer erhöhten Belastung der Datenbank führen kann.

Hinweis: Der Standardwert für diesen Parameter ist optimal, da diese Einstellung eine gute Geschwindigkeit für die Datenübertragung bietet und angemessene Auswirkungen auf die Datenbank hat. Wir empfehlen, diesen Standardwert zu verwenden.
SYNC_FLAGS Eine Liste der zu prüfenden Flags für die erste Synchronisierung. Wird nur empfohlen, wenn Sie beim Replizieren von der Quelle benutzerdefinierte Synchronisierungs-Flags verwenden möchten. Eine Liste der zulässigen Flags finden Sie unter Flags für die erste Synchronisierung.
PROJECT_ID Die ID Ihres Google Cloud-Projekts.
REPLICA_INSTANCE_ID Die ID des Cloud SQL-Replikats.

Flags für die erste Synchronisierung

Für die Migration mit benutzerdefinierten Datenbank-Flags können Sie die folgenden zulässigen Flags verwenden:

  • --add-drop-database
  • --add-drop-table
  • --add-drop-trigger
  • --add-locks
  • --allow-keywords
  • --all-tablespaces
  • --apply-slave-statements
  • --column-statistics
  • --comments
  • --compact
  • --compatible
  • --complete-insert
  • --compress
  • --compression-algorithms
  • --create-options
  • --default-character-set
  • --delayed-insert
  • --disable-keys
  • --dump-date
  • --events
  • --extended-insert
  • --fields-enclosed-by
  • --fields-escaped-by
  • --fields-optionally-enclosed-by
  • --fields-terminated-by
  • --flush-logs
  • --flush-privileges
  • --force
  • --get-server-public-key
  • --hex-blob
  • --ignore-error
  • --ignore-read-lock-error
  • --ignore-table
  • --insert-ignore
  • --lines-terminated-by
  • --lock-all-tables
  • --lock-tables
  • --max-allowed-packet
  • --net-buffer-length
  • --network-timeout
  • --no-autocommit
  • --no-create-db
  • --no-create-info
  • --no-data
  • --no-defaults
  • --no-set-names
  • --no-tablespaces
  • --opt
  • --order-by-primary
  • --pipe
  • --quote-names
  • --quick
  • --replace
  • --routines
  • --secure-auth
  • --set-charset
  • --shared-memory-base-name
  • --show-create-skip-secondary-engine
  • --skip-opt
  • --ssl-cipher
  • --ssl-fips-mode
  • --ssl-verify-server-cert
  • --tls-ciphersuites
  • --tls-version
  • --triggers
  • --tz-utc
  • --verbose
  • --xml
  • --zstd-compression-level

Informationen zu zulässigen Werten finden Sie in den öffentlichen MySQL-Dokumenten.

Migration überwachen

Nachdem Sie die Replikation vom externen Server gestartet haben, müssen Sie die Replikation überwachen. Weitere Informationen finden Sie unter Replikation überwachen. Sie können dann die Migration abschließen.

Fehlerbehebung

Optionen zur Fehlerbehebung:

Problem Fehlerbehebung
Beim Erstellen hat das Lesereplikat nicht repliziert. 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.
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:
Die Replikationsverzögerung steigt plötzlich stark an. Dies wird durch lang andauernde Transaktionen verursacht. Wenn ein Commit einer Transaktion (einzelne oder mehrere Anweisungen) auf der Quellinstanz durchgeführt wird, wird die Startzeit der Transaktion im binären Log aufgezeichnet. Wenn das Replikat dieses binlog-Ereignis empfängt, vergleicht es den Zeitstempel mit dem aktuellen Zeitstempel, um die Replikationsverzögerung zu berechnen. Eine lang andauernde Transaktion in der Quelle würde daher zu einer sofortigen großen Replikationsverzögerung auf dem Replikat führen. Wenn die Menge der Zeilenänderungen in der Transaktion groß ist, würde das Replikat auch viel Zeit für die Ausführung benötigen. Während der Zeit erhöht sich die Replikationsverzögerung. Sobald das Replikat diese Transaktion abgeschlossen hat, hängt die Aufholphase von der Schreibarbeitslast auf der Quelle und der Verarbeitungsgeschwindigkeit des Replikats ab.

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

Für MySQL gelten außerdem folgende Optionen:

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

Replikationslogs prüfen

Beim Prüfen der Replikationseinstellungen werden Logs erstellt.

So können Sie diese Logs abrufen:

  1. Rufen Sie in der Google Cloud Console die Loganzeige auf.

    Zur Loganzeige

  2. Wählen Sie aus dem Drop-down-Menü Instanz das Cloud SQL-Replikat aus.
  3. Wählen Sie die Logdatei replication-setup.log aus.

Prüfen Sie, ob Folgendes zutrifft, wenn das Cloud SQL-Replikat keine Verbindung zum externen Server herstellen kann.

  • Jede Firewall auf dem externen Server ist so konfiguriert, dass Verbindungen von der ausgehenden IP-Adresse des Cloud SQL-Replikats zugelassen sind.
  • Ihre SSL/TLS-Konfiguration ist korrekt.
  • Nutzername, Host und Passwort des Nutzerkontos für die Replikation sind korrekt.

Nächste Schritte