Réplication à partir d'un point de départ CDC Effectuer une réplication bidirectionnelle

Création de tâches pour la réplication continue à l'aide d'AWS DMS

Vous pouvez créer une tâche AWS DMS qui capture les modifications en continu à partir du magasin de données source. Pour ce faire, vous pouvez capturer pendant que vous migrez vos données. Vous pouvez également créer une tâche qui capture les modifications continues une fois que vous avez terminé la migration initiale (chargement complet) vers un magasin de données cible pris en charge. Ce processus est appelé la réplication continue ou capture des données modifiées (CDC). AWS DMS utilise ce processus lors de la réplication des modifications continues à partir d'un magasin de données source. Lors de ce processus, les modifications apportées aux journaux de base de données sont collectées à l'aide de l'API native du moteur de base de données.

Note

Vous pouvez migrer des vues à l'aide de tâches de chargement complet uniquement. Si votre tâche est une tâche CDC uniquement ou une tâche de chargement complet qui démarre la capture des données modifiées (CDC) une fois terminée, la migration inclut uniquement les tables de la source. Si vous utilisez une tâche de chargement complet uniquement, vous pouvez migrer des vues ou une combinaison de tables et de vues. Pour de plus amples informations, veuillez consulter Spécification des règles de sélection de table et de transformation à l’aide de JSON.

Chaque moteur source possède une configuration requise spécifique pour communiquer ce flux de modifications à un compte d'utilisateur donné. La plupart des moteurs ont besoin d'une configuration supplémentaire pour que le processus de capture puisse exploiter les données modifiées de manière significative, sans perte de données. Par exemple, Oracle nécessite l'ajout d'une journalisation supplémentaire et MySQL nécessite une journalisation binaire au niveau des lignes.

Pour lire les modifications continues à partir de la base de données source, AWS DMS utilise des actions d'API propres au moteur pour lire les modifications à partir des journaux de transactions du moteur source. Voici quelques exemples montrant la façon dont AWS DMS exécute cette opération :

Pour Oracle, AWS DMS utilise l'API Oracle LogMiner ou Binary Reader (API bfile) pour lire les modifications en continu. AWS DMS lit les modifications en continu dans les journaux redo en ligne ou archivés en fonction du SCN (numéro de modification système).
Pour Microsoft SQL Server, AWS DMS utilise MS-Replication ou MS-CDC pour écrire des informations dans le journal des transactions SQL Server. Il utilise ensuite la fonction fn_dblog() ou fn_dump_dblog() dans SQL Server pour lire les modifications dans le journal des transactions en fonction du LSN (numéro de séquence de journal).
Pour MySQL, AWS DMS lit les modifications à partir des journaux binaires basés sur les lignes et migre ces modifications vers la cible.
Pour PostgreSQL, AWS DMS configure des emplacements de réplication logique et utilise le plug-in test_decoding pour lire les modifications à partir de la source et les migrer vers la cible.
Pour Amazon RDS en tant que source, nous vous recommandons de vérifier que les sauvegardes sont activées pour configurer la CDC. Nous vous recommandons également de vous assurer que la base de données source est configurée pour conserver les journaux de modification pendant une durée suffisante (24 heures suffisent généralement). Pour obtenir les paramètres spécifiques à chaque point de terminaison, consultez :
- Amazon RDS for Oracle : Configuration d'une source Oracle AWS gérée pour AWS DMS.
- Amazon RDS for MySQL et Aurora MySQL : Utilisation d'une base AWS de données compatible avec MySQL gérée comme source pour AWS DMS.
- Amazon RDS for SQL Server : Configuration de la réplication continue sur une instance de base de données SQL Server cloud.
- Amazon RDS for PostgreSQL et Aurora PostgreSQL : PostgreSQL conserve automatiquement les journaux WAL requis.

Il existe deux types de tâches de réplication continue :

Chargement complet + CDC : la tâche migre les données existantes, puis met à jour la base de données cible en fonction des modifications apportées à la base de données source.
CDC uniquement : la tâche migre les modifications continues une fois que les données sont sur la base de données cible.

Exécution de la réplication à partir d'un point de départ CDC

Vous pouvez démarrer une tâche de réplication continue AWS DMS (tâche de capture des données modifiées (CDC) uniquement) à partir de plusieurs points, Tel est le cas des éléments suivants :

