Mes SQL migrations SQL vers Mes Utiliser My SQL comme source Utiliser My autogéré SQL comme source Utilisation AWS de -managed My SQL comme source Limites relatives à My SQL as a source Prise en charge des transactions XA Paramètres de point de terminaison Types de données source pour My SQL

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

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

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

Vous pouvez l'utiliser SSL pour chiffrer les connexions entre votre point de terminaison SQL compatible My et l'instance de réplication. Pour plus d'informations sur l'utilisation SSL avec un point de terminaison SQL compatible My, 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 « AWS -managed » s'applique à toute base de données sur AmazonRDS, Amazon Aurora ou Amazon S3.

Pour plus de détails sur l'utilisation des bases de données SQL compatibles My AWS DMS, consultez les sections suivantes.

Rubriques

Migrer de Mon SQL vers Mon en utilisant SQL AWS DMS
Utiliser n'importe quelle base de données SQL compatible My comme source pour AWS DMS
Utilisation d'une base de données SQL compatible My autogérée comme source pour AWS DMS
Utilisation d'une base de données SQL compatible My AWS gérée comme source pour AWS DMS
Limitations relatives à l'utilisation d'une SQL base de données My comme source pour AWS DMS
Prise en charge des transactions XA
Paramètres du point de terminaison lors de l'utilisation de My SQL comme source pour AWS DMS
Types de données source pour My SQL

Migrer de Mon SQL vers Mon en utilisant SQL AWS DMS

Dans le cas d'une migration hétérogène, lorsque vous migrez d'un moteur de base de données autre que Ma base de données SQL vers une base de SQL données Ma base de données, 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 Ma base de données vers une SQL base de données Ma SQL base de données, nous vous recommandons d'utiliser un projet de migration de données homogène. 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 SQL compatible My comme source pour AWS DMS

Avant de commencer à utiliser une base de SQL données Ma base de données comme 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 :

REPLICATIONCLIENT— Ce privilège n'est requis que pour CDC les tâches. En d'autres termes, full-load-only les tâches ne nécessitent pas ce privilège.
REPLICATIONSLAVE— Ce privilège n'est requis que pour CDC les tâches. En d'autres termes, full-load-only les tâches ne nécessitent pas ce privilège.
SUPER— Ce privilège n'est requis que dans Mes SQL versions antérieures à la version 5.6.6.

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

Accordez les privilèges suivants si vous utilisez les évaluations de prémigration SQL spécifiques à My.


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

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

Vous pouvez utiliser les bases de données SQL compatibles My autogérées suivantes comme sources pour : AWS DMS

Édition My SQL Community
Mon édition SQL standard
Édition My SQL Enterprise
Édition My SQL Cluster Carrier Grade
MariaDB Community Edition
MariaDB Enterprise Edition
MariaDB Column Store

Pour l'utiliserCDC, assurez-vous d'activer la journalisation binaire. Pour activer la journalisation binaire, les paramètres suivants doivent être configurés dans SQL le fichier My my.ini (Windows) ou my.cnf (UNIX).

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 DMS version 3.4.7 ou antérieure.
`binlog_row_image`	Définissez ce paramètre à `FULL`.
`log_slave_updates`	Définissez ce paramètre sur `TRUE` si vous utilisez une réplique en lecture My SQL ou MariaDB comme source.

Si vous utilisez une réplique en lecture My SQL ou MariaDB comme source pour DMS une tâche de migration à 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. DMSn'écrira pas de transaction pendant le chargement complet ou CDC dans les conditions suivantes :

La transaction avait été validée sur l'instance principale avant le début de la DMS tâche.
La transaction n'a été validée dans la réplique qu'après le début de la DMS tâche, 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 être activés CDC sur les tables qui utilisent ce moteur de stockage. Ajoutez ces modifications dans SQL le fichier My my.ini (Windows) ou my.cnf (UNIX).

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 l'écriture d'UPDATEinstructions sous forme d'INSERTinstructions 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 de données SQL compatible My AWS gérée comme source pour AWS DMS

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

