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

Migración de Azure Database for MySQL/MariaDB a un servidor local

Las migraciones de bases de datos pueden imponer grandes desafíos cuando considera cómo comenzar, qué herramientas usar y cómo lograr una migración completa de la base de datos con éxito. Anteriormente, hemos enumerado los principales código abierto que puede usar en la migración para MySQL o MariaDB. En este blog, le mostraremos cómo migrar datos de Microsoft Azure Database para MySQL o MariaDB.

Ahora se sabe que Microsoft Azure es un competidor contra los otros dos gigantes tecnológicos de la nube:AWS y Google Cloud. Se especializa más en sus productos de Microsoft, especialmente en su base de datos propietaria MSSQL de cosecha propia. Pero no solo eso, también tiene fuentes abiertas como una de sus bases de datos de servicios completamente administradas para ofrecer públicamente. Entre sus bases de datos soportadas se encuentran MySQL y MariaDB.

Salir de Azure Database for MySQL/MariaDB puede ser tedioso, pero depende del tipo de arquitectura y del tipo de conjunto de datos que haya alojado en su Azure como su proveedor de nube actual. Con las herramientas adecuadas, se puede lograr y se puede realizar una migración completa.

Nos centraremos en las herramientas que podemos usar para migraciones de datos en MySQL o MariaDB. Para este blog, estoy usando RHEL/CentOS para instalar los paquetes necesarios. Repasemos y definamos los pasos y procedimientos sobre cómo hacer esto.

Migración desde Azure Database para MySQL o MariaDB

Un enfoque típico para migrar sus datos de Azure Database a un servidor local es realizar una copia de seguridad mediante una copia lógica. Esto se puede hacer usando soluciones de utilidades de respaldo que sean compatibles para operar con Azure Database for MySQL o MariaDB, 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.

Antes de poder migrar o volcar su base de datos existente desde Azure, debe tomar nota de las siguientes consideraciones.

Casos de uso comunes para volcado y restauración local

Los casos de uso más comunes son:

  • Usar una copia de seguridad lógica (como mysqldump, mysqlpump o mydumper/myloader) y restaurar es la única opción. Azure Database for MySQL o MariaDB no admite el acceso físico al almacenamiento físico, ya que se trata de un servicio de base de datos totalmente administrado.
  • Solo admite motores de almacenamiento de memoria e InnoDB. Migración de motores de almacenamiento alternativos a InnoDB. Azure Database for MySQL o MariaDB solo admite el motor de almacenamiento InnoDB y, por lo tanto, no admite motores de almacenamiento alternativos. Si sus tablas están configuradas con otros motores de almacenamiento, conviértalas al formato del motor InnoDB antes de la migración a Azure Database for MySQL.
  • Por ejemplo, si tiene WordPress o una aplicación web que usa las tablas MyISAM, primero convierta esas tablas migrando al formato InnoDB antes de restaurar a Azure Database for MySQL. Utilice la cláusula ENGINE=InnoDB para configurar el motor utilizado al crear una nueva tabla, luego transfiera los datos a la tabla compatible antes de la restauración.
  • Si su base de datos Azure de origen está en una versión específica, entonces su servidor local de destino también ha sido la misma versión que la base de datos Azure de origen.

Entonces, con estas limitaciones, solo espera que sus datos de Azure tengan que ser el motor de almacenamiento InnoDB o la memoria, si existe tal en su conjunto de datos.

Consideraciones de rendimiento para realizar una copia de seguridad lógica de la base de datos de Azure

La única forma de realizar una copia de seguridad lógica con Azure es usar mysqldump o mysqlpump. Para optimizar el rendimiento al realizar un volcado con estas herramientas, tenga en cuenta estas consideraciones al volcar bases de datos de gran tamaño:

  • Utilice la opción de exclusión de activadores en mysqldump al volcar bases de datos. Excluya los activadores de los archivos de volcado para evitar que se activen los comandos de activación durante la restauración de datos.
  • Utilice la opción de transacción única para establecer el modo de aislamiento de transacción en LECTURA REPETIBLE y envíe una declaración SQL de INICIO DE TRANSACCIÓN al servidor antes de volcar los datos. Volcar muchas tablas dentro de una sola transacción hace que se consuma algo de almacenamiento adicional durante la restauración. La opción de transacción única y la opción de tablas de bloqueo se excluyen mutuamente porque LOCK TABLES hace que las transacciones pendientes se confirmen implícitamente. Para volcar tablas grandes, combine la opción de transacción única con la opción rápida.
  • Use la sintaxis de varias filas de inserción extendida que incluye varias listas de VALUE. Esto da como resultado un archivo de volcado más pequeño y acelera las inserciones cuando se vuelve a cargar el archivo.
  • Utilice la opción order-by-primary en mysqldump cuando descargue bases de datos, de modo que los datos se escriban en orden de clave principal.
  • Utilice la opción deshabilitar claves en mysqldump cuando descargue datos, para deshabilitar las restricciones de clave externa antes de la carga. La desactivación de las comprobaciones de clave externa proporciona mejoras de rendimiento. Habilite las restricciones y verifique los datos después de la carga para garantizar la integridad referencial.
  • Utilice tablas particionadas cuando corresponda.
  • Cargar datos en paralelo. Evite demasiado paralelismo que le haría alcanzar un límite de recursos y supervise los recursos con las métricas disponibles en Azure Portal.
  • Utilice la opción defer-table-indexes en mysqlpump cuando descargue bases de datos, para que la creación del índice ocurra después de cargar los datos de la tabla.
  • Utilice la opción skip-definer en mysqlpump para omitir el definidor y las cláusulas SQL SECURITY de las declaraciones de creación para vistas y procedimientos almacenados. Cuando vuelve a cargar el archivo de volcado, crea objetos que utilizan los valores predeterminados DEFINER y SQL SECURITY.
  • Copie los archivos de copia de seguridad en un blob/almacén de Azure y realice la restauración desde allí, lo que debería ser mucho más rápido que realizar la restauración a través de Internet.

