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.
Utiliser une MySQL-compatible base de données comme cible pour AWS Database Migration Service
Vous pouvez migrer des données vers n'importe quelle MySQL-compatible base de données en utilisant AWS DMS, depuis n'importe quel moteur de données source AWS DMS compatible. Si vous migrez vers une base de MySQL-compatible données locale, votre moteur source AWS DMS doit résider dans l' AWS écosystème. Le moteur peut se trouver sur un service AWS géré tel qu'Amazon RDS, Amazon Aurora ou Amazon S3. Sinon, le moteur peut se trouver sur une base de données autogérée sur Amazon EC2.
Vous pouvez utiliser le protocole SSL pour chiffrer les connexions entre votre MySQL-compatible terminal et l'instance de réplication. Pour plus d'informations sur l'utilisation du protocole SSL avec un MySQL-compatible terminal, consultezUtiliser le protocole SSL avec AWS Database Migration Service.
Pour plus d'informations sur les versions de MySQL AWS DMS prises en charge en tant que cible, consultezObjectifs pour AWS DMS.
Vous pouvez utiliser les MySQL-compatible bases de données suivantes comme cibles pour AWS DMS :
-
MySQL Community Edition
-
MySQL Standard Edition
-
MySQL Enterprise Edition
-
MySQL Cluster Carrier Grade Edition
-
MariaDB Community Edition
-
MariaDB Enterprise Edition
-
MariaDB Column Store
-
Amazon Aurora MySQL
Note
Quel que soit le moteur de stockage source (MyISAM, MEMORY, etc.), AWS DMS crée une table MySQL-compatible cible en tant que table InnoDB par défaut.
Si vous avez besoin d'une table dans un moteur de stockage autre qu'InnoDB, vous pouvez créer manuellement la table sur la MySQL-compatible cible et la migrer à l'aide de l'option Ne rien faire. Pour de plus amples informations, veuillez consulter Full-load paramètres des tâches.
Pour plus de détails sur l'utilisation d'une MySQL-compatible base de données comme cible AWS DMS, consultez les sections suivantes.
Rubriques
Utiliser n'importe quelle MySQL-compatible base de données comme cible pour AWS Database Migration Service
Avant de commencer à travailler avec une MySQL-compatible base de données comme cible AWS DMS, assurez-vous de remplir les conditions préalables suivantes :
-
Fournissez un compte utilisateur doté de read/write privilèges AWS DMS d'accès à la MySQL-compatible base de données. Pour créer les privilèges nécessaires, exécutez les commandes suivantes.
CREATE USER '<user acct>'@'%' IDENTIFIED BY '<user password>'; GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT, CREATE TEMPORARY TABLES ON <schema>.* TO '<user acct>'@'%'; GRANT ALL PRIVILEGES ON awsdms_control.* TO '<user acct>'@'%'; -
Pendant la phase de migration de chargement complet, vous devez désactiver les clés étrangères sur vos tables cibles. Pour désactiver la vérification des clés étrangères sur une MySQL-compatible base de données lors d'un chargement complet, vous pouvez ajouter la commande suivante à la section Attributs de connexion supplémentaires de la AWS DMS console de votre terminal cible.
Initstmt=SET FOREIGN_KEY_CHECKS=0; -
Définissez le paramètre de base de données
local_infile = 1pour permettre à AWS DMS de charger les données dans la base de données cible. -
Accordez les privilèges suivants si vous utilisez les évaluations MySQL-specific de prémigration.
grant select on mysql.user to <dms_user>; grant select on mysql.db to <dms_user>; grant select on mysql.tables_priv to <dms_user>; grant select on mysql.role_edges to <dms_user> #only for MySQL version 8.0.11 and higher
Considérations relatives aux cibles Aurora MySQL 8.4
Aurora MySQL 8.4 introduit des modifications de sécurité susceptibles d'affecter la connectivité des terminaux AWS DMS cibles. Consultez les points suivants avant de mettre à niveau votre cible Aurora MySQL vers la version 8.4.
Application du protocole TLS
Aurora MySQL 8.4 est défini require_secure_transport sur ON par défaut, ce qui signifie que toutes les connexions doivent utiliser le protocole TLS. Si votre terminal AWS DMS cible se connecte à Aurora MySQL 8.4 et que le mode SSL est défini sur aucun, les connexions seront rejetées. Si le mode SSL de votre terminal est réglé sur aucun, vous recevrez l'erreur suivante :MySQL Error 3159 (HY000): Connections using insecure transport are
prohibited while --require_secure_transport=ON. Définissez le mode SSL du point de terminaison sur verify-ca ou verify-full. Les deux modes nécessitent un certificat CA. Vous pouvez également require_secure_transport définir cette valeur OFF dans le groupe de paramètres de votre cluster Aurora pour autoriser les connexions non chiffrées.
Note
Aurora MySQL 8.4 prend uniquement en charge les suites de chiffrement GCM pour TLS 1.2. Tous les CBC-mode chiffrements ont été supprimés. AWS DMS utilise TLS 1.2 pour les points de terminaison MySQL et Aurora MySQL et négocie automatiquement un chiffrement GCM pris en charge. Si vous avez des configurations de chiffrement personnalisées, vérifiez qu'elles incluent l'un des chiffrements pris en charge suivants : ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES128-GCM-SHA256 ou. ECDHE-ECDSA-AES256-GCM-SHA384
Note
AWS DMS ne prend pas en charge le protocole TLS 1.3 pour les terminaux MySQL. Cela n'affecte pas la connectivité à Aurora MySQL 8.4, car Aurora MySQL 8.4 continue de prendre en charge le protocole TLS 1.2.
Authentification (Aurora MySQL et RDS pour MySQL 8.4)
Aurora MySQL 8.4 remplace le default_authentication_plugin paramètre parauthentication_policy, dont la valeur par défaut est. *:caching_sha2_password Les utilisateurs de base de données existants conservent leur plug-in d'authentification actuel après la mise à niveau. Si vous créez de nouveaux utilisateurs de AWS DMS
terminaux après la mise à niveau, ils les utiliseront caching_sha2_password par défaut, sauf si vous le définissez authentication_policy *:mysql_native_password dans le groupe de paramètres de votre cluster.
Réinitialisation du mot de passe utilisateur principal
Après la mise à niveau vers Aurora MySQL 8.4, la réinitialisation du mot de passe de l'utilisateur principal via la Console de gestion AWS CLI ou par rotation de Secrets Manager définit le plug-in d'authentification de l'utilisateur principal sur la valeur par défaut définie par le authentication_policy paramètre. S'il authentication_policy est défini sur sa valeur par défaut (*:caching_sha2_password), le plug-in d'authentification de l'utilisateur principal passe de mysql_native_password à caching_sha2_password lors de la prochaine réinitialisation du mot de passe.
Si votre terminal AWS DMS cible utilise le compte utilisateur principal, vérifiez la connectivité après toute réinitialisation du mot de passe. Pour éviter de modifier le plug-in d'authentification, vous pouvez soit :
Définissez sur
authentication_policy*:mysql_native_passworddans le groupe de paramètres de votre cluster avant de réinitialiser le mot de passe, ouCréez un utilisateur de AWS DMS terminal dédié avec un plug-in d'authentification explicitement spécifié (recommandé). Par exemple :
CREATE USER 'dms_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
Pour plus d'informations sur les modifications de sécurité d'Aurora MySQL 8.4, consultez les rubriques Sécurité avec Amazon Aurora MySQL et Gestion des mots de passe avec Amazon Aurora et Secrets Manager dans le guide de l'utilisateur Amazon Aurora. Pour plus d'informations sur les problèmes connus liés au plug-in d'authentification, consultez la section Plug-in d'authentification dans le guide de l'utilisateur Amazon RDS.
Limitations relatives à l'utilisation d'une MySQL-compatible base de données comme cible pour AWS Database Migration Service
Lorsque vous utilisez une base de données MySQL comme cible, AWS DMS ne prend pas en charge les éléments suivants :
-
Les instructions en langage de définition de données (DDL) TRUNCATE PARTITION, DROP TABLE et RENAME TABLE.
-
Utilisation d'une instruction
ALTER TABLEpour ajouter des colonnes au début ou au milieu d'une table.table_nameADD COLUMNcolumn_name -
Lors du chargement de données vers une MySQL-compatible cible dans le cadre d'une tâche de chargement complet, AWS DMS ne signale pas les erreurs causées par des contraintes dans les journaux des tâches, ce qui peut entraîner des erreurs de clé dupliquées ou des incohérences avec le nombre d'enregistrements. Cela est dû à la façon dont MySQL gère les données locales avec la commande
LOAD DATA. Veillez à effectuer les opérations suivantes pendant la phase de chargement complet :Désactivez les contraintes.
Utilisez AWS DMS la validation pour vous assurer que les données sont cohérentes.
-
Lorsque vous mettez à jour la valeur d'une colonne vers sa valeur existante, les MySQL-compatible bases de données renvoient un
0 rows affectedavertissement. Bien que ce comportement ne soit pas techniquement une erreur, il est différent de la façon dont la situation est gérée par d'autres moteurs de base de données. Par exemple, Oracle effectue une mise à jour d'une seule ligne. Pour les MySQL-compatible bases de données, AWS DMS génère une entrée dans la table de contrôle awsdms_apply_exceptions et enregistre l'avertissement suivant.Some changes from the source database had no impact when applied to the target database. See awsdms_apply_exceptions table for details. Aurora sans serveur est disponible en tant que cible pour Amazon Aurora version 2, compatible avec MySQL version 5.7. (Sélectionnez Aurora MySQL version 2.07.1 pour pouvoir utiliser Aurora sans serveur avec la compatibilité MySQL 5.7.) Pour plus d'informations sur Aurora Serverless, consultez la section Utilisation d'Aurora Serverless v2 dans le Guide de l'utilisateur Amazon Aurora.
AWS DMS ne prend pas en charge l'utilisation d'un point de terminaison de lecture pour Aurora ou Amazon RDS, sauf si les instances sont en mode écriture, c'est-à-dire que les
innodb_read_onlyparamètresread_onlyet sont définis sur0ouOFF. Pour plus d’informations sur l’utilisation d’Amazon RDS et Aurora en tant que cibles, consultez les rubriques suivantes :-
Lors de la réplication du type de données TIME, la partie fractionnaire de la valeur du temps n'est pas répliquée.
-
Lors de la réplication du type de données TIME avec un attribut de connexion supplémentaire
loadUsingCSV=false, la valeur temporelle est limitée à une plage.[00:00:00, 23:59:59]
Paramètres des terminaux lors de l'utilisation d'une MySQL-compatible base de données comme cible pour AWS DMS
Vous pouvez utiliser les paramètres des terminaux pour configurer votre base de données MySQL-compatible cible de la même manière que vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison cible à l'aide de la AWS DMS console ou en utilisant la create-endpoint commande du AWS CLI, avec la syntaxe --my-sql-settings '{" JSON.EndpointSetting":
"value", ...}'
Les paramètres de point de terminaison que vous pouvez utiliser avec MySQL en tant que cible sont indiqués dans le tableau suivant.
| Nom | Description |
|---|---|
|
|
Utilisez cet attribut de connexion supplémentaire (ECA) pour définir le délai de connexion du point de terminaison pour l'instance MySQL, en secondes. La valeur par défaut est de 10 secondes. Exemple ECA : |
|
|
Spécifie l'endroit où migrer des tables sources sur la cible, vers une seule base de données ou plusieurs bases de données. Si vous le spécifiez Valeur par défaut : Valeurs valides : { Exemple : |
|
Améliore les performances lors du chargement de données dans la base de données MySQL-compatible cible. Spécifie le nombre de threads à utiliser pour charger les données dans la base de données MySQL-compatible cible. La définition d'un grand nombre de threads peut avoir un impact négatif sur les performances de base de données, dans la mesure où une connexion distincte est requise pour chaque thread. Valeur par défaut : 1 Valeurs valides : 1 à 5 Exemple : |
|
Spécifie un script à exécuter immédiatement après la connexion de AWS DMS au point de terminaison. Par exemple, vous pouvez spécifier que la MySQL-compatible cible doit traduire les instructions reçues dans le jeu de caractères latin1, qui est le jeu de caractères compilé par défaut de la base de données. Ce paramètre améliore généralement les performances lors d'une conversion à partir de clients UTF8. Exemple : |
|
Spécifie la taille maximale (en Ko) de tout fichier .csv utilisé pour transférer des données vers une MySQL-compatible base de données. Valeur par défaut : 32 768 Ko (32 Mo) Valeurs valides : 1 à 1 048 576
|
Vous pouvez également utiliser des attributs de connexion supplémentaires pour configurer votre base de données MySQL-compatible cible.
Le tableau suivant indique les attributs de connexion supplémentaires que vous pouvez utiliser avec MySQL en tant que cible.
| Nom | Description |
|---|---|
|
Désactive les contrôles de clés étrangères. Exemple : |
|
Spécifie le fuseau horaire de la MySQL-compatible base de données cible. Valeur par défaut : UTC Valeurs valides : noms des fuseaux horaires disponibles dans la base de données MySQL cible. Exemple : |
Vous pouvez également utiliser le paramètre AfterConnectScript de la commande --my-sql-settings pour désactiver les contrôles de clés étrangères et spécifier le fuseau horaire de la base de données.
Types de données cibles pour MySQL
Le tableau suivant indique les types de données cibles de la base de données MySQL qui sont pris en charge lors de l'utilisation AWS DMS et le mappage par défaut à partir AWS DMS des types de données.
Pour plus d'informations sur AWS DMS les types de données, consultezTypes de données pour AWS Database Migration Service.
|
AWS DMS types de données |
Types de données MySQL |
|---|---|
|
BOOLEAN |
BOOLEAN |
|
BYTES |
Si la longueur est comprise entre 1 et 65 535, utilisez VARBINARY (length). Si la longueur est comprise entre 65 536 et 2 147 483 647, utilisez LONGLOB. |
|
DATE |
DATE |
|
TIME |
TIME |
|
TIMESTAMP |
« Si l'échelle est => 0 et =< 6, alors : DATETIME (Scale) Si l'échelle est => 7 et =< 9, alors : VARCHAR (37) » |
|
INT1 |
TINYINT |
|
INT2 |
SMALLINT |
|
INT4 |
INTEGER |
|
INT8 |
BIGINT |
|
NUMERIC |
DECIMAL (p,s) |
|
REAL4 |
FLOAT |
|
REAL8 |
DOUBLE PRECISION |
|
CHAÎNE |
Si la longueur est comprise entre 1 et 21 845, utilisez VARCHAR (length). Si la longueur est comprise entre 21 846 et 2 147 483 647, utilisez LONGTEXT. |
|
UINT1 |
UNSIGNED TINYINT |
|
UINT2 |
UNSIGNED SMALLINT |
|
UINT4 |
UNSIGNED INTEGER |
|
UINT8 |
UNSIGNED BIGINT |
|
WSTRING |
Si la longueur est comprise entre 1 et 32 767, utilisez VARCHAR (length). Si la longueur est comprise entre 32 768 et 2 147 483 647, utilisez LONGTEXT. |
|
BLOB |
Si la longueur est comprise entre 1 et 65 535, utilisez BLOB. Si la longueur est comprise entre 65 536 et 2 147 483 647, utilisez LONGBLOB. Si la longueur est 0, utilisez LONGBLOB (full LOB support). |
|
NCLOB |
Si la longueur est comprise entre 1 et 65 535, utilisez TEXT. Si la longueur est comprise entre 65 536 et 2 147 483 647, utilisez LONGTEXT avec ucs2 pour CHARACTER SET. Si la longueur est 0, utilisez LONGTEXT (full LOB support) avec ucs2 pour CHARACTER SET. |
|
CLOB |
Si la longueur est comprise entre 1 et 65 535, utilisez TEXT. Si la longueur est comprise entre 65 536 et 2 147 483 647, utilisez LONGTEXT. Si la longueur est 0, utilisez LONGTEXT (full LOB support). |