Migrations MySQL vers MySQL Utilisation de MySQL comme source Utilisation de MySQL autogéré comme source Utiliser AWS-managed MySQL comme source Sources d'Aurora MySQL 8.4 Limitations sur MySQL comme source Prise en charge des transactions XA Paramètres de point de terminaison Types de données sources pour MySQL

Utilisation d'une MySQL-compatible base de données comme source pour AWS DMS

Vous pouvez migrer des données depuis n'importe quelle MySQL-compatible base de données (MySQL, MariaDB ou Amazon Aurora MySQL) à l'aide du Database Migration AWS Service.

Pour plus d'informations sur les versions de MySQL AWS DMS prises en charge en tant que source, consultezSources pour AWS DMS.

Vous pouvez utiliser le protocole SSL pour chiffrer les connexions entre votre MySQL-compatible point de terminaison et l'instance de réplication. Pour plus d'informations sur l'utilisation du protocole SSL avec un MySQL-compatible point de terminaison, consultezUtilisation du protocole SSL avec AWS Database Migration Service.

Dans les sections suivantes, le terme « autogéré » s’applique à toute base de données installée sur site ou sur Amazon EC2. Le terme « géré par AWS » s’applique à toute base de données sur Amazon RDS, Amazon Aurora ou Amazon S3.

Pour plus de détails sur l'utilisation des MySQL-compatible bases de données AWS DMS, consultez les sections suivantes.

Rubriques

Migration de MySQL vers MySQL en utilisant AWS DMS
Utiliser n'importe quelle MySQL-compatible base de données comme source pour AWS DMS
Utilisation d'une MySQL-compatible base de données autogérée comme source pour AWS DMS
À l'aide d'un AWS MySQL-compatible -base de données gérée en tant que source pour AWS DMS
Considérations relatives aux sources Aurora MySQL 8.4
Limitations relatives à l'utilisation d'une base de données MySQL comme source pour AWS DMS
Prise en charge des transactions XA
Paramètres du point de terminaison lors de l'utilisation de MySQL comme source pour AWS DMS
Types de données sources pour MySQL

Note

Lors de la configuration des règles de mappage AWS Database Migration Service (AWS DMS), il est important d'éviter d'utiliser des caractères génériques (%) pour les noms de base de données ou de schéma. Au lieu de cela, vous devez spécifier explicitement uniquement les bases de données créées par l'utilisateur qui doivent être migrées. L'utilisation d'un caractère générique inclut toutes les bases de données dans le processus de migration, y compris les bases de données système qui ne sont pas requises sur l'instance cible. Étant donné que l'utilisateur principal MySQL Amazon RDS ne dispose pas des autorisations nécessaires pour importer des données dans les bases de données du système cible, la tentative de migration de ces bases de données système échoue.

Migration de MySQL vers MySQL en utilisant AWS DMS

Pour une migration hétérogène, lorsque vous migrez d'un moteur de base de données autre que MySQL vers une base de données MySQL, AWS DMS c'est presque toujours le meilleur outil de migration à utiliser. Mais pour une migration homogène, lorsque vous migrez d’une base de données MySQL vers une base de données MySQL, nous vous recommandons d’utiliser un projet de migrations de données homogènes. Les migrations de données homogènes utilisent des outils de base de données natifs pour fournir des performances et une précision de migration de données améliorées par rapport à AWS DMS.

Utiliser n'importe quelle MySQL-compatible base de données comme source pour AWS DMS

Avant de commencer à utiliser une base de données MySQL en tant que source pour AWS DMS, assurez-vous que vous remplissez les conditions préalables suivantes. Ces prérequis s'appliquent aux sources autogérées ou AWS gérées.

Vous devez disposer d'un compte AWS DMS doté du rôle d'administrateur de réplication. Ce rôle nécessite les privilèges suivants :

REPLICATION CLIENT : ce privilège est obligatoire pour les tâches de CDC uniquement. En d’autres termes, les tâches de chargement complet uniquement ne requièrent pas ce privilège.

Note
Pour la version 10.5.2+ de MariaDB, vous pouvez utiliser BINLOG MONITOR, qui remplace REPLICATION CLIENT.
REPLICATION SLAVE : ce privilège est obligatoire pour les tâches de CDC uniquement. En d’autres termes, les tâches de chargement complet uniquement ne requièrent pas ce privilège.
SUPER : ce privilège est nécessaire uniquement dans les versions de MySQL antérieures à 5.6.6.

