Google Cloud SQL per MySQL è un servizio di database completamente gestito che ti aiuta a configurare, mantenere, gestire e amministrare i tuoi database relazionali MySQL su Google Cloud Platform. Tuttavia, esistono differenze tra Cloud SQL e le funzionalità standard di MySQL come il controllo limitato, le risorse limitate, la località dei dati, il budget e la sicurezza, che possono influenzare la tua decisione finale di uscire dalle istanze di Google Cloud SQL e ospitare il servizio di database in infrastruttura dei locali invece.
Questo post del blog ti spiegherà come eseguire la migrazione online da Google Cloud SQL a un server locale. Il nostro database di destinazione sul server locale è un server Debian, ma i passaggi e le procedure si applicano ad altre versioni di Linux, purché i pacchetti siano installati correttamente.
La nostra istanza Google Cloud MySQL è in esecuzione su MySQL 5.7 e ciò di cui abbiamo bisogno è:
- Un utente slave di replica creato sul master.
- Lo slave deve essere installato con la stessa versione principale del master.
- SSL deve essere abilitato per la replica geografica per motivi di sicurezza.
Poiché Google Cloud ha abilitato per impostazione predefinita la replica GTID per MySQL, eseguiremo una migrazione basata su questo schema di replica. Pertanto, le istruzioni descritte in questo post dovrebbero funzionare anche nelle istanze MySQL 8.0.
Creazione di un utente slave di replica
Prima di tutto, dobbiamo creare un utente slave di replica sulla nostra istanza Google Cloud SQL. Accedi a Google Cloud Platform -> Database -> SQL -> seleziona l'istanza MySQL -> Utenti -> Aggiungi account utente e inserisci i dettagli richiesti:
Il 202.187.194.255 è l'indirizzo IP pubblico slave che si trova nel nostro on- premesse che si replicherà da questa istanza. Come puoi vedere, non esiste una configurazione dei privilegi poiché gli utenti creati da questa interfaccia avranno i privilegi più alti che Google Cloud SQL può offrire (quasi tutto tranne SUPER e FILE). Per verificare i privilegi, possiamo utilizzare il seguente comando:
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 OPTIONSembra che il nostro utente slave abbia l'autorizzazione richiesta per funzionare come slave (REPLICATION SLAVE).
Esecuzione di un backup mysqldump
Prima di creare un backup mysqldump esterno, è necessario configurare i certificati SSL del client a causa del rischio di connettere l'istanza tramite una rete pubblica. Per fare ciò, vai su Connessioni -> Configura certificati client SSL -> Crea un certificato client:
Scarica i file sopra (server-ca.pem, client-cert. pem e client-key.pem) e archiviarli nel server slave. Utilizzeremo questi certificati per connetterci al master in modo sicuro dal servizio slave. Per semplificare il processo, tutti i certificati e i file di chiavi di cui sopra verranno inseriti in una directory chiamata "gcloud-certs":
$ mkdir -p /root/gcloud-certs # put the certs/key hereAssicurati che i permessi siano corretti, in particolare il file della chiave privata, client-key.pem:
$ chmod 600 /root/gcloud-certs/client-key.pemOra siamo pronti per eseguire in modo sicuro un backup mysqldump dalla nostra istanza Google Cloud SQL MySQL 5.7:
$ 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.sqlDovresti ricevere il seguente avviso:
"Avviso:un dump parziale da un server che dispone di GTID includerà per impostazione predefinita i GTID di tutte le transazioni, anche quelle che hanno modificato parti del database soppresse. Se non si desidera ripristinare i GTID, passare --set-gtid-purged=OFF. Per eseguire un dump completo, passare --all-databases --triggers --routines --events."
L'avviso di cui sopra si verifica perché abbiamo saltato la definizione del flag --events che richiede il privilegio SUPER. L'utente root creato per ogni istanza Google Cloud SQL non viene fornito con privilegi FILE e SUPER. Questo è uno degli svantaggi dell'utilizzo di questo metodo:gli eventi MySQL non possono essere importati da Google Cloud SQL.
Configurazione del server slave
Sul server slave, installa MySQL 5.7 per 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-serverQuindi, aggiungi le seguenti righe nella sezione [mysqld] all'interno di /etc/mysql/my.cnf (o qualsiasi altro file di configurazione MySQL rilevante):
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 slaveRiavvia il server MySQL per applicare le modifiche precedenti:
$ systemctl restart mysqlRipristina il backup di mysqldump su questo server:
$ mysql -uroot -p < fullbackup.sqlA questo punto, la password di root MySQL del server slave dovrebbe essere identica a quella in Google Cloud SQL. D'ora in poi dovresti accedere con una password di root diversa.
Tieni presente che l'utente root in Google Cloud non dispone dei privilegi completi. Abbiamo bisogno di apportare alcune modifiche sul lato slave, consentendo all'utente root di avere tutti i privilegi all'interno di MySQL, poiché abbiamo un maggiore controllo su questo server. Per fare ciò, dobbiamo aggiornare la tabella utente di MySQL. Accedi al server MySQL dello slave come utente root MySQL ed esegui la seguente istruzione:
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: 0Svuota la tabella dei privilegi:
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)Esci dal terminale corrente e riaccedi di nuovo. Esegui il comando seguente per verificare che l'utente root abbia ora il livello di privilegi più alto:
mysql> SHOW GRANTS FOR [email protected];
+---------------------------------------------------------------------+
| Grants for [email protected] |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+Impostazione del collegamento di replica
Per motivi di sicurezza, l'utente slave di replica deve connettersi all'host master (istanza Google Cloud) tramite un canale crittografato SSL. Pertanto, dobbiamo preparare la chiave SSL e il certificato con il permesso corretto e accessibile dall'utente mysql. Copia la directory gcloud in /etc/mysql e assegna l'autorizzazione e la proprietà corrette:
$ mkdir -p /etc/mysql
$ cp /root/gcloud-certs /etc/mysql
$ chown -Rf mysql:mysql /etc/mysql/gcloud-certsSul server slave, configurare il collegamento di replica come di seguito:
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';Quindi, avvia lo slave di replica:
mysql> START SLAVE;Verifica l'output come segue:
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:Assicurati che i valori Slave_IO_Running e Slave_SQL_Running siano 'Sì', così come Seconds_Behind_Master dovrebbe essere 0, il che significa che lo slave ha raggiunto il master. Si noti che Executed_Gtid_Set ha due GTID:
- 8539637e-14d1-11eb-ae3c-42010a94001a:1-5664
- b1dabe58-14e6-11eb-840f-0800278dc04d:1-2
Il primo GTID rappresenta le modifiche provenienti dal master corrente (istanza Google Cloud SQL), mentre il secondo GTID rappresenta le modifiche che abbiamo apportato quando abbiamo modificato i privilegi per l'utente root MySQL sull'host slave. Presta attenzione al primo GTID per vedere se il database si sta replicando correttamente (la parte intera dovrebbe essere incrementata durante la replica).
Verifica se il nostro host slave fa parte della replica dal punto di vista del master. Accedi all'istanza SQL Cloud come 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.pemEd esegui la seguente istruzione:
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-0800278dc04dA questo punto, puoi pianificare la tua prossima mossa per reindirizzare il carico di lavoro del database dalle applicazioni a questo server slave come nuovo master e disattivare il vecchio master in Google Cloud.
Pensieri finali
Puoi eseguire una migrazione online da Google Cloud SQL per MySQL a un server locale senza troppi problemi. Ciò ti dà la possibilità di spostare il tuo database al di fuori dei fornitori di cloud per la privacy e il controllo quando è giunto il momento giusto.
