sql >> Base de Datos >  >> RDS >> MariaDB

Migración de Amazon RDS (MySQL o MariaDB) a un servidor local

Amazon Web Services es un gigante tecnológico, especialmente cuando se trata de ser pionero en servicios de computación en la nube de primera línea. Sus productos de servicios completamente administrados (Amazon RDS) son únicos. Pero, de nuevo, si bien puede ser una plataforma perfecta para algunas organizaciones, puede ser un desafío salir de ella si no lo es. Siempre existe la preocupación de quedarse atrapado en una situación de bloqueo de proveedor.

Algunas cosas a tener en cuenta al migrar de RDS a una plataforma local son las restricciones presupuestarias, la seguridad y la autonomía de los datos. Esto se debe a que los datos son su activo más valioso y al retener el control dondequiera que residan, siempre es imperativo que la organización y la empresa sigan siendo competitivas. Ninguna organización puede permitirse el lujo de tener un bloqueo en la nube y, sin embargo, muchas empresas se encuentran exactamente en esa situación y comienzan a buscar cualquier solución alternativa existente que pueda funcionar a través de las instalaciones.

Este blog lo guiará a través de cómo migrar de Amazon RDS a un servidor local. Nuestra base de datos de destino en el servidor local se encuentra en un servidor RHEL/CentOS Linux, pero el procedimiento aplicable se aplicará en otras versiones de Linux siempre que los paquetes estén correctamente instalados.

Existen algunas soluciones de terceros que ofrecen migración de datos, pero no es aplicable a una plataforma local. Además, no es gratuito y migrar utilizando soluciones gratuitas con código abierto siempre es favorable y ventajoso. Aunque también existen dudas e inquietudes, ya que la garantía y el soporte no están vinculados con tecnologías de código abierto, le mostraremos aquí cómo lograrlo en un procedimiento sencillo.

Dado que Amazon RDS es compatible con MySQL y MariaDB. Nos centraremos en ellos para este blog.

Migración desde Amazon RDS para MySQL o MariaDB

Un enfoque típico para migrar sus datos de Amazon RDS a un servidor local es realizar una copia de seguridad mediante una copia lógica. Esto se puede hacer utilizando soluciones de utilidades de respaldo que sean compatibles para operar con Amazon RDS, que es un servicio completamente administrado. Los servicios de bases de datos totalmente administrados no ofrecen inicios de sesión SSH, por lo que la copia física de las copias de seguridad no es una opción.

Uso de mysqldump

El uso de mysqldump debe instalarse en el nodo de la base de datos de destino ubicado en las instalaciones. Debe prepararse como una réplica del nodo AWS RDS para que todas las transacciones posteriores se repliquen en el nodo. Para hacer esto, siga los pasos a continuación.

Host de origen de AWS RDS :base de datos-1.xxxxxxx.us-este-2.rds.amazonaws.com

Host de servidor local :192.168.10.226 (nodo de prueba26)

Antes de iniciar el volcado, asegúrese de que las horas de retención del binlog estén configuradas. Para configurarlo, puede hacer lo mismo que la siguiente llamada de procedimiento de ejemplo en su instancia de 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. Preparar el repositorio.

# 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 paquete de cliente mysql

# Para MySQL

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

# Para MariaDB

$ yum install -y MariaDB-client

  1. Cree un volcado de datos utilizando mysqldump ejecutándolo dentro del nodo de destino. Tome nota, con --master-data=2 especificado como una opción, esto funciona solo para MariaDB pero no en MySQL. Por lo tanto, se debe realizar un trabajo adicional para MySQL. Hablaremos de esto más tarde.

## Aplicable para el enfoque de 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. Instalar el servidor MySQL/MariaDB en el nodo de la base de datos de destino

# Para MySQL (siempre verifique qué versión del repositorio está habilitada en su repositorio de yum. En este punto, estoy usando 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 la instancia del servidor MySQL/MariaDB (my.cnf, permisos de archivo, directorios) e inicie el servidor 

# Configuración de my.cnf (usando el uso de implementación de my.cnf por parte de 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

## Restablezca el directorio de datos y vuelva a instalar los archivos del sistema de la base de datos