À partir d'une heure de début de CDC personnalisée : vous pouvez utiliser AWS Management Console ou AWS CLI pour fournir à AWS DMS un horodatage auquel vous voulez démarrer la réplication. AWS DMS démarre alors une tâche de réplication continue à partir de cette heure de début de CDC personnalisée. AWS DMS convertit l'horodatage donné (au format UTC) en point de départ natif, par exemple un LSN pour SQL Server ou un SCN pour Oracle. AWS DMS utilise des méthodes spécifiques à chaque moteur pour déterminer où démarrer la tâche de migration en fonction du flux de modifications du moteur source.

Note
Ce n'est qu'en définissant l'attribut de connexion StartFromContext sur l'horodatage requis que DB2, en tant que source, propose une heure de début de CDC personnalisée.
PostgreSQL comme source ne prend pas en charge une heure de début CDC personnalisée. Cela est dû au fait que le moteur de base de données PostgreSQL n'a aucun moyen de faire correspondre un horodatage à un LSN ou un SCN, à la différence d'Oracle et SQL Server.
À partir d'un point de départ natif de CDC : vous pouvez également démarrer à partir d'un point natif dans le journal des transactions du moteur source. Dans certains cas, cette approche peut être préférable, car un horodatage peut indiquer plusieurs points natifs dans le journal des transactions. AWS DMS prend en charge cette fonctionnalité pour les points de terminaison source suivants :
- SQL Server
- PostgreSQL
- Oracle
- MySQL
- MariaDB

Lorsque la tâche est créée, AWS DMS marque le point de départ de la CDC et il ne peut pas être modifié. Pour utiliser un point de départ de CDC différent, créez une nouvelle tâche.

Définition d'un point de départ natif CDC

Un point de départ natif CDC est un point dans le journal du moteur de base de données qui définit un moment auquel vous pouvez commencer la capture des données modifiées (CDC). À titre d'exemple, supposons qu'un vidage des données en bloc a déjà été appliqué à la cible. Vous pouvez rechercher le point de départ natif de la tâche de réplication continue uniquement. Pour éviter toute incohérence dans les données, choisissez avec soin le point de départ de la tâche de réplication uniquement. DMS capture les transactions qui ont débuté après le point de départ de CDC choisi.

Voici des exemples montrant comment trouver le point de départ natif CDC à partir de moteurs sources pris en charge :

SQL Server

Dans SQL Server, un LSN (numéro de séquence de journal) comporte trois parties :

Numéro de séquence VLF (fichier journal virtuel)
Décalage de départ d'un bloc de journaux
Numéro de l'emplacement

Voici un exemple de LSN : 00000014:00000061:0001

Pour obtenir le point de départ d'une tâche de migration SQL Server en fonction de vos paramètres de sauvegarde du journal des transactions, utilisez la fonction fn_dblog() ou fn_dump_dblog() dans SQL Server.

Pour utiliser le point de départ natif de CDC avec SQL Server, créez une publication sur n'importe quelle table participant à la réplication continue. AWS DMS crée la publication automatiquement lorsque vous utilisez la CDC sans utiliser de point de départ natif de CDC.

PostgreSQL

Vous utilisez un point de contrôle de récupération CDC pour votre base de données source PostgreSQL. Cette valeur de point de contrôle est générée en différents points pendant l’exécution d'une tâche de réplication continue pour votre base de données source (la tâche parent). Pour plus d'informations sur les points de contrôle en général, consultez Utilisation d'un point de contrôle comme point de départ CDC.

Pour identifier le point de contrôle à utiliser comme point de départ natif, utilisez la vue pg_replication_slots de la base de données ou les détails de présentation de la tâche parent dans AWS Management Console.

Pour trouver les détails de la présentation de votre tâche parent sur la console

Connectez-vous à la AWS Management Console et ouvrez la console AWS DMS à l'adresse https://console.aws.amazon.com/dms/v2/.

Si vous êtes connecté en tant qu'utilisateur IAM, assurez-vous d'avoir les autorisations appropriées pour accéder à AWS DMS. Pour plus d'informations sur les autorisations requises, consultez Autorisations IAM nécessaires pour utiliser AWS DMS.
Dans le volet de navigation de la console, choisissez, Tâches de migration de base de données.
Choisissez votre tâche parent dans la liste de la page Tâches de migration de base de données. Vous ouvrez ainsi la page de la tâche parent et affichez les détails de la présentation.
Trouvez la valeur du point de contrôle sous Capture de données modifiées (CDC), Position de départ de la capture de données modifiées (CDC) et Point de contrôle de récupération de la capture des données modifiées (CDC).

