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 Amazon Aurora My SQL DB
Plusieurs options s'offrent à vous pour migrer les données de votre base de données existante vers un cluster Amazon Aurora My SQL DB. 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 |
|---|---|---|
Et RDS pour My SQL DB instance |
Physique |
Vous pouvez migrer depuis une instance RDS for My SQL DB en créant d'abord une réplique Aurora My SQL read d'une instance My SQL DB. Lorsque le délai de réplication entre l'instance My SQL DB et le réplica Aurora My SQL read est égal à 0, vous pouvez demander à vos applications clientes de lire à partir de la réplique de lecture Aurora, puis d'arrêter la réplication pour faire de la réplique Aurora My SQL read un cluster Aurora My SQL DB autonome pour la lecture et l'écriture. Pour plus de détails, consultez Migration de données d'une instance RDS for My SQL DB vers un cluster Amazon Aurora My SQL DB à l'aide d'une réplique de lecture Aurora. |
Et RDS pour My SQL DB Snapshot |
Physique |
Vous pouvez migrer les données directement RDS depuis un instantané de My SQL DB vers un cluster Amazon Aurora My SQL DB. Pour plus de détails, consultez Migration d'un instantané RDS pour MySQL vers Aurora. |
A Ma SQL base de données externe à Amazon RDS |
Logique |
Vous pouvez créer un dump de vos données à l'aide de l' Pour exporter des métadonnées destinées aux utilisateurs de la base de données lors de la migration depuis une SQL base de données My Database externe, vous pouvez également utiliser une commande My SQL Shell au lieu de NoteL'utilitaire mysqlpump |
A Ma SQL base de données externe à Amazon RDS |
Physique |
Vous pouvez copier les fichiers de sauvegarde de votre base de données vers un bucket Amazon Simple Storage Service (Amazon S3), puis restaurer un cluster Amazon Aurora SQL My DB à partir de ces fichiers. Cette option peut être considérablement plus rapide que la migration des données à l'aide de |
A Ma SQL base de données 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 Aurora My SQL DB existant à l'aide de la SQL commande |
Une base de données qui n'est pas SQL compatible avec My |
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 SQL compatible avec My. Pour plus d'informations AWS DMS, voir Qu'est-ce que le service AWS de migration de base de données ? |
Note
Si vous migrez une SQL base de données My externe à AmazonRDS, les options de migration décrites dans le tableau ne sont prises en charge que si votre base de données prend en charge les tablespaces InnoDB ou ISAM My.
Si la base de SQL données Ma base de données que vous migrez vers Aurora My SQL utilisememcached, supprimez-la memcached avant de la migrer.
Vous ne pouvez pas migrer vers Aurora My SQL version 3.05 ou supérieure à partir de certaines anciennes versions de My SQL 8.0, notamment 8.0.11, 8.0.13 et 8.0.15. Nous vous recommandons de passer à My SQL version 8.0.28 avant de procéder à la migration.