No compatible

Lo siguiente no es compatible:

  • Rol de DBA:Restringido. Alternativamente, puede usar el usuario administrador (creado durante la creación del nuevo servidor), que le permite realizar la mayoría de las declaraciones DDL y DML.
  • Privilegio SUPER:Del mismo modo, el privilegio SUPER está restringido.
  • DEFINITOR:Requiere súper privilegios para crear y está restringido. Si importa datos usando una copia de seguridad, elimine los comandos CREATE DEFINER manualmente o usando el comando --skip-definer cuando realice un mysqldump.
  • Bases de datos del sistema:la base de datos del sistema mysql es de solo lectura y se utiliza para admitir diversas funciones de PaaS. No puede realizar cambios en la base de datos del sistema mysql.
  • SELECCIONAR... EN OUTFILE:No compatible con el servicio.

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 de Azure Database para que todas las transacciones posteriores se repliquen en el nodo. Para hacer esto, siga los pasos a continuación.

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.

$ MYSQL_PWD=<YOUR_MYSQL_PASS> mysqldump -h<YOUR_AZURE_DB_HOSTNAME>  -u<YOUR_AZURE_USERNAME> --single-transaction --master-data=2 --extended-insert --order-by-primary --disable-keys --databases maximusdb db2 db3 > backups/dump.sql

  1. Instalar el servidor MySQL/MariaDB en el nodo de la base de datos de destino

# Para MySQL

$  yum install mysql-community-server.x86_64 mysql-community-client mysql-community-common

# Para MariaDB