La valeur qui apparaît est similaire celle ci-dessous.
```
checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0
```
Ici, le composant 4AF/B00000D0 est ce dont vous avez besoin pour spécifier ce point de départ CDC natif. Définissez le paramètre CdcStartPosition de l’API DMS sur cette valeur lorsque vous créez la tâche CDC pour commencer la réplication à ce point de départ pour votre source PostgreSQL. Pour de plus amples informations sur l'utilisation de l'AWS CLI pour créer cette tâche CDC, veuillez consulter Activation du CDC avec une instance de base de données PostgreSQL AWS gérée avec AWS DMS.

Oracle

Un SCN (numéro de modification système) est un horodatage interne, logique, utilisé par les bases de données Oracle. Les SCN classent les événements qui se produisent au sein de la base de données, ce qui est nécessaire pour répondre aux propriétés ACID d'une transaction. Les bases de données Oracle utilisent des SCN pour marquer l'emplacement où toutes les modifications ont été écrites sur le disque afin qu'une action de récupération n'applique pas les modifications déjà écrites. Oracle utilise également les SCN pour marquer le point où il n'existe pas de redo pour un ensemble de données, afin que la récupération puisse s'arrêter.

Pour obtenir le SCN actuel dans une base de données Oracle, exécutez la commande suivante.


SELECT CURRENT_SCN FROM V$DATABASE

Si vous utilisez le SCN ou l'horodatage pour démarrer une tâche de CDC, les résultats des transactions ouvertes sont manquants et vous ne parvenez pas à les migrer. Les transactions ouvertes sont des transactions qui ont été démarrées avant la position de départ de la tâche et validées après la position de départ de la tâche. Vous pouvez identifier le SCN et l'horodatage pour démarrer une tâche de CDC à un point qui inclut toutes les transactions ouvertes. Pour plus d'informations, consultez Transactions dans la documentation d'Oracle en ligne. Avec la version 3.5.1 et les versions ultérieures, AWS DMS prend en charge les transactions ouvertes pour une tâche de CDC uniquement en utilisant le paramètre de point de terminaison openTransactionWindow si vous utilisez le SCN ou l'horodatage pour démarrer la tâche.

Lorsque vous utilisez le paramètre openTransactionWindow, vous devez fournir la fenêtre (en minutes) dans laquelle gérer les transactions ouvertes. AWS DMS décale la position de capture et trouve la nouvelle position pour démarrer la capture des données. AWS DMS utilise la nouvelle position de départ pour analyser toutes les transactions ouvertes à partir des journaux redo Oracle requis ou des journaux redo archivés.

MySQL

Avant la version MySQL 5.6.3, le LSN pour MySQL était un entier non signé de 4 octets. Dans la version MySQL 5.6.3, lorsque la limite de taille du fichier journal redo est passée de 4 Go à 512 Go, le LSN est devenu un entier non signé à 8 octets. L'augmentation indique qu'il était nécessaire d'augmenter le nombre d'octets pour stocker des informations supplémentaires sur la taille. Les applications reposant sur MySQL 5.6.3 ou versions ultérieures et qui utilisent les LSN doivent utiliser des variables de 64 bits plutôt que 32 bits pour stocker et comparer les valeurs LSN. Pour plus d'informations sur les LSN MySQL, consultez la documentation MySQL.

Pour obtenir le LSN actuel dans une base de données MySQL, exécutez la commande suivante.


mysql> show master status;

La requête renvoie le nom d'un fichier binlog, la position, ainsi que plusieurs autres valeurs. Le point de départ natif CDC est une combinaison du nom du fichier binlog et de la position, par exemple mysql-bin-changelog.000024:373. Dans cet exemple, mysql-bin-changelog.000024 est le nom du fichier binlog et 373, la position où AWS DMS doit démarrer la capture des modifications.

Utilisation d'un point de contrôle comme point de départ CDC

Une tâche de réplication continue migre les modifications, et AWS DMS met de temps en temps en cache des informations spécifiques de AWS DMS. Le point de contrôle créé par AWS DMS contient des informations qui permettent au moteur de réplication de connaître le point de récupération pour le flux des modifications. Vous pouvez utiliser le point de contrôle pour revenir dans la chronologie des modifications et récupérer une tâche de migration ayant échoué. Vous pouvez également utiliser un point de contrôle pour démarrer une autre tâche de réplication continue pour une autre cible à tout moment.

Vous pouvez obtenir les informations de point de contrôle de l'une des trois manières suivantes :