L' AWS DMS utilisateur doit également disposer des privilèges SELECT pour les tables sources destinées à la réplication.

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
grant select on performance_schema.replication_connection_status to <dms_user>;  #Required for primary instance validation - MySQL version 5.7 and higher only

Si vous utilisez une source RDS et que vous prévoyez d'effectuer des évaluations MySQL-specific de prémigration, ajoutez l'autorisation suivante :


grant select on mysql.rds_configuration to <dms_user>;  #Required for binary log retention check

Si le paramètre BatchEnable est définitrue, il est nécessaire d'accorder :


grant create temporary tables on `<schema>`.* to <dms_user>;

Utilisation d'une MySQL-compatible base de données autogérée comme source pour AWS DMS

Vous pouvez utiliser les MySQL-compatible bases de données autogérées suivantes comme sources 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

Pour utiliser la CDC, assurez-vous d’activer la journalisation binaire. Pour activer la journalisation binaire, les paramètres suivants doivent être configurés dans le fichier my.ini (Windows) ou my.cnf (UNIX) de MySQL.

Paramètre	Value
`server_id`	Définissez ce paramètre à une valeur 1 ou supérieure.
`log-bin`	Définissez le chemin d'accès au fichier journal binaire, par exemple `log-bin=E:\MySql_Logs\BinLog`. N'ajoutez pas d'extension de fichier.
`binlog_format`	Définissez ce paramètre à `ROW`. Nous recommandons d’utiliser ce paramètre lors de la réplication car, dans certains cas, lorsque `binlog_format` est défini sur `STATEMENT`, cela peut entraîner des incohérences lors de la réplication des données sur la cible. Le moteur de base de données écrit également des données incohérentes similaires sur la cible lorsque `binlog_format` est défini sur `MIXED`, car le moteur de base de données bascule automatiquement vers la journalisation basée sur `STATEMENT`, ce qui peut entraîner l’écriture de données incohérentes dans la base de données cible.
`expire_logs_days` or `binlog_expire_logs_seconds`	Le paramètre expire_logs_days est obsolète depuis MySQL 8.0 et supprimé dans MySQL 8.4. Pour plus d'informations, consultez Variables de serveur et d'état et options ajoutées, obsolètes ou supprimées dans MySQL 8.4 depuis la version 8.0. Utilisez le `expire_logs_days` paramètre pour MySQL 5.x. Nous vous recommandons de définir ce paramètre sur une valeur `1` ou une valeur supérieure, voir Options et variables de journalisation binaires. Utilisez le `binlog_expire_logs_seconds` paramètre pour MySQL 8.0 et versions ultérieures. Nous vous recommandons de définir ce paramètre sur une valeur de `86400` secondes (1 jour) ou plus. Voir Options et variables de journalisation binaire.
`binlog_checksum`	Définissez ce paramètre sur `NONE` pour la version 3.4.7 ou antérieure de DMS.
`binlog_row_image`	Définissez ce paramètre à `FULL`.
`log_slave_updates`	Définissez ce paramètre sur `TRUE` si vous utilisez un réplica en lecture MySQL ou MariaDB comme source.

Si vous utilisez une réplique en lecture MySQL ou MariaDB comme source pour une tâche de migration DMS en utilisant le mode Migrer les données existantes et répliquer les modifications en cours, il existe un risque de perte de données. DMS n'écrit pas de transaction pendant le chargement complet ou pendant le CDC dans les conditions suivantes :

La transaction avait été validée sur l'instance principale avant le début de la tâche DMS.
La transaction n'a été validée dans la réplique qu'après le démarrage de la tâche DMS, en raison du décalage entre l'instance principale et la réplique.

Plus le délai entre l'instance principale et la réplique est long, plus le risque de perte de données est élevé.

Si votre source utilise le moteur de base de données NDB (en cluster), les paramètres suivants doivent être configurés pour permettre la capture des données modifiées sur les tables qui utilisent ce moteur de stockage. Ajoutez ces modifications dans le fichier my.ini (Windows) ou my.cnf (UNIX) de MySQL.

