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.
Migration de données vers un cluster de base de données Amazon Aurora MySQL
Vous avez plusieurs options pour la migration des données de votre base de données existante vers un cluster de base de données Amazon Aurora MySQL. Vos options de migration dépendent également de la base de données à partir de laquelle vous effectuez la migration et de la taille des données que vous migrez.
Il existe deux types différents de migration : physique et logique. La migration physique signifie que des copies physiques des fichiers de base de données sont utilisées pour migrer la base de données. La migration logique signifie que la migration s'effectue en appliquant des modifications logiques à la base de données, telles que des insertions, des mises à jour et des suppressions.
La migration physique présente les avantages suivants :
-
La migration physique est plus rapide que la migration logique, notamment pour les bases de données volumineuses.
-
Les performances de base de données ne sont pas réduites lorsqu'une sauvegarde est effectuée pour une migration physique.
-
La migration physique peut migrer tout le contenu de la base de données source, y compris les composants de base de données complexes.
La migration physique présente les limites suivantes :
-
Le paramètre
innodb_page_sizedoit être défini sur sa valeur par défaut (16KB). -
Le paramètre
innodb_data_file_pathdoit être configuré avec un seul fichier de données qui utilise le nom de fichier de données par défaut"ibdata1:12M:autoextend". Les bases de données comportant deux fichiers de données, ou avec un fichier de données portant un nom différent, ne peuvent pas faire l'objet d'une migration à l'aide de cette méthode.Voici des exemples de noms de fichier non autorisés :
"innodb_data_file_path=ibdata1:50M; ibdata2:50M:autoextend"et"innodb_data_file_path=ibdata01:50M:autoextend". -
Le paramètre
innodb_log_files_in_groupdoit être défini sur sa valeur par défaut (2).
La migration logique présente les avantages suivants :
-
Vous pouvez migrer des sous-ensembles de la base de données, comme par exemple des tables spécifiques ou des parties d'une table.
-
Les données peuvent être migrées quelle que soit la structure de stockage physique.
La migration logique présente les limites suivantes :
-
La migration logique est généralement plus lente que la migration physique.
-
Les composants de base de données complexes peuvent ralentir le processus de migration logique. Dans certains cas, les composants de base de données complexes peuvent même bloquer la migration logique.
Le tableau ci-dessous décrit vos options et le type de migration pour chaque option.
| Migration à partir de | Type de migration | Solution |
|---|---|---|
Une instance de base de données RDS pour MySQL |
Physique |
Vous pouvez migrer les données d'une instance de base de données RDS pour MySQL en créant d'abord un réplica en lecture Aurora MySQL d'une instance de base de données MySQL. Lorsque le retard du réplica entre l'instance de base de données MySQL et le réplica en lecture Aurora MySQL est égal à 0, vous pouvez diriger vos applications clientes vers la lecture à partir du réplica en lecture Aurora, puis arrêter la réplication pour transformer le réplica en lecture Aurora MySQL en cluster de base de données Aurora MySQL pour la lecture et l'écriture. Pour plus d'informations, consultez Migration des données d'une instance de base de données RDS for MySQL vers un cluster de base de données Amazon Aurora MySQL à l'aide d'un réplica en lecture Aurora. |
Un instantané de bases de données RDS pour MySQL |
Physique |
Vous pouvez migrer les données directement d'un instantané de bases de données RDS pour MySQL vers un cluster de base de données Amazon Aurora MySQL. Pour plus d'informations, consultez Migration d'un instantané RDS pour MySQL vers Aurora. |
Une base de données MySQL externe à Amazon RDS |
Logique |
Vous pouvez créer un vidage de vos données à l'aide de l'utilitaire Pour exporter des métadonnées destinées aux utilisateurs de la base de données lors de la migration depuis une base de données MySQL externe, vous pouvez également utiliser une commande MySQL Shell au lieu de NoteL'utilitaire mysqlpump |
Une base de données MySQL externe à Amazon RDS |
Physique |
Vous pouvez copier les fichiers de sauvegarde de votre base de données vers un compartiment Amazon Simple Storage Service (Amazon S3), puis restaurer un cluster de base de données Amazon Aurora MySQL à partir de ces fichiers. Cette option peut être considérablement plus rapide que la migration des données à l'aide de |
Une base de données MySQL externe à Amazon RDS |
Logique |
Vous pouvez sauvegarder les données de votre base de données sous forme de fichiers texte et copier ces derniers vers un compartiment Amazon S3. Vous pouvez ensuite charger ces données dans un cluster de base de données Aurora MySQL existant à l'aide de la commande MySQL |
Une base de données qui n'est pas compatible avec MySQL |
Logique |
Vous pouvez utiliser AWS Database Migration Service (AWS DMS) pour migrer des données depuis une base de données qui n'est pas compatible avec MySQL. Pour plus d'informations AWS DMS, voir Qu'est-ce que le service AWS de migration de base de données ? |
Note
Si vous effectuez la migration d'une base de données MySQL externe à Amazon RDS, les options de migration décrites dans le tableau sont prises en charge seulement si votre base de données prend en charge les espaces de table InnoDB ou MyISAM.
Si la base de données MySQL que vous migrez vers Aurora MySQL utilise memcached, supprimez memcached avant de la migrer.
Vous ne pouvez pas migrer de certaines anciennes versions de MySQL 8.0, notamment des versions 8.0.11, 8.0.13 et 8.0.15, vers Aurora MySQL 3.05 et versions ultérieures. Nous vous recommandons de passer à MySQL version 8.0.28 avant de procéder à la migration.
