Google Cloud SQL für MySQL ist ein vollständig verwalteter Datenbankdienst, der Sie bei der Einrichtung, Pflege und Verwaltung Ihrer relationalen MySQL-Datenbanken auf der Google Cloud Platform unterstützt. Es gibt jedoch Unterschiede zwischen Cloud SQL- und Standard-MySQL-Funktionen wie eingeschränkte Kontrolle, eingeschränkte Ressourcen, Datenlokalität, Budget und Sicherheit, die Ihre endgültige Entscheidung beeinflussen können, sich von den Google Cloud SQL-Instanzen zu entfernen und den Datenbankdienst im On- stattdessen die lokale Infrastruktur.
In diesem Blogbeitrag erfahren Sie, wie Sie eine Onlinemigration von Google Cloud SQL zu einem lokalen Server durchführen. Unsere Zieldatenbank auf dem lokalen Server ist ein Debian-Server, aber die Schritte und Verfahren gelten auch für andere Linux-Versionen, solange die Pakete ordnungsgemäß installiert sind.
Unsere Google Cloud MySQL-Instanz läuft auf MySQL 5.7 und was wir brauchen ist:
- Ein auf dem Master erstellter Replikations-Slave-Benutzer.
- Der Slave muss mit der gleichen Hauptversion wie der Master installiert werden.
- SSL muss aus Sicherheitsgründen für die geografische Replikation aktiviert werden.
Da Google Cloud standardmäßig die GTID-Replikation für MySQL aktiviert hat, werden wir eine Migration basierend auf diesem Replikationsschema durchführen. Daher sollten die in diesem Beitrag beschriebenen Anweisungen auch in MySQL 8.0-Instanzen funktionieren.
Erstellen eines Replikations-Slave-Benutzers
Zunächst müssen wir einen Replikations-Slave-Benutzer auf unserer Google Cloud SQL-Instanz erstellen. Melden Sie sich bei der Google Cloud Platform an -> Datenbanken -> SQL -> wählen Sie die MySQL-Instanz -> Benutzer -> Benutzerkonto hinzufügen und geben Sie die erforderlichen Details ein:
202.187.194.255 ist die öffentliche IP-Adresse des Slaves, die sich in unserem On- Räumlichkeiten, die von dieser Instanz repliziert werden. Wie Sie sehen können, gibt es keine Privilegienkonfiguration, da Benutzer, die über diese Schnittstelle erstellt wurden, die höchsten Privilegien haben, die Google Cloud SQL bieten kann (fast alles außer SUPER und FILE). Um die Berechtigungen zu überprüfen, können wir den folgenden Befehl verwenden:
mysql> SHOW GRANTS FOR [email protected]\G
*************************** 1. row ***************************
Grants for [email protected]: GRANT SELECT, INSERT, UPDATE, DELETE, CREATE,
DROP, RELOAD, SHUTDOWN, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES,
CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT,
CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER,
CREATE TABLESPACE ON *.* TO 'slave'@'202.187.194.255' WITH GRANT OPTIONEs sieht so aus, als hätte unser Slave-Benutzer die erforderliche Berechtigung, um als Slave zu laufen (REPLICATION SLAVE).
Erstellen einer mysqldump-Sicherung
Bevor wir ein externes mysqldump-Backup erstellen, müssen wir die SSL-Zertifikate des Clients konfigurieren, da das Risiko besteht, die Instanz über ein öffentliches Netzwerk zu verbinden. Gehen Sie dazu auf Verbindungen -> SSL-Client-Zertifikate konfigurieren -> Client-Zertifikat erstellen:
Laden Sie die obigen Dateien herunter (server-ca.pem, client-cert. pem und client-key.pem) und speichern Sie sie auf dem Slave-Server. Wir werden diese Zertifikate verwenden, um vom Slave-Server aus eine sichere Verbindung zum Master herzustellen. Um den Vorgang zu vereinfachen, werden alle oben genannten Zertifikate und Schlüsseldateien in einem Verzeichnis namens „gcloud-certs“ abgelegt:
$ mkdir -p /root/gcloud-certs # put the certs/key hereStellen Sie sicher, dass die Berechtigungen korrekt sind, insbesondere die private Schlüsseldatei client-key.pem:
$ chmod 600 /root/gcloud-certs/client-key.pemJetzt können wir sicher eine mysqldump-Sicherung von unserer Google Cloud SQL MySQL 5.7-Instanz erstellen:
$ mysqldump -uroot -p \
-h 35.198.197.171 \
--ssl-ca=/root/gcloud-certs/server-ca.pem \
--ssl-cert=/root/gcloud-certs/client-cert.pem \
--ssl-key=/root/gcloud-certs/client-key.pem \
--single-transaction \
--all-databases \
--triggers \
--routines > fullbackup.sqlSie sollten die folgende Warnung erhalten:
"Warnung:Ein partieller Speicherauszug von einem Server mit GTIDs enthält standardmäßig die GTIDs aller Transaktionen, auch derjenigen, die unterdrückte Teile der Datenbank geändert haben. Wenn Sie dies nicht möchten Um GTIDs wiederherzustellen, übergeben Sie --set-gtid-purged=OFF. Um einen vollständigen Speicherauszug zu erstellen, übergeben Sie --all-databases --triggers --routines --events."
Die obige Warnung tritt auf, weil wir die Definition des Flags --events übersprungen haben, das das SUPER-Privileg erfordert. Der für jede Google Cloud SQL-Instanz erstellte Root-Nutzer hat keine FILE- und SUPER-Berechtigungen. Einer der Nachteile dieser Methode ist, dass MySQL-Ereignisse nicht aus Google Cloud SQL importiert werden können.
Konfigurieren des Slave-Servers
Installieren Sie auf dem Slave-Server MySQL 5.7 für Debian 10:
$ echo 'deb http://repo.mysql.com/apt/debian/ buster mysql-5.7' > /etc/apt/sources.list.d/mysql.list
$ apt-key adv --keyserver pgp.mit.edu --recv-keys 5072E1F5
$ apt update
$ apt -y install mysql-community-serverFügen Sie dann die folgenden Zeilen unter dem Abschnitt [mysqld] in /etc/mysql/my.cnf (oder einer anderen relevanten MySQL-Konfigurationsdatei) hinzu:
server-id = 1111 # different value than the master
log_bin = binlog
log_slave_updates = 1
expire_logs_days = 7
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = 1
sync_binlog = 1
report_host = 202.187.194.255 # IP address of this slaveStarten Sie den MySQL-Server neu, um die obigen Änderungen zu übernehmen:
$ systemctl restart mysqlStellen Sie die mysqldump-Sicherung auf diesem Server wieder her:
$ mysql -uroot -p < fullbackup.sqlAn dieser Stelle sollte das MySQL-Root-Passwort des Slave-Servers mit dem in Google Cloud SQL identisch sein. Sie sollten sich von nun an mit einem anderen Root-Passwort anmelden.
Beachten Sie, dass der Root-Benutzer in Google Cloud nicht über alle Berechtigungen verfügt. Wir müssen einige Änderungen auf der Slave-Seite vornehmen, indem wir dem Root-Benutzer alle Privilegien innerhalb von MySQL gewähren, da wir mehr Kontrolle über diesen Server haben. Dazu müssen wir die Benutzertabelle von MySQL aktualisieren. Melden Sie sich beim MySQL-Server des Slaves als MySQL-Root-Benutzer an und führen Sie die folgende Anweisung aus:
mysql> UPDATE mysql.user SET Super_priv = 'Y', File_priv = 'Y' WHERE User = 'root';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0Leere die Berechtigungstabelle:
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)Verlassen Sie das aktuelle Terminal und melden Sie sich erneut an. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der Root-Benutzer jetzt über die höchste Berechtigungsstufe verfügt:
mysql> SHOW GRANTS FOR [email protected];
+---------------------------------------------------------------------+
| Grants for [email protected] |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+Einrichten des Replikationslinks
Aus Sicherheitsgründen muss sich der Replikations-Slave-Benutzer über einen SSL-verschlüsselten Kanal mit dem Master-Host (Google Cloud-Instanz) verbinden. Daher müssen wir den SSL-Schlüssel und das Zertifikat mit der richtigen Berechtigung vorbereiten und für den mysql-Benutzer zugänglich machen. Kopieren Sie das gcloud-Verzeichnis in /etc/mysql und weisen Sie die richtige Berechtigung und Eigentümerschaft zu:
$ mkdir -p /etc/mysql
$ cp /root/gcloud-certs /etc/mysql
$ chown -Rf mysql:mysql /etc/mysql/gcloud-certsKonfigurieren Sie auf dem Slave-Server den Replikationslink wie folgt:
mysql> CHANGE MASTER TO MASTER_HOST = '35.198.197.171',
MASTER_USER = 'slave',
MASTER_PASSWORD = 'slavepassword',
MASTER_AUTO_POSITION = 1,
MASTER_SSL = 1,
MASTER_SSL_CERT = '/etc/mysql/gcloud-certs/client-cert.pem',
MASTER_SSL_CA = '/etc/mysql/gcloud-certs/server-ca.pem',
MASTER_SSL_KEY = '/etc/mysql/gcloud-certs/client-key.pem';Starten Sie dann den Replikations-Slave:
mysql> START SLAVE;Überprüfen Sie die Ausgabe wie folgt:
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 35.198.197.171
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 1120160
Relay_Log_File: puppet-master-relay-bin.000002
Relay_Log_Pos: 15900
Relay_Master_Log_File: mysql-bin.000003
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:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1120160
Relay_Log_Space: 16115
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: /etc/mysql/gcloud-certs/server-ca.pem
Master_SSL_CA_Path:
Master_SSL_Cert: /etc/mysql/gcloud-certs/client-cert.pem
Master_SSL_Cipher:
Master_SSL_Key: /etc/mysql/gcloud-certs/client-key.pem
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: 2272712871
Master_UUID: 8539637e-14d1-11eb-ae3c-42010a94001a
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 8539637e-14d1-11eb-ae3c-42010a94001a:5611-5664
Executed_Gtid_Set: 8539637e-14d1-11eb-ae3c-42010a94001a:1-5664,
b1dabe58-14e6-11eb-840f-0800278dc04d:1-2
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:Stellen Sie sicher, dass die Werte für Slave_IO_Running und Slave_SQL_Running „Ja“ sind und dass Seconds_Behind_Master 0 sein sollte, was bedeutet, dass der Slave den Master eingeholt hat. Beachten Sie, dass Executed_Gtid_Set zwei GTIDs hat:
- 8539637e-14d1-11eb-ae3c-42010a94001a:1-5664
- b1dabe58-14e6-11eb-840f-0800278dc04d:1-2
Die erste GTID stellt die Änderungen dar, die vom aktuellen Master (Google Cloud SQL-Instanz) stammen, während die zweite GTID die Änderungen darstellt, die wir vorgenommen haben, als wir die Berechtigungen für den MySQL-Root-Benutzer auf dem Slave-Host geändert haben. Achten Sie auf die erste GTID, um zu sehen, ob die Datenbank korrekt repliziert wird (der ganzzahlige Teil sollte während der Replikation inkrementiert werden).
Überprüfen Sie, ob unser Slave-Host aus der Sicht des Masters Teil der Replikation ist. Melden Sie sich als Root bei der SQL Cloud-Instanz an:
$ mysql -uroot -p \
-h 35.198.197.171 \
--ssl-ca=/root/gcloud-certs/server-ca.pem \
--ssl-cert=/root/gcloud-certs/client-cert.pem \
--ssl-key=/root/gcloud-certs/client-key.pemUnd führen Sie die folgende Anweisung aus:
mysql> SHOW SLAVE HOSTS;
*************************** 1. row ***************************
Server_id: 1111
Host: 202.187.194.255
Port: 3306
Master_id: 2272712871
Slave_UUID: b1dabe58-14e6-11eb-840f-0800278dc04dAn diesem Punkt können Sie Ihren nächsten Schritt planen, um die Datenbank-Workload von den Anwendungen auf diesen Slave-Server als neuen Master umzuleiten und den alten Master in Google Cloud außer Betrieb zu nehmen.
Abschließende Gedanken
Sie können ohne großen Aufwand eine Online-Migration von Google Cloud SQL für MySQL zu einem lokalen Server durchführen. Dies gibt Ihnen die Möglichkeit, Ihre Datenbank aus Gründen des Datenschutzes und der Kontrolle außerhalb der Cloud-Anbieter zu verschieben, wenn der richtige Zeitpunkt gekommen ist.