Édition My SQL Community
MariaDB Community Edition
Édition SQL compatible Amazon Aurora My

Lorsque vous utilisez une base de données SQL compatible My AWS gérée comme source pour AWS DMS, assurez-vous de remplir les conditions préalables suivantes pour : CDC

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

Pour plus d'informations sur la configuration des sauvegardes automatiques, consultez la section Utilisation des sauvegardes automatisées dans le guide de RDS l'utilisateur Amazon.

Pour plus d'informations sur la configuration de la journalisation binaire pour une SQL base de données Amazon RDS for My, consultez la section Configuration du format de journalisation binaire dans le guide de RDS l'utilisateur Amazon.

Pour plus d'informations sur la configuration de la journalisation binaire pour un SQL cluster Aurora My, consultez Comment activer la journalisation binaire pour mon SQL cluster Amazon Aurora My ? .
Si vous prévoyez de l'utiliserCDC, activez la journalisation binaire. Pour plus d'informations sur la configuration de la journalisation binaire pour une SQL base de données Amazon RDS for My, consultez la section Configuration du format de journalisation binaire dans le guide de RDS l'utilisateur Amazon.
Assurez-vous que les journaux binaires sont disponibles pour AWS DMS. Dans la mesure où les bases de données SQL compatibles My 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 My SQL ou MariaDBbinlog_format, il s'agit d'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 binlog_format paramètre d'une base de données MariaDB ou SQL My, veillez à redémarrer la base de données pour fermer toutes les sessions existantes, ou à redémarrer toute application DML effectuant des opérations (langage de manipulation des données). 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 DMS version 3.4.7 ou antérieure. Pour plus d'informations sur la définition des paramètres dans Amazon RDS MySQL, consultez la section Utilisation des sauvegardes automatisées dans le guide de RDS l'utilisateur Amazon.
Si vous utilisez une réplique en lecture Amazon RDS My SQL ou Amazon RDS MariaDB comme source, activez les sauvegardes sur la réplique en lecture et assurez-vous que log_slave_updates le paramètre est défini sur. TRUE

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

Lorsque vous utilisez une SQL base de données My comme source, tenez compte des points suivants :

