O blog da AWS

Como migrar seu banco de dados MySQL para Amazon Aurora

Por Angie Nobre, Sr. Database Specialist da AWS

 

MySQL é o banco de dados open-source relacional de maior popularidade no mercado. Ganhou um grande mercado devido à facilidade de implementação e desenvolvimento.

 

 

Fonte: https://db-engines.com/en/ranking

Embora a implementação tenha uma grande adesão devido a facilidade de desenvolvimento, a administração de motores open-source é onerosa durante a manutenção do ciclo de vida do ambiente, desde a aplicação de patches, execução de backups, monitoração, configuração de alta disponibilidade de forma a atender os níveis de disponibilidade de ambientes de missão crítica.

 

Benefícios de serviços gerenciados para bancos de dados

Serviços gerenciados agregam facilidades importantes para a disponibilidade, durabilidade e segurança dos dados. Tarefas importantes e críticas para garantir a proteção e performance estão disponíveis e automatizadas por meio dos serviços gerenciados. Tarefas como:

  • Instalação do sistema operacional
  • Aplicação de patches do sistema operacional
  • Instalação do software de banco de dados
  • Aplicação de patches do banco de dados
  • Backup, bem como sua retenção.
  • Monitoração
  • Snapshots
  • Alta disponibilidade
  • Replicação dos dados para proteção em caso de desastre

Tais funcionalidades tão críticas e fundamentais para a operação de bases de dados críticas com segurança e escalabilidade.

 

Por que migrar seu banco MySQL para Aurora?

O Amazon Aurora é um banco de dados relacional compatível com MySQL e PostgreSQL e criado para a nuvem que combina a performance e a disponibilidade de bancos de dados comerciais avançados com a simplicidade e a economia de bancos de dados de código aberto.

Por isso segue um passo à passo para migrar um banco de dados MySQL para um serviço com maior escalabilidade, mas também com um tempo de indisponibilidade bem pequeno para a aplicação, e utilizando ferramentas nativas de backup do MySQL.

 

 

Para copiar seu MySQL vamos gerar um backup e copia-lo ao Amazon S3, a partir do S3 restauramos para o Amazon Aurora, e realizamos uma replicação da sua origem para o Amazon Aurora.

 

Setup da infraestrutura do lab:

1. Executar o Cloudformation:

Região AWS escolhida

Link para criação

N.Virginia (us-east-1)

Ohio (us-east-2)

Oregon (us-west-2)

South America (sa-east-1)

Clique next.

2. Selecione, um key pair para a instância EC2, se não tiver um crie conforme aqui.

 

 

3. Na próxima tela clique em Next ao final da página.

 

 

4. Marque “I acknowleged that..” e crie a stack.

 

 

5. Vá até a console do EC2 para logar na sua máquina com MySql. Em Running instances encontre a máquina de nome mysql-source.

 

 

6. Se conecte na instância.

 

 

7. Substituindo a senha do root por alguma que queira, se não alterar o arquivo /tmp/mysqlfile, será ‘Tim3t0change’, se desejar, edite o arquivo com root.

Bash

sudo mysqld --user=mysql --init-file=/tmp/mysqlfile &

mysql -u root -p

(se você não alterou o arquivo a senha será “Tim3t0change”)

 

 

Como extrair o backup do banco MySQL:

1. Verificar no banco MySQL de origem se está habilitado bin_log:

Bash

mysql -u root -p

mysql> show variables like '%server_id%';

+----------------+-------+

| Variable_name  | Value |

+----------------+-------+

| server_id      | 0     |

| server_id_bits | 32    |

+----------------+-------+

2 rows in set (0.00 sec)




mysql> show variables like '%log_bin%';

+---------------------------------+-------+

| Variable_name                   | Value |

+---------------------------------+-------+

| log_bin                         | OFF   |

| log_bin_basename                |       |

| log_bin_index                   |       |

| log_bin_trust_function_creators | OFF   |

| log_bin_use_v1_row_events       | OFF   |

| sql_log_bin                     | ON    |

+---------------------------------+-------+

6 rows in set (0.00 sec)




mysql> show variables like '%version%';

+-------------------------+------------------------------+

| Variable_name           | Value                        |

+-------------------------+------------------------------+

| innodb_version          | 5.6.48                       |

| protocol_version        | 10                           |

| slave_type_conversions  |                              |

| version                 | 5.6.48-log                   |

| version_comment         | MySQL Community Server (GPL) |

| version_compile_machine | x86_64                       |

| version_compile_os      | Linux                        |

+-------------------------+------------------------------+

7 rows in set (0.00 sec)




mysql> quit

2. Desative a sessão que ficou com a alteração de senha:

Bash

sudo kill -9 `ps -ef | grep mysql | grep -v grep | awk '{print $2}'`

