Migração eficiente de instância MySQL para AWS RDS: Guia passo a passo
O desafio
Recentemente recebemos um desafio de migrarmos uma instância MySQL com 1.7TB para a AWS RDS.
A migração deveria obedecer os seguintes requisitos:
- Migrar integralmente todas as databases;
- A Migração deveria ocorrer com o mínimo de downtime (No máximo 1 hora);
- A instância estava no MySQL 5.5 (Sem suporte)
Possíveis estratégias
- Dump / Restore
- AWS Database Migration Service (DMS)
- Xtrabackup / Restore S3
Falhas iniciais
- Começamos o projeto com um dump restore, que após 6h de execução, foi estimado em 7 dias para conclusão, inviabilizando o projeto;
- O DMS levou 48 horas para sincronizar, já sincronizando também com as alterações de binlog;
- Porém o mesmo não levou os índices nem as opções de auto-incremments nem as Foreing Keys (FKs);
- Os ajustes levariam mais de 7 dias pelas estimativas;
- Realizamos então um novo DMS, já com o dump de estrutura pronto. Porém as estimativas também estavam em mais de 7 dias, inviabilizando o projeto;
- Por fim, sobrou então o xtrabackup, que inicialmente foi ignorado por causa da versão, como estava na 5.5, era incompatível com o RDS.
Utilizamos então uma instância replicada utilizada pelo cliente como backup;
Realizamos a migração para a 5.6 e posteriormente para a 5.7, viabilizando a estratégia;
Os passos serão vistos a seguir
Migrando uma instância MYSQL para o RDS de forma simples
Para migrar a instância, você só vai precisar de 3 coisas:
- Um bucket S3 para armazenar o seu backup (Pode ser até um existente);
- Um backup criado no seu servidor on-premises com XtraBackup;
- Uma role IAM com permissão de acesso ao bucket e permissão para criar o RDS (Pode ser uma role existente);
Limitações
Este processo possui algumas limitações que podem inviabilizar a estratégia:
- O Bucket S3 tem que estar na mesma conta e região do RDS a ser criado;
- O RDS tem que ser novo (Vai ser criado com o comando de restore, não pode ser um existente);
- A partir de fevereiro de 2022, a AWS só permitiu o restore para uma instância na versão maior ou igual a 5.7.
- A nova instância tem que estar na mesma versão majoritária do MySQL, porém é possível fazer um upgrade após a criação da instância.
- Também não é possível restaurar de uma versão minitória menor no RDS, por exemplo, da versão 5.7.36 para 5.7.15
- Porém, é possível restaurar de uma versão minitória no on-premises para uma versão minitória superior, por exemplo da 5.7.15 para a 5.7.36
- O RDS tem um limite de 5TB por arquivo (Cada arquivo, e não o backup completo) e 1 milhão de arquivos no bucket. Caso sua instância atinja alguma destas limitações, você pode realizar a compressão com Gzip (.gz), tar (.tar.gz), ou Percona xbstream (.xbstream);
- Funções e procedures não são importadas automaticamente. Isso ocorre porque o RDS não permite superusuários. Basta fazer um dump das suas procedures e funções e importar no RDS sem a opção *DEFINER*;
- Apesar do técnica também restaurar usuários, os mesmos não são garantidos pela AWS. Então recomendamos que seja feito um dump de privilégios. O mesmo pode ser realizado com a ferramenta da Percona pt-show-grants;
- O parâmetro innodb_data_file_path deve estar configurado de forma única, com o valor padrão: ibdata1:12M:autoextend. No nosso desafio, a instância detinha 3 datafiles. Após a geração do backup, concatenamos os 3 em um só, pela ordem que foram gerados, e alteramos a configuração para o valor default.
- O tamanho máximo da base a ser restaurada depende do tamanho máximo do disco menos o tamanho do backup. Então por exemplo, se o tamanho máximo da database for 64 TB o o tamanho do backup for de 30 TB, o tamanho máximo da base restaurada vai ser de 34 TB;
Verifique a documentação completa em neste link.
Passo 1 – Criar o bucket S3
O primeiro passo do processo é criar um bucket do S3.
Você pode utilizar um existente.
Neste passo-a-passo, iremos criar um básico:
Na tela geral do S3, selecione a opção “Create bucket”:
Na próxima tela, escolha um nome para o seu bucket e a região do mesmo.
Tome muito cuidado nesta parte, pois não é possível realizar o restore entre regiões.
O RDS final deve estar na mesma região do bucket:
O RDS final deve estar na mesma região do bucket:
As demais configurações podem ser padrões da AWS, inclusive o bloqueio de acesso público.
Finalize a criação ao final da página, no botão “Create Bucket”
Passo 2 – Criar a Role IAM
O segundo passo do processo é criar uma role IAM para realizar o restore da instância.
Selecione o serviço Identity and Access Management (IAM);
Entre no menu Roles.
Selecione a opção: “Create Role”.
Na primeira tela, em Trusted entity type, selecione Custom trust policy, e preencha com o seguinte conteúdo:
01 | { |
02 | "Version": "2012-10-17", |
03 | "Statement": [ |
04 | { |
05 | "Effect": "Allow", |
06 | "Principal": { |
07 | "Service": [ |
08 | "s3.amazonaws.com", |
09 | "rds.amazonaws.com" |
10 | ] |
11 | }, |
12 | "Action": "sts:AssumeRole" |
13 | } |
14 | ] |
15 | } |
Na segunda etapa, selecione as permissões:
- AmazonRDSFullAccess
- AmazonS3ReadOnlyAccess
Na terceira e última etapa, digite um nome para a política, confirme as permissões e clique em “Create Role”.
[Atenção!!!]
Esta política criada é o básico para a criação de uma forma simples, e após o procedimento pode ser completamente removida.
Caso seja um requisito de segurança, podem ser acrescidas limitações, para ler apenas o bucket criado e permissão para criação apenas do RDS desejado.
Você pode ver mais sobre políticas da AWS em neste link.
Passo 3 – Gerar o backup
Para gerar o backup não tem muito mistério, pode ser gerado da forma mais simples, conforme documentação da AWS:
1 | xtrabackup --backup --user=<usuario> --password=<senha> --target-dir=</diretorio_backup/> |
Caso seja necessário comprimir o backup e dividir em partes menores, a AWS recomenda o seguinte comando:
1 | xtrabackup --backup --user=<myuser> --password=<password> --stream=tar \ |
2 | --target-dir=</on-premises/s3-restore/backup> | gzip - | split -d --bytes=500MB \ |
3 | - </on-premises/s3-restore/backup/backup>.tar.gz |
Recomendamos a utilização de paralelismo para o seu backup, que pode ser com a flag –parallel=
Passo 4 – Enviar o backup para o S3
A maneira mais simples de enviar o backup para o s3 é utilizando a função sync do AWS CLI.
Você só precisará gerar um Token para o seu usuário.
A documentação pode ser obtida neste link.
Após configurar o CLI, basta chamar a função:
1 | aws s3 sync <diretorio_backup_xtrabackup> s3://<nome_bucket> |
Caso utilize um bucket existente, recomendamos a criação de um diretório no bucket. O sync ficaria então desta forma:
1 | aws s3 sync <diretorio_backup_xtrabackup> s3://<nome_bucket>/<diretorio> |
Passo 5 – Restaurar o backup do S3
Dentro do menu de serviço do RDS, selecione a opção “Restore from S3”
O primeiro campo corresponde ao Bucket S3 onde está o seu backup. Lembre-se que ele deve estar na mesma região em que deseja criar o RDS.
Você pode trocar a região no canto superior direito.
Caso você tenha colocado o backup dentro de um diretório, basta colocar o prefixo na linha de baixo.
Escolha a Engine (Auroa ou MySQL). O procedimento é o mesmo para os dois.
Escolha também a versão do banco. Lembre-se que esta versão deve corresponder à versão do backup.
A versão minoritária no RDS também deve ser igual ou superior a versão minoritária do backup.
O próximo passo então é escolher a role IAM criada no tutorial.
Depois preencha a instância do RDS e o identificador da instância.
Os demais parâmetros já são opcionais do RDS e ficam à critério do cliente, como backup e etc.
Por fim, no final da página clique no botão “Create database” e a base será restaurada por completo na AWS.
Aguarde por até algumas horas o restore, dependendo do tamanho do backup.
Passo 6 – Validar as procedures, funções e usuários
Verifique se há procedures e funções na instância.
O mesmo pode ser visto com a seguinte consulta:
1 | select * from information_schema.routines where routine_schema not in ('sys'); |
2 | ou |
3 | SHOW CREATE PROCEDURE <database>.<nome_procedure> |
4 | SHOW CREATE FUNCTION <database>.<nome_funcao> |
[Atenção!!!]
Lembre-se de remover a opção definer=’xxx’ ao criar no RDS.
Em relação aos usuários, pode-se utilizar a ferramenta da Percona, pt-show-grants, disponível aqui.
Não há como criar super usuários na AWS.
Passo 7 – Configurar a instância do RDS como réplica do servidor on-premises
O passo-a-passo para replicação no RDS é semelhante a estrutura do on-premises.
A diferença está no fato de nos servidores RDS não existerem superusuários, então a configuração é realizada por procedures:
Configurar o apontamento para o master
1 | CALL mysql.rds_set_external_master ('{{ host }}', {{ porta }},'{{ usuario }}', '{{ senha }}', '{{ arquivo de log }}', {{ posicao }}, {{ use_ssl }}); |
O último parâmetro corresponde a utilização ou não de criptografia SSL para conexão.
0 desabilita e 1 habilita.
A configuração do binglog pode ser obtida no próprio backup gerado pelo XtraBackup, no arquivo xtrabackup_binlog_info ou no arquivo xtrabackup_info.
Para iniciar a replicação:
1 | CALL mysql.rds_start_replication; |
Para parara a replicação:
1 | ALL mysql.rds_stop_replication; |
Para consultar a replicação:
1 | SHOW SLAVE STATUS; |
Considerações finais
Desta forma, é possível realizar uma migração com o menor tempo de downtime possível, independente do tamanho da base, pois a migração só ocorrerá após a finalização da sincronia do RDS com o master;
Certifique-se de que a réplica irá armazenar binlogs suficiente.