Paramètre	Value
`ndb_log_bin`	Définissez ce paramètre à `ON`. Cette valeur garantit que les modifications dans les tables en cluster sont journalisées dans le journal binaire.
`ndb_log_update_as_write`	Définissez ce paramètre à `OFF`. Cette valeur empêche d'écrire des instructions UPDATE en tant qu'instructions INSERT dans le journal binaire.
`ndb_log_updated_only`	Définissez ce paramètre à `OFF`. Cette valeur permet de s'assurer que le journal binaire contient l'ensemble de la ligne, pas seulement les colonnes modifiées.

À l'aide d'un AWS MySQL-compatible -base de données gérée en tant que source pour AWS DMS

Vous pouvez utiliser les MySQL-compatible bases de données AWS gérées suivantes comme sources pour AWS DMS :

MySQL Community Edition
MariaDB Community Edition
MySQL-Compatible Édition Amazon Aurora

Lorsque vous utilisez une MySQL-compatible base de données AWS gérée comme source pour AWS DMS, assurez-vous que les conditions préalables suivantes sont remplies pour le CDC :

Pour activer les journaux binaires pour RDS for MySQL et pour RDS for MariaDB, activez les sauvegardes automatiques au niveau de l’instance. Pour activer les journaux binaires pour un cluster Aurora MySQL, modifiez la variable binlog_format dans le groupe de paramètres.

Pour plus d’informations sur la configuration des sauvegardes automatiques, consultez Utilisation des sauvegardes dans le Guide de l’utilisateur Amazon RDS.

Pour plus d’informations sur la configuration de la journalisation binaire pour une base de données Amazon RDS for MySQL, consultez Configuration de la journalisation binaire MySQL dans le Guide de l’utilisateur Amazon RDS.

Pour plus d’informations sur la configuration de la journalisation binaire pour un cluster Aurora MySQL, consultez Comment puis-je activer la journalisation binaire pour mon cluster Amazon Aurora MySQL ?
Si vous envisagez d’utiliser la CDC, activez la journalisation binaire. Pour plus d’informations sur la configuration de la journalisation binaire pour une base de données Amazon RDS for MySQL, consultez Configuration de la journalisation binaire MySQL dans le Guide de l’utilisateur Amazon RDS.
Assurez-vous que les journaux binaires sont disponibles pour AWS DMS. Dans la mesure où les MySQL-compatible bases de données AWS gérées purgent les journaux binaires dès que possible, vous devez augmenter la durée pendant laquelle les journaux restent disponibles. Par exemple, pour accroître la rétention des journaux à 24 heures, exécutez la commande suivante.
```
 call mysql.rds_set_configuration('binlog retention hours', 24);
                    
```
Définissez le paramètre binlog_format sur "ROW".

Note
Sur MySQL ou MariaDB, binlog_format est un paramètre dynamique. Vous n’avez donc pas besoin de redémarrer pour que la nouvelle valeur prenne effet. Toutefois, la nouvelle valeur ne s’appliquera qu’aux nouvelles sessions. Si vous redéfinissez binlog_format sur ROW à des fins de réplication, la base de données peut toujours créer des journaux binaires ultérieurs en utilisant le format MIXED, si ces sessions ont débuté avant que vous n’ayez modifié la valeur. Cela peut AWS DMS empêcher de capturer correctement toutes les modifications apportées à la base de données source. Lorsque vous modifiez le paramètre binlog_format sur une base de données MariaDB ou MySQL, veillez à redémarrer la base de données pour fermer toutes les sessions existantes, ou à redémarrer toute application effectuant des opérations DML (Data Manipulation Language). Le fait de forcer votre base de données à redémarrer toutes les sessions après avoir modifié le binlog_format paramètre pour ROW garantir que votre base de données écrit toutes les modifications ultérieures de la base de données source dans le bon format, afin de AWS DMS pouvoir correctement capturer ces modifications.
Définissez le paramètre binlog_row_image sur "Full".
Définissez le binlog_checksum paramètre sur "NONE" pour la version 3.4.7 ou antérieure de DMS. Pour plus d’informations sur la définition des paramètres dans Amazon RDS MySQL, consultez Utilisation des sauvegardes dans le Guide de l’utilisateur Amazon RDS.
Si vous utilisez un réplica en lecture Amazon RDS MySQL ou Amazon RDS MariaDB en tant que source, activez les sauvegardes sur le réplica en lecture et assurez-vous de définir le paramètre log_slave_updates sur TRUE.