3. Habilitar binlog editando o arquivo /usr/my.cnf:

Editar com root. (sudo vi /usr/my.cnf or sudo vim /usr/my.cnf).

log_bin=mysql-bin

server_id=2133421

innodb_flush_log_at_trx_commit=1

sync_binlog=1

4. Start do MySQL:

[ec2-user]# sudo service mysql start

5. Confirmando a modificação dos parâmetros:

Bash

[ec2-user]# mysql -u root -p

mysql> show binary logs;

+------------------+-----------+

| Log_name         | File_size |

+------------------+-----------+

| mysql-bin.000001 |       120 |

+------------------+-----------+

1 row in set (0.00 sec)




mysql> show variables like '%log_bin%';

+---------------------------------+--------------------------------+

| Variable_name                   | Value                          |

+---------------------------------+--------------------------------+

| log_bin                         | ON                             |

| log_bin_basename                | /var/lib/mysql/mysql-bin       |

| log_bin_index                   | /var/lib/mysql/mysql-bin.index |

| log_bin_trust_function_creators | OFF                            |

| log_bin_use_v1_row_events       | OFF                            |

| sql_log_bin                     | ON                             |

+---------------------------------+--------------------------------+

6 rows in set (0.00 sec)




mysql> show variables like '%server_id%';

+----------------+---------+

| Variable_name  | Value   |

+----------------+---------+

| server_id      | 2133421 |

| server_id_bits | 32      |

+----------------+---------+

2 rows in set (0.00 sec)


6. Acidionando tabela

mysql>

create database novo;

use novo;

create table novo.employee (empid  int NOT NULL, name varchar(255) NOT NULL, age int NOT NULL, PRIMARY KEY (empid));

insert into employee (empid, name, age) values(1, "Joe Doe",17);

insert into employee (empid, name, age) values(2, "Bob Mansel",25);

insert into employee (empid, name, age) values(3, "Mary Wilson",32);

commit;

7. Para gerar o backup do banco MySQL é necessário no mínimo a Percona XtraBackup 2.3 ou 2.4:

Bash

[ec2-user]# sudo mkdir -p /mnt/backup

[ec2-user]# sudo chmod 755 /mnt/backup

[ec2-user]# sudo su -

[root]# xtrabackup --backup --user=root --password=Tim3t0change --stream=tar    --target-dir=/mnt/backup | gzip - | split -d --bytes=4096MB    - /mnt/backup/MySQL_Source.tar.gz

[root]# ls -ltr /mnt/backup/

 

 

Ao final terá a mensagem de finalização com sucesso:

xtrabackup: Transaction log of lsn (134718594119) to (134718594119) was copied.

200901 19:32:43 completed OK!

 

Como copiar os arquivos gerados pelo backup para o S3:

1. Com o backup finalizado com sucesso, é necessário copiar os arquivos para um bucket.

O bucket foi criado pelo CloudFormation, verifique na console do S3.

O nome inicia com ’01-mysql-migration-..’ e termina com ‘-raw’

 

 

2. Fazer upload do backup para o bucket identificado acima no S3:

cd /mnt/backup

[root]# aws s3 sync . s3://<nome do seu bucket>/backup/

 

 

Como criar a policy e role para permitir restaurar à partir do S3:

1. Em IAM, crie uma policy para permitir que o Aurora acesse os arquivos de backup do S3:

 

 

2. Selecione Policies, e create policy:

 

 

3. Edite como JSON.

 

 

4. Copie a seguinte permissão substituindo pelo nome do bucket onde copiou o backup:

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Action": [

                "s3:ListBucket",

                "s3:GetBucketLocation"

            ],

            "Resource": [

                "arn:aws:s3:::<nome do seu bucket>"

            ]

        },

        {

            "Effect": "Allow",

            "Action": [

                "s3:GetObject"

            ],

            "Resource": [

                "arn:aws:s3:::<nome do seu bucket>/backup*"

            ]

        }

    ]

}

Name: AllowAuroraRestoreMySQL

 

 

5. Selecione create policy.

 

 

6. Em IAM , Role:

 

 

7. Selecione Create role. Em AWS Service, selecione RDS.

 

 

8. Select your use case “RDS – Add Role to Database”:

 

 

9. Clique em Next: permissions.

10. Selecione a policy com a permissão no S3 criada no passo anterior:

 

 

11. Defina um nome e selecione Create role.

Role name: RDSAuroraLoadFromS3

 

 

 

Como restaurar o MySQL para o Aurora:

1. Nesta tela, clique em Restore Aurora DB cluster from S3, abaixo da opção principal.

 

 

Se tiver nesta outra tela também há opção de Restore from S3.

 

 

2. Selecione o seu bucket ‘01-mysql-migration-…-raw’ e prefix backup:

 

 

