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

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Vous pouvez créer une AWS DMS tâche qui capture les modifications en cours depuis le 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é réplication continue ou capture des données de modification (CDC). AWS DMS utilise ce processus lors de la réplication des modifications en cours à 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.

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 en cours depuis la base de données source, AWS DMS utilise des actions d'API spécifiques au moteur pour lire les modifications dans les journaux de transactions du moteur source. Voici quelques exemples de la façon dont AWS DMS cela fonctionne :

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

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

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

Lorsque la tâche est créée, AWS DMS marque le point de départ du CDC et elle ne peut pas être modifiée. 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 :

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

Une tâche de réplication en cours migre les modifications et met en AWS DMS cache les informations de point de contrôle spécifiques AWS DMS de temps à autre. 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 :

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

Avec l'introduction des points de départ natifs du CDC, AWS DMS vous pouvez également arrêter une tâche aux points suivants :

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.

Effectuer une réplication bidirectionnelle

Vous pouvez utiliser AWS DMS des tâches 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.

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 les moteurs de base de données suivants :

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

Pour activer la réplication AWS DMS bidirectionnelle, 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.

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

Empêcher les boucles

Pour empêcher le bouclage, supposons que, dans une tâche, T1 AWS DMS lise les journaux des modifications 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"
  },

. . .
}

Limites de la réplication bidirectionnelle

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