Pour plus d'informations sur les modifications apportées à la sécurité d'Aurora MySQL 8.4, consultez les sections 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.

Considérations relatives aux sources Aurora MySQL 8.4

Aurora MySQL 8.4 introduit des modifications de sécurité susceptibles d'affecter la connectivité du point de terminaison AWS DMS source. Consultez les points suivants avant de mettre à niveau votre source 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 point de terminaison AWS DMS source se connecte à Aurora MySQL 8.4 et que le mode SSL est défini sur none, les connexions seront rejetées. Si le mode SSL de votre point de terminaison est défini sur aucun, vous recevrez le message d'erreur suivant :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 le require_secure_transport définir OFF dans le groupe de paramètres de votre cluster Aurora pour autoriser les connexions non chiffrées.

Note

Aurora MySQL 8.4 ne prend en charge que les suites de chiffrement GCM pour TLS 1.2. Tous les CBC-mode chiffrements ont été supprimés. AWS DMS utilise le protocole 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 points de terminaison 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 authentication_policy les définissez *:mysql_native_password dans votre groupe de paramètres de 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 AWS Management Console CLI ou via la rotation de Secrets Manager définit le plugin 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 plugin 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 point de terminaison AWS DMS source utilise le compte utilisateur principal, vérifiez la connectivité après chaque réinitialisation du mot de passe. Pour éviter de modifier le plugin d'authentification, vous pouvez soit :

Définissez sur authentication_policy *:mysql_native_password dans le groupe de paramètres de votre cluster avant de réinitialiser le mot de passe, ou
Créez un utilisateur de point de AWS DMS terminaison dédié avec un plugin d'authentification explicitement spécifié (recommandé). Par exemple : CREATE USER 'dms_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

Limitations relatives à l'utilisation d'une base de données MySQL comme source pour AWS DMS

Lorsque vous utilisez une base de données MySQL comme source, tenez compte des éléments suivants :

La capture des données de modification (CDC) n’est pas prise en charge pour Amazon RDS MySQL 5.5 ou antérieur. Pour Amazon RDS MySQL, vous devez utiliser la version 5.6, 5.7 ou 8.0 pour activer la CDC. La CDC est prise en charge pour les sources MySQL 5.5 autogérées.
Pour la CDC, CREATE TABLE, ADD COLUMN, DROP COLUMN, la modification du type de données de colonne et renaming a column sont pris en charge. Toutefois, DROP TABLE, RENAME TABLE et les mises à jour apportées à d’autres attributs, tels que la valeur par défaut de la colonne, la possibilité de valeur NULL de la colonne, le jeu de caractères, etc., ne sont pas pris en charge.
Pour les tables partitionnées sur la source, lorsque vous définissez le mode de préparation des tables cibles sur Supprimer les tables sur la cible, vous AWS DMS créez une table simple sans aucune partition sur la cible MySQL. Pour migrer des tables partitionnées vers une table partitionnée sur la cible, créez à l’avance les tables partitionnées sur la base de données MySQL cible.
L'utilisation d'une ALTER TABLE table_name ADD COLUMN column_name instruction pour ajouter des colonnes au début (FIRST) ou au milieu d'un tableau (AFTER) n'est pas prise en charge pour les cibles relationnelles. Les colonnes sont toujours ajoutées à la fin de la table. Lorsque la cible est Amazon S3 ou Amazon Kinesis Data Streams, l'ajout de colonnes à l'aide de FIRST ou AFTER est pris en charge.
La capture des données modifiées (CDC) n'est pas prise en charge quand un nom de table contient des caractères minuscules et majuscules, et le moteur source est hébergé sur un système d'exploitation avec des noms de fichier sensibles à la casse. Un exemple est Microsoft Windows ou OS X utilisant HFS+.
Vous pouvez utiliser Aurora MySQL-Compatible Edition Serverless v1 pour le chargement complet, mais vous ne pouvez pas l'utiliser pour CDC. En effet, vous ne pouvez pas activer les prérequis pour MySQL. Pour plus d’informations , consultez Groupes de paramètres et Aurora sans serveur v1.