$ rm -rf /var/lib/mysql/*

## Crear los directorios de registro

$ mkdir /var/log/mysql

$ chown -R mysql.mysql /var/log/mysql

## Para MySQL

$ mysqld --initialize

## Para MariaDB

$ mysql_install_db

  1. Inicie el servidor MySQL/MariaDB

## Para MySQL

$ systemctl start mysqld

## Para MariaDB

$ systemctl start mariadb

  1. Cargar el volcado de datos que tomamos de AWS RDS al nodo de la base de datos de destino local

$ mysql --show-warnings < backups/dump.sql

  1. Cree el usuario de replicación desde el nodo de origen de 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. Configure el servidor MySQL/MariaDB como réplica/esclavo del nodo de origen de AWS RDS

## Primero, busquemos o ubiquemos el comando CAMBIAR MAESTRO

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

## Ejecute la declaración CHANGE MASTER pero agregue el usuario/contraseña de replicación y el nombre de host de la siguiente manera,

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)

## Luego inicie los subprocesos esclavos

MariaDB [(none)]> START SLAVE;

Query OK, 0 rows affected (0.001 sec)

## Verifique el estado del esclavo cómo va

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)

Ahora que finalmente hemos podido replicar desde RDS como fuente o maestro de nuestra réplica ubicada en las instalaciones. Aún no está hecho. Hay algunos casos en los que encontrará errores de replicación 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'

 Dado que on-prem no necesita replicar los datos provenientes de la base de datos mysql para las tablas con el prefijo 'rds%', simplemente ignoramos estas tablas durante la replicación. Además, es posible que no desee que AWS RDS actualice y cambie su tabla mysql.user. Para hacer esto, puede ignorar el esquema o simplemente la lista de tablas como,

STOP SLAVE;

Entonces,

SET GLOBAL replicate_wild_ignore_table='mysql.rds%';

o

SET GLOBAL replicate_wild_ignore_table='mysql.%';

El problema de MySQL con --master-data=2

Tomar mysqldump con --master-data=2 requiere privilegios suficientes, lo que requiere privilegios SUPER y RELOAD. El problema es que AWS RDS no proporciona esto para el usuario administrador durante la configuración y creación de la base de datos. Para solucionar este problema, debe ser que su AWS RDS tenga una configuración maestra y una réplica o esclava. Una vez que tenga una configuración esclava, tómela como el host de origen de destino cuando tome mysqldump. Luego, detenga los subprocesos esclavos de su réplica de AWS RDS de la siguiente manera:

rds-replica-mysql> CALL mysql.rds_stop_replication;

Luego tome mysqldump sin la opción --master-data como se muestra a continuación,

mysqldump -h database-1.xxxxxxx.us-east-2.rds.amazonaws.com -uadmin -p --single-transaction --databases db1 db2 db3  > backups/dump.sql

Luego, ejecute SHOW SLAVE STATUS\G desde su réplica de AWS RDS y tome nota de  Master_Log_File y Exec_Master_Log_Pos que usará cuando se conecte a la réplica principal de AWS RDS en su servidor local. Utilice esas coordenadas cuando ejecute CAMBIAR MAESTRO A… MASTER_LOG_FILE=Master_Log_File, MASTER_LOG_POS=. Eso sí, una vez realizada la copia de seguridad, no olvides iniciar tu réplica RDS para iniciar de nuevo sus hilos de replicación,

rds-replica-mysql> CALL mysql.rds_start_replication;

Uso de mydumper

mydumper puede ser su opción alternativa aquí, especialmente cuando el conjunto de datos es muy grande, ya que ofrece paralelismo y velocidad al realizar un volcado o una copia de respaldo de su conjunto de datos desde un nodo RDS de origen. Siga los pasos a continuación, desde instalar mydumper hasta cargarlo en su servidor local de destino.

  1. Instalar el binario. Los archivos binarios se pueden ubicar aquí 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. Tome la copia de seguridad del nodo de origen RDS. Por ejemplo,

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

Ahora, en este punto, mydumper tomará una copia de seguridad de los archivos en forma de archivos *.gz

  1. Cárguelo en su 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 el nodo de destino como esclavo/réplica. MyDumper incluirá un archivo llamado metadatos que consiste en coordenadas de registro binarios, incluidas las posiciones GTID, por ejemplo:

$ 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

## A continuación, ejecute un maestro de cambios desde la réplica o el nodo de la base de datos MySQL/MariaDB 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 el esclavo

MariaDB [jbmrcd_date]> start slave;

Query OK, 0 rows affected (0.001 sec)

En este punto, ya ha replicado desde una instancia de Amazon RDS que ejecuta MySQL/MariaDB. Una vez que su aplicación esté lista para alejarse de su instancia de Amazon RDS, configure el punto final para ir a su servidor local y todas las transacciones restantes de su instancia de RDS se replicarán en su local, sin que se pierda ningún dato que vaya a su servidor local. servidor prem.

Comprobar discrepancias de datos

Una vez que tenga sus datos cargados o volcados en su servidor local que actúa como una réplica de la instancia de AWS RDS, debe verificar esto dos veces ejecutando cálculos de suma de verificación para determinar qué tan lejos están sus datos con respecto a la origen Amazon RDS. Le sugiero que use la herramienta pt-table-checksum de Percona, pero puede crear la suya propia usando herramientas de suma de verificación como md5 o sha256, pero esto lleva tiempo. Además, el uso de pt-upgrade también puede ayudar después de realizar la migración de datos con este enfoque de replicación.

Conclusión

El uso de mysqldump o mydumper son herramientas gratuitas de código abierto, lo que también es una gran ventaja, especialmente si sus datos son muy confidenciales y no desea que un tercero acceda a ellos. Si bien puede ser simple adoptar este enfoque, puede haber un trabajo tedioso y extenso que puede involucrarse, ya que siempre se realizan pruebas y verificaciones dobles para demostrar que la migración se logra por completo sin inconsistencias en los datos.