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

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

Pour en savoir plus sur les versions de MySQL qui sont prises en charge par AWS DMS en tant que source, consultez Sources pour AWS DMS.

Vous pouvez utiliser SSL pour chiffrer les connexions entre votre point de terminaison compatible MySQL et l'instance de réplication. Pour plus d'informations sur l'utilisation de SSL avec un point de terminaison compatible MySQL, consultez Utilisation 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 de bases de données compatibles avec MySQL AWS DMS, consultez les sections suivantes.

Migration de MySQL vers MySQL à l'aide d' 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 base de données compatible avec MySQL 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, full-load-only les tâches ne nécessitent pas ce privilège.

• REPLICATION SLAVE : ce privilège est obligatoire pour les tâches de CDC uniquement. En d'autres termes, full-load-only les tâches ne nécessitent 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.

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

Vous pouvez utiliser les bases de données compatibles MySQL 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	Valeur
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	Définissez ce paramètre à une valeur 1 ou supérieure. Pour éviter l'utilisation excessive d'espace disque, nous recommandons de ne pas utiliser la valeur par défaut de 0.
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 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	Valeur
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.

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

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

• MySQL Community Edition

• MariaDB Community Edition

• Amazon Aurora MySQL-Compatible Edition

Lorsque vous utilisez une base de données compatible avec MySQL AWS gérée comme source pour AWS DMS, assurez-vous de remplir les conditions préalables suivantes 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 bases de données compatibles avec MySQL 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.

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 instruction ALTER TABLE table_name ADD COLUMN column_name pour ajouter des colonnes au début (FIRST) ou au milieu d'une table (AFTER) n'est pas prise en charge. Les colonnes sont toujours ajoutées à la fin de la table.

• 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 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, la 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 source compatible MySQL est arrêtée lors du chargement complet, la tâche AWS DMS 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 une instance en lecture/écriture et non une instance de réplica.

• 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. Pour plus d'informations, consultez Prise en charge des transactions XA, ci-après.

• 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 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 plus d’informations, consultez 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 :

  • Pré-créez la table cible dans la base de données cible et créez la tâche AWS DMS avec le paramètre de tâche de chargement complet DO_NOTHING ou TRUNCATE_BEFORE_LOAD.

  • 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.

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 la 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 la version 10.6 de MariaDB Source DB.

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.

Name (Nom)	Description
EventsPollInterval	Spécifie la fréquence de vérification du journal binaire de nouvelles modifications/événements lorsque la base de données est inactif. 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"}'
CleanSrcMetadataOnMismatch	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 '{"CleanSrcMetadataOnMismatch": 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 partitioned-table-related DDL et continue de traiter d'autres modifications 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 de valeurs FLOAT prise en charge est -1.79E+308 à -2.23E-308, 0 et 2.23E-308 à 1.79E+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	WSTRING (longueur) Ici, longueur correspond à la longueur de la valeur la plus longue dans ENUM.
SET	WSTRING (longueur) Ici, longueur correspond à la longueur totale de toutes les valeurs de SET, virgules incluses.
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.