Migrations MySQL vers MySQL Utilisation de MySQL comme source Utilisation de MySQL autogéré comme source Utilisation AWS de MySQL -managed 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

Utiliser 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 service de migration AWS de base de données.

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 terminal et l'instance de réplication. Pour plus d'informations sur l'utilisation du protocole SSL avec un MySQL-compatible point de terminaison, consultezUtiliser le 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 et AWS DMS, consultez les sections suivantes.

Rubriques

Migrer de MySQL vers MySQL à l'aide de 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 comme source pour AWS DMS
Considérations relatives aux sources d'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 des terminaux 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 bases de données ou de schémas. 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 du 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.

Migrer de MySQL vers MySQL à l'aide de AWS DMS

Pour une migration hétérogène, où 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 comme source pour AWS DMS, assurez-vous que vous disposez des prérequis suivants. Ces conditions préalables 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 MySQL-specific évaluations avant la 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 la section Variables et options de serveur et d'état 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. Consultez la section Options et variables de journalisation binaires.
`binlog_checksum`	Définissez ce paramètre `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 un réplica en lecture MySQL ou MariaDB comme source pour une tâche de migration DMS à l'aide du mode Migrer les données existantes et répliquer les modifications en cours, il existe un risque de perte de données. DMS n'écrira aucune transaction pendant le chargement complet ou le CDC dans les conditions suivantes :

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

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 comme 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 vous disposez des prérequis suivants 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. Étant donné que 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). Si vous forcez votre base de données à redémarrer toutes les sessions après avoir modifié le binlog_format paramètre pour, vous vous ROW assurerez que votre base de données écrit toutes les modifications ultérieures de la base de données source dans le format approprié, afin de AWS DMS pouvoir capturer correctement ces modifications.
Définissez le paramètre binlog_row_image sur "Full".
Définissez le binlog_checksum paramètre sur "NONE" DMS version 3.4.7 ou antérieure. 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 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.

Considérations relatives aux sources d'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 aucun, les connexions seront rejetées. Si le mode SSL de votre terminal est réglé 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 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 point de terminaison AWS DMS source 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_password dans le groupe de paramètres de votre cluster avant de réinitialiser le mot de passe, ou
Cré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';

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 de la table cible sur Supprimer les tables sur la cible, AWS DMS cela crée 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 le 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 prend en charge 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, 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 (SupportLobs« » est faux 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 fait migrer 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 une read/write instance et non une instance de réplication.
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 ne prend en charge que les transactions XA dans les versions 3.5.0 et supérieures. Les versions précédentes ne prenaient 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 ce qui suit. 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 de journaux binaires.
AWS DMS ne propage pas les événements ON DELETE CASCADE et ON UPDATE CASCADE pour les bases de données MySQL à l'aide du 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 reproduire 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, puis créez la AWS DMS tâche avec le paramètre DO_NOTHING ou TRUNCATE_BEFORE_LOAD charge complète de la tâche.
- 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 de la limitation interne de MySQL, il est AWS DMS possible de traiter des BinLogs d'une taille maximale de 4 Go. Les BinLogs supérieurs à 4 Go peuvent entraîner l'échec des tâches DMS ou d'autres comportements imprévisibles. Vous devez réduire la taille des transactions pour éviter les BinLogs supérieurs à 4 Go.
AWS DMS ne prend pas en charge les guillemets ` inverses () ou les guillemets simples (') dans les noms de schéma, de table et de colonne.
AWS DMS ne migre pas les données provenant de colonnes invisibles de votre base de données source. Pour inclure ces colonnes dans votre périmètre de 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éfautTRUE. 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 de l'autorisation suivante :
```
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 des terminaux 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 en utilisant la create-endpoint commande du 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 il convient de vérifier si le journal binaire est nouveau changes/events 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 apportées aux 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 la déclaration 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, ce réglage permet d'`true`ignorer la suspension de la 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, spécifie 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 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 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,23, 0 et 2,23 E-308 à 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 valeur la plus longue de l'ENUM.
SET	CHAÎNE () `length` `length`Voici la longueur totale de toutes les valeurs du SET, virgules comprises.
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