A Amazon Web Services é uma gigante da tecnologia, especialmente quando se trata de ser pioneira em serviços de computação em nuvem de primeira linha. Seus produtos de serviços totalmente gerenciados (Amazon RDS) são únicos. Mas, novamente, embora possa ser uma plataforma perfeita para algumas organizações, pode ser um desafio sair dela se não for. Sempre há preocupações de ficar preso em uma situação de aprisionamento de fornecedor.
Algumas coisas a serem lembradas ao migrar do RDS para uma plataforma local são restrições de orçamento, segurança e autonomia de dados. Isso ocorre porque os dados são seu ativo mais valioso e, mantendo o controle onde quer que residam, é sempre imperativo que a organização e a empresa permaneçam sempre competitivas. Nenhuma organização pode se dar ao luxo de ter o aprisionamento na nuvem e, no entanto, muitas empresas se encontram exatamente nessa situação e começam a procurar soluções alternativas existentes que possam ser operadas no local.
Este blog orientará você sobre como migrar do Amazon RDS para um servidor local. Nosso banco de dados de destino no servidor local está em um servidor Linux RHEL/CentOS, mas o procedimento aplicável deve ser aplicado em outras versões do Linux, desde que os pacotes estejam instalados corretamente.
Existem algumas soluções de terceiros existentes que oferecem migração de dados, mas não é aplicável a uma plataforma local. Além disso, não é gratuito e migrar usando soluções gratuitas com código aberto é sempre favorável e vantajoso. Embora também existam dúvidas e preocupações, pois a garantia e o suporte não estão vinculados a tecnologias de código aberto, mostraremos aqui como fazer isso em um procedimento simples.
Como o Amazon RDS oferece suporte à compatibilidade com MySQL e MariaDB. Vamos nos concentrar neles para este blog.
Migrando do Amazon RDS para MySQL ou MariaDB
Uma abordagem típica de migração de dados do Amazon RDS para um servidor local é fazer um backup usando uma cópia lógica. Isso pode ser feito usando soluções de utilitário de backup compatíveis para operar com o Amazon RDS, que é um serviço totalmente gerenciado. Os serviços de banco de dados totalmente gerenciados não oferecem logins SSH, portanto, a cópia física dos backups não é uma opção.
Usando mysqldump
O uso do mysqldump deve ser instalado em seu nó de banco de dados de destino localizado no local. Ele deve ser preparado como uma réplica do nó AWS RDS para que todas as transações subsequentes sejam replicadas para o nó. Para fazer isso, siga as etapas abaixo.
Host de origem do AWS RDS :database-1.xxxxxxx.us-east-2.rds.amazonaws.com
Host do servidor local :192.168.10.226 (nódeteste26)
Antes de iniciar o dump, certifique-se de que as horas de retenção do log binário estejam definidas. Para configurá-lo, você pode fazer como a chamada de procedimento de exemplo abaixo em sua instância do Amazon RDS,
mysql> call mysql.rds_set_configuration('binlog retention hours', 24);
Query OK, 2 rows affected (0.23 sec)
mysql> CALL mysql.rds_show_configuration;
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| name | value | description |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| binlog retention hours | 24 | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
1 row in set (0.23 sec)
Query OK, 0 rows affected (0.23 sec)Instalar mysqldump
-
Prepare o repositório.
# Para MySQL
$ yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm# Para MariaDB
$ curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash-
Instalar o pacote mysql-client
# Para MySQL
$ yum install -y mysql-community-client.x86_64# Para MariaDB
$ yum install -y MariaDB-client-
Crie um dump de dados usando mysqldump executando-o dentro do nó de destino. Tome nota, com --master-data=2 especificado como uma opção, isso funciona apenas para MariaDB, mas não no MySQL. Portanto, trabalho extra para o MySQL deve ser feito. Falaremos sobre isso mais tarde.
## Aplicável para abordagem MariaDB
[[email protected] ~]# mysqldump -h database-1.xxxxxxx.us-east-2.rds.amazonaws.com -uadmin -p --single-transaction --master-data=2 --databases db1 db2 db3 > backups/dump.sql
Enter password:
[[email protected] ~]# ls -alth backups/dump.sql
-rw-r--r--. 1 root root 196M Oct 18 02:34 backups/dump.sql-
Instale o servidor MySQL/MariaDB no nó do banco de dados de destino
# Para MySQL (sempre verifique qual repositório de versão está habilitado em seu repositório yum. Neste ponto, estou usando o MySQL 5.7)
$ yum --disablerepo=* --enablerepo=mysql57-community install mysql-community-common mysql-community-client mysql-community-server# Para MariaDB
$ yum install MariaDB-server.x86_64-
Configure a instância do servidor MySQL/MariaDB (my.cnf, permissões de arquivo, diretórios) e inicie o servidor
# Configurando o my.cnf (usando a implantação my.cnf usada pelo ClusterControl)
[MYSQLD]
user=mysql
basedir=/usr/
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
pid_file=/var/lib/mysql/mysql.pid
port=3306
log_error=/var/log/mysql/mysqld.log
log_warnings=2
slow_query_log_file=/var/log/mysql/mysql-slow.log
long_query_time=2
slow_query_log=OFF
log_queries_not_using_indexes=OFF
innodb_buffer_pool_size=2G
innodb_flush_log_at_trx_commit=2
innodb_file_per_table=1
innodb_data_file_path=ibdata1:100M:autoextend
innodb_read_io_threads=4
innodb_write_io_threads=4
innodb_doublewrite=1
innodb_log_file_size=256M
innodb_log_buffer_size=32M
innodb_buffer_pool_instances=1
innodb_log_files_in_group=2
innodb_thread_concurrency=0
innodb_flush_method=O_DIRECT
innodb_rollback_on_timeout=ON
innodb_autoinc_lock_mode=2
innodb_stats_on_metadata=0
default_storage_engine=innodb
server_id=1126
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
relay_log=relay-bin
expire_logs_days=7
read_only=OFF
report_host=192.168.10.226
key_buffer_size=24M
tmp_table_size=64M
max_heap_table_size=64M
max_allowed_packet=512M
skip_name_resolve=true
memlock=0
sysdate_is_now=1
max_connections=500
thread_cache_size=512
query_cache_type=0
query_cache_size=0
table_open_cache=1024
lower_case_table_names=0
performance_schema=OFF
performance-schema-max-mutex-classes=0
performance-schema-max-mutex-instances=0
[MYSQL]
socket=/var/lib/mysql/mysql.sock
[client]
socket=/var/lib/mysql/mysql.sock
[mysqldump]
socket=/var/lib/mysql/mysql.sock
max_allowed_packet=512M## Redefina o diretório de dados e reinstale os arquivos do sistema de banco de dados
$ rm -rf /var/lib/mysql/*## Crie os diretórios de log
$ mkdir /var/log/mysql
$ chown -R mysql.mysql /var/log/mysql## Para MySQL
$ mysqld --initialize## Para MariaDB
$ mysql_install_db-
Iniciar o servidor MySQL/MariaDB
## Para MySQL
$ systemctl start mysqld## Para MariaDB
$ systemctl start mariadb-
Carregar o dump de dados que tiramos do AWS RDS para o nó do banco de dados de destino no local
$ mysql --show-warnings < backups/dump.sql-
Crie o usuário de replicação a partir do nó de origem do AWS RDS
MariaDB [(none)]> CREATE USER 'repl_user'@'149.145.213.%' IDENTIFIED BY 'repl_passw0rd';
Query OK, 0 rows affected (0.242 sec)
MariaDB [(none)]> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO repl_user'@'149.145.213.%' IDENTIFIED BY 'repl_passw0rd' ;
Query OK, 0 rows affected (0.229 sec)-
Configurar o servidor MySQL/MariaDB como uma réplica/escravo do nó de origem do AWS RDS
## Primeiro, vamos pesquisar ou localizar o comando CHANGE MASTER
[[email protected] ~]# grep -rn -E -i 'change master to master' backups/dump.sql |head -1
22:-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000584', MASTER_LOG_POS=421;## Execute a instrução CHANGE MASTER, mas adicione o usuário/senha de replicação e o nome do host da seguinte maneira,
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='database-1.xxxxxxx.us-east-2.rds.amazonaws.com', MASTER_LOG_FILE='mysql-bin-changelog.000584', MASTER_LOG_POS=421, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';
Query OK, 0 rows affected (0.004 sec)## Em seguida, inicie os threads escravos
MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.001 sec)## Verifique o status do escravo como está
MariaDB [(none)]> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: database-1.xxxxxxx.us-east-2.rds.amazonaws.com
Master_User: repl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin-changelog.000584
Read_Master_Log_Pos: 421
Relay_Log_File: relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin-changelog.000584
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: 421
Relay_Log_Space: 256
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
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: 1675507089
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: optimistic
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Slave_DDL_Groups: 0
Slave_Non_Transactional_Groups: 0
Slave_Transactional_Groups: 0
1 row in set (0.000 sec)Agora que finalmente conseguimos replicar do RDS como a origem ou mestre de nossa réplica localizada no local. Ainda não está feito. Existem alguns casos em que você encontrará erros de replicação, como,
Last_SQL_Errno: 1146
Last_SQL_Error: Error 'Table 'mysql.rds_heartbeat2' doesn't exist' on query. Default database: 'mysql'. Query: 'INSERT INTO mysql.rds_heartbeat2(id, value) values (1,1602988485784) ON DUPLICATE KEY UPDATE value = 1602988485784' Como o local não precisa replicar dados provenientes do banco de dados mysql para tabelas prefixadas com 'rds%', simplesmente ignoramos essas tabelas durante a replicação. Além disso, talvez você não queira que o AWS RDS atualize e altere sua tabela mysql.user. Para fazer isso, você pode, opcionalmente, ignorar o esquema ou apenas listar tabelas como,
STOP SLAVE;Então,
SET GLOBAL replicate_wild_ignore_table='mysql.rds%';ou
SET GLOBAL replicate_wild_ignore_table='mysql.%';O problema do MySQL com --master-data=2
Pegar o mysqldump com --master-data=2 requer privilégios suficientes que requerem privilégios SUPER e RELOAD. O problema é que o AWS RDS não fornece isso para o usuário administrador durante a configuração e a criação do banco de dados. Para solucionar esse problema, deve ser que seu AWS RDS tenha uma configuração mestre e uma réplica ou escrava. Depois de ter uma configuração de escravo, tome isso como o host de origem de destino ao usar o mysqldump. Em seguida, interrompa os encadeamentos escravos de sua réplica do AWS RDS da seguinte maneira,
rds-replica-mysql> CALL mysql.rds_stop_replication;Então pegue o mysqldump sem a opção --master-data como abaixo,
mysqldump -h database-1.xxxxxxx.us-east-2.rds.amazonaws.com -uadmin -p --single-transaction --databases db1 db2 db3 > backups/dump.sqlEm seguida, execute SHOW SLAVE STATUS\G de sua réplica do AWS RDS e anote o Master_Log_File e Exec_Master_Log_Pos para os quais você usará ao se conectar ao mestre do AWS RDS replicando para seu servidor local. Use essas coordenadas ao executar CHANGE MASTER TO… MASTER_LOG_FILE=Master_Log_File, MASTER_LOG_POS= mydumper pode ser sua opção alternativa aqui, especialmente quando o conjunto de dados é muito grande, pois oferece paralelismo e velocidade ao fazer um dump ou cópia de backup de seu conjunto de dados de um nó RDS de origem. Siga as etapas abaixo da instalação do mydumper para carregá-lo em seu servidor local de destino. Instale o binário. Os binários podem ser localizados aqui https://github.com/maxbube/mydumper/releases. Faça o backup do nó de origem do RDS. Por exemplo, Agora, neste ponto, mydumper fará um backup de arquivos na forma de arquivos *.gz Carregue-o no servidor local de destino Configure o nó de destino como escravo/réplica. mydumper incluirá um arquivo chamado metadados que consiste em coordenadas de log binário, incluindo posições GTID, por exemplo: ## Em seguida, execute um mestre de alterações da réplica ou do nó de banco de dados MySQL/MariaDB de destino de destino ## Inicie o slave Neste ponto, você já replicou de uma instância do Amazon RDS executando MySQL/MariaDB. Quando seu aplicativo estiver pronto para sair de sua instância do Amazon RDS, configure o endpoint indo para o seu servidor local e todas as transações restantes de sua instância do RDS serão replicadas para o seu local, não deixando nenhum dado perdido indo para o seu local. servidor prem. Depois de ter seus dados carregados ou despejados em seu servidor local atuando como uma réplica da instância do AWS RDS, você deve verificar isso executando cálculos de soma de verificação para determinar a distância entre seus dados e o origem Amazon RDS. Eu sugiro que você use a ferramenta pt-table-checksum da Percona, mas você pode criar a sua própria usando ferramentas de soma de verificação como md5 ou sha256, mas isso leva tempo para fazer. Além disso, o uso de pt-upgrade também pode ajudar após a conclusão da migração de dados usando essa abordagem de replicação. Usar mysqldump ou mydumper são ferramentas gratuitas de código aberto, o que também é uma grande vantagem, especialmente se seus dados forem muito confidenciais e você não quiser que terceiros os acessem. Embora possa ser simples adotar essa abordagem, pode haver um trabalho tedioso e grande que pode ser envolvido, já que testes e verificações duplas sempre seguem para provar que a migração é totalmente alcançada sem inconsistências de dados.
rds-replica-mysql> CALL mysql.rds_start_replication;Usando meudumper
$ yum install https://github.com/maxbube/mydumper/releases/download/v0.9.5/mydumper-0.9.5-2.el6.x86_64.rpm
[[email protected] mydumper-2]# /usr/bin/mydumper --outputdir=. --verbose=3 --host=database-1.xxxxxxx.us-east-2.rds.amazonaws.com --port=3306 --kill-long-queries --chunk-filesize=5120 --build-empty-files --events --routines --triggers --compress --less-locking --success-on-1146 --regex='(db1\.|db2\.|db3\.|mydb4\.|testdb5\.)' -u admin --password=admin123
** Message: Connected to a MySQL server
** (mydumper:18904): CRITICAL **: Couldn't acquire global lock, snapshots will not be consistent: Access denied for user 'admin'@'%' (using password: YES)
** Message: Started dump at: 2020-10-18 09:34:08
** Message: Written master status
** Message: Multisource slave detected.
** Message: Thread 5 connected using MySQL connection ID 1109
$ myloader --host localhost --directory=$(pwd) --queries-per-transaction=10000 --threads=8 --compress-protocol --verbose=3
** Message: 8 threads created
** Message: Creating database `db1`
** Message: Creating table `db1`.`folders_rel`
** Message: Creating table `db2`.`p`
** Message: Creating table `db2`.`t1`
** Message: Creating table `db3`.`AddressCodeTest`
$ cat metadata
Started dump at: 2020-10-18 10:23:35
SHOW MASTER STATUS:
Log: mysql-bin-changelog.000680
Pos: 676
GTID:0-1675507089-3044
MariaDB [jbmrcd_date]> CHANGE MASTER TO MASTER_HOST='database-1.cmu8qdlvkepg.us-east-2.rds.amazonaws.com', MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd', MASTER_LOG_FILE='mysql-bin-changelog.000680', MASTER_LOG_POS
=676;
Query OK, 0 rows affected (0.002 sec)
MariaDB [jbmrcd_date]> start slave;
Query OK, 0 rows affected (0.001 sec)
Verificar discrepâncias de dados
Conclusão