3. Selecione a engine option Aurora e a versão compatível com o MySQL no nosso caso (MySQL 5.6) 1.23.0:

 

 

4. Selecione a role com permissão de acesso ao bucket:

 

 

5. Configure o DB cluster identifier : “builders”, user “admin” e senha:

 

 

6. Selecione o tipo de instância:

 

 

7. Selecione a VPC e Security Group para o banco de dados:

            Selecione a mesma VPC informada no Cloud formation.

E o subnet group criado : mysql-dbsubnetgroup-<hash>

            Security Group: lab-mysql-migration

            Public Access: no

 

 

8. Em adicional configuration, coloque um database chamado lab:

 

 

9. Clique em Create database:

 

 

10. Acompanhe o status

 

 

11. Verifique novamente após um tempo estará com status Available e o banco restaurado:

 

 

12. Verifique o endpoint de write do banco de dados:

 

 

Como configurar a replicação do MySQL para o Aurora:

1. Na console RDS, selecione Events para verificar o filename e position da replicação:

 

 

2. Criar o usuário de replicação em seu banco de Origem MySQL:

Na sua instância EC2 mysql-source:

[root@ip-9-0-3-249 datadir]# mysql -u root -p

Enter password:

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 3

Server version: 5.6.48-log MySQL Community Server (GPL)


Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.


Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> create user 'repl'@'%' identified by 'aurorarepl';

Query OK, 0 rows affected (0.00 sec)

mysql> grant replication client,replication slave on *.* to 'repl'@'%';

Query OK, 0 rows affected (0.00 sec)

mysql> GRANT USAGE ON *.* TO 'repl'@'%';

mysql> SHOW MASTER STATUS;

 

 

3. Anote o arquivo (File) e a posição (Position).

4. Na console RDS, selecione Events para verificar o filename e position da replicação:

 

 

5. Em databases copie o Writer endpoint que será usado para conectar:

 

 

6. Conectar na instância Aurora MySQL:

[root@ip-9-0-3-249 datadir]# mysql -h <endpoint-write-aurora> -u admin -p

mysql> show variables like '%version%';

+-------------------------+------------------------------+

| Variable_name           | Value                        |

+-------------------------+------------------------------+

| aurora_version          | 1.23.0                       |

| innodb_version          | 1.2.10                       |

| protocol_version        | 10                           |

| slave_type_conversions  |                              |

| version                 | 5.6.10                       |

| version_comment         | MySQL Community Server (GPL) |

| version_compile_machine | x86_64                       |

| version_compile_os      | Linux                        |

+-------------------------+------------------------------+



mysql> call mysql.rds_set_external_master('<hostname da sua EC2>',3306,'repl','aurorarepl','mysql-bin.000001',<your db positon>,0);



mysql> call mysql.rds_start_replication;

 

 

mysql> SHOW SLAVE STATUS\G;

 

 

7. Ainda conectado no Aurora faça uma query na tabela novo.employee:

Mysql>

select * from novo.employee;

 

 

8. Estes 3 registros vieram do backup agora vamos inserir novos registros na sua origem.

9. Crie eventos no seu banco de Origem:

Na sua instância de mysql de origem mysql-source:

[root@ip-9-0-3-249 datadir]# mysql -u root -p

Enter password:

use novo

insert into novo.employee (empid, name, age) values(4, "Manuel Garcia",37);

insert into novo.employee (empid, name, age) values(5, "Antonio Flores",48);

insert into novo.employee (empid, name, age) values(6, "Alex Palacios",29);

commit;

 

 

10. Verifique a replicação:

Conecte novamente na instância Aurora MySQL:

[root]# mysql -h <endpoint-write-aurora> -u admin -p

mysql> select * from novo.employee;

 

 

As alterações na origem foram aplicadas no destino do Aurora, e a partir deste momento, pode se feita a virada das aplicações para o Aurora.

 

Monitore a atualização da replicação até que esteja sincronizado e assim direcionar a aplicação para o Aurora.

 

O valor de Seconds_Behind_Master deve estar em 0 para que não tenha mais registros para aplicar.

 

Resumo

Neste post descrevemos como migrar suas bases de dados MySQL para o Aurora utilizando um backup inicial e a replicação nativa do MySQL. Você pode utilizar o percona xtrabackup para extrair o backup, e depois realizar uma replicação entre a origem MySQL e o Aurora MySQL.

Demonstramos como é possível gerar o Aurora a partir de um backup do MySQL no S3 com a facilidade de apontar um caminho no Amazon S3. O serviço do RDS sobe o database com o backup e indica qual o último bin log aplicado para ser utilizado na replicação, facilitando a visibilidade e eliminando perda de dados.

 


Sobre a autora

Angie Nobre, é Sr. Database Specialist na AWS.