Exécutez l'opération d'API DescribeReplicationTasks et consultez les résultats. Vous pouvez filtrer les informations par tâche et rechercher le point de contrôle. Vous pouvez récupérer le dernier point de contrôle lorsque la tâche est arrêtée ou en échec. Ces informations sont perdues si la tâche est supprimée.
Affichez la table de métadonnées nommée awsdms_txn_state sur l'instance cible. Vous pouvez interroger la table pour obtenir les informations de point de contrôle. Pour créer la table de métadonnées, définissez le paramètre TaskRecoveryTableEnabled sur Yes lorsque vous créez une tâche. Ce paramètre indique à AWS DMS d'écrire en continu des informations de point de contrôle dans la table de métadonnées cible. Ces informations sont perdues si une tâche est supprimée.

Voici un exemple de point de contrôle dans la table de métadonnées : checkpoint:V1#34#00000132/0F000E48#0#0#*#0#121
Dans le volet de navigation, choisissez Tâches de migration de base de données, puis choisissez votre tâche parent dans la liste qui apparaît sur la page Tâches de migration de base de données. La page de votre tâche parent s'ouvre avec les détails de présentation. Trouvez la valeur du point de contrôle sous Capture de données modifiées (CDC), Position de départ de la capture de données modifiées (CDC) et Point de contrôle de récupération de la capture des données modifiées (CDC). La valeur de point de contrôle qui apparaît est similaire à ce qui suit :

checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

Arrêt d'une tâche à un point de validation ou de serveur

Grâce à l'introduction des points de départ CDC natifs, AWS DMS peut également arrêter une tâche aux points suivants :

Heure de validation sur la source
Heure du serveur sur l'instance de réplication

Vous pouvez modifier une tâche et définir une heure au format UTC pour arrêter au moment souhaité. La tâche s'arrête automatiquement en fonction de l'heure de validation ou du serveur que vous définissez. Par ailleurs, si vous souhaitez arrêter la tâche de migration à une heure précise au moment de la création de la tâche, vous pouvez définir une heure d'arrêt lorsque vous créez la tâche.

Note

L'initialisation de toutes les ressources peut prendre jusqu'à 40 minutes la première fois que vous démarrez une nouvelle réplication AWS DMS sans serveur. Notez que l'option server_time n'est applicable qu'une fois l'initialisation des ressources terminée.

Effectuer une réplication bidirectionnelle

Vous pouvez utiliser des tâches AWS DMS pour effectuer une réplication bidirectionnelle entre deux systèmes. Dans la réplication bidirectionnelle, vous répliquez des données de la même table (ou d’un ensemble de tables) entre deux systèmes dans les deux sens.

Par exemple, vous pouvez copier une table EMPLOYE de la base de données A vers la base de données B et répliquer les modifications apportées à la table de la base de données A vers la base de données B. Vous pouvez également répliquer les modifications apportées à la table EMPLOYE de la base de données B vers A. Ainsi, vous effectuez une réplication bidirectionnelle.

Note

La réplication bidirectionnelle AWS DMS n'est pas conçue comme une solution multi-maître complète incluant un nœud principal, la résolution des conflits, etc.

Utilisez la réplication bidirectionnelle pour des cas dans lesquels les données sur différents nœuds sont séparées au niveau opérationnel. En d'autres termes, supposons qu’un élément de données soit modifié par une application fonctionnant sur le nœud A, et que ce dernier effectue une réplication bidirectionnelle avec le nœud B. Cet élément de données sur le nœud A n'est jamais modifié par une application fonctionnant sur le nœud B.

AWS DMS prend en charge la réplication bidirectionnelle sur ces moteurs de base de données :

Oracle
SQL Server
MySQL
PostgreSQL
Amazon Aurora MySQL-Compatible Edition
Aurora PostgreSQL-Compatible Edition

Création de tâches de réplication bidirectionnelle

Pour activer la réplication bidirectionnelle AWS DMS, configurez les points de terminaison source et cible pour les deux bases de données (A et B). Par exemple, configurez un point de terminaison source pour la base de données A, un point de terminaison source pour la base de données B, un point de terminaison cible pour la base de données A et un point de terminaison cible pour la base de données B.

Ensuite, créez deux tâches : une tâche pour la source A pour déplacer les données vers la cible B, et une autre tâche pour la source B pour déplacer les données vers la cible A. Assurez-vous également que chaque tâche est configurée pour empêcher les boucles. Vous pourrez ainsi empêcher l'application de modifications identiques aux cibles des deux tâches, ce qui corrompt les données d'au moins une d'entre elles. Pour de plus amples informations, veuillez consulter Empêcher les boucles.

Pour l'approche la plus simple, commencez par des jeux de données identiques sur les bases de données A et B. Ensuite, créez deux tâches CDC uniquement, une tâche pour répliquer les données de A vers B et une autre tâche pour répliquer les données de B vers A.

Pour instancier un nouveau jeu de données (base de données) sur le nœud B à partir du nœud A à l’aide de AWS DMS, procédez comme suit :

