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 MariaDB
Vous pouvez utiliser plusieurs techniques différentes pour importer des données dans une instance de base de données RDS for MariaDB. 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 MariaDB :
**Note**
Amazon RDS ne prend pas en charge `mariadb-backup` ni l’importation depuis Amazon S3 for MariaDB.
| Source | Quantité de données | Une seule fois ou en continu | Interruption de l'application | Technique | En savoir plus |
| --- | --- | --- | --- | --- | --- |
| Base de données MariaDB existante sur site ou sur Amazon EC2 | N’importe quel compte | En continu | Minimale | Configurez la réplication avec une base de données MariaDB existante comme source de réplication. Vous pouvez configurer la réplication dans une instance de base de données MariaDB à l'aide des identificateurs de transaction globaux de MariaDB (GTIDs) lorsque l'instance externe est MariaDB version 10.0.24 ou supérieure, ou en utilisant les coordonnées du journal binaire pour les instances de MariaDB sur les versions antérieures à 10.0.24. MariaDB est GTIDs implémenté différemment de GTIDs MySQL, qui n'est pas pris en charge par Amazon RDS. | [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.ReplMariaDB.md) [Importation de données vers une instance de base de données Amazon RDS for MariaDB avec une durée d’indisponibilité réduite](mariadb-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 MariaDB 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 MariaDB existante | Petite | Une seule fois | Momentanée | Copiez les données directement dans votre instance de base de données MariaDB à l’aide d’un utilitaire de ligne de commande. | [Importation de données à partir d’une base de données MariaDB externe vers une instance de base de données Amazon RDS for MariaDB](mariadb-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 MariaDB `LOAD DATA LOCAL INFILE`. | [Importation de données depuis n’importe quelle source vers une instance de base de données Amazon RDS for MariaDB](mariadb-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 des erreurs 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 commande [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).
# Considérations sur l’importation de données pour MariaDB
Le contenu suivant présente des informations techniques sur le chargement de données dans MariaDB. Ce contenu est destiné aux utilisateurs qui connaissent bien l’architecture de serveur MariaDB.
## 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 MariaDB :
+ 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 la récupération, MariaDB extrait les données du journal binaire dans un fichier plat. MariaDB 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 10.11 et antérieures de MariaDB, 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 MariaDB, le thread de purge doit attendre que la plus ancienne transaction active soit validée ou annulée pour supprimer 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
MariaDB 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 mariadb-dump. Si une défaillance se produit lors du chargement d’un fichier mariadb-dump, 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 MariaDB. Contrairement aux autres systèmes de base de données, MariaDB 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. `mariadb-dump` 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.
# Importation de données à partir d’une base de données MariaDB externe vers une instance de base de données Amazon RDS for MariaDB
Vous pouvez importer des données à partir d’une base de données MariaDB existante vers une instance de base de données RDS for MariaDB. Pour cela, vous devez copier la base de données avec [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) ou [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/) et la transférer directement dans l’instance de base de données RDS for MariaDB. L’utilitaire de ligne de commande `mysqldump` ou `mariadb-dump` est généralement utilisé pour effectuer des sauvegardes et des transferts de données d’un serveur MariaDB vers un autre. Il est inclus dans les logiciels clients MariaDB.
À partir de MariaDB 11.0.1, vous devez utiliser `mariadb-dump` à la place de `mysqldump`.
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. Pour les versions 11.0.1 et ultérieures de MariaDB, remplacez `mysqldump` par `mariadb-dump`.
```
mysqldump -u local_user \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u RDS_user \
--port=port_number \
--host=host_name \
-pRDS_password
```
**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` et `mariadb-dump` 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 MariaDB 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 MariaDB 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` ou `mariadb-dump` 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 MariaDB 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 MariaDB. 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` ou `mariadb-dump`. Pour ce faire, incluez les paramètres suivants avec votre commande `mysqldump` ou `mariadb-dump` :
+ `--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 MariaDB. Remplacez les valeurs par vos propres informations.
Pour Linux, macOS ou Unix :
```
sudo mariadb-dump -u local_user \
--databases world \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u rds_user \
--port=3306 \
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com \
-pRDS_password
```
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.
```
mariadb-dump -u local_user ^
--databases world ^
--single-transaction ^
--compress ^
--order-by-primary ^
--routines=0 ^
--triggers=0 ^
--events=0 ^
-plocal_password | mariadb -u RDS_user ^
--port=3306 ^
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^
-pRDS_password
```
**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 instance de base de données Amazon RDS for MariaDB avec une durée d’indisponibilité réduite
Dans certains cas, vous devez importer les données à partir d’une base de données externe MariaDB prenant en charge une application active vers une instance de base de données RDS for MariaDB. 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. À l'aide de cette procédure, vous pouvez réduire le coût de l'importation en réduisant la quantité de données transmises sur le réseau AWS.
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. Si l'instance externe est MariaDB 10.0.24 ou version ultérieure et que l'instance cible est RDS pour MariaDB, configurez la réplication MariaDB en fonction des identifiants de transaction globaux (). GTIDs Sinon, configurez la réplication en fonction des coordonnées des journaux binaires. Nous recommandons la réplication GTID si votre base de données externe la prend en charge, car la réplication GTID est une méthode plus fiable. Pour plus d’informations, consultez [Identifiants de transaction mondiaux](http://mariadb.com/kb/en/mariadb/global-transaction-id/) dans la documentation MariaDB.
Le schéma suivant montre l’importation d’une base de données MariaDB externe dans une base de données MariaDB sur Amazon RDS.
![\[Flux de travail qui montre l’importation d’une base de données MariaDB externe dans une base de données MariaDB sur Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_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 MariaDB 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 MariaDB.
![\[Flux de travail qui montre la création d’une sauvegarde de la base de données MariaDB.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_2.png)
Vous pouvez recourir à l’utilitaire `mysqldump` ou `mariadb-dump` pour créer une sauvegarde de base de données au format SQL ou texte délimité. Dans MariaDB 10.5, le client s’appelle [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/). À partir de MariaDB 11.0.1, vous devez utiliser `mariadb-dump` à la place de `mysqldump`. 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` ou `mariadb-dump`.
Nous vous recommandons également de comparer les performances de `mysqldump` ou `mariadb-dump` 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](mariadb-importing-data-any-source.md#mariadb-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 MariaDB 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` ou `mariadb-dump`, 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` ou de `mariadb-dump`. 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`
Les utilitaires `mysqldump` et `mariadb-dump` excluent 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 `[mariadb]` mise à jour d’un fichier `my.cnf` :
```
[mariadb]
log-bin
server-id=1
log-basename=master1
binlog-format=mixed
```
Pour plus d’informations, consultez [Setting the Replication Source Configuration](https://mariadb.com/docs/server/ha-and-performance/standard-replication/setting-up-replication) dans la documentation MariaDB.
1. Pour la réplication avec un cluster de bases de données multi-AZ, activez `gtid_strict_mode`. Pour plus d’informations, consultez [gtid\$1strict\$1mode](https://mariadb.com/docs/server/ha-and-performance/standard-replication/gtid#gtid_strict_mode) dans la documentation MariaDB.
L’activation de `gtid_strict_mode` n’est pas requise pour la réplication avec une instance de base de données.
1. Redémarrez le service `mariadb`.
```
sudo service mariadb 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` ou `mariadb-dump`, en spécifiant un format SQL ou un format texte délimité.
Pour améliorer les performances et assurer l’intégrité des données, utilisez les options `--order-by-primary` et `--single-transaction` pour `mysqldump` et `mariadb-dump`.
Pour éviter d’inclure la base de données système MySQL dans la sauvegarde, n’utilisez pas l’option `--all-databases` avec `mysqldump` ou `mariadb-dump`. 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 les versions 10.11 et supérieures de MariaDB, remplacez `mariadb-dump` par `mysqldump`.
Pour Linux, macOS ou Unix :
```
sudo mariadb-dump \
--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 :
```
mariadb-dump ^
--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 les versions 11.01 et ultérieures de MariaDB, remplacez `mysqldump` par `mariadb-dump`.
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` ou `mariadb-dump`. Pour ce faire, incluez les arguments suivants dans votre commande `mysqldump` ou `mariadb-dump` :
`--routines=0`
`--triggers=0`
`--events=0`
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. Si l’instance externe est la version 10.0.23 ou antérieure de MariaDB, 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 renvoyée pour les versions de MariaDB.
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
1. Si l’instance externe que vous utilisez est MariaDB version 10.0.24 ou ultérieure, utilisez la réplication basée sur le GTID. Exécutez `SHOW MASTER STATUS` sur l’instance MariaDB externe pour obtenir le nom du fichier journal binaire et son emplacement, puis convertissez-les en un GTID en exécutant `BINLOG_GTID_POS` sur l’instance MariaDB externe.
```
SELECT BINLOG_GTID_POS('binary_log_file_name', binary_log_file_position);
```
Notez le GTID renvoyé. Il vous faut le GTID pour configurer la réplication.
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 MariaDB. 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 que l'instance Amazon EC2 soit Région AWS identique à votre base de données Amazon RDS réduit également la latence du réseau lors de 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/MigrateMariaDBToRDS_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 MariaDB à l’aide des commandes suivantes :
```
sudo yum update -y
sudo yum install mariadb1011-client-utils -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* et [Connecteurs MariaDB](https://mariadb.com/docs/connectors) dans la documentation MariaDB.
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 MariaDB et importer les données depuis votre instance Amazon EC2
En créant une instance de base de données RDS pour MariaDB identique à Région AWS votre instance Amazon EC2, vous pouvez importer le fichier de sauvegarde de base de données depuis Amazon EC2 plus rapidement que sur Internet.
Le schéma suivant montre l’importation de la sauvegarde d’une instance Amazon EC2 vers une base de données MariaDB.
![\[Flux de travail montrant l’importation de la sauvegarde de l’instance EC2 vers la base de données MariaDB.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_4.png)
### Pour créer une base de données MariaDB 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 MariaDB. 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 dans le Région AWS contenant votre instance Amazon EC2. Suivez les instructions présentées dans [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md) et utilisez les directives 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 :
```
MariaDB [(none)]> 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.
```
MariaDB [(none)]> create database database_name;
MariaDB [(none)]> use database_name;
```
Créez ensuite les tables.
```
MariaDB [(none)]> source table1.sql
MariaDB [(none)]> source table2.sql
etc...
```
Enfin, importez les données.
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
etc...
```
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` ou `mariadb-dump` 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 MariaDB. Vous pouvez utiliser la réplication pour intégrer la base de données copiée up-to-date à la base de données source.
![\[Flux de travail qui montre la réplication des données de la base de données externe MariaDB vers la base de données sur Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_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 :
+ [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) 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](#mariadb-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. Si vous avez utilisé le format SQL pour créer votre fichier de sauvegarde et que l’instance externe n’est pas MariaDB 10.0.24 ou version ultérieure, examinez le contenu de ce fichier en exécutant la commande suivante :
```
cat backup.sql
```
Le fichier inclut un commentaire `CHANGE MASTER TO` qui contient le nom du fichier journal maître et son emplacement. Ce commentaire est inclus dans le fichier de sauvegarde quand vous utilisez l'option `--master-data` avec `mysqldump`. Notez les valeurs pour `MASTER_LOG_FILE` et `MASTER_LOG_POS`.
```
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
Si vous avez utilisé le format texte délimité pour créer votre fichier de sauvegarde et que l’instance externe n’est pas MariaDB 10.0.24 ou version ultérieure, vous devez avoir déjà les coordonnées du journal binaire de l’étape 1 dans la tâche 1 [lorsque vous avez créé une copie de sauvegarde de votre base de données existante](#mariadb-importing-data-reduced-downtime-create-backup).
Si l’instance externe est MariaDB 10.0.24 ou version ultérieure, vous devez déjà avoir le GTID à partir duquel démarrer la réplication de l’étape 2 dans la tâche 1, [lorsque vous avez créé une copie de sauvegarde de votre base de données existante](#mariadb-importing-data-reduced-downtime-create-backup).
1. Transformez la base de données Amazon RDS en réplica. Si l’instance externe ne possède pas la version MariaDB 10.0.24 ou ultérieure, 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 [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master).
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. Voici un exemple de commande :
```
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é.
Si l’instance externe possède la version MariaDB 10.0.24 ou ultérieure, 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 [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md). Utilisez le GTID défini à l’étape 2 de la tâche 1 [lorsque vous avez créé une copie de sauvegarde de votre base de données existante](#mariadb-importing-data-reduced-downtime-create-backup). Voici un exemple de commande :
```
CALL mysql.rds_set_external_master_gtid ('source_server_ip_address', 3306, 'ReplicationUser', 'password', 'GTID', 1);
```
`source_server_ip_address` est l'adresse IP de l'instance de réplication source. Une adresse DNS privée EC2 n’est pas prise en charge actuellement.
**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, pour déterminer à quel moment la réplique se trouve up-to-date dans l'instance de réplication source, exécutez la commande [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html). Les résultats de la commande `SHOW REPLICA STATUS` incluent le champ `Seconds_Behind_Master`. Lorsque le `Seconds_Behind_Master` champ renvoie 0, la réplique correspond up-to-date à l'instance de réplication source.
Pour une instance de base de données MariaDB 10.5, 10.6, 10.11, 11.4 ou 11.8, exécutez la procédure stockée [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) à la place de la commande MySQL.
1. Une fois la base de données Amazon RDS up-to-date installée, activez les sauvegardes automatiques afin de pouvoir restaurer cette 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 MariaDB up-to-date est associée à l'instance de réplication source, vous pouvez désormais mettre à jour votre application live pour 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/MigrateMariaDBToRDS_6.png)
### Pour rediriger votre application active vers votre base de données MariaDB 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 `Seconds_Behind_Master` champ des résultats de la commande [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) est égal à 0, ce qui indique que la réplique est up-to-date associée à l'instance de réplication source.
```
SHOW REPLICA STATUS;
```
Pour une instance de base de données MariaDB 10.5, 10.6, 10.11, 11.4 ou 11.8, exécutez la procédure [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) à la place de la commande MySQL.
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.
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 exécutant la commande suivante, qui utilise la procédure stockée [mysql.rds\$1reset\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) sur votre base de données Amazon RDS :
```
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 MariaDB
Amazon RDS vous permet de migrer les données MariaDB existantes depuis n’importe quelle source vers une instance de base de données RDS for MariaDB. 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 MariaDB existantes vers votre instance de base de données RDS for MariaDB 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 MariaDB 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 MariaDB 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 MariaDB à l'aide de méthodes `mariadb-dump` telles que 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](#mariadb-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 MariaDB.
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 MariaDB `LOAD DATA LOCAL INFILE`.
**Note**
Vous devez invoquer le shell `mariadb` à 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 :
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\';
Query OK, 1 row affected (0.01 sec)
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
```
Pour plus d’informations sur l’instruction `LOAD DATA`, consultez [LOAD DATA INFILE](https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/inserting-loading-data/load-data-into-tables-or-index/load-data-infile) dans la documentation MariaDB.
## Étape 6 : Réactiver les sauvegardes automatiques Amazon RDS
Si vous avez désactivé les sauvegardes automatiques Amazon RDS lors de l’[étape 4](#mariadb-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
```