MariaDB
 sql >> Base de Dados >  >> RDS >> MariaDB

Migração do Amazon RDS (MySQL ou MariaDB) para um servidor local

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

  1. 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
  1. Instalar o pacote mysql-client

# Para MySQL

$ yum install -y mysql-community-client.x86_64

# Para MariaDB

$ yum install -y MariaDB-client
  1. 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
  1. 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
  1. 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


  1. Iniciar o servidor MySQL/MariaDB

## Para MySQL

$ systemctl start mysqld

## Para MariaDB

$ systemctl start mariadb
  1. 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
  1. 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)
  1. 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.sql

Em 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=. Claro, uma vez que o backup foi feito, não se esqueça de iniciar sua réplica RDS para iniciar seus threads de replicação novamente,

rds-replica-mysql> CALL mysql.rds_start_replication;

Usando meudumper

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.

  1. Instale o binário. Os binários podem ser localizados aqui https://github.com/maxbube/mydumper/releases.

 $ yum install https://github.com/maxbube/mydumper/releases/download/v0.9.5/mydumper-0.9.5-2.el6.x86_64.rpm
  1. Faça o backup do nó de origem do RDS. Por exemplo,

[[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

Agora, neste ponto, mydumper fará um backup de arquivos na forma de arquivos *.gz

  1. Carregue-o no servidor local de destino

$ 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`
  1. 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:

$ 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

## Em seguida, execute um mestre de alterações da réplica ou do nó de banco de dados MySQL/MariaDB de destino de destino

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)

## Inicie o slave

MariaDB [jbmrcd_date]> start slave;

Query OK, 0 rows affected (0.001 sec)

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.

Verificar discrepâncias de dados

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.

Conclusã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.