Em nosso blog anterior, vimos como é fácil começar a usar o RDS para MySQL. É uma maneira conveniente de implantar e usar o MySQL, sem se preocupar com sobrecarga operacional. A desvantagem é o controle reduzido, pois os usuários dependem totalmente da equipe da Amazon em caso de desempenho ruim ou anomalias operacionais. Nenhum acesso ao diretório de dados ou backups físicos dificulta a movimentação de dados para fora do RDS. Isso pode ser um grande problema se seu banco de dados ultrapassar o RDS e você decidir migrar para outra plataforma. Este blog de duas partes mostra como fazer uma migração online do RDS para seu próprio servidor MySQL.
Estaremos usando o EC2 para executar nosso próprio MySQL Server. Pode ser um primeiro passo para migrações mais complexas para seus próprios datacenters privados. O EC2 dá acesso aos seus dados para que o xtrabackup possa ser usado. O EC2 também permite configurar túneis SSH e remove a necessidade de configurar conexões VPN de hardware entre sua infraestrutura local e a VPC.
Suposições
Antes de começarmos, precisamos fazer algumas suposições - especialmente em relação à segurança. Em primeiro lugar, assumimos que a instância do RDS não pode ser acessada de fora da AWS. Também supomos que você tenha um aplicativo no EC2. Isso implica que a instância do RDS e o restante de sua infraestrutura compartilham uma VPC ou há acesso configurado entre eles, de uma forma ou de outra. Em resumo, assumimos que você pode criar uma nova instância do EC2 e ela terá acesso (ou poderá ser configurada para ter acesso) à sua instância do MySQL RDS.
Configuramos o ClusterControl no host do aplicativo. Vamos usá-lo para gerenciar nossa instância MySQL do EC2.
Configuração inicial
No nosso caso, a instância RDS compartilha a mesma VPC com nosso “aplicativo” (instância EC2 com IP 172.30.4.228) e host que será alvo do processo de migração (instância EC2 com IP 172.30.4.238). Como aplicação, usaremos o benchmark tpcc-MySQL executado da seguinte maneira:
./tpcc_start -h rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com -d tpcc1000 -u tpcc -p tpccpass -w 20 -r 60 -l 600 -i 10 -c 4Plano inicial
Vamos realizar uma migração usando as seguintes etapas:
- Configure nosso ambiente de destino usando o ClusterControl - instale o MySQL em 172.30.4.238
- Em seguida, instale o ProxySQL, que usaremos para gerenciar nosso tráfego no momento do failover
- Descarregue os dados da instância do RDS
- Carregar os dados em nosso host de destino
- Configurar a replicação entre a instância do RDS e o host de destino
- Tráfego de transição do RDS para o host de destino
Prepare o ambiente usando o ClusterControl
Supondo que tenhamos o ClusterControl instalado (se você não tiver, pode pegá-lo em:https://severalnines.com/download-clustercontrol-database-management-system), precisamos configurar nosso host de destino. Usaremos o assistente de implantação do ClusterControl para isso:
Implantando um cluster de banco de dados no ClusterControl 
Implantando um cluster de banco de dados no ClusterControl 
Implantando um cluster de banco de dados no ClusterControl Feito isso, você verá um novo cluster (neste caso, apenas seu único servidor) na lista de clusters:
Agrupamento de banco de dados no ClusterControl O próximo passo será instalar o ProxySQL - a partir do ClusterControl 1.4, você pode fazer isso facilmente a partir da interface do usuário. Cobrimos esse processo em detalhes nesta postagem do blog. Ao instalá-lo, escolhemos nosso host de aplicativo (172.30.4.228) como o host para instalar o ProxySQL. Ao instalar, você também precisa escolher um host para direcionar seu tráfego. Como temos apenas nosso host de “destino” no cluster, você pode incluí-lo, mas algumas alterações são necessárias para redirecionar o tráfego para a instância do RDS.
Se você escolheu incluir o host de destino (no nosso caso foi 172.30.4.238) na configuração do ProxySQL, você verá as seguintes entradas na tabela mysql_servers:
mysql> select * from mysql_servers\G
*************************** 1. row ***************************
hostgroup_id: 20
hostname: 172.30.4.238
port: 3306
status: ONLINE
weight: 1
compression: 0
max_connections: 100
max_replication_lag: 10
use_ssl: 0
max_latency_ms: 0
comment: read server
*************************** 2. row ***************************
hostgroup_id: 10
hostname: 172.30.4.238
port: 3306
status: ONLINE
weight: 1
compression: 0
max_connections: 100
max_replication_lag: 10
use_ssl: 0
max_latency_ms: 0
comment: read and write server
2 rows in set (0.00 sec)O ClusterControl configurou o ProxySQL para usar os grupos de host 10 e 20 para rotear gravações e leituras para os servidores de back-end. Teremos que remover o host atualmente configurado desses grupos de hosts e adicionar a instância RDS lá. Primeiro, porém, precisamos garantir que o usuário monitor do ProxySQL possa acessar a instância do RDS.
mysql> SHOW VARIABLES LIKE 'mysql-monitor_username';
+------------------------+------------------+
| Variable_name | Value |
+------------------------+------------------+
| mysql-monitor_username | proxysql-monitor |
+------------------------+------------------+
1 row in set (0.00 sec)mysql> SHOW VARIABLES LIKE 'mysql-monitor_password';
+------------------------+---------+
| Variable_name | Value |
+------------------------+---------+
| mysql-monitor_password | monpass |
+------------------------+---------+
1 row in set (0.00 sec)Precisamos conceder a esse usuário acesso ao RDS. Se precisarmos rastrear o atraso da replicação, o usuário teria que ter o privilégio 'REPLICATION CLIENT'. No nosso caso, não é necessário, pois não temos instância RDS escrava - 'USAGE' será suficiente.
[email protected]:~# mysql -ppassword -h rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 210
Server version: 5.7.16-log MySQL Community Server (GPL)
Copyright (c) 2000, 2016, 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 'proxysql-monitor'@172.30.4.228 IDENTIFIED BY 'monpass';
Query OK, 0 rows affected (0.06 sec)Agora é hora de reconfigurar o ProxySQL. Vamos adicionar a instância do RDS aos grupos de hosts do gravador (10) e do leitor (20). Também removeremos 172.30.4.238 desses grupos de host - apenas os editaremos e adicionaremos 100 a cada grupo de host.
mysql> INSERT INTO mysql_servers (hostgroup_id, hostname, max_connections, max_replication_lag) VALUES (10, 'rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com', 100, 10);
Query OK, 1 row affected (0.00 sec)mysql> INSERT INTO mysql_servers (hostgroup_id, hostname, max_connections, max_replication_lag) VALUES (20, 'rds2.cvsw8xpajw2b.us-east-1.rds.amazonaws.com', 100, 10);
Query OK, 1 row affected (0.00 sec)mysql> UPDATE mysql_servers SET hostgroup_id=110 WHERE hostname='172.30.4.238' AND hostgroup_id=10;
Query OK, 1 row affected (0.00 sec)mysql> UPDATE mysql_servers SET hostgroup_id=120 WHERE hostname='172.30.4.238' AND hostgroup_id=20;
Query OK, 1 row affected (0.00 sec)mysql> LOAD MYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)mysql> SAVE MYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.07 sec)A última etapa necessária antes de podermos usar o ProxySQL para redirecionar nosso tráfego é adicionar o usuário do aplicativo ao ProxySQL.
mysql> INSERT INTO mysql_users (username, password, active, default_hostgroup) VALUES ('tpcc', 'tpccpass', 1, 10);
Query OK, 1 row affected (0.00 sec)mysql> LOAD MYSQL USERS TO RUNTIME; SAVE MYSQL USERS TO DISK; SAVE MYSQL USERS TO MEMORY;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.05 sec)
Query OK, 0 rows affected (0.00 sec)mysql> SELECT username, password FROM mysql_users WHERE username='tpcc';
+----------+-------------------------------------------+
| username | password |
+----------+-------------------------------------------+
| tpcc | *8C446904FFE784865DF49B29DABEF3B2A6D232FC |
+----------+-------------------------------------------+
1 row in set (0.00 sec)Nota rápida - executamos “SAVE MYSQL USERS TO MEMORY;” apenas para ter a senha hash não apenas em RUNTIME, mas também no buffer da memória de trabalho. Você pode encontrar mais detalhes sobre o mecanismo de hash de senha do ProxySQL em sua documentação.
Agora podemos redirecionar nosso tráfego para ProxySQL. Como fazer isso depende da sua configuração, acabamos de reiniciar o tpcc e apontamos para o ProxySQL.
Redirecionando o tráfego com ProxySQL Neste ponto, criamos um ambiente de destino para o qual migraremos. Também preparamos o ProxySQL e o configuramos para nosso aplicativo usar. Agora temos uma boa base para a próxima etapa, que é a migração de dados real. Na próxima postagem, mostraremos como copiar os dados do RDS para nossa própria instância MySQL (executando no EC2). Também mostraremos como alternar o tráfego para sua própria instância enquanto os aplicativos continuam atendendo aos usuários, sem tempo de inatividade.