Utilisez une charge complète et une tâche CDC pour déplacer les données de la base de données A vers B. Assurez-vous qu'aucune application ne modifie les données de la base de données B pendant ce temps.
Lorsque la charge complète est terminée et avant que les applications ne soient autorisées à modifier les données de la base de données B, notez l'heure ou la position de départ de la CDC de la base de données B. Pour obtenir des instructions, veuillez consulter Exécution de la réplication à partir d'un point de départ CDC.
Créez une tâche CDC uniquement qui déplace les données de la base de données B vers A à l'aide de cette heure de début ou de cette position de départ CDC.

Note

Une seule tâche dans une paire bidirectionnelle peut être totalement chargée et CDC.

Empêcher les boucles

Pour afficher la prévention des boucles, supposons que dans une tâche T1 AWS DMS lit les journaux des modifications à partir de la base de données source A et applique les modifications à la base de données cible B.

Ensuite, une deuxième tâche, T2, lit les journaux des modifications à partir de la base de données source B et les applique à la base de données cible A. Avant que T2 ne fasse cela, DMS doit s'assurer que les modifications apportées à la base de données cible B à partir de la base de données source A ne sont pas apportées à la base de données source A. En d'autres termes, DMS doit s'assurer que ces modifications ne sont pas reprises (en boucle) dans la base de données cible A. Dans le cas contraire, les données de la base de données A peuvent être corrompues.

Pour éviter les boucles de modifications, ajoutez les paramètres de tâche suivants à chaque tâche de réplication bidirectionnelle. Ainsi, vous vous assurez que la corruption des données pour cause de boucles ne se produit dans aucun sens.


{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": Boolean,
    "SourceSchema": String,
    "TargetSchema": String
  },

. . .
}

Les paramètres de tâche LoopbackPreventionSettings déterminent si une transaction est nouvelle ou reprise de la tâche de réplication opposée. Lorsqu'une transaction est appliquée par AWS DMS à une base de données cible, elle met à jour une table DMS (awsdms_loopback_prevention) avec une indication de la modification. Avant d'appliquer chaque transaction à une cible, DMS ignore toute transaction qui inclut une référence à cette table awsdms_loopback_prevention. Par conséquent, il n'applique pas la modification.

Inclure ces paramètres de tâche avec chaque tâche de réplication dans une paire bidirectionnelle. Ces paramètres permettent la prévention des boucles. Ils spécifient également le schéma de chaque base de données source et cible dans la tâche qui inclut la table awsdms_loopback_prevention pour chaque point de terminaison.

Pour permettre à chaque tâche d'identifier une reprise et de le supprimer, définissez EnableLoopbackPrevention sur true. Pour spécifier un schéma dans la source qui inclut awsdms_loopback_prevention, définissez SourceSchema sur le nom de ce schéma dans la base de données source. Pour spécifier un schéma sur la cible qui inclut la même table, définissez TargetSchema sur le nom de ce schéma dans la base de données cible.

Dans l'exemple suivant, les paramètres TargetSchema et SourceSchema pour une tâche de réplication T1 et sa tâche de réplication opposée T2 sont spécifiés avec des paramètres opposés.

Les paramètres de la tâche T1 sont les suivants.


{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "LOOP-DATA",
    "TargetSchema": "loop-data"
  },

. . .
}

Les paramètres de la tâche opposée T2 sont les suivants.


{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "loop-data",
    "TargetSchema": "LOOP-DATA"
  },

. . .
}

Note

Lorsque vous utilisez l’AWS CLI, utilisez uniquement les commandes modify-replication-task ou create-replication-task pour configurer LoopbackPreventionSettings dans vos tâches de réplication bidirectionnelle.

Limites de la réplication bidirectionnelle

La réplication bidirectionnelle pour AWS DMS présente les limites suivantes :

La prévention des boucles suit uniquement les instructions en langage de manipulation de données (DML). AWS DMS ne prend pas en charge la prévention des boucles de langage de définition de données (DDL). Pour ce faire, configurez l'une des tâches dans une paire bidirectionnelle pour filtrer les instructions DDL.
Les tâches qui utilisent la prévention de boucles ne prennent pas en charge la validation des modifications dans des lots. Pour configurer une tâche avec la prévention de boucles, assurez-vous de définir BatchApplyEnabled sur false.
La réplication bidirectionnelle DMS n'inclut pas la détection ou la résolution des conflits. Pour détecter des incohérences de données, utilisez la validation des données sur les deux tâches.

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

Création de plusieurs tâches

Modification d'une tâche