Google Cloud SQL för MySQL är en fullständigt hanterad databastjänst som hjälper dig att konfigurera, underhålla, hantera och administrera dina MySQL-relationsdatabaser på Google Cloud Platform. Det finns dock skillnader mellan Cloud SQL och standard MySQL-funktioner som begränsad kontroll, begränsade resurser, datalokalitet, budget och säkerhet, vilket kan påverka ditt slutliga beslut att flytta ut från Google Cloud SQL-instanserna och vara värd för databastjänsten i on- lokal infrastruktur istället.
Det här blogginlägget går igenom hur du utför onlinemigrering från Google Cloud SQL till en lokal server. Vår måldatabas på den lokala servern är en Debian-server, men stegen och procedurerna ska gälla för andra versioner av Linux så länge som paketen är korrekt installerade.
Vår Google Cloud MySQL-instans körs på MySQL 5.7 och det vi behöver är:
- En replikeringsslavanvändare skapad på mastern.
- Slaven måste installeras med samma huvudversion som mastern.
- SSL måste vara aktiverat för geografisk replikering av säkerhetsskäl.
Eftersom Google Cloud som standard aktiverade GTID-replikering för MySQL, kommer vi att göra en migrering baserad på detta replikeringsschema. Därför bör instruktionerna som beskrivs i det här inlägget också fungera i MySQL 8.0-instanser.
Skapa en replikeringsslavanvändare
Först och främst måste vi skapa en replikeringsslavanvändare på vår Google Cloud SQL-instans. Logga in på Google Cloud Platform -> Databaser -> SQL -> välj MySQL-instansen -> Användare -> Lägg till användarkonto och ange nödvändiga uppgifter:
202.187.194.255 är den offentliga slavadressen som finns i vår on- lokaler som kommer att replikera från den här instansen. Som du kan se finns det ingen privilegiekonfiguration eftersom användare som skapats från detta gränssnitt kommer att ha de högsta privilegierna Google Cloud SQL kan erbjuda (nästan allt utom SUPER och FILE). För att verifiera privilegierna kan vi använda följande kommando:
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 OPTIONDet ser ut som att vår slavanvändare har den nödvändiga behörigheten att köra som slav (REPLICATION SLAVE).
Ta en mysqldump-säkerhetskopia
Innan vi skapar en extern mysqldump-säkerhetskopia måste vi konfigurera klientens SSL-certifikat på grund av risken att ansluta instansen via ett publikt nätverk. För att göra detta, gå till Anslutningar -> Konfigurera SSL-klientcertifikat -> Skapa ett klientcertifikat:
Ladda ner ovanstående filer (server-ca.pem, client-cert. pem och client-key.pem) och lagra dem inuti slavservern. Vi kommer att använda dessa certifikat för att ansluta till mastern på ett säkert sätt från slavserven. För att förenkla processen kommer alla ovanstående certifikat och nyckelfiler att placeras i en katalog som heter "gcloud-certs":
$ mkdir -p /root/gcloud-certs # put the certs/key hereSe till att behörigheterna är korrekta, särskilt den privata nyckelfilen, client-key.pem:
$ chmod 600 /root/gcloud-certs/client-key.pemNu är vi redo att ta en mysqldump-säkerhetskopia från vår Google Cloud SQL MySQL 5.7-instans på ett säkert sätt:
$ 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.sqlDu bör få följande varning:
"Varning:En partiell dump från en server som har GTID kommer som standard att inkludera GTID för alla transaktioner, även de som ändrade undertryckta delar av databasen. Om du inte vill återställ GTID, pass --set-gtid-purged=OFF. För att göra en fullständig dump, skicka --all-databases --triggers --rutiner --events."
Ovanstående varning uppstår eftersom vi hoppade över att definiera flaggan --events som kräver SUPER-privilegiet. Rotanvändaren som skapas för varje Google Cloud SQL-instans kommer inte med FILE- och SUPER-privilegier. Detta är en av nackdelarna med att använda den här metoden, att MySQL Events inte kan importeras från Google Cloud SQL.
Konfigurera slavservern
På slavservern, installera 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-serverLägg sedan till följande rader under [mysqld]-sektionen i /etc/mysql/my.cnf (eller någon annan relevant MySQL-konfigurationsfil):
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 slaveStarta om MySQL-servern för att tillämpa ovanstående ändringar:
$ systemctl restart mysqlÅterställ mysqldump-säkerhetskopian på denna server:
$ mysql -uroot -p < fullbackup.sqlVid denna tidpunkt bör MySQL-rotlösenordet för slavservern vara identiskt med det i Google Cloud SQL. Du bör logga in med ett annat root-lösenord från och med nu.
Observera att rotanvändaren i Google Cloud inte har fullständiga rättigheter. Vi måste göra några ändringar på slavsidan, genom att tillåta rotanvändaren att ha alla privilegier inuti MySQL, eftersom vi har mer kontroll över denna server. För att göra detta behöver vi uppdatera MySQL:s användartabell. Logga in på slavens MySQL-server som MySQL-rotanvändare och kör följande sats:
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: 0Spola privilegietabellen:
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)Avsluta den aktuella terminalen och logga in igen. Kör följande kommando för att verifiera att rotanvändaren nu har den högsta nivån av privilegier:
mysql> SHOW GRANTS FOR [email protected];
+---------------------------------------------------------------------+
| Grants for [email protected] |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+Konfigurera replikeringslänken
Av säkerhetsskäl måste replikeringsslavanvändaren ansluta till huvudvärden (Google Cloud-instans) via en SSL-krypterad kanal. Därför måste vi förbereda SSL-nyckeln och certifikatet med korrekt behörighet och tillgängligt för mysql-användaren. Kopiera gcloud-katalogen till /etc/mysql och tilldela rätt behörighet och äganderätt:
$ mkdir -p /etc/mysql
$ cp /root/gcloud-certs /etc/mysql
$ chown -Rf mysql:mysql /etc/mysql/gcloud-certsPå slavservern, konfigurera replikeringslänken enligt nedan:
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';Starta sedan replikeringsslaven:
mysql> START SLAVE;Verifiera utdata enligt följande:
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:Se till att värdena för Slave_IO_Running och Slave_SQL_Running är 'Yes', samt att Seconds_Behind_Master bör vara 0, vilket betyder att slaven har kommit ikapp mastern. Observera att Executed_Gtid_Set har två GTID:
- 8539637e-14d1-11eb-ae3c-42010a94001a:1-5664
- b1dabe58-14e6-11eb-840f-0800278dc04d:1-2
Det första GTID:t representerar ändringarna som kommer från den aktuella mastern (Google Cloud SQL-instansen), medan det andra GTID:t representerar ändringarna som vi har gjort när vi ändrade privilegierna för MySQL-rotanvändaren på slavvärden. Var uppmärksam på det första GTID:t för att se om databasen replikeras korrekt (heltalsdelen ska öka under replikering).
Verifiera om vår slavvärd är en del av replikeringen från befälhavarens synvinkel. Logga in på SQL Cloud-instansen som root:
$ 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.pemOch kör följande sats:
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-0800278dc04dVid det här laget kan du planera ditt nästa drag för att omdirigera databasens arbetsbelastning från applikationerna till denna slavserver som den nya mastern och avveckla den gamla mastern i Google Cloud.
Sluta tankar
Du kan utföra en onlinemigrering från Google Cloud SQL för MySQL till en lokal server utan mycket krångel. Detta ger dig möjlighet att flytta din databas utanför molnleverantörerna för integritet och kontroll när rätt tid är inne.