La capture des données de modification (CDC) n'est pas prise en charge pour Amazon RDS My SQL 5.5 ou version antérieure. Pour Amazon RDS MySQL, vous devez utiliser la version 5.6, 5.7 ou 8.0 pour l'activerCDC. CDCest pris en charge pour les sources My SQL 5.5 autogérées.
PourCDC, CREATE TABLEADD COLUMN, et la DROP COLUMN 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 SQL cible My target. Pour migrer des tables partitionnées vers une table partitionnée sur la cible, créez au préalable les tables partitionnées sur la base de données Ma base de données cible. SQL
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. Les colonnes sont toujours ajoutées à la fin de la table.
CDCn'est pas pris en charge lorsque le nom d'une table contient des majuscules et des minuscules et que le moteur source est hébergé sur un système d'exploitation dont les noms de fichiers ne distinguent pas les majuscules et minuscules. Microsoft Windows ou OS X utilisant HFS + en est un exemple.
Vous pouvez utiliser Aurora My SQL -Compatible Edition Serverless v1 pour le chargement complet, mais vous ne pouvez pas l'utiliser pour. CDC Cela est dû au fait que 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 My SQL -Compatible Edition Serverless v2 prend en charge. CDC
L'INCREMENTattribut AUTO _ d'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 cela 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 SQL répliques Aurora My comme source, AWS DMS sauf si le mode de votre tâche de DMS migration est Migrer les données existantes, chargement complet uniquement.
Si la source My SQL -compatible 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 être répliquée LOBs (la valeur SupportLobs « » est fausse dans les paramètres de la tâche ou l'option Ne pas inclure LOB les colonnes est sélectionnée dans la console des tâches). Dans ces cas, AWS DMS ne migre aucune LONGTEXT colonne MEDIUMBLOB LONGBLOBMEDIUMTEXT,, et vers la cible.

BLOB, TINYBLOBTEXT, et les TINYTEXT colonnes 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 SQL clusters Amazon RDS Aurora My, le point de terminaison SQL source RDS Aurora My doit être une instance de lecture/écriture, 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 DDL les modifications relatives aux tables partitionnées pour MySQL. Pour ignorer la suspension de la table en cas de DDL modification de partition en coursCDC, réglez skipTableSuspensionForPartitionDdl surtrue.
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'est pas utilisé GTIDs pour la réplication, même si les données source en contiennent.
AWS DMS ne prend pas en charge le journal binaire SQL amélioré Aurora My.
AWS DMS ne prend pas en charge la compression des transactions du journal binaire.
AWS DMS ne propage pas les UPDATE CASCADE événements ON DELETE CASCADE et ON pour Mes SQL bases de données à l'aide du moteur de stockage InnoDB. Pour ces événements, My SQL 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 :
- 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 My SQL comme source pour AWS DMS

Vous pouvez utiliser les paramètres du point de terminaison pour configurer votre base de données My SQL source 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 source à l'aide de la AWS DMS console ou à l'aide de la create-endpoint commande contenue dans le AWS CLI, avec la --my-sql-settings '{"EndpointSetting": "value", ...}' JSON syntaxe.

Le tableau suivant indique les paramètres de point de terminaison que vous pouvez utiliser avec My SQL en tant que source.

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 My SQL source, en secondes. Valeur par défaut : 60 Exemple : `--my-sql-settings '{"ExecuteTimeout": 1500}'`
`ServerTimezone`	Spécifie le fuseau horaire de la base de SQL données Ma base de données source. 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 de s'exécuter indépendamment du succès ou de l'échec de l'SQLinstruction. Valeurs valides : une ou plusieurs SQL instructions valides, signalé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 une situation où l'exécution d'une modification DDL sur la table peut entraîner 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 DDL les modifications relatives aux tables partitionnées pour MySQL. Pour AWS DMS les versions 3.4.6 et supérieures, le réglage de cette option pour éviter la suspension de `true` la table en cas de DDL modification de partition en cours. CDC AWS DMS ignore partitioned-table-related DDL 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 source pour My SQL

Le tableau suivant indique les types de SQL données de source Ma base de données 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.

Mes types SQL de données	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)
BINARY	BYTES(1)
BIT	BOOLEAN
BIT(64)	BYTES(8)
BLOB	BYTES(65535)
LONGBLOB	BLOB
MEDIUMBLOB	BLOB
TINYBLOB	BYTES(255)
DATE	DATE
DATETIME	DATETIME DATETIMEsans valeur entre parenthèses est répliqué sans millisecondes. DATETIMEavec 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 DATETIME colonne, le temps reste le même sur la cible. Il n'est pas converti enUTC.
TIME	STRING
TIMESTAMP	DATETIME Lors de la réplication d'une TIMESTAMP colonne, l'heure est convertie en heure UTC sur la cible.
YEAR	INT2
DOUBLE	REAL8
FLOAT	REAL(DOUBLE) Si les FLOAT valeurs ne se situent pas dans la plage suivante, utilisez une transformation pour les FLOAT mapperSTRING. Pour plus d'informations sur les transformations, consultez Règles et actions de transformation. La FLOAT plage prise en charge est comprise entre -1,79E+308 et -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 (`length`) Ici, `length` est la longueur de la valeur la plus longue duENUM.
SET	WSTRING (`length`) Ici, `length` est la longueur totale de toutes les valeurs comprises dans leSET, y compris les virgules.
JSON	CLOB

Note

Dans certains cas, vous pouvez spécifier les types de TIMESTAMP données DATETIME et 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 TIMESTAMP données DATETIME et. 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

Utiliser Postgre SQL comme source

Utilisation de SAP ASE comme source