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.
# Importation de données dans une instance de base de données Amazon RDS for MySQL
Vous pouvez utiliser plusieurs techniques pour importer des données dans une instance de base de données RDS for MySQL. La meilleure approche dépend d’un certain nombre de facteurs :
+ Source des données
+ Quantité de données
+ Importation en une seule fois ou en continu
+ Durée d’indisponibilité
Si vous migrez également une application avec les données, tenez également compte de la durée d’indisponibilité que vous êtes prêt à accepter.
Le tableau suivant répertorie les techniques d’importation de données dans une instance de base de données RDS for MySQL :
| Source | Quantité de données | Une seule fois ou en continu | Interruption de l'application | Technique | En savoir plus |
| --- | --- | --- | --- | --- | --- |
| Base de données MySQL existante sur site ou sur Amazon EC2 | N'importe quel compte | Une seule fois | Momentanée | Créez une sauvegarde de votre base de données sur site, stockez-la sur Amazon S3, puis restituez le fichier de sauvegarde sur une nouvelle instance de base de données Amazon RDS exécutant MySQL. | [Restauration d’une sauvegarde dans une instance de base de données Amazon RDS for MySQL](MySQL.Procedural.Importing.md) |
| Base de données MySQL existante sur site ou sur Amazon EC2 | N’importe quel compte | En continu | Minimale | Configurez la réplication avec une base de données MySQL existante comme source de réplication. | [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md) [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](mysql-importing-data-reduced-downtime.md) |
| Toute base de données existante | N'importe quel compte | Une seule fois ou en continu | Minimale | AWS Database Migration Service À utiliser pour migrer la base de données avec un temps d'arrêt minimal et, pour de nombreux moteurs de base de données, poursuivre la réplication continue. | [Présentation d' AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) et [Utilisation d'une base de données compatible MySQL comme cible pour AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html) dans le *Guide de l'utilisateur AWS Database Migration Service * |
| Instance de base de données MySQL existante | N'importe quel compte | Une seule fois ou en continu | Minimale | Créez un réplica en lecture pour la réplication continue. Promouvez le réplica en lecture pour la création unique d’une nouvelle instance de base de données. | [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md) |
| Base de données MySQL existante | Petite | Une seule fois | Momentanée | Copiez les données directement dans votre instance de base de données MySQL à l'aide d'un utilitaire de ligne de commande. | [Importation de données à partir d’une base de données MySQL externe vers une instance de base de données Amazon RDS for MySQL](mysql-importing-data-external-database.md) |
| Données non stockées dans une base de données existante | Medium | Une seule fois | Momentanée | Créez des fichiers plats et importez-les à l’aide des instructions MySQL LOAD DATA LOCAL INFILE. | [Importation de données depuis n’importe quelle source vers une instance de base de données Amazon RDS for MySQL](mysql-importing-data-any-source.md) |
**Note**
La base de données système `mysql` contient les informations d’authentification et d’autorisation requises pour se connecter à l’instance de base de données et accéder aux données. La suppression, la modification, le renommage ou la troncation de tables, de données ou d'autres contenus de la base de données `mysql` de votre instance de base de données peut produire une erreur et rendre inaccessibles l'instance de base de données et vos données. Dans ce cas, vous pouvez restaurer l'instance de base de données à partir d'un instantané à l'aide de la AWS CLI [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)commande. Vous pouvez récupérer l'instance de base de données à l'aide de la AWS CLI [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)commande.
# Considérations sur l’importation de données pour MySQL
Le contenu suivant présente des informations techniques sur le chargement de données dans MySQL. Ce contenu est destiné aux utilisateurs qui connaissent bien l’architecture de serveur MySQL.
## Journalisation binaire
L’activation de la journalisation binaire réduit les performances de chargement des données et nécessite jusqu’à quatre fois plus d’espace disque que la journalisation désactivée. La taille des transactions utilisées pour charger les données influe directement sur les performances du système et les besoins en espace disque. Les transactions plus importantes nécessitent davantage de ressources.
## Taille de la transaction
La taille des transactions influence les aspects suivants du chargement de données MySQL :
+ Consommation des ressources
+ Utilisation de l’espace disque
+ Reprendre le processus
+ Délai de récupération
+ Format d’entrée (fichiers plats ou SQL)
Cette section décrit comment la taille de la transaction influe sur la journalisation binaire. En outre, elle plaide en faveur de la désactivation de cette même journalisation lors de chargements de données volumineux. Vous pouvez activer et désactiver la journalisation binaire en définissant la période de rétention des sauvegardes automatiques Amazon RDS. Les valeurs différentes de zéro activent la journalisation binaire, tandis que la valeur zéro la désactive. Pour plus d’informations, consultez [Période de rétention des sauvegardes](USER_WorkingWithAutomatedBackups.BackupRetention.md).
Cette section décrit également l’impact des transactions volumineuses sur InnoDB et pourquoi il est important que les transactions conservent une petite taille.
### Petites transactions
Pour les petites transactions, la journalisation binaire multiplie par deux le nombre d'écritures sur disque requises pour charger les données. Elle peut ainsi affecter gravement les performances des autres sessions de base de données et accroître le temps requis pour charger les données. La dégradation subie dépend en partie des facteurs suivants :
+ Vitesse de chargement
+ Autres activités de base de données ayant lieu pendant le chargement
+ Capacité de votre instance de base de données Amazon RDS
Les journaux binaires consomment aussi un espace disque approximativement égal à la quantité de données chargées jusqu’à ce que les journaux soient sauvegardés et supprimés. Amazon RDS réduit cette consommation en sauvegardant et en supprimant fréquemment les journaux binaires.
### Transactions volumineuses
Pour les transactions importantes, la journalisation binaire triple les IOPS et l’utilisation du disque pour les raisons suivantes :
+ Le cache du journal binaire stocke temporairement les données de transaction sur le disque.
+ Ce cache augmente avec la taille de la transaction, ce qui consomme de l’espace disque.
+ Lorsque la transaction (validation ou annulation) est terminée, le système copie le cache dans le journal binaire.
Ce processus crée trois copies des données :
+ Les données d’origine
+ Le cache sur le disque
+ La dernière entrée du journal binaire
Chaque opération d’écriture entraîne des E/S supplémentaires, ce qui a un impact supplémentaire sur les performances.
De ce fait, la journalisation binaire nécessite trois fois plus d’espace disque que la journalisation désactivée. Par exemple, le chargement de 10 GiB de données en une seule transaction crée trois copies :
+ 10 GiB pour les données du tableau
+ 10 GiB pour le cache du journal binaire
+ 10 GiB pour le fichier journal binaire
L’espace disque temporaire total requis est de 30 GiB.
Considérations importantes relatives à l’espace disque :
+ Le fichier de cache est conservé jusqu’à la fin de la session ou jusqu’à ce qu’une nouvelle transaction crée un autre cache.
+ Le journal binaire est conservé jusqu’à ce qu’il soit sauvegardé et peut contenir 20 GiB (cache et journal) pendant une période prolongée.
Si vous utilisez `LOAD DATA LOCAL INFILE` pour charger les données, la récupération des données crée une quatrième copie au cas où la base de données devrait être récupérée à partir d’une sauvegarde exécutée avant le chargement. Pendant le récupération, MySQL extrait les données du journal binaire dans un fichier plat. MySQL exécute ensuite `LOAD DATA LOCAL INFILE`. Sur la base de l’exemple précédent, cette récupération nécessite un espace disque temporaire total de 40 GiB, soit 10 Gib chacun pour la table, le cache, le journal et le fichier local. Si l’espace disque disponible est inférieur à 40 GiB, la restauration échoue.
### Optimisation des charges de données importantes
Pour les chargements de données volumineux, désactivez la journalisation binaire afin de réduire la surcharge et les contraintes d’espace disque. Vous pouvez désactiver la journalisation binaire en définissant la période de rétention des sauvegardes sur 0. Une fois le chargement terminé, restaurez la période de rétention des sauvegardes sur la valeur appropriée différente de zéro. Pour plus d’informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md) et la [Période de rétention des sauvegardes](USER_ModifyInstance.Settings.md) dans la table des paramètres.
**Note**
Si l’instance de base de données est une instance de base de données source pour les réplicas en lecture, vous ne pouvez pas définir la période de rétention des sauvegardes sur 0.
Avant de charger les données, nous vous recommandons de créer un instantané de base de données. Pour plus d’informations, consultez [Gestion des sauvegardes manuelles](USER_ManagingManualBackups.md).
## InnoDB
Les informations suivantes sur les options de journalisation des annulations et de récupération permettent de limiter la taille des transactions InnoDB afin d’optimiser les performances de la base de données.
### Compréhension de la journalisation des annulations par InnoDB
L’annulation est un mécanisme de journalisation qui permet l’annulation des transactions et prend en charge le contrôle de simultanéité multiversion (MVCC, Multi-Version Concurrency Control).
Pour les versions 5.7 et antérieures de MySQL, les journaux d’annulation sont stockés dans le tablespace système InnoDB (généralement ibdata1) et conservés jusqu’à ce que le thread de purge les supprime. Ainsi, les transactions de chargements de données volumineux peuvent entraîner un agrandissement conséquent du tablespace système et utiliser de l’espace disque que vous ne pouvez pas revendiquer sans recréer la base de données.
Pour toutes les versions de MySQL, le thread de purge doit attendre que la transaction active la plus ancienne soit validée ou annulée pour supprimer tous les journaux d’annulation. Si la base de données traite d’autres transactions pendant le chargement, leurs journaux d’annulation s’accumulent également et ne peuvent pas être supprimés, même si les transactions sont validées et qu’aucune transaction ne nécessite les journaux d’annulation pour MVCC. Dans ce cas, toutes les transactions, y compris celles en lecture seule, ralentissent. Ce ralentissement se produit parce que toutes les transactions accèdent à toutes les lignes modifiées par toutes les transactions, et pas seulement par les transactions de chargement. En effet, les transactions doivent parcourir les journaux d’annulation dont les transactions de chargement de longue durée ont empêché la purge lors du nettoyage du journal d’annulation. Cela affecte les performances de toute opération accédant aux lignes modifiées.
### Options de récupération de transactions InnoDB
Bien qu’InnoDB optimise les opérations de validation, les annulations de transactions importantes sont lentes. Pour accélérer la restauration, effectuez une point-in-time restauration ou restaurez un instantané de base de données. Pour plus d’informations, consultez [Point-in-time rétablissement](USER_PIT.md) et [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
## formats d’importation de données
MySQL prend en charge deux formats d’importation de données : fichiers plats et SQL. Passez en revue les informations relatives à chaque format afin de déterminer l’option la mieux adaptée à vos besoins.
### Fichiers plats
Pour les petites transactions, chargez des fichiers plats avec `LOAD DATA LOCAL INFILE`. Ce format d’importation de données offre les avantages suivants par rapport à l’utilisation de SQL :
+ Moins de trafic réseau
+ Réduction des coûts de transmission de données
+ Diminution des frais de traitement des bases de données
+ Accélération du traitement
`LOAD DATA LOCAL INFILE` charge la totalité du fichier plat comme une seule transaction. Maintenez une taille réduite pour chaque fichier afin de bénéficier des avantages suivants :
+ **Capacité de reprise** : vous pouvez suivre les fichiers qui ont été chargés. Si un problème survient pendant le chargement, vous pouvez reprendre la transaction là où elle s’est arrêtée. Vous devrez peut-être retransmettre des données à Amazon RDS, mais dans le cas de petits fichiers, la quantité retransmise est minimale.
+ **Chargement de données en parallèle** : si vous disposez d’une quantité suffisante d’IOPS et de bande passante du réseau pour le chargement d’un seul fichier, le chargement en parallèle peut faire gagner du temps.
+ **Contrôle du taux de chargement** : si le chargement de vos données a un impact négatif sur les autres processus, vous pouvez contrôler le taux de chargement en augmentant l’intervalle entre les fichiers.
Les transactions importantes réduisent les avantages liés à l’utilisation de `LOAD DATA LOCAL INFILE` pour importer des données. Lorsque vous ne pouvez pas diviser une grande quantité de données en fichiers plus petits, pensez à utiliser SQL.
### SQL
SQL possède un avantage principal sur les fichiers plats : vous pouvez facilement conserver une taille réduite pour les transactions. Cependant, le chargement avec SQL peut prendre beaucoup plus de temps que les fichiers plats. De plus, après un échec, il peut être difficile de définir à quel endroit reprendre : vous ne pouvez pas redémarrer les fichiers mysqldump. Si une défaillance se produit lors du chargement d’un fichier mysqldump, vous devez modifier ou remplacer le fichier avant que le chargement puisse reprendre. Sinon, après avoir corrigé la cause de la défaillance, vous pouvez restaurer à un instant dans le passé avant le chargement et renvoyer le fichier. Pour plus d’informations, consultez [Point-in-time rétablissement](USER_PIT.md).
## Utilisation d’instantanés de base de données Amazon RDS pour les points de contrôle de base de données
Si vous chargez des données sur de longues durées, par exemple des heures ou des jours, sans journalisation binaire, utilisez des instantanés de base de données pour fournir des points de contrôle périodiques en matière de sécurité des données. Chaque instantané de base de données crée une copie cohérente de votre instance de base de données, qui sert de point de récupération lors de défaillances du système ou d’événements de corruption de données. Les instantanés de base de données étant rapides, les points de contrôle fréquents ont un impact minimal sur les performances de chargement. Vous pouvez supprimer des instantanés de base de données précédents sans affecter la durabilité ou les capacités de récupération de la base de données. Pour plus d’informations sur les instantanés de base de données, consultez [Gestion des sauvegardes manuelles](USER_ManagingManualBackups.md).
## Réduction des temps de chargement des bases de données
Voici des conseils supplémentaires pour réduire les temps de chargement :
+ Créez tous les index secondaires avant le chargement des données dans les bases de données MySQL. Contrairement aux autres systèmes de base de données, MySQL reconstruit la table entière lors de l’ajout ou de la modification d’index secondaires. Ce processus crée une nouvelle table avec les modifications d’index, copie toutes les données et supprime la table d’origine.
+ Chargez les données dans l’ordre des clés primaires. Pour les tables InnoDB, cela peut réduire les temps de chargement de 75 % à 80 % et la taille des fichiers de données de 50 %.
+ Désactivez les contraintes liées aux clés étrangères en définissant `foreign_key_checks` sur `0`. Cela est souvent nécessaire pour les fichiers plats chargés avec `LOAD DATA LOCAL INFILE`. Pour tout chargement, la désactivation des contrôles par clé étrangère accélère le chargement des données. Une fois le chargement terminé, réactivez les contraintes en définissant `1` sur `foreign_key_checks` et vérifiez les données.
+ Chargez les données en parallèle à moins que vos ressources ne soient proches d’une limite. Pour permettre le chargement simultané sur plusieurs segments de table, utilisez des tables partitionnées le cas échéant.
+ Pour réduire la charge d’exécution du code SQL, combinez plusieurs instructions `INSERT` en opérations `INSERT` uniques à valeurs multiples. `mysqldump` implémente automatiquement cette optimisation.
+ Réduisez les opérations d’E/S du journal InnoDB en définissant `innodb_flush_log_at_trx_commit` sur `0`. Une fois le chargement terminé, restaurez `innodb_flush_log_at_trx_commit` vers `1`.
**Avertissement**
La définition de `innodb_flush_log_at_trx_commit` sur `0` oblige InnoDB à vider ses journaux toutes les secondes, et non à chaque validation. Ce paramètre améliore les performances, mais peut entraîner la perte de transactions en cas de défaillance du système.
+ Si vous chargez des données dans une instance de base de données ne disposant pas de réplicas en lecture, définissez `sync_binlog` sur `0`. Une fois le chargement terminé, restaurez `sync_binlog parameter` vers `1`.
+ Chargez les données dans une instance de base de données mono-AZ avant de convertir cette instance en déploiement multi-AZ. Si l’instance de base de données utilise déjà un déploiement multi-AZ, le passage à un déploiement mono-AZ pour le chargement des données n’est pas recommandé. Cela n’apporte que des améliorations marginales.
# Restauration d’une sauvegarde dans une instance de base de données Amazon RDS for MySQL
Amazon RDS prend en charge l’importation de bases de données MySQL avec des fichiers de sauvegarde. Vous pouvez créer une sauvegarde de votre base de données, la stocker sur le fichier de sauvegarde sur Amazon S3, puis restaurer le fichier de sauvegarde sur une nouvelle instance de base de données Amazon RDS qui exécute MySQL. Amazon RDS prend en charge l’importation de fichiers de sauvegarde depuis Amazon S3 dans toutes les Régions AWS.
Le scénario décrit dans cette section restaure une sauvegarde d'une base de données sur site. Tant que la base de données est disponible, vous pouvez utiliser cette technique pour les bases de données situées dans d’autres emplacements, tels que Amazon EC2 ou d’autres services cloud.
Le schéma suivant illustre le scénario pris en charge.
![\[Importation MySQL de fichiers de sauvegarde depuis S3.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MySQL-bak-file.png)
Si votre base de données sur site peut être hors ligne lorsque vous créez, copiez et restaurez des fichiers de sauvegarde, nous vous recommandons d’utiliser les fichiers de sauvegarde pour importer votre base de données dans Amazon RDS. Si votre base de données ne peut pas être hors ligne, vous pouvez choisir l’une des méthodes suivantes :
+ **Journaux binaires** : importez d’abord des fichiers de sauvegarde depuis Amazon S3 vers Amazon RDS, comme expliqué dans cette rubrique. Utilisez ensuite la réplication de journal binaire (binlog) pour mettre à jour votre base de données. Pour de plus amples informations, veuillez consulter [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
+ **AWS Database Migration Service**— AWS Database Migration Service À utiliser pour migrer votre base de données vers Amazon RDS. Pour plus d'informations, voir [Qu'est-ce que c'est AWS Database Migration Service ?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)
## Présentation de la configuration de l’importation des fichiers de sauvegarde de Amazon S3 vers Amazon RDS
Pour importer des fichiers de sauvegarde d’Amazon S3 vers Amazon RDS, il vous faut les composants suivants :
+ Un compartiment Amazon S3 pour stocker vos fichiers de sauvegarde.
Si vous avez déjà un compartiment Amazon S3, vous pouvez l’utiliser. Si vous n’avez pas de compartiment Amazon S3, créez-en un nouveau. Pour plus d’informations, consultez [Créer un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html).
+ Une sauvegarde de votre base de données sur site créée par XtraBackup Percona.
Pour de plus amples informations, veuillez consulter [Création de la sauvegarde de votre base de données](#MySQL.Procedural.Importing.Backup).
+ Rôle Gestion des identités et des accès AWS (IAM) permettant à Amazon RDS d'accéder au compartiment S3.
Si vous avez déjà un rôle IAM, vous pouvez l’utiliser et y associer des stratégies de confiance et d’autorisation. Pour de plus amples informations, veuillez consulter [Création manuelle d’un rôle IAM](#MySQL.Procedural.Importing.Enabling.IAM).
Si vous n’avez pas de rôle IAM, vous avez deux options :
+ Vous pouvez créer manuellement un nouveau rôle IAM. Pour de plus amples informations, veuillez consulter [Création manuelle d’un rôle IAM](#MySQL.Procedural.Importing.Enabling.IAM).
+ Vous pouvez laisser Amazon RDS créer un nouveau rôle IAM pour vous. Si vous souhaitez qu'Amazon RDS crée un nouveau rôle IAM pour vous, suivez la procédure qui utilise la section AWS Management Console in[Pour importer des données à partir d'Amazon S3 vers une nouvelle instance de base de données MySQL](#MySQL.Procedural.Importing.PerformingImport).
## Création de la sauvegarde de votre base de données
Utilisez le XtraBackup logiciel Percona pour créer votre sauvegarde. Nous vous recommandons d'utiliser la dernière version de Percona XtraBackup. Vous pouvez installer Percona XtraBackup à partir des [téléchargements de logiciels](https://www.percona.com/downloads/) sur le site Web de Percona.
**Avertissement**
Lors de la création d'une sauvegarde de base de données, XtraBackup vous pouvez enregistrer les informations d'identification dans le fichier xtrabackup\$1info. Assurez-vous que le paramètre `tool_command` du fichier xtrabackup\$1info ne contient aucune information sensible.
La XtraBackup version de Percona que vous utilisez dépend de la version de MySQL que vous sauvegardez.
+ **MySQL 8.4** — Utilisez la XtraBackup version 8.4 de Percona.
+ **MySQL 8.0** — Utilisez Percona XtraBackup version 8.0.
**Note**
Percona XtraBackup 8.0.12 et versions supérieures prennent en charge la migration de toutes les versions de MySQL 8.0. Si vous migrez vers RDS pour MySQL 8.0.32 ou supérieur, vous devez utiliser XtraBackup Percona 8.0.12 ou supérieur.
+ **MySQL 5.7** — Utilisez Percona XtraBackup version 2.4.
Vous pouvez utiliser Percona XtraBackup pour créer une sauvegarde complète de vos fichiers de base de données MySQL. Sinon, si vous utilisez déjà Percona XtraBackup pour sauvegarder les fichiers de votre base de données MySQL, vous pouvez télécharger vos répertoires et fichiers de sauvegarde complets et incrémentiels existants.
Pour plus d'informations sur la sauvegarde de votre base de données avec Percona XtraBackup, consultez [Percona XtraBackup - Documentation](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html) sur le site Web de Percona.
### Création d'une sauvegarde complète avec Percona XtraBackup
Pour créer une sauvegarde complète de vos fichiers de base de données MySQL qu'Amazon RDS peut restaurer depuis Amazon S3, utilisez l' XtraBackup utilitaire Percona ()`xtrabackup`.
Par exemple, la commande suivante crée une sauvegarde d'une base de données MySQL et stocke les fichiers dans le dossier `/on-premises/s3-restore/backup`.
```
xtrabackup --backup --user=myuser --password=password --target-dir=/on-premises/s3-restore/backup
```
Si vous souhaitez compresser votre sauvegarde en un seul fichier, que vous pourrez diviser en plusieurs fichiers ultérieurement, si nécessaire, vous pouvez enregistrer votre sauvegarde dans l’un des formats suivants d’après votre version MySQL :
+ **Gzip (.gz)** : pour MySQL 5.7 et versions antérieures
+ **tar (.tar)** : pour MySQL 5.7 et versions antérieures
+ **Percona xbstream (.xbstream) :** pour toutes les versions de MySQL
**Note**
Percona XtraBackup 8.0 et versions ultérieures ne prend en charge que Percona xbstream pour la compression.
**MySQL 5.7 et versions antérieures**
La commande suivante crée une sauvegarde de votre base de données MySQL, divisée en plusieurs fichiers Gzip. Remplacez les valeurs par vos propres informations.
```
xtrabackup --backup --user=my_user --password=password --stream=tar \
--target-dir=/on-premises/s3-restore/backup | gzip - | split -d --bytes=500MB \
- /on-premises/s3-restore/backup/backup.tar.gz
```
**MySQL 5.7 et versions antérieures**
La commande suivante crée une sauvegarde de votre base de données MySQL, divisée en plusieurs fichiers tar. Remplacez les valeurs par vos propres informations.
```
xtrabackup --backup --user=my_user --password=password --stream=tar \
--target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \
- /on-premises/s3-restore/backup/backup.tar
```
**Toutes les versions de MySQL**
La commande suivante crée une sauvegarde de votre base de données MySQL, divisée en plusieurs fichiers xbstream. Remplacez les valeurs par vos propres informations.
```
xtrabackup --backup --user=myuser --password=password --stream=xbstream \
--target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \
- /on-premises/s3-restore/backup/backup.xbstream
```
**Note**
Si vous obtenez l’erreur suivante, cela indique peut-être que vous avez mélangé des formats de fichiers dans votre commande :
```
ERROR:/bin/tar: This does not look like a tar archive
```
### Utilisation de sauvegardes incrémentielles avec Percona XtraBackup
Si vous utilisez déjà Percona XtraBackup pour effectuer des sauvegardes complètes et incrémentielles de vos fichiers de base de données MySQL, vous n'avez pas besoin de créer une sauvegarde complète et de télécharger les fichiers de sauvegarde sur Amazon S3. Au lieu de cela, pour gagner du temps, copiez vos fichiers et répertoires de sauvegarde existants dans votre compartiment Amazon S3. Pour plus d'informations sur la création de sauvegardes incrémentielles à l'aide de Percona XtraBackup, voir [Création d'une sauvegarde incrémentielle](https://docs.percona.com/percona-xtrabackup/LATEST/create-incremental-backup.html) sur le site Web de Percona.
Lorsque vous copiez les fichiers existants des sauvegardes complètes et incrémentielles dans un compartiment Amazon S3, vous devez copier de façon récursive le contenu du répertoire de base. Ce contenu inclut la sauvegarde complète, ainsi que tous les fichiers et répertoires des sauvegardes incrémentielles. Cette copie doit conserver la structure de répertoire du compartiment Amazon S3. Amazon RDS effectue une itération sur l'ensemble des fichiers et répertoires. Amazon RDS utilise le fichier `xtrabackup-checkpoints` inclus avec chaque sauvegarde incrémentielle pour identifier le répertoire de base et ordonner des sauvegardes incrémentielles selon leur plage de numéros de séquence de journal (LSN).
### Considérations relatives à la sauvegarde pour Percona XtraBackup
Amazon RDS utilise vos fichiers de sauvegarde sur la base des noms de fichier. Nommez vos fichiers de sauvegarde avec l’extension de fichier appropriée basée sur le format de fichier. Par exemple, utilisez `.xbstream` pour les fichiers stockés avec le format Percona xbstream.
Amazon RDS utilise vos fichiers de sauvegarde dans l'ordre alphabétique, ainsi que l'ordre numérique naturel. Utilisez l’option `split` lorsque vous émettez la commande `xtrabackup` pour vous assurer que vos fichiers de sauvegarde sont écrits et nommés dans l’ordre approprié.
Amazon RDS ne prend pas en charge les sauvegardes partielles créées à l'aide de XtraBackup Percona. Vous ne pouvez pas utiliser les options suivantes pour créer une sauvegarde partielle lorsque vous sauvegardez les fichiers source pour votre base de données :
+ `--tables`
+ `--tables-exclude`
+ `--tables-file`
+ `--databases`
+ `--databases-exclude`
+ `--databases-file`
## Création manuelle d’un rôle IAM
Si vous n'avez pas de rôle IAM, vous pouvez en créer manuellement un nouveau. Toutefois, si vous restaurez la base de données à l'aide du AWS Management Console, nous vous recommandons de demander à Amazon RDS de créer ce nouveau rôle IAM pour vous. Pour qu’Amazon RDS puisse créer ce rôle pour vous, suivez la procédure décrite dans la section [Pour importer des données à partir d'Amazon S3 vers une nouvelle instance de base de données MySQL](#MySQL.Procedural.Importing.PerformingImport).
Pour créer un rôle IAM manuellement afin d’importer votre base de données à partir de Amazon S3, créez un rôle pour déléguer des autorisations depuis le service Amazon RDS vers votre compartiment Amazon S3. Lorsque vous créez un rôle IAM, vous attachez des stratégies d'approbation et d'autorisation. Pour importer vos fichiers de sauvegarde à partir d’Amazon S3, utilisez des stratégies d’approbation et d’autorisation similaires aux exemples suivants. Pour plus d'informations sur la création du rôle, voir [Création d'un rôle pour déléguer des autorisations à un AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html).
Les stratégies d'approbation et d'autorisation nécessitent que vous fournissiez un Amazon Resource Name (ARN). Pour plus d'informations sur le formatage de l'ARN, consultez [Amazon Resource Names (ARNs) et espaces AWS de noms de services](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
**Example stratégie d’approbation pour l’importation à partir d’Amazon S3**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRoleForBackup",
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
**Example stratégie d’autorisation pour l’importation à partir de Amazon S3 — Autorisations des utilisateurs IAM**
Dans l'exemple suivant, remplacez *iam\$1user\$1id* par votre propre valeur.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3AccessRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/S3Access"
}
]
}
```
**Example stratégie d’autorisation pour l’importation à partir d’Amazon S3 — Autorisations des rôles**
Dans l'exemple suivant, remplacez *amzn-s3-demo-bucket* et *prefix* par vos propres valeurs.
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Action":
[
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Effect": "Allow",
"Action":
[
"s3:GetObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix*"
},
{
"Effect": "Allow",
"Action":
[
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:111122223333:key/key_id*"
]
}
]
}
```
Si vous incluez un préfixe de nom de fichier, vous devez inclure un astérisque (\$1) après le préfixe. Si vous ne voulez pas spécifier un préfixe, indiquez uniquement un astérisque.
## Pour importer des données à partir d'Amazon S3 vers une nouvelle instance de base de données MySQL
Vous pouvez importer des données depuis Amazon S3 vers une nouvelle instance de base de données MySQL à l'aide de l'API AWS Management Console AWS CLI, ou RDS.
### Console
**Pour importer des données à partir d'Amazon S3 vers une nouvelle instance de base de données MySQL**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le coin supérieur droit de la console Amazon RDS, choisissez l' Région AWS endroit où vous souhaitez créer votre instance de base de données. Choisissez le même Région AWS que le compartiment Amazon S3 qui contient la sauvegarde de votre base de données.
1. Dans la panneau de navigation, choisissez **Databases (Bases de données)**.
1. Choisissez **Restaurer à partir de S3**.
La page **Créer une base de données par restauration à partir de S3** s’affiche.
![\[Page Créer une base de données en restaurant à partir de S3 sur laquelle vous spécifiez les détails de la restauration d’une instance de base de données à partir de S3.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/mys-s3-ingestion.png)
1. Sous **Source S3** :
1. Choisissez le **compartiment S3** qui contient la sauvegarde.
1. (Facultatif) Pour **Préfixe S3**, saisissez un préfixe de chemin de fichier pour les fichiers stockés dans votre compartiment Amazon S3.
Si vous ne spécifiez pas de préfixe, Amazon RDS crée votre cluster/instance de base de données à l’aide de tous les fichiers et dossiers du dossier racine du compartiment S3. Si vous indiquez un préfixe, Amazon RDS crée votre instance de base de données à l’aide des fichiers et dossiers du compartiment S3 pour lesquels le chemin du fichier commence par le préfixe spécifié.
Par exemple, supposons que vous stockez vos fichiers de sauvegarde sur S3 dans un sous-dossier appelé « sauvegardes » et que vous avez plusieurs ensembles de fichiers de sauvegarde, chacun dans son propre répertoire (gzip\$1backup1, gzip\$1backup2, etc.). Dans ce cas, pour restaurer les fichiers dans le dossier gzip\$1backup1, spécifiez le préfixe sauvegardes/gzip\$1backup1.
1. Sous **Options du moteur** :
1. Dans le champ **Type de moteur**, choisissez **MySQL**.
1. Dans le champ **Version du moteur source**, choisissez la version MySQL majeure de votre base de données source.
1. Pour **Version du moteur**, choisissez la version mineure par défaut de votre version majeure MySQL dans votre Région AWS.
Dans le AWS Management Console, seule la version mineure par défaut est disponible. Une fois l’importation terminée, vous pouvez mettre à niveau votre instance de base de données.
1. Pour le **rôle IAM**, créez ou choisissez un rôle IAM avec la politique de confiance et la politique d’autorisation requises qui permettent à Amazon RDS d’accéder à votre compartiment Amazon S3. Effectuez l’une des opérations suivantes :
+ (Recommandé) Choisissez **Créer un nouveau rôle** et entrez le **nom du rôle IAM**. Avec cette option, Amazon RDS crée automatiquement le rôle avec la politique de confiance et la politique d’autorisation.
+ Choisissez un rôle IAM existant. Assurez-vous que ce rôle répond à tous les critères de [Création manuelle d’un rôle IAM](#MySQL.Procedural.Importing.Enabling.IAM).
1. Spécifiez les informations de votre instance de base de données. Pour plus d’informations sur chaque paramètre, consultez [Paramètres des instances de base de données](USER_CreateDBInstance.Settings.md).
**Note**
Veillez à allouer suffisamment de stockage à votre nouvelle instance de base de données afin que l’opération de restauration aboutisse.
Pour permettre automatiquement la croissance future, sous **Configuration de stockage supplémentaire**, sélectionnez **Activer la mise à l’échelle automatique du stockage**.
1. Choisissez des paramètres supplémentaires selon vos besoins.
1. Choisissez **Create database (Créer une base de données)**.
### AWS CLI
Pour importer des données depuis Amazon S3 vers une nouvelle instance de base de données MySQL à l'aide de AWS CLI, exécutez la commande [restore-db-instance-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html) avec les options suivantes. Pour plus d’informations sur chaque paramètre, consultez [Paramètres des instances de base de données](USER_CreateDBInstance.Settings.md).
**Note**
Veillez à allouer suffisamment de stockage à votre nouvelle instance de base de données afin que l’opération de restauration aboutisse.
Pour activer la mise à l’échelle automatique du stockage et faciliter une croissance automatique ultérieure, utilisez l’option `--max-allocated-storage`.
+ `--allocated-storage`
+ `--db-instance-identifier`
+ `--db-instance-class`
+ `--engine`
+ `--master-username`
+ `--manage-master-user-password`
+ `--s3-bucket-name`
+ `--s3-ingestion-role-arn`
+ `--s3-prefix`
+ `--source-engine`
+ `--source-engine-version`
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds restore-db-instance-from-s3 \
2. --allocated-storage 250 \
3. --db-instance-identifier my_identifier \
4. --db-instance-class db.m5.large \
5. --engine mysql \
6. --master-username admin \
7. --manage-master-user-password \
8. --s3-bucket-name amzn-s3-demo-bucket \
9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename \
10. --s3-prefix bucket_prefix \
11. --source-engine my_sql \
12. --source-engine-version 8.0.32 \
13. --max-allocated-storage 1000
```
Pour Windows :
```
1. aws rds restore-db-instance-from-s3 ^
2. --allocated-storage 250 ^
3. --db-instance-identifier my_identifier ^
4. --db-instance-class db.m5.large ^
5. --engine mysql ^
6. --master-username admin ^
7. --manage-master-user-password ^
8. --s3-bucket-name amzn-s3-demo-bucket ^
9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename ^
10. --s3-prefix bucket_prefix ^
11. --source-engine mysql ^
12. --source-engine-version 8.0.32 ^
13. --max-allocated-storage 1000
```
### API RDS
Pour importer des données d'Amazon S3 vers une nouvelle instance de base de données MySQL à l'aide de l'API Amazon RDS, appelez l'opération [Restore DBInstance FromS3.](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html)
## Limitations et considérations relatives à l’importation de fichiers de sauvegarde d’Amazon S3 vers Amazon RDS
Les limitations et considérations suivantes s’appliquent à l’importation de fichiers de sauvegarde d’Amazon S3 vers une instance de base de données RDS for MySQL :
+ Vous pouvez uniquement migrer vos données vers une nouvelle instance de base de données, et non vers une instance de base de données existante.
+ Vous devez utiliser Percona XtraBackup pour sauvegarder vos données sur Amazon S3. Pour de plus amples informations, veuillez consulter [Création de la sauvegarde de votre base de données](#MySQL.Procedural.Importing.Backup).
+ Le compartiment Amazon S3 et l’instance de base de données RDS for MySQL doivent se trouver dans la même Région AWS.
+ Vous ne pouvez pas restaurer à partir des sources suivantes :
+ Une exportation d’instantané d’instance de base de données vers Amazon S3. Vous ne pouvez pas non plus migrer des données à partir de l’exportation d’un instantané d’instance de base de données dans votre compartiment Amazon S3.
+ Une base de données source chiffrée. Toutefois, vous pouvez chiffrer les données migrées. Vous pouvez également laisser les données non chiffrées pendant le processus de migration.
+ Une base de données MySQL 5.5 ou 5.6.
+ RDS for MySQL ne prend pas en charge Percona Server for MySQL en tant que base de données source, car il peut contenir des tables `compression_dictionary*` dans le `mysql schema`.
+ RDS for MySQL ne prend pas en charge la rétromigration pour les versions majeures ni mineures. Par exemple, il n’est pas possible de migrer de MySQL version 8.0 vers RDS for MySQL 5.7. De même, il n’est pas possible de migrer de MySQL version 8.0.32 vers MySQL version 8.0.26.
+ Amazon RDS ne prend pas en charge l’importation sur la classe d’instance de base de données db.t2.micro à partir d’Amazon S3. Toutefois, vous pouvez restaurer vers une autre classe d’instance de base de données, puis modifier la classe d’instance de base de données ultérieurement. Pour plus d'informations sur les classes d'instance , consultez [Spécifications matérielles pour les classes d'instances de base de données ](Concepts.DBInstanceClass.Summary.md).
+ Amazon S3 limite la taille d'un fichier chargé vers un compartiment Amazon S3 à 5 To. Si un fichier de sauvegarde dépasse 5 To, vous devez diviser celui-ci en plusieurs fichiers plus petits.
+ Amazon RDS limite le nombre de fichiers chargés vers un compartiment Amazon S3 à 1 million. Si les données de sauvegarde de votre base de données, y compris toutes les sauvegardes complètes et incrémentielles, dépassent 1 million de fichiers, utilisez un fichier Gzip (.gz), tar (.tar.gz) ou Percona xbstream (.xbstream) pour stocker les fichiers des sauvegardes complètes et incrémentielles dans le compartiment Amazon S3. Percona XtraBackup 8.0 prend uniquement en charge Percona xbstream pour la compression.
+ Pour fournir des services de gestion à chaque instance de base de données, Amazon RDS crée l’utilisateur `rdsadmin` lorsqu’il crée l’instance de base de données. Comme `rdsamin` est un utilisateur réservé dans Amazon RDS, les limitations suivantes s’appliquent :
+ Amazon RDS n’importe pas les fonctions, les procédures, les vues, les événements et les déclencheurs avec le définisseur `'rdsadmin'@'localhost'`. Pour plus d’informations, consultez [Objets stockés avec ’rdsadmin’@’localhost’ comme définisseur](#MySQL.Procedural.Importing.StoredObjects) et [Privilèges du compte utilisateur principal](UsingWithRDS.MasterAccounts.md).
+ Lors de la création de l’instance de base de données, Amazon RDS crée un utilisateur principal avec le maximum de privilèges pris en charge. Lors de la restauration à partir d’une sauvegarde, Amazon RDS supprime automatiquement tous les privilèges non pris en charge attribués aux utilisateurs importés.
Pour identifier les utilisateurs susceptibles d’être concernés, consultez [Comptes d’utilisateur avec des privilèges non pris en charge](#MySQL.Migrating.ExtMySQL.Prechecks.Users). Pour plus d’informations sur les privilèges pris en charge dans RDS for MySQL, consultez [Modèle de privilège basé sur les rôles pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md).
+ Amazon RDS ne migre pas les tables créées par les utilisateurs dans le schéma `mysql`.
+ Vous devez configurer le paramètre `innodb_data_file_path` avec un seul fichier de données qui utilise le nom de fichier de données par défaut `ibdata1:12M:autoextend`. Vous pouvez migrer des bases de données comportant deux fichiers de données, ou avec un fichier de données portant un nom différent, à l’aide de cette méthode.
Les exemples suivants sont des noms de fichiers qu’Amazon RDS n’autorise pas :
+ `innodb_data_file_path=ibdata1:50M`
+ `ibdata2:50M:autoextend`
+ `innodb_data_file_path=ibdata01:50M:autoextend`
+ Vous ne pouvez pas migrer à partir d’une base de données source dotée de tables définies à l’extérieur du répertoire de données MySQL par défaut.
+ La taille maximale prise en charge pour les sauvegardes non compressées utilisant cette méthode est limitée à 64 Tio. Pour les sauvegardes compressées, cette limite est abaissée pour tenir compte de l’espace requis pour la décompression. Dans de tels cas, la taille de sauvegarde maximale prise en charge est `64 TiB - compressed backup size`.
Pour en savoir plus sur la taille maximale de base de données prise en charge par RDS for MySQL, consultez [Stockage SSD à usage général](CHAP_Storage.md#Concepts.Storage.GeneralSSD) et [Stockage SSD à IOPS provisionnées](CHAP_Storage.md#USER_PIOPS).
+ Aurora RDS ne prend pas en charge l’importation de MySQL ni d’autres composants et plugins externes.
+ Amazon RDS ne restaure pas tous les éléments de votre base de données. Nous vous recommandons d’enregistrer le schéma de base de données et les valeurs pour les éléments suivants à partir de votre base de données système MySQL source et de les ajouter à votre instance de base de données RDS for MySQL restauré après qu’il a été créé :
+ Comptes utilisateurs
+ Fonctions
+ Procédures stockées
+ Informations de fuseau horaire. Les informations de fuseau horaire sont chargées depuis le système d’exploitation local de votre instance de base de données RDS for MySQL. Pour de plus amples informations, veuillez consulter [Fuseau horaire local pour les instances de bases de données MySQL](MySQL.Concepts.LocalTimeZone.md).
### Objets stockés avec ’rdsadmin’@’localhost’ comme définisseur
Amazon RDS n’importe pas les fonctions, les procédures, les vues, les événements et les déclencheurs avec `'rdsadmin'@'localhost'` en tant que définisseur.
Vous pouvez utiliser le script SQL suivant sur votre base de données MySQL source pour répertorier les objets stockés qui possèdent le définisseur non pris en charge.
```
-- This SQL query lists routines with `rdsadmin`@`localhost` as the definer.
SELECT
ROUTINE_SCHEMA,
ROUTINE_NAME
FROM
information_schema.routines
WHERE
definer = 'rdsadmin@localhost';
-- This SQL query lists triggers with `rdsadmin`@`localhost` as the definer.
SELECT
TRIGGER_SCHEMA,
TRIGGER_NAME,
DEFINER
FROM
information_schema.triggers
WHERE
DEFINER = 'rdsadmin@localhost';
-- This SQL query lists events with `rdsadmin`@`localhost` as the definer.
SELECT
EVENT_SCHEMA,
EVENT_NAME
FROM
information_schema.events
WHERE
DEFINER = 'rdsadmin@localhost';
-- This SQL query lists views with `rdsadmin`@`localhost` as the definer.
SELECT
TABLE_SCHEMA,
TABLE_NAME
FROM
information_schema.views
WHERE
DEFINER = 'rdsadmin@localhost';
```
### Comptes d’utilisateur avec des privilèges non pris en charge
Les comptes d’utilisateur dotés de privilèges non pris en charge par RDS for MySQL sont importés sans les privilèges non pris en charge. Pour obtenir la liste des privilèges pris en charge, consultez [Modèle de privilège basé sur les rôles pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md).
Vous pouvez exécuter la requête SQL suivante sur votre base de données source pour répertorier les comptes d’utilisateur dotés de privilèges non pris en charge.
```
SELECT
user,
host
FROM
mysql.user
WHERE
Shutdown_priv = 'y'
OR File_priv = 'y'
OR Super_priv = 'y'
OR Create_tablespace_priv = 'y';
```
# Importation de données à partir d’une base de données MySQL externe vers une instance de base de données Amazon RDS for MySQL
Vous pouvez importer des données à partir d’une base de données MySQL existante vers une instance de base de données RDS for MySQL. Pour ce faire, vous devez copier la base de données avec [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) et la transférer directement dans l’instance de base de données RDS for MySQL. L’utilitaire de ligne de commande `mysqldump` est généralement utilisé pour effectuer des sauvegardes et des transferts de données d’un serveur MySQL vers un autre. Il est inclus dans les logiciels clients MySQL.
**Note**
Si vous importez ou exportez de grandes quantités de données avec une instance de base de données MySQL, il est plus fiable et plus rapide de déplacer les données dans et en dehors d’Amazon RDS en utilisant des fichiers de sauvegarde `xtrabackup` et Amazon S3. Pour de plus amples informations, veuillez consulter [Restauration d’une sauvegarde dans une instance de base de données Amazon RDS for MySQL](MySQL.Procedural.Importing.md).
Une commande `mysqldump` classique pour déplacer les données d’une base de données externe vers une instance de bases de données Amazon RDS ressemble à l’exemple suivant. Remplacez les valeurs par vos propres informations.
```
mysqldump -u local_user \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mysql -u RDS_user \
--port=port_number \
--host=host_name \
-pRDS_password
```
**Important**
Veillez à ne pas laisser d’espace entre l’option `-p` et le mot de passe saisi.
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans cet exemple.
Assurez-vous que vous êtes conscient des recommandations et des considérations suivantes :
+ Excluez les schémas suivants du fichier de vidage :
+ `sys`
+ `performance_schema`
+ `information_schema`
L’utilitaire `mysqldump` exclut ces schémas par défaut.
+ Si vous devez migrer des utilisateurs et des privilèges, pensez à utiliser un outil qui génère le langage de contrôle des données (DCL) pour les recréer, tel que l'[pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html)utilitaire.
+ Pour effectuer l'importation, assurez-vous que l'utilisateur qui l'effectue a accès à l'instance de base de données. Pour de plus amples informations, veuillez consulter [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md).
Les paramètres utilisés sont les suivants :
+ `-u local_user` : utilisez ce paramètre pour spécifier un nom d’utilisateur. Lors de la première utilisation de ce paramètre, spécifiez le nom d’un compte utilisateur sur la base de données MySQL locale que vous identifiez avec le paramètre `--databases`.
+ `--databases database_name` : utilisez ce paramètre pour spécifier le nom de la base de données sur l’instance MySQL locale que vous souhaitez importer dans Amazon RDS.
+ `--single-transaction` : utilisez ce paramètre pour vérifier que toutes les données chargées depuis la base de données locale sont en cohérence avec un point dans le temps unique. S'il existe d'autres processus qui modifient les données pendant que `mysqldump` les lit, l'utilisation de ce paramètre permet de maintenir l'intégrité des données.
+ `--compress` : utilisez ce paramètre pour réduire la consommation de bande passante réseau par compression des données à partir de la base de données locale avant de les envoyer vers Amazon RDS.
+ `--order-by-primary` : utilisez ce paramètre pour réduire le temps de chargement en triant les données de chaque tableau sur par clé primaire.
+ `--routines` : utilisez ce paramètre si des routines telles que des procédures stockées ou des fonctions existent dans la base de données que vous copiez. Définissez le paramètre sur `0` pour exclure les routines pendant le processus d’importation. Ensuite, recréez manuellement les routines dans la base de données Amazon RDS.
+ `--triggers` : utilisez ce paramètre si des déclencheurs existent dans la base de données que vous copiez. Définissez le paramètre sur `0` pour exclure les déclencheurs pendant le processus d’importation. Ensuite, recréez manuellement les déclencheurs dans la base de données Amazon RDS.
+ `--events` : utilisez ce paramètre si des événements existent dans la base de données que vous copiez. Définissez le paramètre sur `0` pour exclure les événements pendant le processus d’importation. Ensuite, recréez manuellement les événements dans la base de données Amazon RDS.
+ `-plocal_password` : utilisez ce paramètre pour spécifier un mot de passe. Lors de la première utilisation de ce paramètre, spécifiez le mot de passe du compte utilisateur identifié avec le premier paramètre `-u`.
+ `-u RDS_user` : utilisez ce paramètre pour spécifier un nom d’utilisateur. Lors de la seconde utilisation de ce paramètre, spécifiez le nom d’un compte utilisateur sur la base de données par défaut pour l’instance de bases de données MySQL que vous identifiez avec le paramètre `--host`.
+ `--port port_number` : utilisez ce paramètre pour spécifier le port pour votre instance de base de données MySQL. Par défaut, il s’agit du port 3306, sauf si vous avez modifié la valeur lorsque vous avez créé l’instance de base de données.
+ `--host host_name` : utilisez ce paramètre pour spécifier le nom du système de nom de domaine (DNS) du point de terminaison de l’instance de base de données Amazon RDS, par exemple, `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de l’instance de base de données dans la console Amazon RDS.
+ `-pRDS_password` : utilisez ce paramètre pour spécifier un mot de passe. Lors de la seconde utilisation de ce paramètre, vous spécifiez le mot de passe du compte utilisateur identifié par le second paramètre `-u`.
Assurez-vous de créer manuellement les procédures stockées, déclencheurs, fonctions ou événements dans votre base de données Amazon RDS. Si vous avez l’un de ces objets dans la base de données que vous copiez, excluez-les lorsque lors de l’exécution de `mysqldump`. Pour ce faire, incluez les paramètres suivants avec votre commande `mysqldump` :
+ `--routines=0`
+ `--triggers=0`
+ `--events=0`
**Exemple**
L’exemple suivant copie l’exemple de base de données `world` de l’hôte local sur une instance de bases de données RDS for MySQL. Remplacez les valeurs par vos propres informations.
Pour Linux, macOS ou Unix :
```
sudo mysqldump -u local_user \
--databases world \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mysql -u rds_user \
--port=3306 \
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com \
-pRDS_password
```
Pour Windows :
Exécutez la commande suivante dans une invite de commandes ouverte en cliquant avec le bouton droit sur **Invite de commandes** dans le menu Programmes de Windows, puis en choisissant **Exécuter en tant qu’administrateur**. Remplacez les valeurs par vos propres informations.
```
mysqldump -u local_user ^
--databases world ^
--single-transaction ^
--compress ^
--order-by-primary ^
--routines=0 ^
--triggers=0 ^
--events=0 ^
-plocal_password | mysql -u RDS_user ^
--port=3306 ^
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^
-pRDS_password
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
# Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite
Dans certains cas, vous pouvez avoir besoin d’importer des données d’une base de données MySQL externe qui prend en charge une application active vers une instance de base de données RDS for MySQL, ou un cluster de bases de données multi-AZ RDS for MySQL. Utilisez la procédure suivante pour réduire l’impact sur la disponibilité des applications. Cette procédure peut s’avérer également utile si vous travaillez avec une base de données très volumineuse. Cette procédure vous permet de réduire le coût de l'importation en diminuant la quantité de données transmises à AWS via le réseau.
Dans cette procédure, vous transférez une copie des données de votre base de données vers une instance Amazon EC2 et vous importez les données dans une nouvelle base de données Amazon RDS. Vous utilisez ensuite la réplication pour intégrer la base de données Amazon RDS up-to-date à votre instance externe active, avant de rediriger votre application vers la base de données Amazon RDS. Configurez la réplication en fonction des coordonnées des journaux binaires.
**Note**
Si vous souhaitez importer des données dans une instance de base de données RDS for MySQL et que votre scénario le permet, nous recommandons de déplacer les données dans et hors d’Amazon RDS en utilisant des fichiers de sauvegarde et Amazon S3. Pour de plus amples informations, veuillez consulter [Restauration d’une sauvegarde dans une instance de base de données Amazon RDS for MySQL](MySQL.Procedural.Importing.md).
Le schéma suivant montre l’importation d’une base de données MySQL externe dans une base de données MySQL sur Amazon RDS.
![\[Flux de travail qui montre l’importation d’une base de données MySQL externe dans une base de données MySQL sur Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_1.png)
## Tâche 1 : Créer une copie de votre base de données existante
La première étape du processus de migration d’une grande quantité de données vers une base de données RDS for MySQL avec une durée d’indisponibilité minimale consiste à créer une copie des données sources.
Le schéma suivant montre la création d’une sauvegarde de base de données MySQL.
![\[Flux de travail qui montre la création d’une sauvegarde de la base de données MySQL.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_2.png)
Vous pouvez recourir à l'utilitaire `mysqldump` pour créer une sauvegarde de base de données au format SQL ou texte délimité. Nous vous recommandons d’effectuer un test avec chaque format dans un environnement autre que celui de production afin de déterminer la méthode qui minimise le temps d’exécution de `mysqldump`.
Nous vous recommandons également de comparer les performances de `mysqldump` avec les avantages offerts par l’utilisation du format texte délimité pour le chargement. Une sauvegarde à l’aide du format texte délimité crée un fichier texte séparé par des tabulations pour chaque table vidée. Pour réduire le temps nécessaire à l’importation de votre base de données, vous pouvez charger ces fichiers en parallèle en utilisant la commande `LOAD DATA LOCAL INFILE`. Pour plus d’informations, consultez [Étape 5 : Charger les données](mysql-importing-data-any-source.md#mysql-importing-data-any-source-load-data) dans la procédure Importation de données à partir de n’importe quelle source.
Avant de commencer l’opération de sauvegarde, assurez-vous de définir les options de réplication sur la base de données MySQL que vous copiez vers Amazon RDS. Les options de réplication incluent l’activation de la journalisation binaire et la configuration d’un ID de serveur unique. La définition de ces options oblige votre serveur à démarrer la journalisation des transactions de base de données et le prépare à être une instance de réplication source ultérieurement dans le processus.
Assurez-vous que vous êtes conscient des recommandations et des considérations suivantes :
+ Utilisez l'option `--single-transaction` avec `mysqldump`, car elle vide un état cohérent de la base de données. Pour vous assurer de la validité d'un fichier de vidage, n'exécutez pas les instructions DDL (Data Definition Language) pendant l'exécution de `mysqldump`. Vous pouvez planifier une fenêtre de maintenance pour ces opérations.
+ Excluez les schémas suivants du fichier de vidage :
+ `sys`
+ `performance_schema`
+ `information_schema`
L’utilitaire `mysqldump` exclut ces schémas par défaut.
+ Si vous devez migrer des utilisateurs et des privilèges, pensez à utiliser un outil qui génère le langage de contrôle des données (DCL) pour les recréer, tel que l'[pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html)utilitaire.
### Pour définir les options de réplication
1. Modifiez le fichier `my.cnf`. Ce fichier se trouve généralement sous `/etc`.
```
sudo vi /etc/my.cnf
```
Ajoutez les options `log_bin` et `server_id` à la section `[mysqld]`. L’option `log_bin` fournit un identifiant de nom de fichier pour les fichiers journaux binaires. L’option `server_id` fournit un identifiant unique pour le serveur dans les relations source/réplica.
L’exemple suivant illustre la section `[mysqld]` mise à jour d’un fichier `my.cnf` :
```
[mysqld]
log-bin=mysql-bin
server-id=1
```
Pour plus d’informations, consultez [Setting the Replication Source Configuration](https://dev.mysql.com/doc/refman/8.4/en/replication-howto-masterbaseconfig.html) dans la documentation MySQL.
1. Pour la réplication avec un cluster de bases de données multi-AZ, définissez les paramètres `ENFORCE_GTID_CONSISTENCY` et `GTID_MODE` sur `ON`.
```
mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
```
```
mysql> SET @@GLOBAL.GTID_MODE = ON;
```
Ces paramètres ne sont pas requis pour la réplication avec une instance de base de données.
1. Redémarrez le service `mysql`.
```
sudo service mysqld restart
```
### Pour créer une copie de sauvegarde de votre base de données existante
1. Créez une sauvegarde de vos données à l'aide de l'utilitaire `mysqldump`, en spécifiant un format SQL ou un format texte délimité.
Pour MySQL 8.0.25 et versions antérieures, spécifiez `--master-data=2` pour créer un fichier de sauvegarde qui peut être utilisé pour démarrer la réplication entre les serveurs. Pour MySQL 8.0.26 et versions ultérieures, spécifiez `--source-data=2` pour créer un fichier de sauvegarde qui peut être utilisé pour démarrer la réplication entre les serveurs. Pour plus d’informations, consultez [mysqldump – Programme de sauvegarde de base de données](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html) dans la documentation MySQL.
Pour améliorer les performances et assurer l’intégrité des données, utilisez les options `--order-by-primary` et `--single-transaction` pour `mysqldump`.
Pour éviter d’inclure la base de données système MySQL dans la sauvegarde, n’utilisez pas l’option `--all-databases` avec `mysqldump`. Pour plus d’informations, consultez [Création d’un instantané de données avec mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) dans la documentation MySQL.
Utilisez `chmod`, si nécessaire, pour vous assurer que le répertoire où le fichier de sauvegarde est en cours de création est accessible en écriture.
**Important**
Sur Windows, exécutez la fenêtre de commande en tant qu’administrateur.
+ Pour produire une sortie SQL, utilisez la commande suivante :
Pour Linux, macOS ou Unix :
```
sudo mysqldump \
--databases database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u local_user \
-ppassword
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
Pour Windows :
```
mysqldump ^
--databases database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-r backup.sql ^
-u local_user ^
-ppassword
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
+ Pour produire une sortie à texte délimité, utilisez la commande suivante :
Pour Linux, macOS ou 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
```
Pour 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
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
Assurez-vous de créer manuellement les procédures stockées, déclencheurs, fonctions ou événements dans votre base de données Amazon RDS. Si vous avez l’un de ces objets dans la base de données que vous copiez, excluez-les lorsque lors de l’exécution de `mysqldump`. Pour ce faire, incluez les arguments suivants dans votre commande `mysqldump` :
`--routines=0`
`--triggers=0`
`--events=0`
Pour MySQL 8.0.22 et versions antérieures, lorsque vous exécutez `mysqldump` et spécifiez le format texte délimité, un commentaire `CHANGE MASTER TO` est retourné. Ce commentaire contient le nom du fichier journal maître et son emplacement. Pour MySQL 8.0.23 et versions ultérieures, lorsque vous exécutez `mysqldump` et spécifiez le format texte délimité, un commentaire `CHANGE REPLICATION SOURCE TO` est retourné. Ce commentaire contient le nom du fichier journal source et son emplacement. Si l’instance externe est MySQL 8.0.23 et versions ultérieures, notez les valeurs pour `MASTER_LOG_FILE` et `MASTER_LOG_POS`. Vous avez besoin de ces valeurs lors de la configuration de la réplication.
La sortie suivante est retournée pour MySQL 8.0.22 et versions antérieures :
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
La sortie suivante est retournée pour MySQL 8.0.23 et versions ultérieures :
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE SOURCE TO SOURCE_LOG_FILE='mysql-bin-changelog.000031', SOURCE_LOG_POS=107;
```
Pour MySQL 8.0.22 et versions antérieures, si vous utilisez le format SQL, vous pouvez obtenir le nom du fichier journal principal et son emplacement dans le commentaire `CHANGE MASTER TO` du fichier de sauvegarde. Pour MySQL 8.0.23 et versions ultérieures, si vous utilisez le format SQL, vous pouvez obtenir le nom du fichier journal source et son emplacement dans le commentaire `CHANGE REPLICATION SOURCE TO` du fichier de sauvegarde.
1. Compressez les données copiées afin de réduire la quantité de ressources réseau nécessaires pour copier vos données sur la base de données Amazon RDS. Notez la taille du fichier de sauvegarde. Vous avez besoin de cette information lorsque vous déterminez la taille de l'instance Amazon EC2 à créer. Lorsque vous avez terminé, compressez le fichier de sauvegarde à l’aide de GZIP ou de votre utilitaire de compression favori.
+ Pour compresser une sortie SQL, utilisez la commande suivante :
```
gzip backup.sql
```
+ Pour compresser une sortie à texte délimité, utilisez la commande suivante :
```
tar -zcvf backup.tar.gz target_directory
```
## Tâche 2 : Créer une instance Amazon EC2 et copier la base de données compressée
La copie du fichier de sauvegarde compressé de votre base de données sur une instance Amazon EC2 nécessite moins de ressources réseau que l’exécution d’une copie directe de données non compressées entre instances de bases de données. Une fois que vos données sont dans Amazon EC2, vous pouvez les copier directement de cet emplacement vers votre base de données MySQL. Pour que vous puissiez économiser sur le coût des ressources réseau, votre instance Amazon EC2 doit être Région AWS identique à votre instance de base de données Amazon RDS. Le fait d’avoir l’instance Amazon EC2 dans la même Région AWS que votre base de données Amazon RDS a également pour effet de réduire la latence réseau pendant l’importation.
Le schéma suivant montre la copie de la sauvegarde de base de données vers une instance Amazon EC2.
![\[Flux de travail montrant la copie de la sauvegarde de base de données vers une instance Amazon EC2.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_3.png)
### Pour créer une instance Amazon EC2 et copier vos données
1. Dans l' Région AWS endroit où vous prévoyez de créer la base de données Amazon RDS, créez un cloud privé virtuel (VPC), un groupe de sécurité VPC et un sous-réseau VPC. Assurez-vous que les règles entrantes de votre groupe de sécurité VPC autorisent les adresses IP requises pour que votre application se connecte à AWS. Vous pouvez spécifier une plage d’adresses IP (par exemple, `203.0.113.0/24`) ou un autre groupe de sécurité VPC. Vous pouvez utiliser la [console Amazon VPC](https://console.aws.amazon.com/vpc) pour créer et gérer des sous-réseaux et VPCs des groupes de sécurité. Pour plus d’informations, consultez [Démarrez avec Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#getting-started) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
1. Ouvrez la [console Amazon EC2](https://console.aws.amazon.com/ec2) et choisissez celle qui doit contenir Région AWS à la fois votre instance Amazon EC2 et votre base de données Amazon RDS. Lancez une instance Amazon EC2 à l’aide du VPC, du sous-réseau et du groupe de sécurité que vous avez créés à l’étape 1. Vérifiez que vous sélectionnez un type d’instance avec un stockage suffisant pour le fichier de sauvegarde de votre base de données une fois qu’il est décompressé. Pour plus d’informations sur les instances Amazon EC2, consultez [Démarrez avec Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
1. Pour vous connecter à votre base de données Amazon RDS à partir de votre instance Amazon EC2, modifiez votre groupe de sécurité VPC. Ajoutez une règle de trafic entrant en spécifiant l’adresse IP privée de votre instance EC2. L’adresse IP privée se trouve sous l’onglet **Détails** du volet **Instance** de la fenêtre de la console EC2. Pour modifier le groupe de sécurité VPC et ajouter une règle de trafic entrant, choisissez **Security Groups** (Groupes de sécurité) dans le panneau de navigation de la console EC2, choisissez votre groupe de sécurité et ajoutez une règle de trafic entrant pour MySQL/Aurora en spécifiant l’adresse IP privée de votre instance EC2. Pour apprendre à ajouter une règle de trafic entrant à un groupe de sécurité VPC, consultez [Règles du groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) dans le *Guide de l’utilisateur Amazon VPC Private Cloud*.
1. Copiez le fichier de sauvegarde compressé de votre base de données depuis votre système local vers votre instance Amazon EC2. Utilisez `chmod`, si nécessaire, pour vous assurer d’avoir l’autorisation d’écriture dans le répertoire cible de l’instance Amazon EC2. Vous pouvez utiliser `scp` ou un client SSH pour copier le fichier. Voici un exemple de commande `scp` :
```
scp -r -i key pair.pem backup.sql.gz ec2-user@EC2 DNS:/target_directory/backup.sql.gz
```
**Important**
Lorsque vous copiez des données sensibles, assurez-vous d’utiliser un protocole de transfert réseau sécurisé.
1. Connectez-vous à votre instance Amazon EC2, puis installez les dernières mises à jour et les outils clients MySQL à l'aide des commandes suivantes :
```
sudo yum update -y
sudo yum install mysql -y
```
Pour plus d’informations, consultez [Connexion à votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) pour les instances Linux dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
**Important**
Cet exemple installe le client MySQL sur une Amazon Machine Image (AMI) pour une distribution Amazon Linux. Cet exemple n’installe pas le client MySQL sur une autre distribution, comme Ubuntu ou Red Hat Enterprise Linux. Pour en savoir plus sur l’installation de MySQL, consultez [Installation de MySQL](https://dev.mysql.com/doc/refman/8.4/en/installing.html) dans la documentation MySQL.
1. Une fois connecté à votre instance Amazon EC2, décompressez le fichier de sauvegarde de votre base de données. Les commandes suivantes sont des exemples.
+ Pour décompresser une sortie SQL, utilisez la commande suivante :
```
gzip backup.sql.gz -d
```
+ Pour décompresser une sortie texte délimité, utilisez la commande suivante :
```
tar xzvf backup.tar.gz
```
## Tâche 3 : Créer une base de données MySQL et importer les données depuis votre instance Amazon EC2
En créant une instance de base de données RDS for MySQL, ou un cluster de bases de données multi-AZ RDS for MySQL dans la même Région AWS que votre instance Amazon EC2, vous pouvez importer le fichier de sauvegarde de base de données plus rapidement à partir d’Amazon EC2 que via Internet.
Le schéma suivant montre l’importation de la sauvegarde d’une instance Amazon EC2 vers une base de données MySQL.
![\[Flux de travail montrant l’importation de la sauvegarde de l’instance EC2 vers la base de données MySQL.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_4.png)
### Pour créer une base de données MySQL et importer vos données
1. Déterminez quelle classe d’instance de base de données et quelle quantité d’espace de stockage sont nécessaires pour prendre en charge la charge de travail attendue pour cette base de données Amazon RDS. Dans le cadre de ce processus, décidez de l’espace suffisant et de la capacité de traitement qui conviennent à vos procédures de chargement des données. Décidez également ce qui est nécessaire pour gérer la charge de travail de production. Vous pouvez estimer ces éléments en fonction de la taille et des ressources de la base de données source MySQL. Pour de plus amples informations, veuillez consulter [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
1. Créez une instance de base de données ou un cluster de base de données multi-AZ dans celui Région AWS qui contient votre instance Amazon EC2.
Pour créer un cluster de bases de données multi-AZ RDS for MySQL, suivez les instructions dans [Création d’un cluster de bases de données Multi-AZ pour Amazon RDS](create-multi-az-db-cluster.md).
Pour créer une instance de base de données RDS for MySQL, suivez les instructions dans [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md) et utilisez les instructions suivantes :
+ Spécifiez une version du moteur de base de données compatible avec votre instance de base de données source.
+ Spécifiez les mêmes cloud privé virtuel (VPC) et groupe de sécurité VPC que pour votre instance Amazon EC2. Cette approche garantit que votre instance Amazon EC2 et votre instance Amazon RDS sont visibles l’une de l’autre sur le réseau. Assurez-vous que votre instance de base de données est accessible au public. Pour configurer la réplication avec votre base de données source comme décrit dans l’une des sections suivantes, votre instance de base de données doit être publiquement accessible.
+ Ne configurez pas plusieurs zones de disponibilité, la rétention des sauvegardes ou les réplicas en lecture tant que vous n’avez pas importé la sauvegarde de la base de données. Lorsque l'importation est terminée, vous pouvez configurer l'option multi-AZ et la rétention des sauvegardes pour l'instance de production.
1. Vérifiez les options de configuration par défaut de la base de données Amazon RDS. Si le groupe de paramètres par défaut pour la base de données ne dispose pas des options de configuration que vous voulez, trouvez un autre groupe qui les possède ou créez un groupe de paramètres. Pour plus d’informations sur la création d’un groupe de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
1. Connectez-vous à la nouvelle base de données Amazon RDS en tant qu’utilisateur principal. Créez ensuite les utilisateurs requis pour prendre en charge les administrateurs, les applications et les services qui doivent accéder à l’instance de base de données. Le nom d’hôte de la base de données Amazon RDS est la valeur **Point de terminaison** de cette instance de base de données sans le numéro de port. Par exemple, `mysampledb.123456789012.us-west-2.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de la base de données dans la console Amazon RDS.
1. Connectez-vous à votre instance EC2 Amazon. Pour plus d’informations, consultez [Connexion à votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) pour les instances Linux dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
1. Connectez-vous à votre base de données Amazon RDS comme hôte distant depuis votre instance Amazon EC2 à l’aide de la commande `mysql`. Voici un exemple de commande :
```
mysql -h host_name -P 3306 -u db_master_user -p
```
*host\$1name*Il s'agit du point de terminaison de la base de données Amazon RDS.
1. À l’invite `mysql`, exécutez la commande `source` et transmettez-lui le nom du fichier de vidage de votre base de données. Cette commande charge les données dans l’instance de base de données Amazon RDS.
+ Pour le format SQL, utilisez la commande suivante :
```
mysql> source backup.sql;
```
+ Pour le format texte délimité, créez d’abord la base de données, s’il ne s’agit pas de la base de données par défaut que vous avez créée lors de la configuration de la base de données Amazon RDS.
```
mysql> create database database_name;
mysql> use database_name;
```
Créez ensuite les tables.
```
mysql> source table1.sql
mysql> source table2.sql
etc...
```
Enfin, importez les données.
```
mysql> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
mysql> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
etc...
```
Pour améliorer les performances, vous pouvez exécuter ces opérations en parallèle à partir de plusieurs connexions de telle sorte que l’ensemble de vos tables soit créé et chargé simultanément.
**Note**
Si vous avez utilisé des options de mise en forme des données avec `mysqldump` lorsque vous avez initialement vidé la table, assurez-vous d’utiliser les mêmes options avec `LOAD DATA LOCAL INFILE` pour garantir une interprétation correcte du contenu du fichier de données.
1. Exécutez une simple requête `SELECT` sur l’une ou les deux tables de la base de données importée afin de vérifier que l’importation s’est déroulée avec succès.
Si vous n'avez plus besoin de l'instance Amazon EC2 utilisée dans cette procédure, mettez-la hors service afin de réduire votre AWS consommation de ressources. Pour mettre fin à une instance EC2, consultez [Terminer une instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
## Tâche 4 : Répliquer les données de votre base de données externe vers votre nouvelle base de données Amazon RDS
Votre base de données source a probablement été mise à jour pendant la copie et le transfert des données vers la base de données MySQL. Ainsi, vous pouvez utiliser la réplication pour intégrer la base de données up-to-date copiée à la base de données source.
![\[Flux de travail qui montre la réplication des données de la base de données externe MySQL vers la base de données sur Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_5.png)
Les autorisations requises pour démarrer la réplication sur une base de données Amazon RDS sont restreintes et ne sont pas disponibles pour votre utilisateur principal Amazon RDS. Vous devez donc utiliser la procédure stockée Amazon RDS appropriée pour votre version de moteur majeure :
+ [mysql\$1rds\$1set\$1external\$1master (versions majeures RDS for MySQL 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source)
+ [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) pour configurer la réplication et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour la démarrer
### Pour démarrer la réplication
Dans la Tâche 1, [lorsque vous avez défini les options de réplication](#mysql-importing-data-reduced-downtime-set-replication-options), vous avez activé la journalisation binaire et défini un ID de serveur unique pour votre base de données source. À présent, vous pouvez configurer votre base de données Amazon RDS comme réplica avec votre base de données active comme instance de réplication source.
1. Dans la console Amazon RDS, ajoutez l’adresse IP du serveur qui héberge la base de données source au groupe de sécurité VPC de la base de données Amazon RDS. Pour plus d’informations sur la configuration d’un groupe de sécurité VPC, consultez [Configuration de règles de groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
Il se peut aussi que vous ayez besoin de configurer votre réseau local pour autoriser les connexions à partir de l’adresse IP de votre base de données Amazon RDS, de telle sorte qu’elle puisse communiquer avec votre instance source. Pour obtenir l’adresse IP de la base de données Amazon RDS, utilisez la commande `host` :
```
host host_name
```
*host\$1name*Il s'agit du nom DNS du point de terminaison de la base de données Amazon RDS, par exemple`myinstance.123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de l’instance de base de données dans la console Amazon RDS.
1. A l’aide du client de votre choix, connectez-vous à l’instance source et créez un utilisateur à utiliser pour la réplication. Ce compte est utilisé exclusivement pour la réplication et doit être limité à votre domaine pour améliorer la sécurité. Voici un exemple de commande :
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**Note**
Spécifiez des informations d’identification autres que celles affichées ici, en tant que bonne pratique de sécurité.
1. Pour l’instance source, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. Par exemple, pour accorder les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données à l’utilisateur « `repl_user` » de votre domaine, émettez la commande suivante :
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Transformez la base de données Amazon RDS en réplica. Connectez-vous à la base de données Amazon RDS en tant qu’utilisateur principal et identifiez la base de données source comme instance de réplication source à l’aide de la procédure stockée Amazon RDS appropriée.
+ [mysql\$1rds\$1set\$1external\$1master (versions majeures RDS for MySQL 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source)
Si vous avez un fichier de sauvegarde au format SQL, utilisez le nom et la position du fichier journal maître que vous avez déterminés à l’étape 4. Si vous avez utilisé le format texte délimité, utilisez le nom et la position que vous avez déterminés lors de la création des fichiers de sauvegarde. Les commandes suivantes sont des exemples :
**MySQL versions 8.4 et ultérieures**
```
CALL mysql.rds_set_external_source ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**MySQL 8.0 et versions antérieures**
```
CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**Note**
Spécifiez des informations d’identification autres que celles affichées ici, en tant que bonne pratique de sécurité.
1. Pour démarrer la réplication sur la base de données Amazon RDS, exécutez la commande suivante qui utilise la procédure stockée [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) :
```
CALL mysql.rds_start_replication;
```
1. Sur la base de données Amazon RDS, exécutez la commande [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) pour déterminer quand le réplica est à jour avec l’instance de réplication source. Les résultats de la commande `SHOW REPLICA STATUS` incluent le champ `Seconds_Behind_Master`. Lorsque le champ `Seconds_Behind_Master` renvoie 0, le réplica est à jour avec l’instance de réplication source.
**Note**
Les versions précédentes de MySQL utilisaient `SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version de MySQL antérieure à la version 8.0.23, utilisez alors `SHOW SLAVE STATUS`.
1. Une fois que la base de données Amazon RDS est à jour, activez les sauvegardes automatiques de façon à pouvoir restaurer la base de données si nécessaire. Vous pouvez activer ou modifier les sauvegardes automatiques de votre base de données Amazon RDS à l’aide de la [console Amazon RDS](https://console.aws.amazon.com/rds/). Pour de plus amples informations, veuillez consulter [Présentation des sauvegardes](USER_WorkingWithAutomatedBackups.md).
## Tâche 5 : Rediriger votre application active vers votre instance Amazon RDS
Une fois que la base de données MySQL est à jour avec l’instance de réplication source, vous pouvez mettre à jour votre application active et utiliser l’instance Amazon RDS.
![\[Flux de travail qui montre l’arrêt de la réplication et la direction de l’application active vers la base de données sur Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_6.png)
### Pour rediriger votre application active vers votre base de données MySQL et arrêter la réplication
1. Pour ajouter le groupe de sécurité VPC pour la base de données Amazon RDS, ajoutez l’adresse IP du serveur qui héberge l’application. Pour plus d’informations sur la modification d’un groupe de sécurité VPC, consultez [Configuration de règles de groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
1. Vérifiez que le champ `Seconds_Behind_Master` de la commande [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) a pour résultat 0, valeur indiquant que le réplica est à jour avec l’instance de réplication source.
```
SHOW REPLICA STATUS;
```
**Note**
Les versions précédentes de MySQL utilisaient `SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version MySQL antérieure à la version 8.0.23, utilisez alors `SHOW SLAVE STATUS`.
1. Fermez toutes les connexions à la source une fois leurs transactions terminées.
1. Mettez à jour votre application pour utiliser la base de données Amazon RDS. Cette mise à jour implique généralement de modifier les paramètres de connexion pour identifier le nom d'hôte et le port de la base de données Amazon RDS, le compte utilisateur et le mot de passe avec lesquels se connecter, et la base de données à utiliser.
1. Connectez-vous à l’instance de base de données.
Pour un cluster de bases de données multi-AZ, connectez-vous à l'instance de base de données d'écriture.
1. Arrêtez la réplication pour l’instance Amazon RDS en exécutant la commande suivante qui utilise la procédure stockée [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) :
```
CALL mysql.rds_stop_replication;
```
1. Réinitialisez la configuration de réplication de telle sorte que cette instance ne soit plus identifiée comme un réplica en utilisant la procédure stockée Amazon RDS appropriée sur votre base de données Amazon RDS :
+ [mysql\$1rds\$1reset\$1external\$1master (versions majeures RDS for MySQL 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master)
+ [mysql.rds\$1reset\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source)
**MySQL versions 8.4 et ultérieures**
```
CALL mysql.rds_reset_external_source;
```
**MySQL 8.0 et versions antérieures**
```
CALL mysql.rds_reset_external_master;
```
1. Activez des fonctions Amazon RDS supplémentaires, telles que la prise en charge Multi-AZ et les réplicas en lecture. Pour plus d’informations, consultez [Configuration et gestion d’un déploiement multi-AZ pour Amazon RDS](Concepts.MultiAZ.md) et [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
# Importation de données depuis n’importe quelle source vers une instance de base de données Amazon RDS for MySQL
Amazon RDS vous permet de migrer les données MySQL existantes depuis n’importe quelle source vers une instance de base de données RDS for MySQL. Vous pouvez transférer des données depuis des bases de données sur site, d’autres fournisseurs de cloud ou des instances de base de données RDS for MySQL existantes vers votre instance de base de données RDS for MySQL cible. Cette fonctionnalité vous permet de consolider les bases de données, de mettre en œuvre des solutions de reprise après sinistre ou d’y basculer à partir de bases de données autogérées. Les scénarios courants incluent le passage de serveurs MySQL auto-hébergés vers des instances de base de données Amazon RDS entièrement gérées, la consolidation de plusieurs bases de données MySQL en une seule instance de base de données ou la création d’environnements de test avec des données de production. Les sections suivantes fournissent des step-by-step instructions pour importer vos données MySQL à l'aide de méthodes telles que `mysqldump` les fichiers de sauvegarde ou la réplication.
## Étape 1 : Créer les fichiers plats contenant les données à charger
Utilisez un format courant, tel que CSV (valeurs séparées par des virgules), pour stocker les données à charger. Chaque table doit avoir son propre fichier ; les données de plusieurs tables ne peuvent pas être combinées dans le même fichier. Attribuez à chaque fichier le même nom que celui de la table à laquelle il correspond. L’extension du fichier est laissée à votre libre choix. Par exemple, si le nom de la table est `sales`, le nom du fichier peut être `sales.csv` ou `sales.txt`.
Si possible, triez les données sur la clé primaire de la table en cours de chargement. Cela améliore de façon spectaculaire les temps de chargement et réduit le stockage disque requis.
Cette procédure est d'autant plus rapide et efficace que les fichiers ont une petite taille. Si la taille non compressée d’un fichier est supérieure à 1 Gio, scindez-le en plusieurs fichiers et chargez chacun d’eux séparément.
Sur les systèmes Unix (Linux inclus), utilisez la commande `split`. Par exemple, la commande suivante fractionne le fichier `sales.csv` en plusieurs fichiers de moins d’1 Gio, le fractionnement n’intervenant qu’aux sauts de ligne (-C 1 024m). Les noms des nouveaux fichiers incluent des suffixes numériques croissants. La commande suivante génère des fichiers portant des noms tels que `sales.part_00` et `sales.part_01`.
```
split -C 1024m -d sales.csv sales.part_
```
Des utilitaires semblables sont disponibles sur les autres systèmes d’exploitation.
Vous pouvez stocker les fichiers plats n’importe où. Toutefois, lorsque vous chargez les données à l’[Étape 5](#mysql-importing-data-any-source-load-data), vous devez invoquer le shell `mysql` à partir de l’emplacement où se trouvent les fichiers, ou utiliser le chemin absolu des fichiers lors de l’exécution de `LOAD DATA LOCAL INFILE`.
## Étape 2 : Empêcher les applications d’accéder à l’instance de base de données cible
Avant de démarrer un chargement volumineux, empêchez toute activité d’application d’accéder à l’instance de base de données cible sur laquelle s’effectuera le chargement. Nous le recommandons particulièrement quand d’autres sessions sont susceptibles de modifier les tables chargées ou les tables qu’elles référencent. Cela réduit le risque de violation des contraintes intervenant pendant le chargement et améliore les performances de chargement. Dans le même temps, cela permet également de restaurer l'instance de base de données au point juste antérieur au chargement sans perdre les modifications effectuées par les processus non impliqués dans le chargement.
Il est vrai que cela peut ne pas être possible ou pratique. Si vous ne pouvez pas empêcher les applications d'accéder à l'instance de base de données avant le chargement, prenez les mesures nécessaires pour garantir la disponibilité et l'intégrité de vos données. Les étapes spécifiques requises varient grandement en fonction de cas d’utilisation spécifiques et des exigences du site.
## Étape 3 : Créer un instantané de base de données
Si vous envisagez de charger des données dans une nouvelle instance de base de données qui ne contient aucune donnée, vous pouvez ignorer cette étape. Sinon, nous vous recommandons de créer des instantanés de base de données de l’instance de base de données Amazon RDS cible avant et après le chargement de données. Les instantanés de base de données Amazon RDS sont des sauvegardes complètes de votre instance de base de données qui peuvent être utilisées pour restaurer l’instance de base de données à un état connu. Lorsque vous lancez un instantané de base de données, I/O les opérations sur votre instance de base de données sont momentanément suspendues pendant la sauvegarde de votre base de données.
La création d’un instantané de base de données juste avant le chargement vous permet, si besoin est, de restaurer la base de données à son état avant le chargement. Un instantané de base de données pris immédiatement après le chargement vous évite de devoir charger les données à nouveau en cas d’incident. Vous pouvez également utiliser des instantanés de base de données après le chargement pour importer des données dans de nouvelles instances de base de données.
L'exemple suivant exécute la AWS CLI [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html)commande pour créer un instantané de base de données de l'`AcmeRDS`instance et attribuer l'identifiant à l'instantané de base de données`"preload"`.
Pour Linux, macOS ou Unix :
```
aws rds create-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Pour Windows :
```
aws rds create-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
Vous pouvez aussi utiliser la restauration de la fonctionnalité d’instantané de bases de données pour créer des instances de bases de données de test dans le but de réaliser des essais ou pour annuler les modifications effectuées pendant le chargement.
Gardez à l’esprit que la restauration d’une base de données à partir d’un instantané de bases de données crée une nouvelle instance de base de données qui, comme toutes les instances de base de données, possède un point de terminaison et un identifiant unique. Si vous devez restaurer l'instance de base de données sans modifier le point de terminaison, vous devez d'abord supprimer l'instance de base de données de telle sorte que le point de terminaison puisse être réutilisé.
Par exemple, pour créer une instance de base de données pour les essais ou autres tests, vous attribuez à l'instance de base de données son propre identifiant. Dans cet exemple, l'identifiant est `AcmeRDS-2`. L’exemple se connecte à l’instance de base de données à l’aide du point de terminaison associé à `AcmeRDS-2`. Pour plus d'informations, consultez [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html).
Pour Linux, macOS ou Unix :
```
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS-2 \
--db-snapshot-identifier preload
```
Pour Windows :
```
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS-2 ^
--db-snapshot-identifier preload
```
Pour réutiliser le point de terminaison existant, il faut d’abord supprimer l’instance de base de données, puis donner le même identifiant à la base de données restaurée. Pour de plus amples informations, veuillez consulter [delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html).
L’exemple suivant prend également un instantané de base de données final de l’instance de base de données avant de la supprimer. Cette action est facultative, mais recommandée.
Pour Linux, macOS ou 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
```
Pour 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
```
## Étape 4 (facultative) : Désactiver les sauvegardes automatiques Amazon RDS
**Avertissement**
Ne désactivez pas les sauvegardes automatiques si vous devez effectuer une point-in-time restauration.
La désactivation des sauvegardes automatiques est une optimisation des performances et n’est pas requise pour les chargements de données. La désactivation des sauvegardes automatiques efface toutes les sauvegardes existantes. Par conséquent, une fois les sauvegardes automatisées désactivées, la point-in-time restauration n'est pas possible. Les instantanés de bases de données manuels ne sont pas affectés par la désactivation des sauvegardes automatiques. Tous les instantanés manuels de base de données existants demeurent disponibles pour la restauration.
La désactivation des sauvegardes automatiques réduit le temps de chargement de près de 25 %, ainsi que la quantité d'espace de stockage requise pendant le chargement. Si vous envisagez de charger des données dans une nouvelle instance de base de données qui ne contient aucune donnée, la désactivation des sauvegardes constitue un moyen simple d'accélérer le chargement et d'éviter d'utiliser le stockage supplémentaire nécessaire pour les sauvegardes. Cependant, dans certains cas, vous pouvez envisager de charger dans une instance de base de données qui contient déjà des données. Si tel est le cas, évaluez les avantages de la désactivation des sauvegardes par rapport à l'impact de la perte de performance point-in-time-recovery.
Les instances de bases de données ont les sauvegardes automatiques activées par défaut (avec une période de rétention égale à une journée). Pour désactiver les sauvegardes automatiques, définissez la période de rétention des sauvegardes à 0. Après le chargement, vous pouvez réactiver les sauvegardes en définissant la période de rétention des sauvegardes avec une valeur différente de zéro. Pour activer ou désactiver les sauvegardes, Amazon RDS arrête l’instance de base de données, puis la redémarre pour activer ou désactiver la journalisation MySQL.
Exécutez la AWS CLI `modify-db-instance` commande pour définir la rétention des sauvegardes sur zéro et appliquez la modification immédiatement. Comme la définition de la période de rétention à la valeur zéro nécessite un redémarrage de l’instance de base de données, attendez que le redémarrage soit terminé avant de poursuivre. Pour de plus amples informations, veuillez consulter [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html).
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--apply-immediately \
--backup-retention-period 0
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--apply-immediately ^
--backup-retention-period 0
```
Vous pouvez vérifier l'état de votre instance de base de données à l'aide de la AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande. L’exemple suivant montre comment afficher le statut de l’instance de base de données `AcmeRDS`.
```
aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}"
```
Lorsque le statut de l’instance de base de données est `available`, vous êtes prêt à continuer.
## Étape 5 : Charger les données
Pour lire les lignes de vos fichiers plats dans les tables de base de données, utilisez l’instruction MySQL `LOAD DATA LOCAL INFILE`.
**Note**
Vous devez invoquer le shell `mysql` à partir de l’emplacement où se trouvent vos fichiers plats, ou utiliser le chemin absolu des fichiers lors de l’exécution de `LOAD DATA LOCAL INFILE`.
L’exemple suivant montre comment charger les données d’un fichier nommé `sales.txt` dans une table nommée `Sales` dans la base de données :
```
mysql> 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
```
Pour plus d’informations sur l’instruction `LOAD DATA`, consultez [Instruction LOAD DATA](https://dev.mysql.com/doc/refman/8.4/en/load-data.html) dans la documentation MySQL.
## Étape 6 : Réactiver les sauvegardes automatiques Amazon RDS
Si vous avez désactivé les sauvegardes automatiques Amazon RDS lors de l’[étape 4](#mysql-importing-data-any-source-turn-off-automated-backups), une fois le chargement terminé, réactivez-les en redéfinissant la période de rétention des sauvegardes à la valeur qui était la sienne avant le chargement. Comme noté dans l’étape 4, Amazon RDS redémarre l’instance de base de données. Par conséquent, préparez-vous à une brève interruption de service.
L'exemple suivant exécute la AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)commande pour activer les sauvegardes automatiques pour l'`AcmeRDS`instance de base de données et définir la période de rétention sur un jour :
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--backup-retention-period 1 \
--apply-immediately
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--backup-retention-period 1 ^
--apply-immediately
```