$ yum install MariaDB-server.x86_64

  1. Configure la instancia del servidor MySQL/MariaDB (my.cnf, permisos de archivos, 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 hemos tomado de Azure Database al nodo de la base de datos de destino local

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

  1. Cree el usuario de replicación desde su nodo de origen de Azure Database

CREATE USER 'repl_user'@'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO [email protected]'<your-target-node-ip>' IDENTIFIED BY 'repl_passw0rd';

Asegúrese de cambiar la dirección IP de su nodo de destino como el cliente desde el que conectarse.

  1. Configure el servidor MySQL/MariaDB como réplica/esclavo del nodo de origen de la base de datos de Azure

## Primero, busquemos o ubiquemos el comando CAMBIAR MAESTRO

$ grep -rn -E -i 'change master to master' backups/dump.sql |head -1

22:-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610;

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

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=2938610, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## En algunos casos, es posible que deba ignorar el esquema mysql. Ejecute la siguiente instrucción:

SET GLOBAL replicate_wild_ignore_table='mysql.%';

## Luego inicie los subprocesos esclavos

START SLAVE;

## Verifique el estado del esclavo cómo va

SHOW SLAVE STATUS \G

Ahora que finalmente hemos podido replicar desde Azure Database para MySQL/MariaDB como la fuente de su réplica ubicada localmente.

Uso de mydumper

Azure Database para MySQL o MariaDB de hecho sugiere que usar mydumper especialmente para copias de seguridad grandes como 1 TB puede ser su opción alternativa. Ofrece paralelismo y velocidad al realizar un volcado o una copia de seguridad de su conjunto de datos desde un nodo de Azure Database de origen.

 Siga los pasos a continuación desde la instalación de mydumper hasta la carga 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 de Azure Database. Por ejemplo,

[[email protected] mydumper]# MYSQL_PWD=<YOUR_AZURE_DB_PASSWORD> /usr/bin/mydumper --outputdir=. --verbose=3 --host=<YOUR_AZURE_DB_HOSTNAME>  -u <YOUR_AZURE_USER>@<YOUR_AZURE_DB_HOSTNAME> --port=3306 --kill-long-queries --chunk-filesize=5120 --build-empty-files --events --routines --triggers --compress --less-locking --success-on-1146 --regex='(maximusdb\.|db1\.|db2\.)'

** Message: Connected to a MySQL server

** Message: Using Percona Backup Locks



** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

** Message: Started dump at: 2020-10-26 01:34:05



** Message: Written master status

** Message: Multisource slave detected.

** Message: Thread 5 connected using MySQL connection ID 64315

** Message: Thread 6 connected using MySQL connection ID 64345

** Message: Thread 7 connected using MySQL connection ID 64275

** Message: Thread 8 connected using MySQL connection ID 64283

** Message: Thread 1 connected using MySQL connection ID 64253

** Message: Thread 2 connected using MySQL connection ID 64211

** Message: Thread 3 connected using MySQL connection ID 64200

** Message: Thread 4 connected using MySQL connection ID 64211



** (mydumper:28829): CRITICAL **: Error: DB: mysql - Could not execute query: Access denied for user 'mysqldbadmin'@'%' to database 'mysql'

** Message: Thread 5 shutting down

** Message: Thread 6 shutting down

** Message: Thread 7 shutting down

** Message: Thread 8 shutting down

** Message: Thread 1 dumping data for `db1`.`TB1`

** Message: Thread 2 dumping data for `db1`.`tb2

….

Como puede ver, existe una limitación para realizar copias de seguridad desde una base de datos administrada como Azure. Podrías notar,

** (mydumper:28829): CRITICAL **: Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG FOR BACKUP' at line 1

Esto se debe a que SUPER PRIVILEGE no es compatible o está restringido. Idealmente, la mejor opción para hacer esto es tomar la copia de seguridad de una réplica de su base de datos de Azure. Hablaremos de esto más tarde.

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 `maximusdb`

** Message: Creating table `maximusdb`.`usertbl`

** Message: Creating table `maximusdb`.`familytbl`

** Message: Creating table `db2`.`t1`

** Message: Creating table `db3`.`test1`

…

….

  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-26 01:35:12

SHOW MASTER STATUS:

        Log: mysql-bin.000007

        Pos: 801

        GTID:0-3649485694-1705



Finished dump at: 2020-10-26 01:37:12

## A continuación, ejecute un maestro de cambios desde la réplica o el nodo de la base de datos MySQL/MariaDB de destino

CHANGE MASTER TO MASTER_HOST='<YOUR_AZURE_DB_HOSTNAME>', MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=801, MASTER_USER='repl_user', MASTER_PASSWORD='repl_passw0rd';

## Inicie el esclavo

START SLAVE;

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

Limitaciones de manejo con bases de datos administradas para MySQL o MariaDB en Azure

Lidiar con las limitaciones, especialmente cuando se realiza un volcado de respaldo de su conjunto de datos, debe ser 100 % preciso desde el momento en que se realizó el volcado de respaldo. Por supuesto, esta es una migración ideal para su entorno local. Para lidiar con esto, la mejor configuración de arquitectura es tener una presencia de topología de replicación en su base de datos de Azure.

Una vez que lo tenga y esté listo para la migración, mysqldump/mysqlpump o mydumper tiene que usar la réplica de Azure Database como fuente. Dentro de esa réplica de Azure Database, asegúrese de que SQL_THREAD esté detenido para que pueda tomar una instantánea o registrar el MASTER_LOG_FILE y EXEC_MASTER_LOG_POS correctos del resultado de SHOW SLAVE STATUS.

Por supuesto, una vez realizada la copia de seguridad, no olvide iniciar su réplica de Azure Database para iniciar sus subprocesos de replicación nuevamente.

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 la base de datos de Azure, debe verificar esto dos veces ejecutando cálculos de suma de verificación para determinar qué tan lejos están sus datos contra el origen de la base de datos de Azure. Le sugerimos que use la herramienta pt-table-checksum de Percona Toolkit, pero puede crear la suya propia utilizando herramientas de suma de verificación como md5 o sha256, pero esto lleva tiempo. Además, el uso de pt-upgrade de Percona Toolkit también puede ayudar después de realizar la migración de datos con este enfoque de replicación.

Conclusión

Las limitaciones de privilegios y los tipos no admitidos de Azure Database pueden ser un desafío, pero con el flujo y la arquitectura adecuados, no es imposible migrar desde una base de datos totalmente administrada en las instalaciones. Todo lo que necesita hacer es preparar los pasos requeridos, configurar la topología requerida desde su fuente de Azure Database, luego comenzar la migración desde la realización de copias de seguridad hasta la replicación y la migración total a su entorno local.