Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Options de migration pour les grandes bases de données MySQL et MariaDB
Vous pouvez choisir parmi une vaste gamme d'options pour migrer des bases de données MySQL ou MariaDB sur site vers des instances de bases de données Amazon Relational Database Service (Amazon RDS) ou Amazon Aurora MySQL Edition compatible. Le choix de l'approche et du bon outil de migration est essentiel pour une migration réussie. Dans ce guide, vous évaluez les options en fonction de votre facilité d'utilisation, de la taille des données et de vos exigences en matière de temps d'arrêt.
Voici les outils et approches de migration courants disponibles pour migrer efficacement des bases de données MySQL autogérées de plusieurs téraoctets vers des instances de base de données Amazon RDS, Aurora ou Amazon Elastic Compute Cloud (Amazon EC2) :
+ [Percona XtraBackup](percona-xtrabackup.md)(Physique)
+ [MyDumper](mydumper.md)(Logique)
+ [mysqldump et mysqlpump](mysqldump-and-mysqlpump.md)(Logique)
+ [Sauvegarde fractionnée](split-backup.md)(Physique, logique ou les deux)
Voici les outils et approches de migration courants disponibles pour migrer efficacement des bases de données compatibles avec MySQL de plusieurs téraoctets (telles que MariaDB) vers des instances de base de données Amazon RDS, Aurora ou Amazon EC2 :
+ [MyDumper](mydumper.md)(Logique)
+ [mysqldump et mysqlpump](mysqldump-and-mysqlpump.md)(Logique)
+ [Sauvegarde fractionnée](split-backup.md)(Physique, logique ou les deux)
Pour chaque outil de migration, vous pouvez utiliser plusieurs approches pour transférer le fichier de sauvegarde de base de données volumineux vers le AWS Cloud. Des options sont fournies pour chaque outil, et vous pouvez également utiliser Amazon S3 File Gateway. Pour plus d’informations, consultez [Utilisation d'Amazon S3 File Gateway pour transférer des fichiers de sauvegarde](amazon-s3-file-gateway.md) dans ce guide.
# Percona XtraBackup
**Important**
Percona n' XtraBackup est pas pris en charge pour les versions 10.3 ou ultérieures de MariaDB et n'est que partiellement pris en charge pour les versions 10.1 et 10.2.
[Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/index.html) est un logiciel de sauvegarde à chaud open source courant pour MySQL et MariaDB qui effectue des sauvegardes non bloquantes pour les moteurs de stockage InnoDB et XtraDB. Il fonctionne avec les serveurs MySQL ou MariaDB. Pour plus d'informations sur l'outil et certaines de ses fonctionnalités et avantages, voir [À propos de Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/about-xtrabackup.html) dans la documentation Percona XtraBackup .
Cet outil utilise l'approche de migration physique. Il copie directement le répertoire de données MySQL ou MariaDB et les fichiers qu'il contient. Pour les bases de données volumineuses, telles que celles de plus de 100 Go, cela peut fournir un temps de restauration nettement supérieur à celui de certains autres outils. Vous créez une sauvegarde de la base de données source sur site, vous migrez les fichiers de sauvegarde vers le cloud, puis vous restaurez la sauvegarde sur la nouvelle instance de base de données cible.
Le schéma suivant montre les étapes de haut niveau impliquées dans la migration d'une base de données à l'aide d'un fichier de XtraBackup sauvegarde Percona. Selon la taille du fichier de sauvegarde, deux options sont disponibles pour transférer la sauvegarde vers un bucket Amazon Simple Storage Service (Amazon S3) situé dans le. AWS Cloud
![\[Schéma de migration d'un XtraBackup fichier Percona et de sa restauration sur une AWS instance de base de données.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/percona-xtrabackup-migration-aws.png)
Voici les étapes à suivre pour utiliser Percona pour XtraBackup migrer une base de données vers : AWS Cloud
1. Installez Percona XtraBackup sur le serveur local. Si vous utilisez Amazon Aurora MySQL version 2 ou Amazon RDS, consultez [Installation de Percona 2.4 XtraBackup](https://docs.percona.com/percona-xtrabackup/2.4/installation.html). Si vous utilisez Amazon Aurora MySQL version 3, consultez la section Installation de [Percona XtraBackup 8.0](https://docs.percona.com/percona-xtrabackup/8.0/installation.html) dans la documentation Percona XtraBackup.
1. Créez une sauvegarde complète de la base de données source MySQL ou MariaDB. Pour les instructions relatives à Percona XtraBackup 2.4, voir [Sauvegarde complète](https://docs.percona.com/percona-xtrabackup/2.4/backup_scenarios/full_backup.html). Pour obtenir des instructions relatives à Percona XtraBackup 8.0, voir [Création d'une sauvegarde complète](https://docs.percona.com/percona-xtrabackup/8.0/create-full-backup.html).
1. Transférez les fichiers de sauvegarde sur Internet à l'aide d'un service ou d'un outil approuvé dans votre organisation, tel que le suivant :
+ [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) (pour plus d'informations, consultez [Utilisation d'Amazon S3 File Gateway pour transférer des fichiers de sauvegarde](amazon-s3-file-gateway.md) ce guide.)
+ [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/getting-started/hands-on/backup-to-s3-cli/)
1. À partir du compartiment Amazon S3, restaurez les fichiers de sauvegarde sur l'instance de base de données cible. Pour obtenir des instructions, veuillez consulter les sections suivantes :
+ Pour l'édition compatible avec Aurora MySQL, consultez la section [Migration de données depuis MySQL à l'aide d'un compartiment Amazon S3 dans](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.Restore) la documentation Amazon RDS.
+ Pour Amazon RDS for MySQL ou Amazon EC2[, consultez Importation de données dans une instance de base de données MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.Other.html).
+ Pour Amazon RDS pour MariaDB ou pour Amazon EC2, [consultez Importation de données dans une instance de base de données](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MariaDB.Procedural.Importing.html) MariaDB.
1. (Facultatif) Vous pouvez configurer la réplication entre la base de données source et l'instance de base de données cible. Vous pouvez utiliser la réplication des journaux binaires (binlog) pour réduire les temps d'arrêt. Pour plus d’informations, consultez les ressources suivantes :
+ [Configuration de la source de réplication](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) dans la documentation MySQL
+ Pour Amazon Aurora, consultez les informations suivantes :
+ [Synchronisation du cluster de base de données Amazon Aurora MySQL avec la base de données MySQL à l'aide de la réplication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) dans la documentation Aurora
+ [Utilisation de la réplication binlog dans Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) dans la documentation d'Aurora
+ Pour Amazon RDS, consultez les rubriques suivantes :
+ [Utilisation de la réplication MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) dans la documentation Amazon RDS
+ [Utilisation de la réplication MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) dans la documentation Amazon RDS
+ Pour Amazon EC2, consultez les rubriques suivantes :
+ [Configuration de la réplication basée sur la position du fichier journal binaire](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) dans la documentation MySQL
+ [Configuration des répliques](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) dans la documentation MySQL
+ [Configuration de la réplication](https://mariadb.com/kb/en/setting-up-replication/) dans la documentation MariaDB
## Avantages
+ Percona XtraBackup utilisant une approche de migration physique, le processus de restauration est généralement plus rapide que les outils utilisant une approche de migration logique. Cela est dû au fait que les performances sont limitées par le débit du disque ou du réseau plutôt que par les ressources informatiques nécessaires au traitement des données.
+ Le processus de restauration étant une copie directe des fichiers du compartiment S3 vers l'instance de base de données cible, les XtraBackup fichiers Percona sont généralement restaurés plus rapidement que les fichiers de sauvegarde créés avec d'autres outils.
+ Percona XtraBackup est adaptable. Par exemple, il prend en charge plusieurs threads pour vous aider à copier des fichiers plus rapidement et prend en charge la compression pour réduire la taille de la sauvegarde.
## Limitations
+ La sauvegarde hors ligne n'est pas possible car Percona XtraBackup doit avoir accès au serveur de base de données source.
+ Percona ne XtraBackup peut être utilisé que sur des systèmes dotés d'architectures système identiques. Par exemple, il n'est pas possible de restaurer une sauvegarde d'une base de données source exécutée sur Intel pour Windows Server sur un serveur cible ARM pour Linux.
+ Percona XtraBackup n'est pas pris en charge pour MariaDB version 10.3 ou ultérieure, et il n'est que partiellement pris en charge pour MariaDB versions 10.2 et 10.1. Pour plus d'informations, voir [ XtraBackup Présentation de Percona : compatibilité avec MariaDB dans la base](https://mariadb.com/kb/en/percona-xtrabackup-overview/#compatibility-with-mariadb) de connaissances MariaDB.
+ Vous ne pouvez pas utiliser Percona XtraBackup pour restaurer une base de données MariaDB source sur une instance de base de données MySQL cible, telle qu'Amazon RDS for MySQL ou Aurora MySQL compatible.
+ Le volume total de données et le nombre d'objets que vous pouvez stocker dans un compartiment S3 sont illimités, mais la taille maximale du fichier est de 5 To. Si votre fichier de sauvegarde dépasse 5 To, vous pouvez le diviser en plusieurs fichiers plus petits.
+ Lorsque le `innodb_file_per_table` paramètre est désactivé, Percona XtraBackup ne prend pas en charge les sauvegardes partielles qui utilisent `--tables``--tables-exclude`,`--tables-file`,, `--databases``--databases-exclude`, ou`--databases-file`. Pour plus d'informations sur Percona XtraBackup version 2.4, voir [Sauvegardes partielles](https://docs.percona.com/percona-xtrabackup/2.4/innobackupex/partial_backups_innobackupex.html). Pour plus d'informations sur Percona XtraBackup version 8.0, voir [Création d'une sauvegarde partielle](https://docs.percona.com/percona-xtrabackup/8.0/create-partial-backup.html).
## Bonnes pratiques
+ Pour améliorer les performances du processus de sauvegarde, procédez comme suit :
+ Copiez plusieurs fichiers en parallèle en utilisant [--parallel=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-parallel)
+ Compressez plusieurs fichiers en parallèle en utilisant [--compress-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-compress-threads)
+ Augmentez la mémoire en utilisant [--use-memory=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-use-memory)
+ [Chiffrez plusieurs fichiers en parallèle en utilisant --encrypt-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-encrypt-threads)
+ Assurez-vous qu'il y a suffisamment d'espace sur le serveur source pour enregistrer les fichiers de sauvegarde de la base de données.
+ Générez la sauvegarde de base de données avec le fichier au format Percona xbstream (.xbstream). Pour plus d'informations, consultez [la présentation du binaire xbstream](https://docs.percona.com/percona-xtrabackup/8.0/xbstream-binary-overview.html) dans la documentation de XtraBackup Percona.
# MyDumper
[MyDumper](https://github.com/mydumper/mydumper#what-is-mydumper)(GitHub) est un outil de migration logique open source composé de deux utilitaires :
+ MyDumper exporte une sauvegarde cohérente des bases de données MySQL. Il prend en charge la sauvegarde de la base de données en utilisant plusieurs threads parallèles, jusqu'à un thread par cœur de processeur disponible.
+ myloader lit les fichiers de sauvegarde créés par MyDumper, se connecte à l'instance de base de données cible, puis restaure la base de données.
Le schéma suivant montre les étapes de haut niveau de la migration d'une base de données à l'aide d'un fichier MyDumper de sauvegarde. Ce schéma d'architecture inclut trois options pour migrer le fichier de sauvegarde du centre de données sur site vers une instance EC2 dans le. AWS Cloud
![\[Schéma de migration d'un fichier de MyDumper sauvegarde et d'utilisation de myloader pour le restaurer sur l'instance de AWS base de données.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mydumper-myloader-migration-aws.png)
Voici les étapes à suivre pour MyDumper migrer une base de données vers AWS Cloud :
1. Installer MyDumper et myloader. Pour obtenir des instructions, consultez [Comment installer mydumper/myloader](https://github.com/mydumper/mydumper#how-to-install-mydumpermyloader) (). GitHub
1. MyDumper À utiliser pour créer une sauvegarde de la base de données source MySQL ou MariaDB. Pour obtenir des instructions, reportez-vous [à la section Comment utiliser MyDumper](https://github.com/mydumper/mydumper#how-to-use-mydumper).
1. Déplacez le fichier de sauvegarde vers une instance EC2 dans le en AWS Cloud utilisant l'une des approches suivantes :
**Approche 3A** — Montez un système de fichiers [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) [ou Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) sur le serveur local qui exécute votre instance de base de données. Vous pouvez utiliser AWS Direct Connect ou Site-to-Site VPN pour établir la connexion. Vous pouvez sauvegarder directement la base de données sur le partage de fichiers monté, ou vous pouvez effectuer la sauvegarde en deux étapes en sauvegardant la base de données sur un système de fichiers local, puis en la téléchargeant sur le volume FSx ou EFS monté. Ensuite, montez le système de fichiers Amazon FSx ou Amazon EFS, qui est également monté sur le serveur local, sur une instance EC2.
**Approche 3B** — Utilisez le AWS CLI AWS SDK ou l'API REST Amazon S3 pour déplacer directement le fichier de sauvegarde du serveur sur site vers un compartiment S3. Si le compartiment S3 cible se trouve dans un Région AWS endroit éloigné du centre de données, vous pouvez utiliser [Amazon S3 Transfer Acceleration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) pour transférer le fichier plus rapidement. Utilisez le système de fichiers [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) pour monter le compartiment S3 sur l'instance EC2.
**Approche 3C** — Installez l' AWS DataSync agent dans le centre de données local, puis utilisez-le [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)pour déplacer le fichier de sauvegarde vers un compartiment Amazon S3. Utilisez le système de fichiers [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) pour monter le compartiment S3 sur l'instance EC2.
**Note**
Vous pouvez également utiliser Amazon S3 File Gateway pour transférer les fichiers de sauvegarde de base de données volumineux vers un compartiment S3 du AWS Cloud. Pour plus d’informations, consultez [Utilisation d'Amazon S3 File Gateway pour transférer des fichiers de sauvegarde](amazon-s3-file-gateway.md) dans ce guide.
1. Utilisez myloader pour restaurer la sauvegarde sur l'instance de base de données cible. Pour obtenir des instructions, consultez [myloader usage](https://github.com/mydumper/mydumper_docs/blob/0e5cd71a5549c8a5de0105adf4d5f95953eadb67/myloader_usage.rst) (GitHub).
1. (Facultatif) Vous pouvez configurer la réplication entre la base de données source et l'instance de base de données cible. Vous pouvez utiliser la réplication des journaux binaires (binlog) pour réduire les temps d'arrêt. Pour plus d’informations, consultez les ressources suivantes :
+ [Configuration de la source de réplication](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) dans la documentation MySQL
+ Pour Amazon Aurora, consultez les informations suivantes :
+ [Synchronisation du cluster de base de données Amazon Aurora MySQL avec la base de données MySQL à l'aide de la réplication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) dans la documentation Aurora
+ [Utilisation de la réplication binlog dans Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) dans la documentation d'Aurora
+ Pour Amazon RDS, consultez les rubriques suivantes :
+ [Utilisation de la réplication MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) dans la documentation Amazon RDS
+ [Utilisation de la réplication MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) dans la documentation Amazon RDS
+ Pour Amazon EC2, consultez les rubriques suivantes :
+ [Configuration de la réplication basée sur la position du fichier journal binaire](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) dans la documentation MySQL
+ [Configuration des répliques](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) dans la documentation MySQL
+ [Configuration de la réplication](https://mariadb.com/kb/en/setting-up-replication/) dans la documentation MariaDB
## Avantages
+ MyDumper prend en charge le parallélisme en utilisant le multithreading, qui améliore la vitesse des opérations de sauvegarde et de restauration.
+ MyDumper évite les routines coûteuses de conversion de jeux de caractères, ce qui contribue à garantir l'efficacité du code.
+ MyDumper simplifie l'affichage et l'analyse des données en utilisant le vidage de fichiers séparés pour les tables et les métadonnées.
+ MyDumper gère les instantanés sur tous les threads et fournit des positions précises des journaux principaux et secondaires.
+ Vous pouvez utiliser les expressions régulières compatibles Perl (PCRE) pour spécifier s'il faut inclure ou exclure des tables ou des bases de données.
## Limitations
+ Vous pouvez choisir un autre outil si vos processus de transformation de données nécessitent des fichiers de vidage intermédiaires au format plat au lieu du format SQL.
+ myloader n'importe pas automatiquement les comptes utilisateur de la base de données. Si vous restaurez la sauvegarde sur Amazon RDS ou Aurora, recréez les utilisateurs avec les autorisations requises. Pour plus d'informations, consultez la section [Privilèges du compte utilisateur principal](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.MasterAccounts.html) dans la documentation Amazon RDS. Si vous restaurez la sauvegarde sur une instance de base de données Amazon EC2, vous pouvez exporter manuellement les comptes utilisateur de la base de données source et les importer dans l'instance EC2.
## Bonnes pratiques
+ Configurez MyDumper pour diviser chaque table en segments, par exemple 10 000 lignes dans chaque segment, et écrivez chaque segment dans un fichier distinct. Cela permet d'importer les données en parallèle ultérieurement.
+ Si vous utilisez le moteur InnoDB, utilisez l'`--trx-consistency-only`option pour minimiser le verrouillage.
+ L'exportation MyDumper de la base de données peut nécessiter beaucoup de lecture et le processus peut avoir un impact sur les performances globales de la base de données de production. Si vous disposez d'une instance de base de données répliquée, exécutez le processus d'exportation à partir de la réplique. Avant d'exécuter l'exportation depuis le réplica, arrêtez le thread SQL de réplication. Cela permet au processus d'exportation de s'exécuter plus rapidement.
+ N'exportez pas la base de données pendant les heures de pointe. En évitant les heures de pointe, vous pouvez stabiliser les performances de votre base de données de production principale lors de l'exportation de la base de données.
+ Amazon RDS for MySQL ne prend pas en charge `keyring_aws` le plug-in. Pour plus d'informations, consultez la section [Problèmes et limites connus](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.KnownIssuesAndLimitations.html#MySQL.Concepts.Limits.KeyRing). Pour migrer les tables chiffrées sur site vers l'instance Amazon RDS, vous devez supprimer `ENCRYPTION` ou supprimer la syntaxe dans les scripts `DEFAULT ENCRYPTION` de sauvegarde. `CREATE TABLE` Pour le chiffrement au repos, vous pouvez utiliser une clé AWS Key Management Service (AWS KMS). Pour plus d’informations, consultez [Chiffrer des ressources Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html).
# mysqldump et mysqlpump
[mysqldump et [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html)](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) sont des outils de sauvegarde de base de données natifs pour MySQL. MariaDB supporte mysqldump mais ne supporte pas mysqlpump. Ces deux outils créent des sauvegardes logiques et font partie des programmes clients MySQL. mysqldump prend en charge le traitement monothread. mysqlpump prend en charge le traitement parallèle des bases de données et des objets au sein des bases de données, afin d'accélérer le processus de vidage. Il a été introduit dans la version 5.7.8 de MySQL. mysqlpump a été supprimé dans la version 8.4 de MySQL.
Le schéma suivant montre les étapes de haut niveau impliquées dans la migration d'une base de données à l'aide d'un fichier de sauvegarde mysqldump ou mysqlpump.
![\[Schéma de migration d'un fichier de sauvegarde mysqldump ou mysqlpump et de sa restauration sur une instance de base de données. AWS\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mysqldump-mysqlpump-migration-aws.png)
Voici les étapes à suivre pour utiliser mysqldump ou mysqlpump pour migrer une base de données vers : AWS Cloud
1. Installez MySQL Shell sur le serveur local. Pour obtenir des instructions, consultez la section [Installation de MySQL Shell](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-install-linux-quick.html) dans la documentation MySQL. Ceci installe à la fois mysqldump et mysqlpump.
1. À l'aide de mysqldump ou mysqlpump, créez une sauvegarde de la base de données source sur site. Pour obtenir des instructions, consultez [mysqldump et mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) [dans la documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html), ou [consultez Making Backups with mysqldump](https://mariadb.com/kb/en/making-backups-with-mysqldump/) dans la documentation MariaDB. Pour plus d'informations sur l'appel de programmes MySQL et la spécification d'options, consultez [Utilisation de programmes MySQL](https://dev.mysql.com/doc/refman/8.0/en/programs-using.html).
1. Déplacez le fichier de sauvegarde vers une instance EC2 dans le en AWS Cloud utilisant l'une des approches suivantes :
**Approche** **3A** — Montez un système de fichiers [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) [ou Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) sur le serveur local qui exécute votre instance de base de données. Vous pouvez utiliser AWS Direct Connect ou Site-to-Site VPN pour établir la connexion. Vous pouvez sauvegarder directement la base de données sur le partage de fichiers monté, ou vous pouvez effectuer la sauvegarde en deux étapes en sauvegardant la base de données sur un système de fichiers local, puis en la téléchargeant sur le volume FSx ou EFS monté. Ensuite, montez le système de fichiers Amazon FSx ou Amazon EFS, qui est également monté sur le serveur local, sur une instance EC2.
**Approche 3B** — Utilisez le AWS CLI AWS SDK ou l'API REST Amazon S3 pour déplacer directement le fichier de sauvegarde du serveur sur site vers un compartiment S3. Si le compartiment S3 cible se trouve dans un Région AWS endroit éloigné du centre de données, vous pouvez utiliser [Amazon S3 Transfer Acceleration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) pour transférer le fichier plus rapidement. Utilisez le système de fichiers [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) pour monter le compartiment S3 sur l'instance EC2.
**Approche 3C** — Installez l' AWS DataSync agent dans le centre de données local, puis utilisez-le [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)pour déplacer le fichier de sauvegarde vers un compartiment Amazon S3. Utilisez le système de fichiers [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) pour monter le compartiment S3 sur l'instance EC2.
**Note**
Vous pouvez également utiliser Amazon S3 File Gateway pour transférer les fichiers de sauvegarde de base de données volumineux vers un compartiment S3 du AWS Cloud. Pour plus d’informations, consultez [Utilisation d'Amazon S3 File Gateway pour transférer des fichiers de sauvegarde](amazon-s3-file-gateway.md) dans ce guide.
1. Utilisez la méthode de restauration native pour restaurer la sauvegarde sur la base de données cible. Pour obtenir des instructions, consultez [Reloading SQL backups](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html) dans la documentation MySQL, ou consultez [Restaurer des données à partir de fichiers dump](https://mariadb.com/kb/en/restoring-data-from-dump-files/) dans la documentation MariaDB.
1. (Facultatif) Vous pouvez configurer la réplication entre la base de données source et l'instance de base de données cible. Vous pouvez utiliser la réplication des journaux binaires (binlog) pour réduire les temps d'arrêt. Pour plus d’informations, consultez les ressources suivantes :
+ [Configuration de la source de réplication](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) dans la documentation MySQL
+ Pour Amazon Aurora, consultez les informations suivantes :
+ [Synchronisation du cluster de base de données Amazon Aurora MySQL avec la base de données MySQL à l'aide de la réplication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) dans la documentation Aurora
+ [Utilisation de la réplication binlog dans Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) dans la documentation d'Aurora
+ Pour Amazon RDS, consultez les rubriques suivantes :
+ [Utilisation de la réplication MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) dans la documentation Amazon RDS
+ [Utilisation de la réplication MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) dans la documentation Amazon RDS
+ Pour Amazon EC2, consultez les rubriques suivantes :
+ [Configuration de la réplication basée sur la position du fichier journal binaire](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) dans la documentation MySQL
+ [Configuration des répliques](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) dans la documentation MySQL
+ [Configuration de la réplication](https://mariadb.com/kb/en/setting-up-replication/) dans la documentation MariaDB
## Avantages
+ mysqldump et mysqlpump sont inclus dans l'installation de MySQL Server
+ Les fichiers de sauvegarde générés par ces outils sont dans un format plus lisible.
+ Avant de restaurer le fichier de sauvegarde, vous pouvez modifier le fichier .sql obtenu à l'aide d'un éditeur de texte standard.
+ Vous pouvez sauvegarder une table, une base de données ou même une sélection de données spécifique.
+ mysqldump et mysqlpump sont indépendants de l'architecture de la machine.
## Limitations
+ mysqldump est un processus de sauvegarde monothread. Les performances de sauvegarde sont bonnes pour les petites bases de données, mais elles peuvent devenir inefficaces lorsque la taille de sauvegarde est supérieure à 10 Go.
+ Les fichiers de sauvegarde au format logique sont volumineux, en particulier lorsqu'ils sont enregistrés sous forme de texte, et leur création et leur restauration sont souvent lentes.
+ La restauration des données peut être lente car la réapplication des instructions SQL dans l'instance de base de données cible implique un traitement intensif du disque I/O et du processeur pour l'insertion, la création d'index et l'application des contraintes d'intégrité référentielle.
+ L'utilitaire mysqlpump n'est pas pris en charge pour les versions de MySQL antérieures à 5.7.8 ou pour les versions 8.4 et ultérieures.
+ Par défaut, mysqlpump n'effectue pas de sauvegarde des bases de données du système, telles que ou. `performance_schema` `sys` Pour sauvegarder une partie de la base de données système, nommez-la explicitement dans la ligne de commande.
+ mysqldump ne sauvegarde pas les instructions InnoDB. `CREATE TABLESPACE`
**Note**
Les sauvegardes des instructions CREATE TABLESPACE et des bases de données système ne sont utiles que lorsque vous restaurez des sauvegardes de bases de données MySQL ou MariaDB sur une instance EC2. Ces sauvegardes ne sont pas utilisées pour Amazon RDS ou Aurora.
## Bonnes pratiques
+ Lorsque vous restaurez la sauvegarde de la base de données, désactivez les contrôles clés, par exemple au niveau de la session dans la base de données cible. `FOREIGN_KEY_CHECKS` Cela augmente la vitesse de restauration.
+ Assurez-vous que l'utilisateur de la base de données dispose de [privilèges](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html) suffisants pour créer et restaurer la sauvegarde.
# Sauvegarde fractionnée
Une stratégie *de sauvegarde fractionnée* consiste à migrer un serveur de base de données volumineux en divisant la sauvegarde en plusieurs parties. Vous pouvez utiliser différentes approches pour migrer chaque partie de la sauvegarde. Cela peut être la meilleure option pour les cas d'utilisation suivants :
+ **Grand serveur de base de données mais petites bases de données individuelles** : cette approche est recommandée lorsque la taille totale du serveur de base de données est multiple TBs mais que la taille de chaque base de données utilisateur indépendante est inférieure à 1 To. Pour réduire la période de migration globale, vous pouvez migrer chaque base de données séparément et en parallèle.
Prenons l'exemple d'un serveur de base de données de 2 To sur site. Ce serveur est composé de quatre bases de données de 0,5 To chacune. Vous pouvez effectuer des sauvegardes de chaque base de données séparément. Lors de la restauration de la sauvegarde, vous pouvez soit restaurer toutes les bases de données d'une instance en parallèle, soit, si les bases de données sont indépendantes, vous pouvez restaurer chaque sauvegarde sur une instance distincte. Il est recommandé de restaurer des bases de données indépendantes sur des instances distinctes, au lieu de les restaurer sur la même instance. Pour plus d'informations, consultez la section Bonnes pratiques de ce guide.
+ **Grand serveur de base de données mais petites tables de base de données individuelles** : il s'agit d'une bonne approche lorsque la taille totale du serveur de base de données est multiple TBs mais que la taille de chaque table de base de données indépendante est inférieure à 1 To. Pour réduire la période de migration globale, vous pouvez migrer des tables indépendantes individuellement.
Prenons l'exemple d'une base de données mono-utilisateur de 1 To, qui est la seule base de données d'un serveur de base de données sur site. La base de données contient 10 tables, chacune d'une capacité de 100 Go. Vous pouvez effectuer des sauvegardes de chaque table séparément. Lors de la restauration de la sauvegarde, vous pouvez restaurer toutes les tables d'une instance en parallèle.
+ **Une base de données contient des tables de charge de travail transactionnelles et non transactionnelles**. Comme dans le cas d'utilisation précédent, vous pouvez utiliser une approche de sauvegarde fractionnée lorsque vous avez des tables de charge de travail transactionnelles et non transactionnelles dans la même base de données.
Prenons l'exemple d'une base de données de 2 To composée de 0,5 To de tables de charge de travail critiques utilisées pour le traitement des transactions en ligne (OLTP) et d'une seule table de 1,5 To utilisée pour archiver les anciennes données. Vous pouvez effectuer la sauvegarde de tous les objets de base de données, à l'exception de la table d'archive, dans le cadre d'une sauvegarde cohérente et unique. Ensuite, vous effectuez une autre sauvegarde séparée de la table d'archive uniquement. Pour la sauvegarde de la table d'archive, vous pouvez également envisager d'effectuer plusieurs sauvegardes parallèles en utilisant des conditions pour diviser le nombre de lignes du fichier de sauvegarde. Voici un exemple :
```
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
```
Lors de la restauration des fichiers de sauvegarde, vous pouvez restaurer la sauvegarde de la charge de travail transactionnelle et la sauvegarde de la table d'archivage en parallèle.
+ **Limitations des ressources de calcul** : si les ressources de calcul du serveur local sont limitées, telles que le processeur, la mémoire ou les E/S de disque, cela peut affecter la stabilité et les performances lors de la sauvegarde. Au lieu de faire une sauvegarde complète, vous pouvez la diviser en plusieurs parties.
Par exemple, un serveur de production sur site peut être chargé de charges de travail importantes et disposer de ressources CPU limitées. Si vous effectuez une sauvegarde en une seule exécution d'une base de données de plusieurs téraoctets sur ce serveur, cela peut consommer des ressources CPU supplémentaires et affecter négativement le serveur de production. Au lieu d'effectuer la sauvegarde complète de la base de données, divisez-la en plusieurs parties, telles que 2 à 3 tables chacune.