O Google Cloud SQL para MySQL é um serviço de banco de dados totalmente gerenciado que ajuda você a configurar, manter, gerenciar e administrar seus bancos de dados relacionais MySQL no Google Cloud Platform. No entanto, existem diferenças entre o Cloud SQL e a funcionalidade padrão do MySQL, como controle limitado, recursos restritos, localidade de dados, orçamento e segurança, que podem influenciar sua decisão final de sair das instâncias do Google Cloud SQL e hospedar o serviço de banco de dados no local. infra-estrutura das instalações.
Esta postagem do blog orientará você sobre como realizar a migração on-line do Google Cloud SQL para um servidor local. Nosso banco de dados de destino no servidor local é um servidor Debian, mas as etapas e procedimentos devem ser aplicados em outras versões do Linux, desde que os pacotes estejam instalados corretamente.
Nossa instância MySQL do Google Cloud está sendo executada no MySQL 5.7 e o que precisamos é:
- Um usuário escravo de replicação criado no mestre.
- O escravo deve ser instalado com a mesma versão principal que o mestre.
- O SSL deve ser ativado para replicação geográfica por motivos de segurança.
Como o Google Cloud por padrão ativou a replicação de GTID para MySQL, faremos uma migração com base nesse esquema de replicação. Portanto, as instruções descritas neste post também devem funcionar em instâncias do MySQL 8.0.
Criando um usuário escravo de replicação
Primeiro, precisamos criar um usuário escravo de replicação em nossa instância do Google Cloud SQL. Faça login no Google Cloud Platform -> Bancos de dados -> SQL -> escolha a instância MySQL -> Usuários -> Adicionar conta de usuário e insira os detalhes necessários:
O 202.187.194.255 é o endereço IP público escravo localizado em nosso premissas que serão replicadas a partir desta instância. Como você pode ver, não há configuração de privilégios, pois os usuários criados a partir dessa interface terão os privilégios mais altos que o Google Cloud SQL pode oferecer (quase tudo, exceto SUPER e FILE). Para verificar os privilégios, podemos usar o seguinte 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 OPTIONParece que nosso usuário escravo tem a permissão necessária para executar como escravo (REPLICATION SLAVE).
Fazendo um backup do mysqldump
Antes de criarmos um backup externo do mysqldump, precisamos configurar os certificados SSL do cliente devido ao risco de conectar a instância por meio de uma rede pública. Para fazer isso, vá para Conexões -> Configurar certificados de cliente SSL -> Criar um certificado de cliente:
Baixe os arquivos acima (server-ca.pem, client-cert. pem e client-key.pem) e armazená-los dentro do servidor escravo. Vamos usar esses certificados para conectar-se ao mestre com segurança a partir do servidor escravo. Para simplificar o processo, todos os certificados e arquivos de chave acima serão colocados em um diretório chamado "gcloud-certs":
$ mkdir -p /root/gcloud-certs # put the certs/key hereCertifique-se de que as permissões estejam corretas, especialmente o arquivo de chave privada, client-key.pem:
$ chmod 600 /root/gcloud-certs/client-key.pemAgora estamos prontos para fazer um backup mysqldump de nossa instância MySQL 5.7 do Google Cloud SQL com segurança:
$ 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.sqlVocê deve receber o seguinte aviso:
"Aviso:Um dump parcial de um servidor que possui GTIDs incluirá, por padrão, os GTIDs de todas as transações, mesmo aquelas que alteraram partes suprimidas do banco de dados. Se você não quiser restaure os GTIDs, passe --set-gtid-purged=OFF. Para fazer um dump completo, passe --all-databases --triggers --routines --events."
O aviso acima ocorre porque ignoramos a definição do sinalizador --events que requer o privilégio SUPER. O usuário root criado para cada instância do Google Cloud SQL não vem com privilégios FILE e SUPER. Essa é uma das desvantagens de usar esse método, que os eventos do MySQL não podem ser importados do Google Cloud SQL.
Configurando o servidor escravo
No servidor escravo, instale o MySQL 5.7 para 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-serverEntão, adicione as seguintes linhas na seção [mysqld] dentro de /etc/mysql/my.cnf (ou qualquer outro arquivo de configuração MySQL relevante):
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 slaveReinicie o servidor MySQL para aplicar as alterações acima:
$ systemctl restart mysqlRestaure o backup do mysqldump neste servidor:
$ mysql -uroot -p < fullbackup.sqlNeste ponto, a senha raiz do MySQL do servidor escravo deve ser idêntica à do Google Cloud SQL. Você deve fazer login com uma senha de root diferente a partir de agora.
Observe que o usuário root no Google Cloud não tem privilégios totais. Precisamos fazer algumas modificações no lado escravo, permitindo que o usuário root tenha todos os privilégios dentro do MySQL, já que temos mais controle sobre este servidor. Para fazer isso, precisamos atualizar a tabela de usuários do MySQL. Faça login no servidor MySQL do escravo como usuário root do MySQL e execute a seguinte instrução:
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: 0Descarregue a tabela de privilégios:
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)Saia do terminal atual e faça login novamente. Execute o seguinte comando para verificar se o usuário root agora tem o nível mais alto de privilégios:
mysql> SHOW GRANTS FOR [email protected];
+---------------------------------------------------------------------+
| Grants for [email protected] |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+Configurando o link de replicação
Por motivos de segurança, o usuário escravo de replicação precisa se conectar ao host mestre (instância do Google Cloud) por meio de um canal criptografado SSL. Portanto, temos que preparar a chave e o certificado SSL com a permissão correta e acessível pelo usuário mysql. Copie o diretório gcloud para /etc/mysql e atribua a permissão e a propriedade corretas:
$ mkdir -p /etc/mysql
$ cp /root/gcloud-certs /etc/mysql
$ chown -Rf mysql:mysql /etc/mysql/gcloud-certsNo servidor escravo, configure o link de replicação conforme abaixo:
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';Em seguida, inicie o escravo de replicação:
mysql> START SLAVE;Verifique a saída como o seguinte:
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:Certifique-se de que os valores Slave_IO_Running e Slave_SQL_Running sejam 'Yes', assim como Seconds_Behind_Master deve ser 0, o que significa que o slave alcançou o master. Observe que o Executed_Gtid_Set tem dois GTIDs:
- 8539637e-14d1-11eb-ae3c-42010a94001a:1-5664
- b1dabe58-14e6-11eb-840f-0800278dc04d:1-2
O primeiro GTID representa as alterações provenientes do mestre atual (instância do Google Cloud SQL), enquanto o segundo GTID representa as alterações que fizemos quando modificamos os privilégios do usuário root do MySQL no host escravo. Preste atenção ao primeiro GTID para ver se o banco de dados está replicando corretamente (a parte inteira deve ser incrementada durante a replicação).
Verifique se nosso host escravo faz parte da replicação do ponto de vista do mestre. Faça login na instância do SQL Cloud como 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.pemE execute a seguinte instrução:
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-0800278dc04dNesse ponto, você pode planejar seu próximo passo para redirecionar a carga de trabalho do banco de dados dos aplicativos para esse servidor escravo como o novo mestre e encerrar o antigo mestre no Google Cloud.
Considerações finais
Você pode realizar uma migração on-line do Google Cloud SQL para MySQL para um servidor local sem muitos problemas. Isso lhe dá a possibilidade de mover seu banco de dados para fora dos fornecedores de nuvem para privacidade e controle quando chegar a hora certa.
