Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Opciones de migración de bases de datos de MySQL y MariaDB grandes
Puede elegir entre una amplia gama de opciones para migrar desde bases de datos de MySQL o MariaDB en las instalaciones a instancias de bases de datos de Amazon Relational Database Service (Amazon RDS) o una edición compatible con MySQL de Amazon Aurora. Elegir el enfoque y la herramienta de migración correctos es esencial para que la migración sea correcta. En esta guía, se evaluarán las opciones según sus requisitos de usabilidad, tamaño de datos y tiempo de inactividad.
A continuación, se muestran los enfoques y herramientas de migración más comunes que están disponibles para migrar las bases de datos de MySQL autoadministradas de varios terabytes de manera eficiente a las instancias de bases de datos de Amazon RDS, Aurora o Amazon Elastic Compute Cloud (Amazon EC2):
+ [Percona XtraBackup](percona-xtrabackup.md) (física)
+ [MyDumper](mydumper.md) (lógica)
+ [mysqldump y mysqlpump](mysqldump-and-mysqlpump.md) (lógica)
+ [Copia de seguridad dividida](split-backup.md) (físicas, lógicas o ambas)
A continuación, se muestran los enfoques y las herramientas de migración más comunes que están disponibles para migrar las bases de datos compatibles con MySQL de varios terabytes (como MariaDB) de manera eficiente a las instancias de las bases de datos de Amazon RDS, Aurora o Amazon EC2:
+ [MyDumper](mydumper.md) (lógica)
+ [mysqldump y mysqlpump](mysqldump-and-mysqlpump.md) (lógica)
+ [Copia de seguridad dividida](split-backup.md) (físicas, lógicas o ambas)
Para cada herramienta de migración, hay varios enfoques que puede utilizar para transferir el archivo de copia de seguridad de la base de datos grande a la Nube de AWS. Se proporcionan opciones para cada herramienta y también puede utilizar Amazon S3 File Gateway. Para obtener más información, consulte la sección [Uso de Amazon S3 File Gateway para transferir archivos de copia de seguridad](amazon-s3-file-gateway.md) de esta guía.
# Percona XtraBackup
**importante**
Percona no XtraBackup es compatible con las versiones 10.3 o posteriores de MariaDB y solo es compatible parcialmente con las versiones 10.1 y 10.2.
[Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/index.html) es un software común de copia de seguridad en caliente de código abierto para MySQL y MariaDB que realiza copias de seguridad sin bloqueo para los motores de almacenamiento InnoDB y XtraDB. Funciona con servidores MySQL o MariaDB. [Para obtener más información sobre la herramienta y algunas de sus características y ventajas, consulte Acerca de Percona en la documentación de Percona. XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/about-xtrabackup.html) XtraBackup
Esta herramienta utiliza el enfoque de migración física. Copia de manera directa el directorio de datos de MySQL o MariaDB y los archivos que contiene. En el caso de las bases de datos grandes, como las de más de 100 GB, esto puede proporcionar un tiempo de restauración significativamente mejor que el de otras herramientas. Se crea una copia de seguridad de la base de datos de origen en las instalaciones, se migran los archivos de la copia de seguridad a la nube y, a continuación, se restaura la copia de seguridad en la nueva instancia de base de datos de destino.
El siguiente diagrama muestra los pasos de alto nivel necesarios para migrar una base de datos mediante un archivo de respaldo de XtraBackup Percona. Según el tamaño del archivo de copia de seguridad, hay dos opciones disponibles para transferir la copia de seguridad a un bucket de Amazon Simple Storage Service (Amazon S3) en la Nube de AWS.
![\[Diagrama de la migración de un XtraBackup archivo de Percona y su restauración en una instancia de base de datos. AWS\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/percona-xtrabackup-migration-aws.png)
Los siguientes son los pasos para usar Percona para XtraBackup migrar una base de datos a: Nube de AWS
1. Instale Percona XtraBackup en el servidor local. Si utiliza Amazon Aurora MySQL versión 2 o Amazon RDS, consulte [Instalación de Percona 2.4 XtraBackup](https://docs.percona.com/percona-xtrabackup/2.4/installation.html). Si utiliza Amazon Aurora MySQL versión 3, consulte Instalación de [Percona XtraBackup 8.0](https://docs.percona.com/percona-xtrabackup/8.0/installation.html) en la documentación de Percona XtraBackup.
1. Cree una copia de seguridad completa de la base de datos de MySQL o MariaDB de origen. [Para obtener instrucciones sobre Percona XtraBackup 2.4, consulte Copia de seguridad completa.](https://docs.percona.com/percona-xtrabackup/2.4/backup_scenarios/full_backup.html) Para obtener instrucciones sobre Percona XtraBackup 8.0, consulte [Crear una copia de seguridad completa](https://docs.percona.com/percona-xtrabackup/8.0/create-full-backup.html).
1. Transfiera los archivos de respaldo a través de Internet mediante un servicio o una herramienta aprobados de su organización, como los siguientes:
+ [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ [AWS Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/client-vpn-user-what-is.html)
+ [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
+ [Amazon S3 File Gateway](https://docs.aws.amazon.com/filegateway/latest/files3/what-is-file-s3.html) (para más información, consulte [Uso de Amazon S3 File Gateway para transferir archivos de copia de seguridad](amazon-s3-file-gateway.md) en esta guía.)
+ [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/getting-started/hands-on/backup-to-s3-cli/)
1. Desde el bucket de Amazon S3, restaure los archivos de respaldo en la instancia de base de datos de destino. Para obtener instrucciones, consulte lo siguiente:
+ Para la edición compatible con MySQL de Aurora, consulte [Migración de datos desde MySQL con un bucket de Amazon S3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.Restore) en la documentación de Amazon RDS.
+ En el caso de Amazon RDS para MySQL o Amazon EC2, consulte [Importación de datos en una instancia de base de datos de MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.Other.html).
+ En el caso de Amazon RDS para MariaDB o Amazon EC2, consulte [Importación de datos a una instancia de base de datos de MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MariaDB.Procedural.Importing.html).
1. (Opcional) Puede configurar la replicación entre la base de datos de origen y la instancia de base de datos de destino. Puede utilizar la replicación del registro binario (binlog) para reducir el tiempo de inactividad. Para obtener más información, consulte los siguientes temas:
+ [Setting the replication source configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) en la documentación de MySQL
+ Para Amazon Aurora, consulte lo siguiente:
+ [Sincronización del clúster de base de datos de Amazon Aurora MySQL con la base de datos MySQL mediante replicación](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) en la documentación de Aurora
+ [Uso de la replicación de registro binario en Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) en la documentación de Aurora
+ Para Amazon RDS, consulte lo siguiente:
+ [Uso de la replicación de MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) en la documentación de Amazon RDS
+ [Uso de la replicación de MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) en la documentación de Amazon RDS
+ Para Amazon EC2, consulte lo siguiente:
+ [Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) en la documentación de MySQL
+ [Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) en la documentación de MySQL
+ [Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/) en la documentación de MariaDB
## Ventajas
+ Como Percona XtraBackup utiliza un enfoque de migración física, el proceso de restauración suele ser más rápido que el de las herramientas que utilizan un enfoque de migración lógica. Esto se debe a que el rendimiento está limitado por el rendimiento del disco o la red y no por los recursos de computación necesarios para el procesamiento de datos.
+ Como el proceso de restauración consiste en una copia directa de los archivos del bucket de S3 a la instancia de base de datos de destino, los XtraBackup archivos de Percona suelen restaurarse más rápido que los archivos de backup creados con otras herramientas.
+ Percona XtraBackup es adaptable. Por ejemplo, admite varios subprocesos para copiar archivos más rápido y admite la compresión para reducir el tamaño de la copia de seguridad.
## Limitaciones
+ La copia de seguridad sin conexión no es posible porque Percona XtraBackup debe tener acceso al servidor de la base de datos de origen.
+ Percona solo se XtraBackup puede usar en sistemas con arquitecturas de sistema idénticas. Por ejemplo, no es posible restaurar una copia de seguridad de una base de datos de origen que se ejecuta en un servidor Intel para Windows en un servidor de destino ARM para Linux.
+ Percona XtraBackup no es compatible con la versión 10.3 o posterior de MariaDB, y solo es compatible parcialmente con las versiones 10.2 y 10.1 de MariaDB. Para obtener más información, consulte [ XtraBackup Descripción general de Percona: compatibilidad con MariaDB](https://mariadb.com/kb/en/percona-xtrabackup-overview/#compatibility-with-mariadb) en la base de conocimiento de MariaDB.
+ No puede usar Percona XtraBackup para restaurar una base de datos MariaDB de origen en una instancia de base de datos MySQL de destino, como Amazon RDS for MySQL o Aurora MySQL compatible.
+ El volumen total de datos y la cantidad de objetos que puede almacenar en un bucket de S3 son ilimitados. Sin embargo, el tamaño máximo del archivo es de 5 TB. Si el archivo de copia de seguridad supera los 5 TB, puede dividirlo en varios archivos más pequeños.
+ Cuando la `innodb_file_per_table` configuración está desactivada, Percona XtraBackup no admite copias de seguridad parciales que usen,,,, o. `--tables` `--tables-exclude` `--tables-file` `--databases` `--databases-exclude` `--databases-file` Para obtener más información sobre la XtraBackup versión 2.4 de Percona, consulte Copias de seguridad [parciales](https://docs.percona.com/percona-xtrabackup/2.4/innobackupex/partial_backups_innobackupex.html). Para obtener más información sobre la XtraBackup versión 8.0 de Percona, consulte [Crear una copia de seguridad parcial](https://docs.percona.com/percona-xtrabackup/8.0/create-partial-backup.html).
## Prácticas recomendadas
+ Para mejorar el rendimiento del proceso de copia de seguridad, haga lo siguiente:
+ Copie varios archivos en paralelo mediante [--parallel=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-parallel)
+ Comprima varios archivos en paralelo mediante [--compress-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-compress-threads)
+ Aumente la memoria mediante [--use-memory=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-use-memory)
+ Cifre varios archivos en paralelo mediante [--encrypt-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-encrypt-threads)
+ Asegúrese de que haya suficiente espacio suficiente en el servidor de origen para guardar los archivos de copia de seguridad de la base de datos.
+ Genere la copia de seguridad de la base de datos con el archivo con formato (.xbstream) de Percona xbstream. Para obtener más información, consulte [la descripción general del binario xbstream](https://docs.percona.com/percona-xtrabackup/8.0/xbstream-binary-overview.html) en la documentación de Percona. XtraBackup
# MyDumper
[MyDumper](https://github.com/mydumper/mydumper#what-is-mydumper)(GitHub) es una herramienta de migración lógica de código abierto que consta de dos utilidades:
+ MyDumper exporta una copia de seguridad coherente de las bases de datos MySQL. Permite hacer copias de seguridad de la base de datos mediante el uso de varios subprocesos paralelos, hasta un subproceso por núcleo de CPU disponible.
+ myloader lee los archivos de respaldo creados por MyDumper, se conecta a la instancia de base de datos de destino y, a continuación, restaura la base de datos.
El siguiente diagrama muestra los pasos de alto nivel necesarios para migrar una base de datos mediante un archivo de MyDumper respaldo. En este diagrama de arquitectura se incluyen tres opciones para migrar el archivo de copia de seguridad del centro de datos en las instalaciones a una instancia de EC2 en la Nube de AWS.
![\[Diagrama de migración de un archivo de MyDumper copia de seguridad y uso de myloader para restaurarlo en la AWS instancia de base de datos.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mydumper-myloader-migration-aws.png)
Los siguientes son los pasos que se deben seguir para MyDumper migrar una base de datos a: Nube de AWS
1. Install MyDumper y myloader. Para obtener instrucciones, consulte [Cómo instalar mydumper/myloader](https://github.com/mydumper/mydumper#how-to-install-mydumpermyloader) (). GitHub
1. Se utiliza MyDumper para crear una copia de seguridad de la base de datos MySQL o MariaDB de origen. Para obtener instrucciones, consulte [Cómo usarlo](https://github.com/mydumper/mydumper#how-to-use-mydumper). MyDumper
1. Mueva el archivo de respaldo a una instancia EC2 de la siguiente manera: Nube de AWS
**Método 3A**: monte un sistema de archivos [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) [o Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) en el servidor local que ejecuta la instancia de base de datos. Puede usar AWS Direct Connect o Site-to-Site VPN para establecer la conexión. Puede hacer una copia de seguridad de la base de datos de manera directa en el recurso compartido de archivos montado o puede hacer la copia de seguridad en dos pasos: haga una copia de seguridad de la base de datos en un sistema de archivos local y, a continuación, cárguela en el volumen de FSx o EFS montado. A continuación, monte el sistema de archivos de Amazon FSx o Amazon EFS, que también está montado en el servidor en las instalaciones, en una instancia de EC2.
**Método 3B**: utilice el AWS CLI AWS SDK o la API REST de Amazon S3 para mover directamente el archivo de respaldo del servidor local a un bucket de S3. Si el depósito S3 de destino se encuentra en un Región de AWS lugar alejado del centro de datos, puede utilizar [Amazon S3 Transfer Acceleration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) para transferir el archivo con mayor rapidez. Utilice el sistema de archivos [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) para montar el bucket S3 en la instancia de EC2.
**Enfoque 3C**: instale el agente de AWS DataSync en el centro de datos en las instalaciones y utilice [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) para mover el archivo de copia de seguridad a un bucket de Amazon S3. Utilice el sistema de archivos [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) para montar el bucket S3 en la instancia de EC2.
**nota**
También puede utilizar Amazon S3 File Gateway para transferir los archivos de copia de seguridad de una base de datos grande a un bucket de S3 en la Nube de AWS. Para obtener más información, consulte la sección [Uso de Amazon S3 File Gateway para transferir archivos de copia de seguridad](amazon-s3-file-gateway.md) de esta guía.
1. Utilice myloader para restaurar la copia de seguridad en la instancia de base de datos de destino. Para obtener instrucciones, consulte [myloader usage](https://github.com/mydumper/mydumper_docs/blob/0e5cd71a5549c8a5de0105adf4d5f95953eadb67/myloader_usage.rst) (GitHub).
1. (Opcional) Puede configurar la replicación entre la base de datos de origen y la instancia de base de datos de destino. Puede utilizar la replicación del registro binario (binlog) para reducir el tiempo de inactividad. Para obtener más información, consulte los siguientes temas:
+ [Setting the replication source configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) en la documentación de MySQL
+ Para Amazon Aurora, consulte lo siguiente:
+ [Sincronización del clúster de base de datos de Amazon Aurora MySQL con la base de datos MySQL mediante replicación](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) en la documentación de Aurora
+ [Uso de la replicación de registro binario en Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) en la documentación de Aurora
+ Para Amazon RDS, consulte lo siguiente:
+ [Uso de la replicación de MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) en la documentación de Amazon RDS
+ [Uso de la replicación de MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) en la documentación de Amazon RDS
+ Para Amazon EC2, consulte lo siguiente:
+ [Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) en la documentación de MySQL
+ [Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) en la documentación de MySQL
+ [Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/) en la documentación de MariaDB
## Ventajas
+ MyDumper admite el paralelismo mediante el uso de subprocesos múltiples, lo que mejora la velocidad de las operaciones de copia de seguridad y restauración.
+ MyDumper evita costosas rutinas de conversión de conjuntos de caracteres, lo que ayuda a garantizar que el código sea altamente eficiente.
+ MyDumper simplifica la visualización y el análisis de los datos mediante la descarga de archivos separados para las tablas y los metadatos.
+ MyDumper mantiene instantáneas en todos los subprocesos y proporciona posiciones precisas de los registros principales y secundarios.
+ Puede utilizar las expresiones regulares compatibles con Perl (PCRE) para especificar si quiere incluir o excluir las tablas o las bases de datos.
## Limitaciones
+ Puede elegir otra herramienta si los procesos de transformación de datos requieren archivos de volcado intermedios en formato plano en lugar de formato SQL.
+ myloader no importa de manera automática las cuentas de usuario de la base de datos. Si va a restaurar la copia de seguridad en Amazon RDS o Aurora, vuelva a crear los usuarios con los permisos necesarios. Para más información, consulte[Privilegios de la cuenta de usuario maestro](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.MasterAccounts.html) en la documentación de Amazon RDS. Si va a restaurar la copia de seguridad en una instancia de base de datos de Amazon EC2, puede exportar de manera manual las cuentas de usuario de la base de datos de origen e importarlas a la instancia de EC2.
## Prácticas recomendadas
+ Configúrela MyDumper para dividir cada tabla en segmentos, por ejemplo, 10 000 filas en cada segmento, y escriba cada segmento en un archivo independiente. Esto permite importar los datos en paralelo más tarde.
+ Si utiliza el motor de InnoDB, utilice la opción `--trx-consistency-only` para minimizar el bloqueo.
+ El uso de la base de datos MyDumper para exportar puede resultar intensivo en lectura y el proceso puede afectar al rendimiento general de la base de datos de producción. Si tiene una instancia de base de datos de réplica, ejecute el proceso de exportación desde la réplica. Antes de ejecutar la exportación desde la réplica, detenga el subproceso de SQL de replicación. De este modo, el proceso de exportación se ejecute con mayor rapidez.
+ No exporte la base de datos durante las horas de mayor actividad. Evitar las horas de mayor actividad puede estabilizar el rendimiento de la base de datos de producción principal durante la exportación de la base de datos.
+ Amazon RDS para MySQL no admite el complemento `keyring_aws`. Para más información, consulte [Known issues and limitations](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.KnownIssuesAndLimitations.html#MySQL.Concepts.Limits.KeyRing). Para migrar las tablas cifradas en las instalaciones a la instancia de Amazon RDS, en los scripts de copia de seguridad, debe eliminar `ENCRYPTION` o `DEFAULT ENCRYPTION` de la sintaxis `CREATE TABLE`. Para el cifrado en reposo, puede utilizar una clave AWS Key Management Service (AWS KMS). Para obtener más información, consulte [Cifrado de recursos de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html).
# mysqldump y mysqlpump
[mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) y [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html) son herramientas de copia de seguridad de bases de datos nativas para MySQL. MariaDB es compatible con mysqldump, pero no con mysqlpump. Ambas herramientas crean copias de seguridad lógicas y forman parte de los programas cliente de MySQL. mysqldump admite el procesamiento de un solo subproceso. mysqlpump admite el procesamiento paralelo de bases de datos y objetos en las bases de datos para acelerar el proceso de volcado. Se introdujo en la versión 5.7.8 de MySQL. mysqlpump se eliminó en la versión 8.4 de MySQL.
En el diagrama siguiente se muestran los pasos generales que implica migrar una base de datos con un archivo de copia de seguridad de mysqldump o mysqlpump.
![\[Diagrama que muestra la migración de un archivo de respaldo de mysqldump o mysqlpump y su restauración en una instancia de base de datos. AWS\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mysqldump-mysqlpump-migration-aws.png)
A continuación, se muestran los pasos para utilizar mysqldump o mysqlpump para migrar una base de datos a la Nube de AWS.
1. Instale MySQL Shell en el servidor en las instalaciones. Para ver las instrucciones, consulte [Installing MySQL Shell](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-install-linux-quick.html) en la documentación de MySQL. Esto instala mysqldump y mysqlpump.
1. Con mysqldump o mysqlpump, cree una copia de seguridad de la base de datos de origen en las instalaciones. Para obtener instrucciones, consulte [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) and [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html) en la documentación de MySQL, o consulte [Making Backups with mysqldump](https://mariadb.com/kb/en/making-backups-with-mysqldump/) en la documentación de MariaDB. Para más información sobre la invocación de programas de MySQL y la especificación de opciones, consulte [Using MySQL programs](https://dev.mysql.com/doc/refman/8.0/en/programs-using.html).
1. Mueva el archivo de respaldo a una instancia EC2 de la siguiente manera: Nube de AWS
**Método** **3A**: monte un sistema de archivos [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) [o Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) en el servidor local que ejecuta la instancia de base de datos. Puede usar AWS Direct Connect o Site-to-Site VPN para establecer la conexión. Puede hacer una copia de seguridad de la base de datos de manera directa en el recurso compartido de archivos montado o puede hacer la copia de seguridad en dos pasos: haga una copia de seguridad de la base de datos en un sistema de archivos local y, a continuación, cárguela en el volumen de FSx o EFS montado. A continuación, monte el sistema de archivos de Amazon FSx o Amazon EFS, que también está montado en el servidor en las instalaciones, en una instancia de EC2.
**Método 3B**: utilice el AWS CLI AWS SDK o la API REST de Amazon S3 para mover directamente el archivo de respaldo del servidor local a un bucket de S3. Si el depósito S3 de destino se encuentra en un Región de AWS lugar alejado del centro de datos, puede utilizar [Amazon S3 Transfer Acceleration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) para transferir el archivo con mayor rapidez. Utilice el sistema de archivos [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) para montar el bucket S3 en la instancia de EC2.
**Enfoque 3C**: instale el agente de AWS DataSync en el centro de datos en las instalaciones y utilice [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) para mover el archivo de copia de seguridad a un bucket de Amazon S3. Utilice el sistema de archivos [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) para montar el bucket S3 en la instancia de EC2.
**nota**
También puede utilizar Amazon S3 File Gateway para transferir los archivos de copia de seguridad de una base de datos grande a un bucket de S3 en la Nube de AWS. Para obtener más información, consulte la sección [Uso de Amazon S3 File Gateway para transferir archivos de copia de seguridad](amazon-s3-file-gateway.md) de esta guía.
1. Utilice el método de restauración nativo para restaurar la copia de seguridad en la base de datos de destino. Para obtener instrucciones, consulte [Reloading SQL-Format Backups](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html) en la documentación de MySQL o consulte [Restoring Data from Dump Files](https://mariadb.com/kb/en/restoring-data-from-dump-files/) en la documentación de MariaDB.
1. (Opcional) Puede configurar la replicación entre la base de datos de origen y la instancia de base de datos de destino. Puede utilizar la replicación del registro binario (binlog) para reducir el tiempo de inactividad. Para obtener más información, consulte los siguientes temas:
+ [Setting the replication source configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) en la documentación de MySQL
+ Para Amazon Aurora, consulte lo siguiente:
+ [Sincronización del clúster de base de datos de Amazon Aurora MySQL con la base de datos MySQL mediante replicación](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) en la documentación de Aurora
+ [Uso de la replicación de registro binario en Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) en la documentación de Aurora
+ Para Amazon RDS, consulte lo siguiente:
+ [Uso de la replicación de MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) en la documentación de Amazon RDS
+ [Uso de la replicación de MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) en la documentación de Amazon RDS
+ Para Amazon EC2, consulte lo siguiente:
+ [Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) en la documentación de MySQL
+ [Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) en la documentación de MySQL
+ [Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/) en la documentación de MariaDB
## Ventajas
+ mysqldump y mysqlpump se incluyen en la instalación de MySQL Server
+ Los archivos de copia de seguridad que generan estas herramientas están en un formato más legible.
+ Antes de restaurar el archivo de copia de seguridad, puede modificar el archivo .sql resultante mediante un editor de texto estándar.
+ Puede hacer una copia de seguridad de una tabla, base de datos o incluso de una selección de datos concreta.
+ mysqldump y mysqlpump son independientes de la arquitectura de la máquina.
## Limitaciones
+ mysqldump es un proceso de copias de seguridad de un solo subproceso. El rendimiento al hacer una copia de seguridad es bueno para bases de datos pequeñas, pero puede resultar ineficiente cuando el tamaño de la copia de seguridad es superior a 10 GB.
+ Los archivos de copia de seguridad en formato lógico son voluminosos, sobre todo cuando se guardan como texto, y suelen tardar en crearse y restaurarse.
+ La restauración de los datos puede resultar lenta porque volver a aplicar las sentencias SQL en la instancia de base de datos de destino implica un procesamiento intensivo del disco I/O y la CPU para su inserción, creación de índices y aplicación de las restricciones de integridad referencial.
+ La utilidad mysqlpump no es compatible con las versiones de MySQL anteriores a la 5.7.8 ni a las versiones 8.4 y posteriores.
+ De manera predeterminada, mysqlpump no hace copias de seguridad de las bases de datos del sistema, por ejemplo, `performance_schema` o `sys`. Para hacer una copia de seguridad de una parte de la base de datos del sistema, asígnele un nombre explícito en la línea de comandos.
+ mysqldump no hace copias de seguridad de las instrucciones `CREATE TABLESPACE` de InnoDB
**nota**
Las copias de seguridad de las instrucciones CREATE TABLESPACE y las bases de datos del sistema solo son útiles cuando se restauran las copias de seguridad de las bases de datos de MySQL o MariaDB en una instancia de EC2. Estas copias de seguridad no se utilizan para Amazon RDS ni Aurora.
## Prácticas recomendadas
+ Cuando restaure la copia de seguridad de la base de datos, desactive las comprobaciones clave, por ejemplo `FOREIGN_KEY_CHECKS`, de la sesión en la base de datos de destino. Esto aumenta la velocidad de restauración.
+ Asegúrese de que el usuario de la base de datos tenga los [privilegios](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html) suficientes para crear y restaurar la copia de seguridad.
# Copia de seguridad dividida
Una estrategia de *división de copia de seguridad* consiste en migrar un servidor de bases de datos grande al dividir la copia de seguridad en varias partes. Podría utilizar enfoques distintos para migrar cada parte de la copia de seguridad. Esta puede ser la mejor opción para los casos de uso siguientes:
+ **Servidor de bases de datos grande pero bases de datos individuales pequeñas**: este es un buen enfoque cuando el tamaño total del servidor de bases de datos es múltiple, TBs pero el tamaño de cada base de datos de usuario individual e independiente es inferior a 1 TB. Para reducir el periodo de migración general, puede migrar bases de datos individuales por separado y en paralelo.
Utilicemos un ejemplo de un servidor de base de datos en las instalaciones de 2 TB. Este servidor consta de cuatro bases de datos de 0,5 TB cada una. Puede hacer copias de seguridad de cada base de datos individual por separado. Al restaurar la copia de seguridad, puede restaurar todas las bases de datos de una instancia en paralelo o, si las bases de datos son independientes, puede restaurar cada copia de seguridad en una instancia independiente. Se recomienda restaurar las bases de datos independientes en instancias distintas, en lugar de restaurarlas en la misma instancia. Para más información, consulte la sección Prácticas recomendadas de guía.
+ **Servidor de bases de datos grande pero tablas de bases de datos individuales pequeñas**: este es un buen enfoque cuando el tamaño total del servidor de bases de datos es múltiple TBs , pero el tamaño de cada tabla de base de datos independiente es inferior a 1 TB. Para reducir el periodo de migración general, puede migrar tablas independientes de manera individual.
Utilicemos un ejemplo de una base de datos de un solo usuario de 1 TB y que es la única base de datos de un servidor de bases de datos en las instalaciones. Hay 10 tablas en la base de datos y cada una tiene 100 GB. Puede hacer copias de seguridad de cada tabla individual por separado. Al restaurar la copia de seguridad, puede restaurar todas las tablas de una instancia en paralelo.
+ **Una base de datos contiene tablas de cargas de trabajo transaccionales y no transaccionales**: al igual que en el caso de uso anterior, puede utilizar un enfoque de copia de seguridad dividida cuando tiene tablas de cargas de trabajo transaccionales y no transaccionales en la misma base de datos.
Utilicemos un ejemplo de una base de datos de 2 TB que consta de 0,5 TB de tablas de cargas de trabajo críticas que se utilizan para el procesamiento de transacciones en línea (OLTP) y una sola tabla de 1,5 TB que se utiliza para archivar datos antiguos. Puede hacer la copia de seguridad de todos los objetos de la base de datos, excepto la tabla de archivo, como una copia de seguridad coherente y de una sola transacción. A continuación, haga otra copia de seguridad independiente de la tabla de archivo únicamente. Para la copia de seguridad de la tabla de archivo, también puede considerar la posibilidad de hacer varias copias de seguridad paralelas con condiciones para dividir el número de filas del archivo de copia de seguridad. A continuación, se muestra un ejemplo:
```
mysqldump -p your_db1 --tables your_table1 --where="column1 between 1 and 1000000 " > your_table1_part1.sql
mysqldump -p your_db1 --tables your_table1 --where="column1 between 1000001 and 2000000 " > your_table1_part2.sql
mysqldump -p your_db1 --tables your_table1 --where="column1 > 2000000 " > your_table1_part3.sql
```
Al restaurar los archivos de copia de seguridad, puede restaurar la copia de seguridad de la carga de trabajo transaccional y la copia de seguridad de la tabla de archivo en paralelo.
+ **Limitaciones de recursos de computación**: si tiene recursos de computación limitados en el servidor en las instalaciones, como la CPU, la memoria o las E/S del disco, esto puede afectar a la estabilidad y al rendimiento al hacer la copia de seguridad. En lugar de hacer una copia de seguridad completa, puede dividirla en partes.
Por ejemplo, un servidor de producción en las instalaciones puede estar muy cargado de cargas de trabajo y tener recursos de CPU limitados. Si hace una copia de seguridad de una sola ejecución de una base de datos de varios terabytes en este servidor, puede consumir recursos de CPU adicionales y afectar de manera negativa al servidor de producción. En lugar de hacer la copia de seguridad completa de la base de datos, divida la copia de seguridad en varias partes, por ejemplo, de 2 a 3 tablas cada una.