Aurora MySQL-Compatible Edition Serverless v2 est compatible avec le CDC.
L'attribut AUTO_INCREMENT sur une colonne n'est pas migré vers une colonne de base de données cible.
La capture des modifications n'est pas prise en charge lorsque les journaux binaires ne sont pas stockés sur un stockage en bloc standard. Par exemple, le CDC ne fonctionne pas lorsque les journaux binaires sont stockés sur Amazon S3.
AWS DMS crée des tables cibles avec le moteur de stockage InnoDB par défaut. Si vous avez besoin d'utiliser un moteur de stockage autre qu'InnoDB, vous devez créer manuellement la table et y migrer les données à l'aide du mode « Ne rien faire ».
Vous ne pouvez pas utiliser les répliques Aurora MySQL comme source, AWS DMS sauf si le mode de tâche de migration de votre DMS est Migrer les données existantes, chargement complet uniquement.
Si la MySQL-compatible source est arrêtée pendant le chargement complet, la AWS DMS tâche ne s'arrête pas avec une erreur. La tâche se termine avec succès, mais la cible peut ne pas être synchronisée avec la source. Si cela se produit, redémarrez la tâche ou rechargez les tables affectées.
Les index créés sur une partie d'une valeur de colonne ne sont pas migrés. Par exemple, l'index CREATE INDEX first_ten_chars ON customer (name(10)) n'est pas créé sur la cible.
Dans certains cas, la tâche est configurée pour ne pas répliquer les LOB (la valeur SupportLobs « » est fausse dans les paramètres de la tâche ou l'option Ne pas inclure les colonnes LOB est sélectionnée dans la console des tâches). Dans ces cas, AWS DMS ne migre aucune colonne MEDIUMBLOB, LONGBLOB, MEDIUMTEXT et LONGTEXT vers la cible.

Les colonnes BLOB, TINYBLOB, TEXT et TINYTEXT ne sont pas affectées et sont migrées vers la cible.
Les tables de données temporelles ou les tables gérées par version du système ne sont pas prises en charge dans les bases de données sources et cibles MariaDB.
En cas de migration entre deux clusters Amazon RDS Aurora MySQL, le point de terminaison source RDS Aurora MySQL doit être read/write une instance et non une instance de réplique.
AWS DMS ne prend actuellement pas en charge la migration des vues pour MariaDB.
AWS DMS ne prend pas en charge les modifications DDL pour les tables partitionnées pour MySQL. Pour ignorer la suspension de table en cas de modification de DDL de partition pendant la CDC, définissez skipTableSuspensionForPartitionDdl sur true.
AWS DMS prend uniquement en charge les transactions XA dans les versions 3.5.0 et supérieures. Les versions précédentes ne prennent pas en charge les transactions XA. AWS DMS ne prend pas en charge les transactions XA dans MariaDB version 10.6 ou supérieure. Pour plus d'informations, voir ci-dessous. Prise en charge des transactions XA
AWS DMS n'utilise pas les GTID pour la réplication, même si les données source en contiennent.
AWS DMS ne prend pas en charge le journal binaire amélioré Aurora MySQL.
AWS DMS ne prend pas en charge la compression des transactions du journal binaire.
AWS DMS ne propage pas les événements ON DELETE CASCADE et ON UPDATE CASCADE pour les bases de données MySQL utilisant le moteur de stockage InnoDB. Pour ces événements, MySQL ne génère pas d’événements binlog pour refléter les opérations en cascade sur les tables enfants. Par conséquent, AWS DMS impossible de répliquer les modifications correspondantes dans les tables enfants. Pour de plus amples informations, veuillez consulter Non-migration des index, des clés étrangères ou des mises à jour ou suppressions en cascade.
AWS DMS ne capture pas les modifications apportées aux colonnes calculées (VIRTUALetGENERATED ALWAYS). Pour contourner cette limitation, procédez comme suit :
- Pre-create la table cible dans la base de données cible, et créez la AWS DMS tâche avec le DO_NOTHING paramètre de tâche TRUNCATE_BEFORE_LOAD à chargement complet.
- Ajoutez une règle de transformation pour retirer la colonne calculée de la portée de tâche. Pour en savoir plus sur les règles de transformation, consultez Règles et actions de transformation.
En raison des limites internes de MySQL, les BinLogs ne AWS DMS peuvent pas être traités avec une taille supérieure à 4 Go. Les BinLogs supérieurs à 4 Go peuvent entraîner des échecs de tâches DMS ou d'autres comportements imprévisibles. Vous devez réduire la taille des transactions pour éviter que les BinLogs ne dépassent 4 Go.
AWS DMS ne prend pas en charge les backticks (`) ou les guillemets simples (') dans les noms de schéma, de table et de colonne.
AWS DMS ne migre pas les données des colonnes invisibles de votre base de données source. Pour inclure ces colonnes dans le périmètre de votre migration, utilisez l'instruction ALTER TABLE pour les rendre visibles.

Prise en charge des transactions XA

Une transaction Extended Architecture (XA) est une transaction qui peut être utilisée pour regrouper une série d’opérations provenant de plusieurs ressources transactionnelles en une seule transaction globale fiable. Une transaction XA utilise un protocole de validation en deux phases. En général, la capture des modifications avec des transactions XA ouvertes peut entraîner une perte de données. Si votre base de données n'utilise pas de transactions XA, vous pouvez ignorer cette autorisation et la configuration IgnoreOpenXaTransactionsCheck en utilisant la valeur par défaut. TRUE Pour commencer la réplication à partir d’une source qui contient des transactions XA, procédez comme suit :

Assurez-vous que l'utilisateur du AWS DMS terminal dispose des autorisations suivantes :
```
grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';
```
Définissez le paramètre de point de terminaison IgnoreOpenXaTransactionsCheck sur false.

Note

AWS DMS ne prend pas en charge les transactions XA sur MariaDB Source DB version 10.6 ou supérieure.

Paramètres du point de terminaison lors de l'utilisation de MySQL comme source pour AWS DMS

Vous pouvez utiliser des paramètres de point de terminaison pour configurer la base de données source MySQL comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console ou à l'aide de la create-endpoint commande dans le AWS CLI, avec la syntaxe --my-sql-settings '{"EndpointSetting": "value", ...}' JSON.

Les paramètres de point de terminaison que vous pouvez utiliser avec MySQL en tant que source sont indiqués dans le tableau suivant.

Nom	Description
`ConnectionTimeout`	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 :`ConnectionTimeout=30`.
`EventsPollInterval`	Spécifie la fréquence à laquelle le journal binaire doit être vérifié pour détecter la présence de nouveaux changes/events éléments lorsque la base de données est inactive. Valeur par défaut : 5 Valeurs valides : 1 à 60 Exemple : `--my-sql-settings '{"EventsPollInterval": 5}'` Dans l'exemple, AWS DMS vérifie les modifications dans les journaux binaires toutes les cinq secondes.
`ExecuteTimeout`	Pour AWS DMS les versions 3.4.7 et supérieures, définit le délai d'expiration de l'instruction client pour un point de terminaison source MySQL, en secondes. Valeur par défaut : 60 Exemple : `--my-sql-settings '{"ExecuteTimeout": 1500}'`
`ServerTimezone`	Spécifie le fuseau horaire de la base de données source MySQL. Exemple : `--my-sql-settings '{"ServerTimezone": "US/Pacific"}'`
`AfterConnectScript`	Spécifie un script à exécuter immédiatement après la AWS DMS connexion au point de terminaison. La tâche de migration continue à s'exécuter, que l'instruction SQL réussisse ou échoue. Valeurs valides : une ou plusieurs instructions SQL valides, séparées par un point-virgule. Exemple : `--my-sql-settings '{"AfterConnectScript": "ALTER SESSION SET CURRENT_SCHEMA=system"}'`
`CleanSourceMetadataOnMismatch`	Nettoie et recrée les informations de métadonnées de table sur l'instance de réplication lorsqu'une non-correspondance survient. Par exemple, dans le cas où l'exécution d'une instruction alter DDL sur la table pourrait générer des informations différentes sur la table mise en cache dans l'instance de réplication. Booléen. Valeur par défaut : `false` Exemple : `--my-sql-settings '{"CleanSourceMetadataOnMismatch": false}'`
`skipTableSuspensionForPartitionDdl`	AWS DMS ne prend pas en charge les modifications DDL pour les tables partitionnées pour MySQL. Pour AWS DMS les versions 3.4.6 et supérieures, le paramétrer pour `true` ignorer la suspension de table en cas de modification du DDL de partition pendant le CDC. AWS DMS ignore le DDL lié aux tables partitionnées et continue de traiter les modifications ultérieures du journal binaire. Valeur par défaut : `false` Exemple : `--my-sql-settings '{"skipTableSuspensionForPartitionDdl": true}'`
`IgnoreOpenXaTransactionsCheck`	Pour AWS DMS les versions 3.5.0 et supérieures, indique si les tâches doivent ignorer les transactions XA ouvertes lors du démarrage. Définissez ce paramètre sur `false` si votre source possède des transactions XA. Valeur par défaut : `true` Exemple : `--my-sql-settings '{"IgnoreOpenXaTransactionsCheck": false}'`

Types de données sources pour MySQL

Le tableau suivant indique les types de données source de base de données MySQL pris en charge lors de l'utilisation AWS DMS et le mappage par défaut à partir AWS DMS des types de données.

Pour en savoir plus sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section concernant le point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultezTypes de données pour AWS Database Migration Service.

Types de données MySQL	AWS DMS types de données
INT	INT4
BIGINT	INT8
MEDIUMINT	INT4
TINYINT	INT1
SMALLINT	INT2
UNSIGNED TINYINT	UINT1
UNSIGNED SMALLINT	UINT2
UNSIGNED MEDIUMINT	UINT4
UNSIGNED INT	UINT4
UNSIGNED BIGINT	UINT8
DECIMAL(10)	NUMERIC (10,0)
BINAIRE	BYTES(1)
BIT	BOOLEAN
BIT(64)	BYTES(8)
BLOB	BYTES(65535)
LONGBLOB	BLOB
MEDIUMBLOB	BLOB
TINYBLOB	BYTES(255)
DATE	DATE
DATETIME	DATETIME DATETIME sans valeur entre parenthèses est répliqué sans millisecondes. DATETIME avec une valeur entre parenthèses comprise entre 1 et 5 (par exemple, `DATETIME(5)`) est répliqué en millisecondes. Lors de la réplication d’une colonne DATETIME, l’heure reste la même sur la cible. Elle n’est pas convertie au format UTC.
TIME	CHAÎNE
TIMESTAMP	DATETIME Lors de la réplication d’une colonne TIMESTAMP, l’heure est convertie au format UTC sur la cible.
YEAR	INT2
DOUBLE	REAL8
FLOAT	REAL(DOUBLE) Si les valeurs FLOAT ne sont pas comprises dans la plage suivante, utilisez une transformation pour mapper FLOAT à STRING. Pour plus d'informations sur les transformations, consultez Règles et actions de transformation. La plage FLOAT prise en charge est comprise entre -1,79E+308 et -2,23E-308, 0 et 2,23 à 1,79E+308 E-308
VARCHAR (45)	WSTRING (45)
VARCHAR (2000)	WSTRING (2000)
VARCHAR (4000)	WSTRING (4000)
VARBINARY (4000)	BYTES (4000)
VARBINARY (2000)	BYTES (2000)
CHAR	WSTRING
TEXT	WSTRING
LONGTEXT	NCLOB
MEDIUMTEXT	NCLOB
TINYTEXT	WSTRING(255)
GEOMETRY	BLOB
POINT	BLOB
LINESTRING	BLOB
POLYGON	BLOB
MULTIPOINT	BLOB
MULTILINESTRING	BLOB
MULTIPOLYGON	BLOB
GEOMETRYCOLLECTION	BLOB
ENUM	CHAÎNE () `length` `length`Voici la longueur de la plus longue valeur de l'ENUM.
SET	CHAÎNE () `length` `length`Voici la longueur totale de toutes les valeurs du SET, y compris les virgules.
JSON	CLOB

Note

Dans certains cas, vous pouvez spécifier les types de données DATETIME et TIMESTAMP avec une valeur « zéro » (c’est-à-dire 0000-00-00). Dans ce cas, assurez-vous que la base de données cible de la tâche de réplication prend en charge les valeurs « zéro » pour les types de données DATETIME et TIMESTAMP. Dans le cas contraire, ces valeurs sont enregistrées en tant que valeurs NULL dans la cible.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Utilisation de PostgreSQL comme source

Utilisation de SAP ASE comme source