Em blogs anteriores (parte 1 e parte 2), discutimos como migrar seus dados do RDS para uma instância do EC2. No processo, conseguimos mover nossos dados para fora do RDS, mas ainda estamos executando na AWS. Se você deseja mover seus dados completamente para fora da Amazon Web Services, há um pouco mais de trabalho a fazer. No post de hoje do blog, mostraremos como isso pode ser feito.
Introdução ao meio ambiente
O ambiente com o qual trabalharemos é bastante semelhante ao que acabamos em nosso último post da série. A única diferença é que não houve cutover, pois usaremos a instância do EC2 como uma etapa intermediária no processo de saída da AWS.
Configuração inicial da infraestrutura O Plano de Ação
Recursos relacionados MySQL na nuvem - Migração online do Amazon RDS para a instância do EC2 (parte 1) MySQL na nuvem - Migração online do Amazon RDS para seu próprio servidor (parte 2) MySQL na nuvem - Prós e contras do Amazon RDSNo blog anterior, primeiro migramos nossos dados do RDS para uma instância do EC2 à qual temos acesso total. Como já temos o MySQL rodando em nossa instância do EC2, temos mais opções para escolher sobre como copiar nossos dados para outra nuvem. O DigitalOcean é usado apenas para fins de demonstração aqui, o processo que descrevemos abaixo pode ser usado para migrar para qualquer outro provedor de hospedagem ou nuvem. Você precisaria de acesso direto às instâncias VPS. Nesse processo, usaremos o xtrabackup para copiar os dados (embora seja perfeitamente aceitável usar qualquer outro método de transferência binária). Precisaríamos preparar uma conexão segura entre a AWS e a DigitalOcean. Assim que fizermos isso, configuraremos a replicação da instância do EC2 em um droplet da DigitalOcean. O próximo passo seria realizar um cutover e mover aplicativos, mas não o abordaremos aqui.
Decidindo sobre o método de conectividade
A Amazon Web Services permite que você escolha entre muitas maneiras diferentes de criar uma conexão com redes externas. Se você tiver um dispositivo de hardware compatível com conexões VPN, poderá usá-lo para formar uma conexão VPN entre sua VPC na AWS e sua infraestrutura local. Se o seu provedor de rede oferecer uma conexão de peering com a rede AWS e você tiver um roteador BGP, você poderá obter uma conexão VLAN direta entre sua rede e a AWS por meio do AWS Direct Connect. Se você tiver várias redes isoladas, poderá vinculá-las à Amazon usando o AWS VPN CloudHub. Por fim, como as instâncias do EC2 são suas para gerenciar, você também pode configurar uma VPN entre essa instância do EC2 e sua rede local usando soluções de software como o OpenVPN.
Como estamos falando de bancos de dados, você também pode decidir configurar a replicação SSL entre o MySQL no EC2 (o mestre) e o escravo em execução no DigitalOcean. - Ainda temos que descobrir como fazer uma transferência de dados inicial para o escravo - uma solução pode ser tar a saída do xtrabackup, criptografar esse arquivo e enviá-lo via WAN (rsync) ou fazer upload para o bucket do S3 e baixá-lo de lá. Você também pode confiar na criptografia SSH e apenas scp (ou mesmo rsync, usando SSH) os dados para o novo local.
Há muitas opções para escolher. No entanto, usaremos outra solução - estabeleceremos um túnel SSH entre a instância do EC2 e nosso droplet DigitalOcean para formar um canal seguro que usaremos para replicar dados. A transferência inicial será feita usando rsync pela conexão SSH.
Guia de DevOps para gerenciamento de banco de dados de vários novesSaiba mais sobre o que você precisa saber para automatizar e gerenciar seus bancos de dados de código abertoBaixe gratuitamente
Copiando dados para a DigitalOcean
Assim que tivermos o MySQL 5.7 em execução na instância DigitalOcean, precisamos realizar um backup da instância EC2 e depois transferi-la para DO. Tecnicamente, deve ser possível realizar um streaming direto de dados xtrabackup entre os nós, mas não podemos realmente recomendá-lo. Os links WAN podem não ser confiáveis, e seria melhor fazer um backup localmente e usar o rsync com sua capacidade de repetir a transferência sempre que algo não estiver certo.
Primeiro, vamos fazer um backup em nossa instância do EC2:
[email protected]:~# innobackupex --user=tpcc --password=tpccpass /tmp/backupQuando estiver pronto, precisamos transferi-lo para a rede DigitalOcean. Para fazer isso de forma segura, vamos criar um novo usuário no droplet DO, gerar uma chave SSH e usar esse usuário para copiar os dados. Claro, você também pode usar qualquer um dos usuários existentes, não é necessário criar um novo. Então, vamos adicionar um novo usuário. Existem muitas maneiras de fazer isso, usaremos o comando ‘adduser’.
[email protected]:~# adduser rdscopy
Adding user `rdscopy' ...
Adding new group `rdscopy' (1001) ...
Adding new user `rdscopy' (1001) with group `rdscopy' ...
Creating home directory `/home/rdscopy' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for rdscopy
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] yAgora, é hora de gerar um par de chaves ssh para usar para conectividade:
[email protected]:~# ssh-keygen -C 'rdscopy' -f id_rsa_rdscopy -t rsa -b 4096
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_rdscopy.
Your public key has been saved in id_rsa_rdscopy.pub.
The key fingerprint is:
3a:b0:d2:80:5b:b8:60:1b:17:58:bd:8e:74:c9:56:b3 rdscopy
The key's randomart image is:
+--[ RSA 4096]----+
| .. |
| o . o |
| . .. + o |
| o ..* E |
|+o+.* S |
|o+++ + . |
|o.. o o |
| . . |
| |
+-----------------+Tendo a chave SSH, precisamos configurá-la em nosso droplet Digital Ocean. Precisamos criar o diretório .ssh e criar o arquivo authorized_keys com as devidas permissões de acesso.
[email protected]:~# mkdir /home/rdscopy/.ssh
[email protected]:~# cat id_rsa_rdscopy.pub > /home/rdscopy/.ssh/authorized_keys
[email protected]:~# chown rdscopy.rdscopy /home/rdscopy/.ssh/authorized_keys
[email protected]:~# chmod 600 /home/rdscopy/.ssh/authorized_keysEm seguida, precisamos copiar nossa chave privada para a instância do EC2. Quando estivermos prontos, podemos copiar nossos dados. Como mencionamos anteriormente, usaremos o rsync para isso - ele nos permitirá reiniciar a transferência se, por qualquer motivo, o processo for interrompido. Combinado com SSH, criamos um método seguro e robusto de copiar os dados pela WAN. Vamos iniciar o rsync no host EC2:
[email protected]:~# rsync -avz -e "ssh -i id_rsa_rdscopy -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress /tmp/backup/2017-02-20_16-34-18/ [email protected]:/home/rdscopyDepois de um tempo, que vai depender da quantidade de dados e da velocidade de transferência, nossos dados de backup devem ficar disponíveis no droplet da DigitalOcean. Isso significa que é hora de prepará-lo aplicando logs de redo do InnoDB e, em seguida, copiando-o de volta para o diretório de dados do MySQL. Para isso, precisamos parar o MySQL, remover o diretório de dados atual, copiar os arquivos de volta usando innobackupex ou manualmente e, finalmente, verificar se o proprietário e o grupo para novos arquivos estão definidos como mysql:
[email protected]:~# innobackupex --apply-log /home/rdscopy/
[email protected]:~# service mysql stop
[email protected]:~# rm -rf /var/lib/mysql/*
[email protected]:~# innobackupex --copy-back /home/rdscopy/
[email protected]:~# chown -R mysql.mysql /var/lib/mysqlAntes de iniciarmos o MySQL, também precisamos garantir que server_id e UUID sejam diferentes. O primeiro pode ser editado em my.cnf, o segundo pode ser assegurado por:
[email protected]:~# rm /var/lib/mysql/auto.cnfAgora, podemos iniciar o MySQL:
[email protected]:~# service mysql startConfigurando a replicação
Estamos prontos para configurar a replicação entre o EC2 e o DO, mas primeiro precisamos configurar um túnel ssh - criaremos uma chave ssh adicional para o usuário do Ubuntu na instância do EC2 e a copiaremos para a instância DO. Em seguida, usaremos o usuário do Ubuntu para criar um túnel que usaremos para a replicação.
Vamos começar criando a nova chave ssh:
[email protected]:~# ssh-keygen -C 'tunnel' -f id_rsa_tunnel -t rsa -b 4096
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_tunnel.
Your public key has been saved in id_rsa_tunnel.pub.
The key fingerprint is:
c4:44:79:39:9c:c6:ce:45:bb:13:e5:6f:c5:d9:8c:14 tunnel
The key's randomart image is:
+--[ RSA 4096]----+
| .o+ +. E. |
| o. O .= +o|
| o= oo o.=|
| . o o ..|
| S o o|
| . . |
| |
| |
| |
+-----------------+Próxima etapa - precisamos adicionar nossa chave pública ao arquivo authorized_keys na instância do EC2, à qual nos conectaremos da DigitalOcean para criar um túnel.
[email protected]:~# cat id_rsa_tunnel.pub >> /home/ubuntu/.ssh/authorized_keysTambém precisamos que uma chave privada seja transferida para o droplet DO. Isso pode ser feito de várias maneiras, mas usaremos o scp seguro usando o usuário e a chave rdscopy que criamos anteriormente:
[email protected]:~# scp -i id_rsa_rdscopy id_rsa_tunnel [email protected]:/home/rdscopy
id_rsa_tunnel 100% 3247 3.2KB/s 00:00Isso é tudo que precisamos - agora podemos criar o túnel SSH. Queremos que esteja disponível o tempo todo, então usaremos a sessão de tela para isso.
[email protected]:~# screen -S tunnel
[email protected]:~# ssh -L 3307:localhost:3306 [email protected] -i /home/rdscopy/id_rsa_tunnelO que fizemos aqui foi abrir um túnel SSH entre localhost, porta 3307 e host remoto, 54.224.107.6, porta 3306 usando o usuário “ubuntu” e uma chave localizada em /home/rdscopy/id_rsa_tunnel. Desanexe a sessão de tela e o host remoto deve estar disponível via 127.0.0.1:3307.
Para configurar a replicação, ainda precisamos adicionar n usuário que usaremos para conectar ao MySQL no EC2. Vamos criá-lo no host EC2 e usaremos '127.0.0.1' como host - as conexões via túnel SSH parecerão que vêm de localhost:
mysql> CREATE USER [email protected] IDENTIFIED BY 'rds_rpl_pass';
Query OK, 0 rows affected (0.00 sec)mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected];
Query OK, 0 rows affected (0.00 sec)Tudo está pronto para configurar a replicação, agora é hora de seguir um processo tradicional de criação de um escravo baseado em dados xtrabackup. Precisamos usar os dados do xtrabackup_binlog_info para identificar a posição do mestre no momento do backup. Esta posição é o que queremos usar em nosso comando CHANGE MASTER TO …. Vamos dar uma olhada no conteúdo do arquivo xtrabackup_binlog_info:
[email protected]:~# cat /home/rdscopy/xtrabackup_binlog_info
binlog.000052 896957365Este é o arquivo de log binário e a posição que usaremos em nosso CHANGE MASTER TO:
[email protected]:~# mysql -u root -ppassmysql> CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3307, MASTER_USER='rds_rpl', MASTER_PASSWORD='rds_rpl_pass', MASTER_LOG_FILE='binlog.000052', MASTER_LOG_POS=896957365; START SLAVE;É isso - a replicação deve estar funcionando agora e nosso escravo DigitalOcean deve estar atualizando a replicação. Uma vez alcançado, nossa camada de banco de dados está pronta para a alternância. Claro, geralmente é mais do que apenas um único nó - você provavelmente terá que configurar vários escravos em DO antes que a infraestrutura esteja pronta para lidar com o tráfego de produção.
A mudança em si é um tópico diferente - você terá que elaborar um plano para minimizar o tempo de inatividade. Em geral, o tráfego deve ser movido do local antigo para o novo, mas como isso deve ser feito depende principalmente do seu ambiente. Pode ser qualquer coisa, desde uma simples alteração na entrada de DNS até scripts complexos que puxarão todos os gatilhos na ordem correta para redirecionar o tráfego. Não importa o que aconteça, seu banco de dados já está no novo local, pronto para atender às solicitações.
