Auf dieser Seite wird die Vorgehensweise zur Einrichtung der Replikation von einem externen Server mithilfe eines benutzerdefinierten Imports erläutert. Diese Schritte werden empfohlen, wenn Sie aus einer großen externen Datenbank replizieren müssen.
Es müssen dafür alle Schritte auf dieser Seite ausgeführt werden. Nach Abschluss können Sie das Replikat auf die gleiche Weise verwalten und überwachen wie jede andere Cloud SQL-Instanz.
Dieser Prozess wird nur für externe Server unterstützt, die so konfiguriert sind, dass sie die auf einer globalen Transaktions-ID (GTID) basierende Replikation verwenden. Bevor die Replikation initiiert werden kann, müssen Sie Daten vom externen Server in das Cloud SQL-Replikat laden. Wenn Sie keine GTID-basierte Replikation verwenden, kann Cloud SQL die genaue Position des binären Logs, ab der die Replikation beginnen soll, nicht identifizieren. Wenn Sie keine GITD-basierte Replikation verwenden können, müssen Sie Ihr Dump-Tool so konfigurieren, dass während des Dumpprozesses eine globale schreibgeschützte Sperre eingerichtet wird.
Vorbereitung
Für diesen Vorgang muss der externe Server konfiguriert, die Quelldarstellungsinstanz erstellt und das Cloud SQL-Replikat eingerichtet sein.
Berechtigungen für den Replikationsnutzer aktualisieren
Das Nutzerkonto für die Replikation auf dem externen Server ist so konfiguriert, dass Verbindungen von jedem Host (%) akzeptiert werden. Aktualisieren Sie dieses Nutzerkonto so, dass es nur mit dem Cloud SQL-Replikat verwendet werden kann.
Öffnen Sie auf dem Quelldatenbankserver ein Terminal und geben Sie die folgenden Befehle ein:
MYSQL-Client
UPDATE mysql.user SET Host='NEW_HOST' WHERE Host='OLD_HOST' AND User='USERNAME'; GRANT REPLICATION SLAVE, EXECUTE 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 ON *.*
TO 'gcp_user'@'gmail.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 GCP-Nutzerkonto. |
| HOST | Der Hostname für das GCP-Nutzerkonto. |
Cloud SQL-Replikat als primäre Instanz einrichten
Da Cloud SQL-Replikatinstanzen schreibgeschützt sind, müssen Sie für einen benutzerdefinierten Import das Cloud SQL-Replikat zu einer eigenständigen Instanz hochstufen. Nach Abschluss des anfänglichen Datenimports stufen Sie die Instanz wieder auf ein Replikat zurück.
Benutzerdefinierten Dump/Import durchführen
In diesem Abschnitt wird gezeigt, wie Sie die Dumpdatei erstellen und sie mithilfe des Clientdienstprogramms mydumper odermysqldump in das letztendliche Cloud SQL-Replikat importieren.
Beim Auslesen der Daten müssen Sie möglicherweise generische MySQL-Datenbanken, einschließlich mysql und sys, ausschließen, sofern sie auf der Quellinstanz vorhanden sind. Andernfalls schlägt der Datenimport fehl. Weitere Informationen finden Sie unter Datenbanken ausschließen oder einschließen.
mydumper und myloader verwenden
So erstellen Sie eine Dumpdatei und importieren sie in Cloud SQL:
Erstellen Sie mit
mydumpereine Dumpdatei der externen Serverdatenbank.$ mydumper -u USERNAME -p PASSWORD \ --threads=16 -o ./backup \ -h HOST \ --no-locks \ --regex '^(?!(mysql\.|sys\.))'
Attribut Beschreibung USERNAME Der Name des Nutzerkontos für die Replikation oder der Name des Nutzerkontos mit Datenbankleseberechtigungen auf dem externen Server. PASSWORD Nutzerpasswort für die Replikation. HOST Die IPv4- oder DNS-Adresse des externen Servers. Importieren Sie die Daten mit
myloaderin die Cloud SQL-Instanz.$ myloader -u REPLICA_USERNAME -p REPLICA_PASSWORD \ --threads=16 \ -d ./backup -h HOST -o
Attribut Beschreibung REPLICA_USERNAME Das Nutzerkonto in der Cloud SQL-Instanz. REPLICA_PASSWORD Nutzerpasswort für die Cloud SQL-Instanz. HOST Die IPv4-Adresse für die Cloud SQL-Instanz. Notieren Sie sich die GTID- oder binlog-Informationen des Datendumps. Sie benötigen diese Informationen, wenn Sie die Replikation mit den gespeicherten Prozeduren konfigurieren.
Führen Sie den folgenden Befehl aus, um die GTID- oder binlog-Informationen der Datenverschiebung abzurufen:
sudo cat ./backup/metadata
mysqldump verwenden
Erstellen Sie einen Dump mithilfe von
mysqldump:mysqldumpmysqldump \ --host=EXTERNAL_HOST \ --port=EXTERNAL_PORT \ --user=USERNAME\ --password=PASSWORD \ --databases=DATABASE_LIST \ --hex-blob \ --master-data=EXTERNAL_DATA \ --no-autocommit \ --default-character-set=utf8mb4 \ --single-transaction \ GTID_PURGED \ ADD_DROP_TABLE \ ROUTINES \ COMPRESS \ GZIP
Attribut Beschreibung EXTERNAL_HOST Die IPv4- oder DNS-Adresse des externen Servers. EXTERNAL_PORT Der Port für den externen Server. Wenn der externe Server in Cloud SQL gehostet wird, lautet dieser Port 3306.USERNAME Der Name des Nutzerkontos für die Replikation oder der Name des Nutzerkontos mit Datenbankleseberechtigungen auf dem externen Server. USER_PASSWORD Nutzerpasswort für die Replikation. DATABASE_LIST Durch Leerzeichen getrennte Liste aller Datenbanken auf dem externen Server mit Ausnahme der Systemdatenbanken ( sys,mysql,performance_schemaundinformation_schema). Verwenden Sie den MySQL-BefehlSHOW DATABASES, um Ihre Datenbanken aufzulisten.EXTERNAL_DATA Wenn der externe Server GTID nicht unterstützt und Sie berechtigt sind, auf dessen globale Lesesperre zuzugreifen, verwenden Sie --master-data=1. Andernfalls sollten Sie dieses Attribut nicht nutzen.GTID_PURGED Wenn der externe Server GTID unterstützt, verwenden Sie --set-gtid-purged=on. Andernfalls sollten Sie dieses Attribut nicht nutzen.ADD_DROP_TABLE Wenn Sie vor jeder CREATE TABLE-Anweisung eineDROP TABLE-Anweisung einfügen möchten, fügen Sie--add-drop-tablehinzu.ROUTINES Wenn Sie gespeicherte Routinen wie Prozeduren und Funktionen anzeigen lassen möchten, geben Sie in der Ausgabe für Dumpdatenbanken --routinesan.COMPRESS Um alle Informationen zu komprimieren, die zwischen dem Cloud SQL-Replikat und dem externen Server gesendet werden, verwenden Sie --compress.GZIP Wenn Sie die Dumpdatei noch stärker komprimieren möchten, verwenden Sie | gzip. Verwenden Sie dies nicht, wenn Ihre Datenbank Daten enthält, die sich nicht gut komprimieren lassen, z. B. nicht komprimierbare Binärdaten oder JPG-Bilder.Beispiel
mysqldump \ --host=192.0.2.1 \ --port=3306 \ --user=replicationUser \ --password \ --databases guestbook journal \ --hex-blob \ --master-data=1 \ --no-autocommit \ --default-character-set=utf8mb4 \ --single-transaction \ --compress \ | gzip
Notieren Sie sich die GTID- oder binlog-Informationen des Datendumps. Sie benötigen diese Informationen, um die Replikation mit den gespeicherten Prozeduren von Cloud SQL zu konfigurieren.
Suchen Sie für GTID eine Zeile wie die folgende:
SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496';
Suchen Sie für binlog eine Zeile wie die folgende:
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;
Entfernen Sie die folgenden Zeilen in der Dumpdatei, die Superberechtigungen benötigen. Da Cloud SQL-Nutzer keine Superberechtigungen haben, führen diese Zeilen dazu, dass der Import fehlschlägt.
Entfernen Sie bei der GTID-basierten Replikation die Anweisung SET GTID_PURGED zusammen mit der Anweisung zur Festlegung der Sitzungsvariablen im Dump. Beispiel:
... SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN; SET @@SESSION.SQL_LOG_BIN= 0; ... SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496'; ... SET @@SESSION.SQL_LOG_BIN=@MYSQLDUMP_TEMP_LOG_BIN;
Entfernen Sie bei der binlogbasierten Replikation die Anweisung CHANGE MASTER. Beispiel:
... CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360; ...
Importieren Sie die Daten mit der
mysql-Befehlszeile in das Cloud SQL-Replikat:mysqlmysql -h REPLICA_HOST -u REPLICA_USER \ -p REPLICA_DATABASE_NAME RESULT_FILE
Attribut Beschreibung REPLICA_HOST Host, auf dem sich der MySQL-Server befindet. REPLICA_USER MySQL-Nutzername, der beim Herstellen einer Verbindung zum Server verwendet werden soll. REPLICA_DATABASE_NAME Name der Datenbank, in der sich die Daten befinden. RESULT_FILE Name der Dumpdatei, die importiert werden soll. Beispiel
mysql -h 255.255.255.255 -u replica_username -p replica_db < result.sql
Sie können die Dumpdatei auch mithilfe eines Google Cloud-Buckets importieren. Weitere Informationen dazu erhalten Sie unter Daten aus einer SQL-Dumpdatei in Cloud SQL importieren.
Cloud SQL-Instanz zurückstufen
Um die Cloud SQL-Instanz auf ein Cloud SQL-Replikat zurückzustufen, verwenden Sie auf der Instanz die Methode demoteMaster.
Bereiten Sie eine JSON-Anfragedatei mit dem Namen der Instanz vor, die Sie zurückstufen möchten.
Source JSON
{ "demoteMasterContext": { "masterInstanceName": SOURCE_REPRESENTATION_INSTANCE_NAME, "skipReplicationSetup": true } }
Attribut Beschreibung SOURCE_REPRESENTATION_INSTANCE_NAME Der Name der Quelldarstellungsinstanz. Beispiel
{ "demoteMasterContext": { "masterInstanceName": "cloudsql-source-instance", "skipReplicationSetup": true } }
Öffnen Sie ein Terminal und rufen Sie mit den folgenden Befehlen
demoteMasterauf:curl
gcloud auth login ACCESS_TOKEN="$(gcloud auth print-access-token)" curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header 'Content-Type: application/json' \ --data @JSON_PATH \ -X POST \ https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT-ID/instances/INSTANCE-NAME/demoteMaster
Attribut Beschreibung JSON_PATH Der Pfad zur Datei JSON.PROJECT_ID Die ID Ihres Projekts in Google Cloud. INSTANCE-NAME Der Name der Instanz, die zurückgestuft werden soll. Beispiel
gcloud auth login ACCESS_TOKEN="$(gcloud auth print-access-token)" curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header 'Content-Type: application/json' \ --data @./source.json \ -X POST \ https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/cloudsql-replica-instance/demoteMaster
Was Sie nach dem Abschluss sehen sollten
Rufen Sie die Seite Cloud SQL-Instanzen auf, um zu prüfen, ob die Instanzen korrekt eingerichtet wurden.
Sie sollten die Quelldarstellungsinstanz und das Cloud SQL-Replikat sehen. Sie sehen etwa so aus:
| Instanz-ID | Typ | Öffentliche IP-Adresse |
|---|---|---|
| (-) source-representation-instance | Externe primäre MySQL-Instanz | 10.68.48.3:3306 |
| Replikatinstanz | MySQL-Lesereplikat | 34.66.48.59 |
Replikation in der Cloud SQL-Instanz starten
In diesem Schritt werden gespeicherte Prozeduren von Cloud SQL verwendet. Die gespeicherten Prozeduren von Cloud SQL werden nach dem Aufruf der demoteMaster-Anfrage installiert. Nach dem Aufruf von promoteReplica werden Sie wieder entfernt. Weitere Informationen finden Sie unter Gespeicherte Prozeduren für die Replikationsverwaltung.
- Melden Sie sich bei der Replikatinstanz an. Weitere Informationen finden Sie unter Verbindung mithilfe eines Datenbankclients von einem lokalen Computer herstellen.
Verwenden Sie die gespeicherte Prozedur
mysql.resetMaster, um die Replikationseinstellungen zurückzusetzen.mysql> call mysql.resetMaster();
Konfigurieren Sie die Replikation. Für diesen Schritt sind die zuvor notierten GTID- oder binlog-Informationen erforderlich.
GTID
- Konfigurieren Sie das Feld
gtid_purgedmit der gespeicherten Prozedurmysql.skipTransactionWithGtid(GTID_TO_SKIP).
Attribut Beschreibung GTID_TO_SKIP Der GTID-Satzwert, der konfiguriert werden soll. Beispiel:
mysql> call mysql.skipTransactionWithGtid('32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496');
- Führen Sie die gespeicherte Prozedur
mysql.setupExternalSourceAutoPosition(HOST, PORT, USER_NAME, USER_PASSWORD, MASTER_AUTO_POSITION, USE_SSL, USE_SSL_CLIENT_AUTH)aus.
Attribut Beschreibung HOST Quellendpunkt. PORT Quellport. USER_NAME Quellnutzer. USER_PASSWORD Quellnutzerpasswort. MASTER_AUTO_POSITION Wert des Parameters master_auto_position. Folgende Werte sind möglich:0,1.USE_SSL Legt fest, ob die SSL-basierte Replikation verwendet werden soll. Folgende Werte sind möglich: true,false. Fürtruemüssen Sie das FeldcaCertificatein derDemoteMaster-Anfrage festlegen.USE_SSL_CLIENT_AUTH Legt fest, ob die SSL-Clientauthentifizierung verwendet werden soll. Folgende Werte sind möglich: true,false. Fürtruemüssen Sie die FelderclientKeyundclientCertificatesin derdemoteMaster-Anfrage festlegen.mysql> call mysql.setupExternalSourceAutoPosition('1.1.1.1', 3306, \ 'USERNAME', 'PASSWORD', \ /* master_auto_position= */ 1,false, false); \
binlog
Führen Sie die gespeicherte Prozedur
mysql.setupExternalSource(HOST, PORT, USER_NAME, USER_PASSWORD, SOURCE_LOG_NAME, SOURCE_LOG_POS, USE_SSL, USE_SSL_CLIENT_AUTH)aus.Attribut Beschreibung HOST Quellendpunkt. PORT Quellport. USER_NAME Quellnutzer. USER_PASSWORD Quellnutzerpasswort. SOURCE_LOG_NAME Der Name des binären Logs auf der Quelldatenbankinstanz, die die Replikationsinformationen enthält. SOURCE_LOG_POS Der Speicherort im Binärlog mysql_binary_log_file_name, an dem die Replikation mit dem Lesen der Replikationsinformationen startet.USE_SSL Legt fest, ob die SSL-basierte Replikation verwendet werden soll. Folgende Werte sind möglich: true,false. Fürtruemüssen Sie das FeldcaCertificatein derDemoteMaster-Anfrage festlegen.USE_SSL_CLIENT_AUTH Legt fest, ob die SSL-Clientauthentifizierung verwendet werden soll. Folgende Werte sind möglich: true,false. Fürtruemüssen Sie die FelderclientKeyundclientCertificatesin derdemoteMaster-Anfrage festlegen.mysql> call mysql.setupExternalSource('1.1.1.1', 3306, \ 'user_name', 'password', 'mysql-bin-changelog.033877', 360, \ false, false);
- Konfigurieren Sie das Feld
Verwenden Sie die gespeicherte Prozedur
mysql.startReplication(), um die Replikation aus der externen Datenbank zu starten.mysql> call mysql.startReplication();
Prüfen Sie den Replikationsstatus. Achten Sie darauf, dass sowohl für das Feld
Slave_IO_Runningals auch für das FeldSlave_SQL_Runningder WertYESgilt.mysql> show slave status\G
Die Ausgabe dieses Befehls sieht in etwa so aus:
*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 1.1.1.1 Master_User: user_name Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin-changelog.000001 Read_Master_Log_Pos: 1 Relay_Log_File: relay-log.000002 Relay_Log_Pos: 1 Relay_Master_Log_File: mysql-bin-changelog.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: mysql.% Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 412 Relay_Log_Space: 752 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1509941531 Master_UUID: 1cb2c80e-90f0-11eb-9ea3-02389b1c2e6f Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all r Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: 478af53c-bd24-11eb-be72-42010a80002a:1-226 Auto_Position: 0 1 row in set (0.00 sec)
Mit Replikation fortfahren
Nachdem Sie die Replikation vom externen Server gestartet haben, müssen Sie die Replikation überwachen und dann die Migration ausführen. Weitere Informationen finden Sie unter Replikation überwachen.
Fehlerbehebung
| 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 |
| 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 Führen Sie den Befehl |
| Die Datenmigration verlief anfangs erfolgreich, danach jedoch nicht mehr. | Versuchen Sie Folgendes:
|
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:
Rufen Sie in der Google Cloud Console die Loganzeige auf.
- Wählen Sie aus dem Drop-down-Menü Instanz das Cloud SQL-Replikat aus.
- Wählen Sie die Logdatei
replication-setup.logaus.
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
- Aktualisieren einer Instanzvorlage
- Verwalten von Replikaten
- Überwachen von Instanzen
- Mehr darüber erfahren, wie Sie das Cloud SQL-Replikat hochstufen und damit als eine eigenständige Instanz definieren sowie wie Sie die Replikation vom externen Server beenden