# Importación de datos en una instancia de base de datos de Amazon RDS para MariaDB
Puede utilizar varias técnicas diferentes para importar datos en una instancia de base de datos de RDS for MariaDB. El mejor enfoque depende de varios factores:
+ Origen de los datos
+ Cantidad de datos
+ Importar una vez o de forma continua
+ Cantidad de tiempo de inactividad
Si también está migrando una aplicación con los datos, es importante tener en cuenta la cantidad de tiempo de inactividad.
En la siguiente tabla se muestran técnicas para importar datos en una instancia de base de datos de RDS para MariaDB:
**nota**
Amazon RDS no admite `mariadb-backup` o importación desde Amazon S3 para MariaDB.
| Origen | Cantidad de datos | Una vez o continua | Tiempo de inactividad de las aplicaciones | Técnica | Más información |
| --- | --- | --- | --- | --- | --- |
| Base de datos de MariaDB existente en las instalaciones o en Amazon EC2 | Cualquiera | Continuo | Minimal | Configure la replicación con una base de datos de MariaDB existente como origen de replicación. Puede configurar la replicación en una instancia de base de datos de MariaDB mediante el uso de identificadores de transacciones globales (GTID) de MariaDB cuando la instancia externa sea de la versión 10.0.24 o posterior de MariaDB, o mediante coordenadas de registro binario para las instancias de MariaDB en versiones anteriores a 10.0.24. Los identificadores de transacciones globales (GTID) de MariaDB se implementan de un modo distinto al de los GTID de MySQL, que no son compatibles con Amazon RDS. | [Configuración de la replicación de posición de archivo de registro binario con una instancia de origen externa](MySQL.Procedural.Importing.External.ReplMariaDB.md) [Importación de datos a una instancia de base de datos de Amazon RDS para MariaDB con tiempo de inactividad reducido](mariadb-importing-data-reduced-downtime.md) |
| Cualquier base de datos existente | Cualquiera | Una vez o continua | Mínima | Utilizar AWS Database Migration Service para migrar la base de datos con un tiempo de inactividad mínimo y, para numerosos motores de base de datos, continuar las replicaciones en curso. | [Qué es AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) y [Uso de una base de datos compatible con MySQL como destino para AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html) en la *Guía del usuario de AWS Database Migration Service* |
| Instancia de base de datos de MariaDB existente | Cualquiera | Una vez o continua | Mínima | Cree una réplica de lectura para la replicación continua. Promocione la réplica de lectura para la creación única de una nueva instancia de base de datos. | [Trabajo con réplicas de lectura de instancias de base de datos](USER_ReadRepl.md) |
| Base de datos existente de MariaDB | Pequeña | Una vez | Alguno | Copie los datos directamente en la instancia de base de datos de MariaDB con una utilidad de línea de comandos. | [Importación de datos de una base de datos de MariaDB externa a una instancia de base de datos de Amazon RDS para MariaDB](mariadb-importing-data-external-database.md) |
| Datos no almacenados en una base de datos existente | Media | Una vez | Alguno | Cree archivos sin formato e impórtelos con instrucciones `LOAD DATA LOCAL INFILE` de MariaDB. | [Importación de datos de cualquier origen a una instancia de base de datos de Amazon RDS para MariaDB](mariadb-importing-data-any-source.md) |
**nota**
La base de datos del sistema `mysql` contiene la información de autenticación y autorización necesaria para iniciar sesión en la instancia de base de datos y obtener acceso a los datos. La eliminación, la modificación, el cambio de nombre o el truncamiento de tablas, datos u otros contenidos de la base de datos `mysql` de la instancia de base de datos puede provocar errores e impedir el acceso a la instancia de base de datos y a los datos. En ese caso, puede restaurar la instancia de base de datos desde una instantánea con el comando [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) de la AWS CLI. Puede recuperar la instancia de base de datos con el comando [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html).
# Consideraciones sobre la importación de datos para MariaDB
En el siguiente contenido se encuentra información técnica relacionada con la carga de datos en MariaDB. Este contenido está dirigido a usuarios familiarizados con la arquitectura del servidor de MariaDB.
## Registro binario
La habilitación del registro binario reduce el rendimiento de la carga de datos y requiere hasta cuatro veces más espacio en disco en comparación con el registro desactivado. El tamaño de la transacción utilizado para cargar los datos afecta directamente al rendimiento del sistema y a las necesidades de espacio en disco; las transacciones más grandes requieren más recursos.
## Tamaño de la transacción
El tamaño de la transacción influye en los siguientes aspectos de las cargas de datos de MariaDB:
+ Consumo de recursos
+ Utilización del espacio en disco
+ Reanudación del proceso
+ Tiempo de recuperación
+ Formato de entrada (archivos sin formato o SQL)
En esta sección se describe el modo en que el tamaño de transacción afecta al registro binario y se argumentan los beneficios de desactivar el registro binario durante la carga de grandes volúmenes de datos. Puede habilitar y desactivar el registro binario estableciendo el periodo de retención de copia de seguridad automatizado de Amazon RDS. Un valor distinto de cero activa el registro binario y el valor cero lo desactiva. Para obtener más información, consulte [Backup retention period](USER_WorkingWithAutomatedBackups.BackupRetention.md).
En esta sección también se describe el impacto de las transacciones de gran tamaño en InnoDB y por qué es importante que los tamaños de transacción sean pequeños.
### Transacciones pequeñas
En las transacciones pequeñas, el registro binario duplica el número de escrituras en disco requeridas para cargar los datos. Este efecto puede degradar el desempeño notablemente en otras sesiones de base de datos y aumentar el tiempo requerido para cargar los datos. La degradación experimentada depende en parte de los siguientes factores:
+ Tasa de carga
+ Otra actividad de la base de datos que tenga lugar durante la carga
+ Capacidad de la instancia de base de datos de Amazon RDS
Los registros binarios también consumen un espacio en disco aproximadamente igual al volumen de datos cargado hasta que se hace una copia de seguridad de los registros y se eliminan. Amazon RDS minimiza este impacto creando copias de seguridad de los registros binarios y retirándolos con frecuencia.
### Transacciones grandes
En el caso de transacciones grandes, el registro binario triplica IOPS y el uso del disco por los siguientes motivos:
+ La caché del registro binario almacena temporalmente los datos de las transacciones en el disco.
+ Esta caché crece con el tamaño de la transacción, lo que consume espacio en disco.
+ Cuando se completa la transacción (confirmación o reversión), el sistema copia la caché en el registro binario.
Este proceso crea tres copias de los datos:
+ Los datos originales
+ La caché en el disco
+ La entrada del registro binario final
Cada operación de escritura implica una E/S adicional, lo que repercute aún más en el rendimiento.
Por este motivo, el registro binario requiere el triple de espacio en disco en comparación con el registro desactivado. Por ejemplo, si se cargan 10 GiB de datos en una sola transacción, se crean tres copias:
+ 10 GiB para los datos de la tabla
+ 10 GiB para la caché del registro binario
+ 10 GiB para el archivo del registro binario
El espacio total en disco temporal necesario es 30 GiB.
Consideraciones importantes sobre el espacio en disco:
+ El archivo de caché persiste hasta que finaliza la sesión o hasta que una nueva transacción crea otra caché.
+ El registro binario permanece hasta que se realiza una copia de seguridad, lo que podría retener 20 GiB (caché y registro) durante un periodo prolongado.
Si se usa `LOAD DATA LOCAL INFILE` para cargar los datos, la recuperación de datos crea una cuarta copia en caso de que la base de datos deba recuperarse desde una copia de seguridad realizada antes de la carga. Durante la recuperación, MariaDB extrae los datos desde el registro binario en un archivo sin formato. Luego, MariaDB ejecuta `LOAD DATA LOCAL INFILE`. En función del ejemplo anterior, esta recuperación requiere un espacio total en disco temporal de 40 GiB o 10 GiB cada uno para la tabla, la caché, el registro y el archivo local. Sin al menos 40 GiB de espacio libre en disco, la recuperación produce un error.
### Optimización de grandes cargas de datos
Para grandes cargas de datos, desactive el registro binario para reducir la sobrecarga y los requisitos de espacio en disco. Puede desactivar el registro binario estableciendo el periodo de retención de copias de seguridad en 0. Una vez completada la carga, restaure el periodo de retención de copias de seguridad al valor apropiado distinto de cero. Para obtener más información, consulte [Modificación de una instancia de base de datos de Amazon RDS](Overview.DBInstance.Modifying.md) y [Periodo de retención de copia de seguridad](USER_ModifyInstance.Settings.md) en la tabla de configuración.
**nota**
Si la instancia de base de datos es una instancia de base de datos de origen para réplicas de lectura, no puede establecer el periodo de retención de copia de seguridad en 0.
Antes de cargar los datos, recomendamos que cree una instantánea de base de datos. Para obtener más información, consulte [Administración de copias de seguridad manuales](USER_ManagingManualBackups.md).
## InnoDB
La siguiente información sobre las opciones de registro de reversión y recuperación ayuda a mantener pequeñas las transacciones de InnoDB para optimizar el rendimiento de la base de datos.
### Descripción del registro de reversión de InnoDB
La reversión es un mecanismo de registro que permite la reversión de transacciones y admite el control de concurrencia multiversión (MVCC).
Para MariaDB 10.11 y versiones anteriores, los registros de reversión se almacenan en el espacio de tablas del sistema InnoDB (normalmente ibdata1) y se retienen hasta que el subproceso de purga los elimina. De este modo, las transacciones de carga de datos de gran tamaño pueden provocar que el espacio de tablas del sistema sea muy grande y consumir espacio en disco que no puede recuperar si no recrea la base de datos.
Para todas las versiones de MariaDB, el subproceso de purga debe esperar para eliminar cualquier registro de reversión hasta que la transacción activa más antigua se confirme o se revierta. Si la base de datos procesa otras transacciones durante la carga, los registros de reversión también se acumulan y no pueden eliminarse, incluso si se confirman las transacciones y ninguna otra transacción necesita registros de reversión para MVCC. En esta situación, todas las transacciones, incluidas las de solo lectura, se ralentizan. Esta ralentización se produce porque todas las transacciones acceden a todas las filas que cualquier transacción (no solo la transacción de carga) cambia. En efecto, las transacciones deben examinar los registros de reversión que las transacciones de carga de larga duración impidieron purgar durante una limpieza del registro de reversión. Esto afecta al rendimiento de cualquier operación que acceda a las filas modificadas.
### Opciones de recuperación de transacciones de InnoDB
Aunque InnoDB optimiza las operaciones de confirmación, las reversiones de transacciones grandes son lentas. Para una recuperación más rápida, realice una recuperación en un momento dado o restaure una instantánea de base de datos. Para obtener más información, consulte [Recuperación a un momento dado](USER_PIT.md) y [Restauración a una instancia de base de datos](USER_RestoreFromSnapshot.md).
## Formatos de importación de datos
MariaDB admite dos formatos de importación de datos: archivos sin formato y SQL. Revise la información sobre cada formato para determinar cuál es la mejor opción para sus necesidades.
### Archivos sin formato
Para transacciones pequeñas, cargue archivos sin formato con `LOAD DATA LOCAL INFILE`. Este formato de importación de datos puede proporcionar los siguientes beneficios en comparación con el uso de SQL:
+ Menos tráfico de red
+ Costos de transmisión de datos más bajos
+ Menor sobrecarga de procesamiento de bases de datos
+ Procesamiento más rápido
`LOAD DATA LOCAL INFILE` carga todo el archivo sin formato en una sola transacción. Mantenga pequeño el tamaño de los archivos individuales para obtener las siguientes ventajas:
+ **Posibilidad de reanudación**: puede hacer un seguimiento de los archivos que se han cargado. Si surge un problema durante la carga, puede continuar donde se detuvo. Es posible que sea necesario volver a transmitir algunos datos a Amazon RDS, pero con los archivos pequeños, el volumen es mínimo.
+ **Carga de datos en paralelo**: si tiene IOPS y ancho de banda de la red suficiente para la carga de un solo archivo, la carga en paralelo podría ahorrar tiempo.
+ **Control de la velocidad de carga**: si la carga de datos tiene un impacto negativo en otros procesos, puede controlar la velocidad de carga aumentando el intervalo entre los archivos.
Las transacciones de gran tamaño reducen los beneficios de usar `LOAD DATA LOCAL INFILE` para importar datos. Cuando no pueda dividir una gran cantidad de datos en archivos más pequeños, considere la posibilidad de utilizar SQL.
### SQL
SQL tiene una ventaja fundamental con respecto a los archivos sin formato: puede mantener pequeños los tamaños de transacción. Sin embargo, SQL puede tardar mucho más en cargar que los archivos sin formato. Además, después de un error, puede ser difícil determinar dónde reanudar, ya que no se pueden reiniciar los archivos mariadb-dump. Si se produce un error durante la carga de un archivo mariadb-dump, debe modificarlo o sustituirlo antes de poder reanudar la carga. De forma alternativa, después de corregir la causa del error, puede restaurar a un momento anterior a la carga antes de cargar y volver a enviar el archivo. Para obtener más información, consulte [Recuperación a un momento dado](USER_PIT.md).
## Uso de instantáneas de base de datos de Amazon RDS para puntos de comprobación de la base de datos
Si carga datos durante periodos prolongados, como horas o días, sin registro binario, utilice las instantáneas de base de datos para proporcionar puntos de comprobación periódicos para garantizar la seguridad de los datos. Cada instantánea de base de datos crea una copia coherente de la instancia de base de datos que sirve como punto de recuperación durante errores del sistema o eventos de corrupción de datos. Como las instantáneas de base de datos son rápidas, los puntos de comprobación frecuentes tienen un impacto mínimo en el rendimiento de la carga. Puede eliminar las instantáneas de base de datos anteriores sin que ello afecte a la durabilidad de la base de datos ni a las capacidades de recuperación. Para obtener más información acerca de las instantáneas de base de datos, consulte [Administración de copias de seguridad manuales](USER_ManagingManualBackups.md).
## Reducción de los tiempos de carga de bases de datos
Los siguientes elementos son consejos adicionales para reducir los tiempos de carga:
+ Cree todos los índices secundarios antes de cargar los datos en las bases de datos MariaDB. A diferencia de otros sistemas de bases de datos, MariaDB reconstruye toda la tabla al agregar o modificar índices secundarios. Este proceso crea una nueva tabla con los cambios de índice, copia todos los datos y elimina la tabla original.
+ Cargue los datos en el orden de la clave principal. Para las tablas de InnoDB, esto puede reducir los tiempos de carga entre un 75 % y un 80 % y reducir el tamaño del archivo de datos en un 50 %.
+ Desactive las restricciones de clave externa estableciendo `foreign_key_checks` en `0`. Esto es obligatorio en muchos casos para archivos sin formato cargados con `LOAD DATA LOCAL INFILE`. Para cualquier carga, desactivar las comprobaciones de claves externas acelera la carga de datos. Una vez completada la carga, vuelva a habilitar las restricciones configurando `foreign_key_checks` en `1` y verifique los datos.
+ Cargue datos en paralelo a no ser que se aproxime al límite de los recursos. Para habilitar la carga simultánea en varios segmentos de la tabla, use tablas particionadas cuando sea apropiado.
+ Para reducir la sobrecarga de ejecución de SQL, combine varias instrucciones `INSERT` en operaciones `INSERT` únicas con varios valores. `mariadb-dump` implementa esta optimización automáticamente.
+ Reduzca las operaciones de E/S de registro de InnoDB estableciendo `innodb_flush_log_at_trx_commit` en `0`. Una vez completada la carga, restaure `innodb_flush_log_at_trx_commit` a `1`.
**aviso**
Si se establece `innodb_flush_log_at_trx_commit` en `0`, InnoDB vaciará sus registros cada segundo en lugar de hacerlo con cada confirmación. Esta configuración aumenta el rendimiento, pero puede conllevar el riesgo de perder transacciones si se produce un error en el sistema.
+ Si va a cargar datos en una instancia de base de datos que no tiene réplicas de lectura, establezca `sync_binlog` en `0`. Una vez completada la carga, restaure `sync_binlog parameter` a `1`.
+ Cargue los datos en una instancia de base de datos de Single-AZ antes de convertir la instancia de base de datos en una implementación Multi-AZ. Si la instancia de base de datos ya usa una implementación Multi-AZ, no se recomienda cambiar a una implementación Single-AZ para la carga de datos. Hacerlo solo proporciona mejoras marginales
# Importación de datos de una base de datos de MariaDB externa a una instancia de base de datos de Amazon RDS para MariaDB
Puede importar datos desde una base de datos de MariaDB existente a una instancia de base de datos de RDS para MariaDB. Esto se lleva a cabo copiando la base de datos con [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) o [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/) y canalizándola de forma directa en la instancia de base de datos de RDS para MariaDB. La utilidad de línea de comandos `mysqldump` o `mariadb-dump` suele utilizarse para crear copias de seguridad y transferir datos de un servidor de MariaDB a otro. Se incluye con el software de cliente de MariaDB.
A partir de MariaDB 11.0.1, debe usar `mariadb-dump` en lugar de `mysqldump`.
Un comando `mysqldump` típico para mover datos de una base de datos externa a una instancia de base de datos de Amazon RDS tiene el aspecto del ejemplo siguiente. Sustituya valores con su propia información. Para MariaDB 11.0.1 y versiones posteriores, sustituya `mysqldump` por `mariadb-dump`.
```
mysqldump -u local_user \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u RDS_user \
--port=port_number \
--host=host_name \
-pRDS_password
```
**importante**
Asegúrese de no dejar un espacio entre la opción `-p` y la contraseña especificada.
Como práctica recomendada de seguridad, especifique credenciales distintas de las que se muestran en este ejemplo.
Asegúrese de conocer las siguientes recomendaciones y consideraciones:
+ Excluya los siguientes esquemas del archivo de volcado:
+ `sys`
+ `performance_schema`
+ `information_schema`
La utilidad `mysqldump` y `mariadb-dump` excluye estos esquemas de forma predeterminada.
+ Si necesita migrar usuarios y privilegios, considere la posibilidad de usar una herramienta que genere el lenguaje de control de datos (DCL) para volver a crearlos, como la utilidad [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html).
+ Para realizar la importación, asegúrese de que el usuario que lo haga tenga acceso a la instancia de base de datos. Para obtener más información, consulte [Control de acceso con grupos de seguridad](Overview.RDSSecurityGroups.md).
Los parámetros son los siguientes:
+ `-u local_user`: use este parámetro para especificar un nombre de usuario. La primera vez que utilice este parámetro, especifique el nombre de una cuenta de usuario en la base de datos de MariaDB local que identifique con el parámetro `--databases`.
+ `--databases database_name`: use para especificar el nombre de la base de datos en la instancia de MariaDB local que desea importar a Amazon RDS.
+ `--single-transaction`: use este parámetro para asegurarse de que todos los datos cargados desde la base de datos local sean coherentes en un momento determinado. Si hay otros procesos que modifican los datos mientras `mysqldump` o `mariadb-dump` los lee, el uso de este parámetro ayuda a mantener la integridad de los datos.
+ `--compress`: use este parámetro para reducir el consumo de ancho de banda mediante la compresión de los datos de la base de datos local antes de su envío a Amazon RDS.
+ `--order-by-primary`: use este parámetro para reducir el tiempo de carga mediante la ordenación de los datos de cada tabla según su clave primaria.
+ `--routines`: úselo si existen rutinas como procedimientos almacenados o funciones en la base de datos que está copiando. Establezca el parámetro en `0`, lo que excluye las rutinas durante el proceso de importación. Después, vuelva a crear manualmente las rutinas en la base de datos de Amazon RDS.
+ `--triggers`: úselo si existen desencadenadores en la base de datos que va a copiar. Establezca el parámetro en `0`, lo que excluye los desencadenadores durante el proceso de importación. Después, vuelva a crear manualmente los desencadenadores en la base de datos de Amazon RDS.
+ `--events`: úselo si existen eventos en la base de datos que está copiando. Establezca el parámetro en `0`, lo que excluye los eventos durante el proceso de importación. Después, vuelva a crear manualmente los eventos en la base de datos de Amazon RDS.
+ `-plocal_password`: use este parámetro para especificar una contraseña. La primera vez que use este parámetro, especifique la contraseña de la cuenta de usuario identificada con el primer parámetro `-u`.
+ `-u RDS_user`: use este parámetro para especificar un nombre de usuario. La segunda vez que utilice este parámetro, especifique el nombre de una cuenta de usuario en la base de datos predeterminada de la instancia de base de datos de MariaDB identificada con el parámetro `--host`.
+ `--port port_number`: use para especificar el puerto de la instancia de base de datos de MariaDB. El valor predeterminado es 3306, salvo que se haya cambiado al crear la instancia de base de datos.
+ `--host host_name` – se utiliza para especificar el nombre del sistema de nombres de dominio (DNS) del punto de conexión de la instancia de base de datos de Amazon RDS, por ejemplo, `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Puede encontrar el valor del punto de conexión en los detalles de la instancia de base de datos en la consola de Amazon RDS.
+ `-pRDS_password`: use este parámetro para especificar una contraseña. La segunda vez que use este parámetro, debe especificar la contraseña de la cuenta de usuario identificada por el segundo parámetro `-u`.
Asegúrese de crear de forma manual procedimientos almacenados, desencadenadores, funciones o eventos en su base de datos de Amazon RDS. Si hay alguno de estos objetos en la base de datos que va a copiar, exclúyalo cuando ejecute `mysqldump` o `mariadb-dump`. Para hacerlo, incluya los siguientes parámetros con el comando `mysqldump` o `mariadb-dump`:
+ `--routines=0`
+ `--triggers=0`
+ `--events=0`
**Ejemplo**
En el siguiente ejemplo se copia la base de datos de ejemplo `world` del host local en una instancia de base de datos de RDS para MariaDB. Sustituya valores con su propia información.
Para Linux, macOS o Unix:
```
sudo mariadb-dump -u local_user \
--databases world \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u rds_user \
--port=3306 \
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com \
-pRDS_password
```
Para Windows:
Ejecute el siguiente comando en un símbolo del sistema que se haya abierto con un clic con el botón derecho en **Símbolo del sistema** del menú de programas de Windows y con la selección de **Ejecutar como administrador**. Sustituya valores con su propia información.
```
mariadb-dump -u local_user ^
--databases world ^
--single-transaction ^
--compress ^
--order-by-primary ^
--routines=0 ^
--triggers=0 ^
--events=0 ^
-plocal_password | mariadb -u RDS_user ^
--port=3306 ^
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^
-pRDS_password
```
**nota**
Como práctica recomendada de seguridad, especifique credenciales distintas de las que se muestran en el ejemplo.
# Importación de datos a una instancia de base de datos de Amazon RDS para MariaDB con tiempo de inactividad reducido
En algunos casos, es posible que tenga que importar datos de una base de datos MariaDB externa que admite una aplicación en directo a una instancia de base de datos de RDS para MariaDB. Utilice el siguiente procedimiento para minimizar el impacto en la disponibilidad de las aplicaciones. Este procedimiento también puede resultar útil al trabajar con una base de datos de gran tamaño. Con este procedimiento, puede reducir el coste de la importación al reducir la cantidad de datos que se transfieren a través de la red a AWS.
En el procedimiento, se transfiere primero una copia de los datos de la base de datos a una instancia de Amazon EC2 y después se importan los datos a una nueva base de datos de Amazon RDS. A continuación, se usa la replicación para actualizar la base de datos de Amazon RDS al estado de la instancia externa activa, antes de redirigir la aplicación a la base de datos de Amazon RDS. Si la instancia externa es MariaDB 10.0.24 o superior y la instancia de destino es RDS para MariaDB, configure la replicación de MariaDB en función de los identificadores de transacción globales (GTID). De lo contrario, debe configurar la replicación en función de las coordenadas de los registros binarios. Si la base de datos externa la admite, recomendamos la replicación basada en GTID porque es un método más fiable. Para obtener más información, consulte [Global Transaction ID](http://mariadb.com/kb/en/mariadb/global-transaction-id/) en la documentación de MariaDB.
El siguiente diagrama muestra la importación de una base de datos de MariaDB externa a una base de datos de MariaDB en Amazon RDS.
![\[Flujo de trabajo que muestra la importación de una base de datos de MariaDB externa a una base de datos de MariaDB en Amazon RDS.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_1.png)
## Tarea 1: Crear una copia de la base de datos existente
El primer paso del proceso de migración de una gran cantidad de datos a una base de datos de RDS para MariaDB con un tiempo de inactividad mínimo es crear una copia de los datos de origen.
El siguiente diagrama muestra la creación de una copia de seguridad de la base de datos de MariaDB.
![\[Flujo de trabajo que muestra la creación de una copia de seguridad de la base de datos de MariaDB.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_2.png)
Puede usar la utilidad `mysqldump` o `mariadb-dump` para crear una copia de seguridad de la base de datos, ya sea en formato SQL o como texto delimitado. En MariaDB 10.5, el cliente se llama [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/). A partir de MariaDB 11.0.1, debe usar `mariadb-dump` en lugar de `mysqldump`. Recomendamos que haga una prueba con cada formato en un entorno que no sea de producción para determinar con qué método tarda menos la ejecución de `mysqldump` o `mariadb-dump`.
También se recomienda comparar el rendimiento de `mysqldump` o `mariadb-dump` con el beneficio que ofrece el uso del formato de texto delimitado para la carga. Una copia de seguridad con formato de texto delimitado crea un archivo de texto separado por tabuladores por cada tabla volcada. Los archivos obtenidos pueden cargarse en paralelo con el comando `LOAD DATA LOCAL INFILE` para reducir el tiempo necesario para importar la base de datos. Para obtener más información, consulte [Paso 5: cargar los datos](mariadb-importing-data-any-source.md#mariadb-importing-data-any-source-load-data) en la importación de datos de cualquier procedimiento de origen.
Antes de iniciar la operación de copia de seguridad, asegúrese de configurar las opciones de replicación para la base de datos de MariaDB que va a copiar en Amazon RDS. Las opciones de replicación incluyen la activación del registro binario y la configuración de un ID de servidor único. La activación de estas opciones hace que el servidor comience a registrar las transacciones de la base de datos y la prepare para ser una instancia de replicación de origen en una fase posterior del proceso.
Asegúrese de conocer las siguientes recomendaciones y consideraciones:
+ Utilice la opción `--single-transaction` con `mysqldump` o `mariadb-dump` porque vuelca un estado coherente de la base de datos. Para garantizar un archivo de volcado válido, no ejecute instrucciones de lenguaje de definición de datos (DDL) mientras `mysqldump` o `mariadb-dump` se está ejecutando. Puede programar un periodo de mantenimiento para estas operaciones.
+ Excluya los siguientes esquemas del archivo de volcado:
+ `sys`
+ `performance_schema`
+ `information_schema`
Las utilidades `mysqldump` y `mariadb-dump` excluyen estos esquemas de forma predeterminada.
+ Si necesita migrar usuarios y privilegios, considere la posibilidad de usar una herramienta que genere el lenguaje de control de datos (DCL) para volver a crearlos, como la utilidad [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html).
### Para establecer las opciones de replicación
1. Edite el archivo `my.cnf`. Este archivo se suele encontrar en `/etc`.
```
sudo vi /etc/my.cnf
```
Añada las opciones `log_bin` y `server_id` a la sección `[mysqld]`. La opción `log_bin` proporciona un identificador de nombre de archivo para los archivos de log binarios. La opción `server_id` proporciona un identificador único para el servidor en las relaciones origen-réplica.
El siguiente ejemplo muestra la sección `[mariadb]` actualizada de un archivo `my.cnf`:
```
[mariadb]
log-bin
server-id=1
log-basename=master1
binlog-format=mixed
```
Para obtener más información, consulte [Setting the Replication Source Configuration](https://mariadb.com/docs/server/ha-and-performance/standard-replication/setting-up-replication) en la documentación de MariaDB.
1. Para la replicación con un clúster de base de datos multi-AZ, habilite `gtid_strict_mode`. Para obtener más información, consulte [gtid\$1strict\$1mode](https://mariadb.com/docs/server/ha-and-performance/standard-replication/gtid#gtid_strict_mode) en la documentación de MariaDB.
La habilitación de `gtid_strict_mode` no es necesaria para la replicación con una instancia de base de datos.
1. Reinicie el servicio `mariadb`.
```
sudo service mariadb restart
```
### Para crear una copia de seguridad de la base de datos existente
1. Cree una copia de seguridad de los datos con la utilidad `mysqldump` o `mariadb-dump`, especificando el formato SQL o de texto delimitado.
Para mejorar el desempeño y asegurar la integridad de los datos, use las opciones `--order-by-primary` y `--single-transaction` para `mysqldump` y `mariadb-dump`.
Para evitar incluir la base de datos de sistema de MySQL en la copia de seguridad, no use la opción `--all-databases` con `mysqldump` o `mariadb-dump`. Para obtener más información, consulte [Creating a Data Snapshot Using mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) en la documentación de MySQL.
Use `chmod`, si es necesario, para asegurarse de que es posible escribir en el directorio donde se va a crear el archivo de copia de seguridad.
**importante**
En Windows, ejecute el símbolo del sistema como administrador.
+ Para generar la salida en formato SQL, ejecute el siguiente comando. Para versiones de MariaDB 10.11 y anteriores, sustituya `mariadb-dump` por `mysqldump`.
Para Linux, macOS o Unix:
```
sudo mariadb-dump \
--databases database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u local_user \
-ppassword
```
**nota**
Como práctica recomendada de seguridad, especifique credenciales distintas de las que se muestran en el ejemplo.
Para Windows:
```
mariadb-dump ^
--databases database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-r backup.sql ^
-u local_user ^
-ppassword
```
**nota**
Como práctica recomendada de seguridad, especifique credenciales distintas de las que se muestran en el ejemplo.
+ Para generar la salida en formato de texto delimitado, ejecute el siguiente comando. Para MariaDB 11.01 y versiones posteriores, sustituya `mysqldump` por `mariadb-dump`.
Para Linux, macOS o Unix:
```
sudo mysqldump \
--tab=target_directory \
--fields-terminated-by ',' \
--fields-enclosed-by '"' \
--lines-terminated-by 0x0d0a \
database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-ppassword
```
Para Windows:
```
mysqldump ^
--tab=target_directory ^
--fields-terminated-by "," ^
--fields-enclosed-by """ ^
--lines-terminated-by 0x0d0a ^
database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-ppassword
```
**nota**
Como práctica recomendada de seguridad, especifique credenciales distintas de las que se muestran en el ejemplo.
Asegúrese de crear de forma manual procedimientos almacenados, desencadenadores, funciones o eventos en su base de datos de Amazon RDS. Si hay alguno de estos objetos en la base de datos que va a copiar, exclúyalo cuando ejecute `mysqldump` o `mariadb-dump`. Para hacerlo, incluya los siguientes argumentos con el comando `mysqldump` o `mariadb-dump`:
`--routines=0`
`--triggers=0`
`--events=0`
Al ejecutar `mysqldump` y especificar el formato de texto delimitado, se devuelve un comentario `CHANGE MASTER TO`. Este comentario contiene el nombre y la ubicación del archivo de registro maestro. Si la instancia externa es distinta de MariaDB 10.0.23 o anterior, tenga en cuenta los valores de `MASTER_LOG_FILE` y `MASTER_LOG_POS`. Necesita estos valores al configurar la replicación.
Se devuelve el siguiente resultado para las versiones de MariaDB.
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
1. Si la instancia externa que utiliza es MariaDB versión 10.0.24 o posterior, use la reproducción basada en GTID. Ejecute `SHOW MASTER STATUS` en la instancia de MariaDB externa para obtener el nombre y ubicación del archivo de registro binario y, a continuación, conviértalos en un GTID ejecutando `BINLOG_GTID_POS` en la instancia de MariaDB externa.
```
SELECT BINLOG_GTID_POS('binary_log_file_name', binary_log_file_position);
```
Tenga en cuenta el GTID devuelto. Necesita GTID para configurar la replicación.
1. Comprima los datos copiados para reducir los recursos de red necesarios para copiarlos a la base de datos de Amazon RDS. Tenga en cuenta el tamaño del archivo de copia de seguridad. Necesitará esta información para determinar el tamaño de la instancia de Amazon EC2 que se debe crear. Cuando haya terminado, comprima el archivo de copia de seguridad con GZIP o la utilidad de compresión que prefiera.
+ Para comprimir la salida en formato SQL, ejecute el siguiente comando:
```
gzip backup.sql
```
+ Para comprimir la salida en formato de texto delimitado, ejecute el siguiente comando:
```
tar -zcvf backup.tar.gz target_directory
```
## Tarea 2: Crear una instancia de Amazon EC2 y copiar la base de datos comprimida
La copia del archivo de copia de seguridad comprimido a una instancia Amazon EC2 requiere menos recursos de red que una copia directa de los datos sin comprimir entre las instancias de base de datos. Una vez que los datos se encuentran en Amazon EC2, puede copiarlos desde allí directamente a la base de datos de MariaDB. Para ahorrar en el costo de los recursos de red, la instancia de Amazon EC2 debe estar en la misma Región de AWS que la instancia de base de datos de Amazon RDS. Tener la instancia de Amazon EC2 en la misma Región de AWS que la base de datos de Amazon RDS también reduce la latencia de red durante la importación.
El siguiente diagrama muestra cómo copiar la copia de seguridad de la base de datos a una instancia de Amazon EC2.
![\[Flujo de trabajo que muestra cómo copiar la copia de seguridad de la base de datos a una instancia de Amazon EC2.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_3.png)
### Para crear una instancia Amazon EC2 y copiar los datos
1. En la Región de AWS donde tiene pensado crear la base de datos de Amazon RDS, cree una nube privada virtual (VPC), un grupo de seguridad de VPC y una subred de VPC. Asegúrese de que las reglas de entrada del grupo de seguridad de VPC permiten las direcciones IP necesarias para que la aplicación se conecte a AWS. Puede especificar un intervalo de direcciones IP, por ejemplo, `203.0.113.0/24`, u otro grupo de seguridad de VPC. Puede usar la [Consola de Amazon VPC](https://console.aws.amazon.com/vpc) para crear y administrar VPC, subredes y grupos de seguridad. Para obtener más información, consulte [Introducción a Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#getting-started) en la *Guía del usuario de Amazon Virtual Private Cloud*.
1. Abra la [consola de Amazon EC2](https://console.aws.amazon.com/ec2) y elija la Región de AWS que contendrá la instancia de Amazon EC2 y la base de datos de Amazon RDS. Lance una instancia Amazon EC2 utilizando la VPC, la subred y el grupo de seguridad que creó en el paso 1. Asegúrese de seleccionar un tipo de instancia con suficiente espacio de almacenamiento para el archivo de copia de seguridad de base de datos sin comprimir. Para obtener más información sobre las instancias de Amazon EC2, consulte [Introducción a Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) en la *Guía del usuario de Amazon Elastic Compute Cloud*.
1. Para conectarse a la base de datos de Amazon RDS desde la instancia de Amazon EC2, edite el grupo de seguridad de VPC. Agregue una regla de entrada que especifique la dirección IP privada de la instancia de EC2. La dirección IP privada aparece en la pestaña **Details (Detalles)** del panel **Instance (Instancia)** de la consola de EC2. Para editar el grupo de seguridad de VPC y agregar una regla de entrada, elija **Security Groups (Grupos de seguridad)** en el panel de navegación de la consola de EC2, elija el grupo de seguridad y, luego, agregue una regla de entrada para MySQL o Aurora que especifique la dirección IP privada de la instancia de EC2. Para obtener información sobre cómo agregar una regla de entrada a un grupo de seguridad de VPC, consulte [Reglas de grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) en la *Guía del usuario de Amazon Virtual Private Cloud*.
1. Copie el archivo de copia de seguridad de base de datos comprimido del sistema local a la instancia Amazon EC2. Use `chmod`, si es necesario, para asegurarse de que tiene permiso de escritura para el directorio de destino de la instancia de Amazon EC2. Puede utilizar `scp` o un cliente de Secure Shell (SSH) para copiar el archivo. El siguiente comando es un comando `scp` de ejemplo:
```
scp -r -i key pair.pem backup.sql.gz ec2-user@EC2 DNS:/target_directory/backup.sql.gz
```
**importante**
Al copiar la información confidencial, asegúrese de usar un protocolo de transferencia de red seguro.
1. Establezca una conexión con la instancia de Amazon EC2 e instale las últimas actualizaciones y las herramientas de cliente de MariaDB con los comandos siguientes:
```
sudo yum update -y
sudo yum install mariadb1011-client-utils -y
```
Para obtener más información, consulte [Conexión a la instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) para instancias de Linux en la *Guía del usuario de Amazon Elastic Compute Cloud* y [conectores de MariaDB](https://mariadb.com/docs/connectors) en la documentación de MariaDB.
1. Una vez establecida la conexión la instancia Amazon EC2 descomprima el archivo de copia de seguridad de base de datos. Los siguientes comandos son ejemplos.
+ Para descomprimir la salida en formato SQL, ejecute el siguiente comando:
```
gzip backup.sql.gz -d
```
+ Para descomprimir la salida en formato de texto delimitado, ejecute el siguiente comando:
```
tar xzvf backup.tar.gz
```
## Tarea 3: creación de una base de datos de MariaDB e importación de los datos desde la instancia de Amazon EC2
Al crear una instancia de base de datos de RDS para MariaDB en la misma Región de AWS que la instancia de Amazon EC2, puede importar el archivo de copia de seguridad de base de datos desde Amazon EC2 más rápidamente que a través de Internet.
El siguiente diagrama muestra la importación de la copia de seguridad desde una instancia de Amazon EC2 a una base de datos de MariaDB.
![\[Flujo de trabajo que muestra la importación de la copia de seguridad desde la instancia de EC2 a la base de datos de MariaDB.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_4.png)
### Creación de una base de datos de MariaDB e importación de los datos
1. Determine la clase de la instancia de base de datos y la cantidad de espacio de almacenamiento requeridas para atender la carga de trabajo prevista para esta base de datos de Amazon RDS. Como parte de este proceso, decida cuánto espacio y qué capacidad de procesamiento requieren los procedimientos de carga de datos. Decida también lo que se necesita para manejar la carga de trabajo de producción. Puede estimar esto en función del tamaño y los recursos de la base de datos de MariaDB de origen. Para obtener más información, consulte [Clases de instancia de base de datos de ](Concepts.DBInstanceClass.md).
1. Cree una instancia de base de datos en la Región de AWS que contenga la instancia de Amazon EC2. Siga las instrucciones en [Creación de una instancia de base de datos de Amazon RDS](USER_CreateDBInstance.md) y use las siguientes directrices:
+ Especifique una versión del motor de base de datos compatible con la instancia de base de datos de origen.
+ Especifique la misma nube privada virtual (VPC) y el mismo grupo de seguridad de VPC que para la instancia de Amazon EC2. De este modo se asegura de que la instancia Amazon EC2 y la instancia de Amazon RDS sean visibles mutuamente a través de la red. Asegúrese de que la instancia de base de datos sea de acceso público. Para configurar la replicación con la base de datos de origen como se describe en la siguiente sección, la instancia de base de datos debe ser accesible públicamente.
+ No configure varias zonas de disponibilidad, retenciones de copia de seguridad ni réplicas de lectura hasta haber importado la copia de seguridad de la base de datos. Una vez completada la importación, puede configurar Multi-AZ y la retención de copia de seguridad para la instancia de producción.
1. Revise las opciones de configuración predeterminadas para la base de datos de Amazon RDS. Si el grupo de parámetros predeterminado para la base de datos no tiene las opciones de configuración que desea, busque otro que sea adecuado o cree un grupo de parámetros nuevo. Para obtener más información acerca de cómo crear un grupo de parámetros, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
1. Conéctese a la nueva base de datos de Amazon RDS como usuario maestro. Cree los usuarios necesarios para admitir a los administradores, las aplicaciones y los servicios que necesitan acceso a la instancia de base de datos. El nombre de host para la base de datos de Amazon RDS es el valor de **Punto de conexión** para esta instancia de base de datos, sin el número de puerto; por ejemplo, `mysampledb.123456789012.us-west-2.rds.amazonaws.com`. Puede encontrar el valor del punto de conexión en los detalles de la base de datos en la consola de Amazon RDS.
1. Conéctese a la instancia de Amazon EC2. Para obtener más información, consulte [Conexión a la instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) para instancias de Linux en la *Guía del usuario de Amazon Elastic Compute Cloud*.
1. Conecte con la base de datos de Amazon RDS como host remoto desde la instancia de Amazon EC2 con el comando `mysql`. El siguiente comando es un ejemplo:
```
mysql -h host_name -P 3306 -u db_master_user -p
```
El *host\$1name* es el punto de conexión de la base de datos de Amazon RDS.
1. En la petición de `mysql`, ejecute el comando `source` y pásele el nombre del archivo de volcado de la base de datos. Este comando carga los datos en la instancia de base de datos de Amazon RDS.
+ Para el formato SQL, utilice el siguiente comando:
```
MariaDB [(none)]> source backup.sql;
```
+ Para el formato de texto delimitado, cree primero la base de datos, si no es la predeterminada que se creó cuando se configuró la base de datos de Amazon RDS.
```
MariaDB [(none)]> create database database_name;
MariaDB [(none)]> use database_name;
```
A continuación, cree las tablas.
```
MariaDB [(none)]> source table1.sql
MariaDB [(none)]> source table2.sql
etc...
```
Importe entonces los datos.
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
etc...
```
Para mejorar el rendimiento, puede ejecutar estas operaciones en paralelo desde varias conexiones, de modo que todas las tablas se creen y luego se carguen al mismo tiempo.
**nota**
Si utilizó alguna opción de formato de datos con `mysqldump` o `mariadb-dump` en el volcado inicial de la tabla, asegúrese de utilizar las mismas opciones con `LOAD DATA LOCAL INFILE` para garantizar una interpretación adecuada del contenido del archivo de datos.
1. Ejecute una consulta `SELECT` sencilla en una o dos de las tablas de la base de datos importada para comprobar que la importación se ha completado correctamente.
Si ya no necesita la instancia de Amazon EC2 utilizada en este procedimiento, termine la instancia de EC2 para reducir el uso de recursos de AWS. Para terminar una instancia de EC2, consulte [Terminación de una instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console) en la *Guía del usuario de Amazon Elastic Compute Cloud*.
## Tarea 4: Replicación de los datos de la base de datos externa a la nueva base de datos de Amazon RDS
Es probable que la base de datos de origen se haya actualizado durante el tiempo que tardó en copiar y transferir los datos a la base de datos MariaDB. Puede utilizar la replicación para actualizar la base de datos copiada con la base de datos de origen.
![\[Flujo de trabajo que muestra la replicación de datos desde la base de datos de MariaDB externa a la base de datos en Amazon RDS.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_5.png)
Los permisos requeridos para comenzar la replicación en una base de datos de Amazon RDS están restringidos y no están disponibles para el usuario principal de Amazon RDS. Por ello, utilice el procedimiento almacenado de Amazon RDS adecuado:
+ [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) para configurar la replicación y [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) para iniciar la replicación
### Para iniciar la replicación
En la tarea 1, [cuando estableció las opciones de replicación](#mariadb-importing-data-reduced-downtime-set-replication-options), activó el registro binario y estableció un ID de servidor único para la base de datos de origen. Ahora, puede configurar la base de datos de Amazon RDS como réplica estableciendo la base de datos activa como instancia de replicación de origen.
1. En la consola de Amazon RDS, agregue la dirección IP del servidor que aloja la base de datos de origen al grupo de seguridad de VPC configurado para la base de datos de Amazon RDS. Para obtener más información sobre la configuración de un grupo de seguridad de VPC, consulte [Configuración de reglas de grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) en la *Guía del usuario de Amazon Virtual Private Cloud*.
Es posible que también necesite configurar la red local para permitir las conexiones desde la dirección IP de la base de datos de Amazon RDS para que se pueda comunicar con la instancia de origen. Para encontrar la dirección IP de la base de datos de Amazon RDS, use el comando `host`:
```
host host_name
```
El *host\$1name* es el nombre de DNS del punto de conexión de la base de datos de Amazon RDS, por ejemplo, `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Puede encontrar el valor del punto de conexión en los detalles de la instancia de base de datos en la consola de Amazon RDS.
1. Con el cliente que prefiera, conecte con la instancia de origen y cree un usuario para la replicación. Esta cuenta se usa únicamente para la replicación y debe estar limitada a su dominio para mejorar la seguridad. El siguiente comando es un ejemplo:
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**nota**
Especifique credenciales distintas de las que se muestran aquí como práctica recomendada de seguridad.
1. En la instancia de origen, conceda al usuario de replicación los privilegios `REPLICATION CLIENT` y `REPLICATION SLAVE`. Por ejemplo, para conceder los privilegios `REPLICATION CLIENT` y `REPLICATION SLAVE` referidos a todas las bases de datos al usuario "`repl_user`" del dominio, ejecute el siguiente comando:
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Si utilizó el formato SQL para crear el archivo de copia de seguridad y la instancia externa no es MariaDB 10.0.24 o posterior, observe el contenido de ese archivo ejecutando el siguiente comando:
```
cat backup.sql
```
El archivo contiene un comentario `CHANGE MASTER TO` que contiene el nombre y la posición del archivo de registro maestro. Este comentario se incluye en el archivo de copia de seguridad cuando se usa la opción `--master-data` con `mysqldump`. Tenga en cuenta los valores de `MASTER_LOG_FILE` y `MASTER_LOG_POS`.
```
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
Si utilizó el formato de texto delimitado para crear el archivo de copia de seguridad y la instancia externa no es MariaDB 10.0.24 o posterior, ya debe haber obtenido las coordenadas del registro binario del paso 1 en la tarea 1 [cuando creó una copia de seguridad de la base de datos existente](#mariadb-importing-data-reduced-downtime-create-backup).
Si la instancia externa es MariaDB 10.0.24 o posterior, ya debe haber obtenido el GTID desde el que se inicia la replicación del paso 2 en la tarea 1 [cuando creó una copia de seguridad de la base de datos existente](#mariadb-importing-data-reduced-downtime-create-backup).
1. Convertir la base de datos de Amazon RDS en la réplica. Si la instancia externa no es MariaDB 10.0.24 o una versión posterior, conéctese a la base de datos de Amazon RDS como usuario maestro e identifique la base de datos de origen como la instancia de replicación de origen con el procedimiento almacenado [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master).
Si tiene un archivo de copia de seguridad con formato SQL, utilice el nombre de archivo de registro y la ubicación del registro principal que determinó en el paso 4. Si utilizó formato de texto delimitado, utilice el nombre y la posición que determinó cuando se crearon los archivos de copia de seguridad. El siguiente comando es un ejemplo:
```
CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**nota**
Especifique credenciales distintas de las que se muestran aquí como práctica recomendada de seguridad.
Si la instancia externa es MariaDB 10.0.24 o una versión posterior, conéctese a la base de datos de Amazon RDS como usuario maestro e identifique la base de datos de origen como la instancia de replicación de origen con el procedimiento almacenado [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md). Utilice el GTID que determinó en el paso 2 de la tarea 1 [cuando creó una copia de seguridad de la base de datos existente](#mariadb-importing-data-reduced-downtime-create-backup). El siguiente comando es un ejemplo:
```
CALL mysql.rds_set_external_master_gtid ('source_server_ip_address', 3306, 'ReplicationUser', 'password', 'GTID', 1);
```
`source_server_ip_address` es la dirección IP de la instancia de replicación de origen. Una dirección DNS privada de EC2 no se admite actualmente.
**nota**
Especifique credenciales distintas de las que se muestran aquí como práctica recomendada de seguridad.
1. En la base de datos de Amazon RDS, para empezar la replicación, ejecute el comando siguiente que usa el procedimiento almacenado [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication):
```
CALL mysql.rds_start_replication;
```
1. En la base de datos de Amazon RDS, para determinar si la réplica está actualizada con la instancia de replicación de origen, ejecute el comando [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html). Los resultados del comando `SHOW REPLICA STATUS` incluyen el campo `Seconds_Behind_Master`. Cuando el campo `Seconds_Behind_Master` devuelve 0, la réplica está actualizada con la instancia de replicación de origen.
Para una instancia de base de datos de MariaDB 10.5, 10.6, 10.11, 11.4 u 11.8, use el procedimiento almacenado [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) en lugar de ejecutar el comando de MySQL.
1. Una vez que la base de datos de Amazon RDS esté actualizada, active las copias de seguridad automatizadas para poder restaurar la base de datos si es necesario. Puede activar o modificar copias de seguridad automatizadas para la base de datos de Amazon RDS mediante la [consola de Amazon RDS](https://console.aws.amazon.com/rds/). Para obtener más información, consulte [Introducción a las copias de seguridad](USER_WorkingWithAutomatedBackups.md).
## Tarea 5: Redirigir la aplicación en funcionamiento a la instancia de Amazon RDS
Una vez que la base de datos de MariaDB esté actualizada con la instancia de replicación de origen, puede actualizar la aplicación activa para utilizar la instancia de Amazon RDS.
![\[Flujo de trabajo que muestra la detención de la replicación y el direccionamiento de la aplicación en funcionamiento a la base de datos en Amazon RDS.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_6.png)
### Redirección de la aplicación activa a la base de datos de MariaDB y detención de la replicación
1. Para añadir el grupo de seguridad de VPC para la base de datos de Amazon RDS, añada la dirección IP del servidor que aloja la aplicación. Para obtener más información sobre la modificación de un grupo de seguridad de VPC, consulte [Configuración de reglas de grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) en la *Guía del usuario de Amazon Virtual Private Cloud*.
1. Compruebe que el valor del campo `Seconds_Behind_Master` en el comando [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) sea 0, lo que indica que la réplica está actualizada al estado de la instancia de reproducción de origen.
```
SHOW REPLICA STATUS;
```
Para una instancia de base de datos de MariaDB 10.5, 10.6, 10.11, 11.4 u 11.8, use el procedimiento [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) en lugar de ejecutar el comando de MySQL.
1. Cierre todas las conexiones con el origen cuando se completen las transacciones.
1. Actualice la aplicación para que use la base de datos de Amazon RDS. Normalmente, la actualización implicará cambar la configuración de conexión para identificar el nombre de host y el puerto de la base de datos de Amazon RDS, la cuenta de usuario y la contraseña con las que conectarse y la base de datos que se debe emplear.
1. Conéctese a la instancia de base de datos.
1. Detenga la replicación de la instancia de Amazon RDS mediante la ejecución del comando siguiente que usa el procedimiento almacenado [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication):
```
CALL mysql.rds_stop_replication;
```
1. Restablezca la configuración de replicación para que esta instancia deje de considerarse una réplica mediante la ejecución del siguiente comando que usa el procedimiento almacenado [mysql.rds\$1reset\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) en la base de datos de Amazon RDS:
```
CALL mysql.rds_reset_external_master;
```
1. Active las características adicionales de Amazon RDS, como la compatibilidad con Multi-AZ y las réplicas de lectura. Para obtener más información, consulte [Configuración y administración de una implementación multi-AZ para Amazon RDS](Concepts.MultiAZ.md) y [Trabajo con réplicas de lectura de instancias de base de datos](USER_ReadRepl.md).
# Importación de datos de cualquier origen a una instancia de base de datos de Amazon RDS para MariaDB
Con Amazon RDS, puede migrar datos de MariaDB existentes de cualquier origen a una instancia de base de datos de RDS para MariaDB. Puede transferir datos de bases de datos en las instalaciones, otros proveedores de nube o instancias de base de datos de RDS para MariaDB existentes a la instancia de base de datos de RDS para MariaDB de destino. Con esta funcionalidad, puede consolidar bases de datos, implementar soluciones de recuperación ante desastres o realizar la transición desde bases de datos autoadministradas. Los escenarios comunes incluyen pasar de servidores de MariaDB autoalojados a instancias de base de datos de Amazon RDS totalmente administradas, consolidar varias bases de datos MariaDB en una sola instancia de base de datos o crear entornos de prueba con datos de producción. En las siguientes secciones se proporcionan instrucciones paso a paso para importar los datos de MariaDB mediante métodos como `mariadb-dump`, archivos de copia de seguridad o replicación.
## Paso 1: crear archivos sin formato con los datos que se van a cargar
Utilice un formato habitual, como valores separados por comas (CSV), para almacenar los datos que se deben cargar. Cada tabla debe tener su propio archivo. No puede combinar los datos de varias tablas en el mismo archivo. Dé a cada archivo el nombre de la tabla correspondiente. Puede elegir la extensión que desee para el nombre de los archivos. Por ejemplo, si el nombre de la tabla es `sales`, el nombre del archivo podría ser `sales.csv` o `sales.txt`.
Si es posible, ordene los datos según la clave principal de la tabla que se va a cargar. Esto mejorará drásticamente los tiempos de carga y minimizará los requisitos de almacenamiento en disco.
La velocidad y la eficiencia de este procedimiento dependen de que el tamaño de los archivos sea pequeño. Si el tamaño sin comprimir de algún archivo es mayor de 1 GiB, divídalo en varios archivos y cárguelos por separado.
En los sistemas de tipo Unix (incluido Linux), utilice el comando `split`. Por ejemplo, el siguiente comando divide el archivo `sales.csv` en varios archivos de menos de 1 GiB y los divide solo en los saltos de línea (-C 1024m). Los nombres de los nuevos archivos incluyen sufijos numéricos ascendentes. El siguiente comando genera archivos con nombres como `sales.part_00` y `sales.part_01`.
```
split -C 1024m -d sales.csv sales.part_
```
Otros sistemas operativos disponen de utilidades similares.
Puede almacenar los archivos sin formato en cualquier lugar. No obstante, cuando cargue los datos en el [paso 5](#mariadb-importing-data-any-source-load-data), debe invocar el intérprete de comandos de `mysql` desde la misma ubicación donde existen los archivos o utilizar la ruta absoluta de los archivos cuando ejecute `LOAD DATA LOCAL INFILE`.
## Paso 2: Detener las aplicaciones con acceso a la instancia de base de datos de destino
Antes de iniciar una carga grande, detenga toda la actividad de aplicaciones de acceder a la instancia de base de datos de destino que prevé cargar. Se recomienda esto en particular si otras sesiones modificarán las tablas que se cargan o las tablas a las que hacen referencia. Hacer esto reduce el riesgo de violaciones de restricciones que se producen durante la carga y mejoran el desempeño de carga. También permite restaurar la instancia de base de datos al estado inmediatamente anterior a la carga sin perder los cambios efectuados por los procesos no implicados en la carga.
Por supuesto, en ocasiones esto no será posible o no resultará práctico. Si no puede detener el acceso de las aplicaciones con acceso a la instancia de base de datos antes de la carga, tome las medidas oportunas para asegurar la disponibilidad e integridad de los datos. Los pasos específicos requeridos varían mucho en función de cada caso y de los requisitos del sitio.
## Paso 3: crear una instantánea de base de datos
Si tiene previsto cargar los datos en una nueva instancia de base de datos que aún está vacía, puede omitir este paso. De lo contrario, recomendamos crear instantáneas de bases de datos de la instancia de base de datos de Amazon RDS elegida como destino antes y después de la carga de los datos. Las instantáneas de base de datos de Amazon RDS son copias de seguridad completas de la instancia de base de datos que puede usar para restaurar la instancia de base de datos a un estado conocido. Cuando se inicia una instantánea de base de datos, las operaciones de E/S de la instancia de base de datos se suspenden de forma temporal mientras se crea una copia de seguridad de la base de datos.
La creación de una instantánea de base de datos inmediatamente antes de la carga permite restaurar la base de datos al estado previo a la carga, si es necesario. Una instantánea de base de datos tomada inmediatamente después de la carga le evita tener que volver a cargar los datos en caso de error. También puede usar instantáneas de bases de datos después de la carga para importar datos a nuevas instancias de bases de datos.
En el ejemplo siguiente se ejecuta el comando [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html) de la AWS CLI para crear una instantánea de base de datos de la instancia `AcmeRDS` y se otorga el identificador `"preload"` a la instantánea de base de datos.
Para Linux, macOS o Unix:
```
aws rds create-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Para Windows:
```
aws rds create-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
También puede utilizar la funcionalidad de restauración de instantáneas de bases de datos para crear instancias de bases de datos de prueba para simulacros o para deshacer cambios realizados durante la carga.
Tenga en cuenta que al restaurar una base de datos a partir de una instantánea de base de datos se crea una instancia nueva de base de datos que, como todas las instancias de base de datos, tiene un identificador y un punto de conexión únicos. Para restaurar la instancia de base de datos sin cambiar de punto de conexión, primero, elimine la instancia de base de datos para poder reutilizar el mismo punto de conexión.
Por ejemplo, para crear una instancia de base de datos para simulacros u otras pruebas, asigne a la instancia de base de datos su propio identificador. En el ejemplo, el identificador es `AcmeRDS-2`. El ejemplo se conecta a la instancia de base de datos mediante el punto de conexión asociado con `AcmeRDS-2`. Para obtener más información, consulte [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html).
Para Linux, macOS o Unix:
```
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS-2 \
--db-snapshot-identifier preload
```
Para Windows:
```
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS-2 ^
--db-snapshot-identifier preload
```
Para reutilizar el punto de conexión existente, es necesario eliminar primero la instancia de base de datos y, luego, asignar el mismo identificador a la base de datos restaurada. Para obtener más información, consulte [delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html).
En el ejemplo siguiente se toma una instantánea de base de datos final de la instancia de base de datos antes de eliminarla. Esto es opcional, pero recomendable.
Para Linux, macOS o Unix:
```
aws rds delete-db-instance \
--db-instance-identifier AcmeRDS \
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Para Windows:
```
aws rds delete-db-instance ^
--db-instance-identifier AcmeRDS ^
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
## Paso 4 (opcional): Desactivar copias de seguridad automatizadas de Amazon RDS
**aviso**
No desactive las copias de seguridad automatizadas si necesita realizar una recuperación en un momento dado.
La desactivación de las copias de seguridad automatizadas es una optimización del rendimiento y no es un requisito para las cargas de datos. La desactivación de las copias de seguridad automatizadas elimina todas las copias de seguridad existentes. Como resultado, después de desactivar las copias de seguridad automatizadas, no es posible la recuperación en un momento dado. Las instantáneas de base de datos manuales no se ven afectadas por la desactivación de las copias de seguridad automatizadas. Todas las instantáneas de base de datos manuales existentes seguirán estando disponibles para su restauración.
La desactivación de las copias de seguridad automatizadas reduce el tiempo de carga en aproximadamente un 25 % y reduce el espacio de almacenamiento necesario durante la carga. Si planea cargar los datos en una instancia de base de datos nueva que no contiene datos, desactivar las copias de seguridad es una forma sencilla de acelerar la carga y evitar utilizar el almacenamiento adicional que las copias de seguridad necesitan. Sin embargo, en algunos casos, es posible que tenga previsto cargar en una instancia de base de datos que ya contiene datos. Si es así, evalúe los beneficios de la desactivación de las copias de seguridad frente al impacto de perder la capacidad de realizar una recuperación a un momento dado.
Las instancias de base de datos tienen copias de seguridad automatizadas activadas de forma predeterminada (con un periodo de retención de un día). Para desactivar las copias de seguridad automatizadas, configure el periodo de retención de copia de seguridad en cero. Después de la carga, puede volver a activar las copias de seguridad mediante la configuración del periodo de retención de copia de seguridad en un valor distinto de cero. Para activar o desactivar las copias de seguridad, Amazon RDS apaga la instancia de base de datos y, a continuación, la reinicia para activar o desactivar el registro de MariaDB.
Ejecute el comando `modify-db-instance` de la AWS CLI para establecer el valor cero como período de retención de copia de seguridad y aplicar el cambio inmediatamente. Al configurar cero como periodo de retención es necesario reiniciar la instancia de base de datos, por lo que debe esperar a que la operación se complete para poder continuar. Para obtener más información, consulte [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html).
Para Linux, macOS o Unix:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--apply-immediately \
--backup-retention-period 0
```
Para Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--apply-immediately ^
--backup-retention-period 0
```
Puede comprobar el estado de la instancias de base de datos con el comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) de la AWS CLI. En el siguiente ejemplo se muestra el estado de la instancia de base de datos de la instancia de base de datos `AcmeRDS`:
```
aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}"
```
Cuando el estado de la instancia de base de datos es `available`, está listo para continuar con el siguiente paso.
## Paso 5: cargar los datos
Para leer las filas de los archivos sin formato en las tablas de base de datos, use la instrucción `LOAD DATA LOCAL INFILE` de MariaDB.
**nota**
Debe invocar el intérprete de comandos de `mariadb` desde la misma ubicación donde existen los archivos o utilizar la ruta absoluta de los archivos cuando ejecute `LOAD DATA LOCAL INFILE`.
En el siguiente ejemplo, se muestra cómo cargar datos de un archivo denominado `sales.txt` en una tabla denominada `Sales` en la base de datos:
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\';
Query OK, 1 row affected (0.01 sec)
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
```
Para obtener más información sobre la instrucción `LOAD DATA`, consulte [LOAD DATA INFILE](https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/inserting-loading-data/load-data-into-tables-or-index/load-data-infile) en la documentación de MariaDB.
## Paso 6: Activar las copias de seguridad automatizadas de Amazon RDS
Si desactiva las copias de seguridad automatizadas de Amazon RDS en el [paso 4](#mariadb-importing-data-any-source-turn-off-automated-backups), una vez terminada la carga, active las copias de seguridad automatizadas estableciendo nuevamente el periodo de retención de copia de seguridad en el valor que había antes de la carga. Como se ha indicado en el paso 4, Amazon RDS reinicia la instancia de base de datos, por lo que debe estar preparado para una breve interrupción del servicio.
El siguiente ejemplo ejecuta el comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) de la AWS CLI para activar las copias de seguridad automatizadas para la instancia de base de datos `AcmeRDS` y establecer el periodo de retención en un día:
Para Linux, macOS o Unix:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--backup-retention-period 1 \
--apply-immediately
```
Para Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--backup-retention-period 1 ^
--apply-immediately
```