Pour quelles raisons les conditions du filtre de source de ma tâche AWS DMS ne fonctionnent-elles plus ?

Résolution

Vérifier si le moteur prend en charge la fonction de filtrage de source

La plupart des sources AWS DMS prennent en charge le filtrage de source. Cependant, ni MongoDB ni Amazon DocumentDB compatible avec MongoDB ne prennent en charge la fonctionnalité de filtrage de source. Pour plus d’informations, consultez la section Sources pour la migration des données.

Les limitations suivantes peuvent affecter le filtrage de source :

• Les filtres ne calculent pas les colonnes des langues de droite à gauche.
• Vous ne pouvez pas appliquer de filtres aux colonnes d’objets volumineux (LOB).
• Vous ne pouvez appliquer des filtres qu’aux colonnes fixes qui ne peuvent pas être mises à jour une fois créées. Si vous appliquez des filtres de source à des colonnes fixes pouvant être mises à jour une fois créées, les filtres de source risquent de ne pas fonctionner.

Résoudre les problèmes liés au non-fonctionnement des filtres durant les tâches de chargement complet

Déterminez la phase pendant laquelle le filtrage de source ne fonctionne pas.

Si le filtrage de source ne fonctionne pas pendant le chargement complet, effectuez les actions suivantes :

• Vérifiez que la sensibilité à la casse dans les règles de mappage correspond au moteur source.
• Lorsque vous filtrez des types de données de date, utilisez les formats requis par AWS DMS.
• Exécutez la journalisation de débogage au niveau de SOURCE_UNLOAD pour reproduire le problème. Capturez ensuite la requête qu’AWS DMS exécute sur la source pour décharger les données.

Exemple de problème de filtrage sur une table Oracle source :

CREATE TABLE DMS.FILTERS  
( ID NUMBER(10) NOT NULL,  
  ENTRY_DATE DATE,  
  CONSTRAINT FILTERS_PK PRIMARY KEY (ID)  
);  
SQL> SELECT * FROM FILTERS;  
  ID       ENTRY_DATE  
---------- ---------  
         1 01-JAN-22  
         2 01-JUN-22  
         3 01-JAN-21  
         4 01-JUN-21  
         5 01-JAN-20  
         6 01-JUN-20

Créez une tâche AWS DMS et configurez des règles de mappage permettant de répliquer uniquement les lignes dont la valeur ENTRY_DATE est supérieure ou égale au 01/01/2022.

Exemple de tâche :

{    
 "rules": [  
    {  
      "rule-type": "selection",  
      "rule-id": "893662253",  
      "rule-name": "893662253",  
      "object-locator": {  
        "schema-name": "DMS",  
        "table-name": "FILTERS"  
      },  
      "rule-action": "include",  
      "filters": [  
        {  
          "filter-type": "source",  
          "column-name": "ENTRY_DATE",  
          "filter-conditions": [  
            {  
              "filter-operator": "gte",  
              "value": "01/01/2022"  
            }  
          ]  
        }  
      ]  
    }  
  ]  
}

Pour vous assurer qu’aucun enregistrement n’est répliqué et que les erreurs apparaissent dans les journaux des tâches, exécutez la requête suivante :

01786264: 2022-06-22T10:36:53 [SOURCE_UNLOAD   ]E:  ORA-01843: not a valid month  [1020417]  (oracle_endpoint_unload.c:171)

Comme les journaux de débogage sont activés pour SOURCE_UNLOAD, les journaux des tâches indiquent la requête exacte qu’AWS DMS exécute sur la base de données source.

Exemple de requête :

1786264: 2022-06-22T10:36:53 [SOURCE_UNLOAD   ]D:  Select statement for UNLOAD is 'SELECT "ID","ENTRY_DATE"  FROM "DMS"."FILTERS" WHERE ((("ENTRY_DATE" >= TO_DATE('0000-00-00','YYYY-MM-DD'))))'  (oracle_endpoint_utils.c:1979)

Dans la sortie de journal suivante, AWS DMS exécute la requête sur la base de données source :

SELECT "ID","ENTRY_DATE"  FROM "DMS"."FILTERS" WHERE ((("ENTRY_DATE" >= TO_DATE('0000-00-00','YYYY-MM-DD'))));

AWS DMS ne reconnaît pas la date dans les règles de mappage. Cela signifie que le format de date ne correspond pas à celui attendu par AWS DMS.

Pour modifier les règles de mappage de façon à établir une correspondance au format de date attendu, exécutez la requête suivante :

{                            "filter-operator": "gte",  
                            "value": "2022-01-01"  
                        }

Résoudre les problèmes liés au non-fonctionnement des filtres lors de la saisie des données de modification (CDC)

Lorsque vous filtrez des colonnes fixes, les problèmes de filtrage se produisent uniquement pendant la phase CDC. Ces problèmes peuvent survenir uniquement sur des instructions spécifiques du langage de manipulation des données (DML), telles que UPDATES ou DELETES. Assurez-vous d’activer un niveau de journalisation suffisant dans la table source.

Pour allouer un niveau de journalisation supplémentaire, utilisez Oracle, PostgreSQL ou Microsoft SQL Server.

Oracle

Oracle utilise la journalisation supplémentaire pour ajouter des journaux supplémentaires pour les colonnes du tableau. Si la colonne que vous filtrez n’est pas une colonne de clé primaire, activez le niveau de journalisation supplémentaire pour la colonne et les colonnes de clé primaire.

L’exemple suivant réplique une table nommée TEST.LOGGING qui possède un ID de clé primaire et un filtre dans la colonne NAME. Pour créer le niveau de journalisation supplémentaire du groupe de journaux, exécutez la commande suivante :

ALTER TABLE TEST.LOGGING ADD SUPPLEMENTAL LOG GROUP TEST_LOG_GROUP (ID, NAME) ALWAYS;

Si un niveau de journalisation supplémentaire est déjà ajouté pour toutes les colonnes du tableau, n’en ajoutez pas d’autre.

Exemple avec une journalisation supplémentaire déjà ajoutée :

ALTER TABLE TableName ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

PostgreSQL

PostgreSQL utilise la propriété REPLICA IDENTITY pour configurer le niveau de journalisation d’une table. Lorsque vous définissez REPLICA IDENTITY sur DEFAULT, PostgreSQL enregistre les anciennes valeurs des colonnes de la clé primaire dans des journaux en écriture anticipée (WAL, write-ahead logs). Toutefois, lorsque vous utilisez une colonne autre que la clé primaire, le niveau de journalisation par défaut peut ne pas être suffisant pour les suppressions.

Assurez-vous que la tâche AWS DMS utilise le plug-in défini sur l’une des propriétés suivantes :

Si vous utilisez test_decoding, définissez REPLICA IDENTITY sur FULL :

ALTER TABLE tablename REPLICA IDENTITY FULL;

Remarque : Si vous ne définissez pas REPLICA IDENTITY sur FULL, AWS DMS peut envoyer toutes les suppressions vers la table cible.

Si vous utilisez pglogical, définissez REPLICA IDENTITY sur FULL après avoir ajouté la table au jeu de réplication :

ALTER TABLE tablename REPLICA IDENTITY FULL;

Remarque : Lorsque vous définissez REPLICA IDENTITY sur FULL, pglogical inclut une limitation qui vous empêche d’ajouter une table à un jeu de réplication. Vous augmentez également le nombre de journaux WAL générés sur la base de données source. Lorsque le nombre de journaux WAL augmente, toutes les colonnes sont enregistrées dans les journaux WAL.

Microsoft SQL Server

Vérifiez que toutes les exigences de journalisation AWS DMS CDC suivantes sont respectées pour activer MS-CDC.

Pour chaque table qui possède une clé primaire, exécutez la requête suivante :

exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL,
@supports_net_changes = 1
GO

Remarque : La requête précédente est requise pour les sources basées sur le cloud.

Pour chaque table qui possède des clés uniques mais aucune clé primaire, exécutez la requête suivante :

exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@index_name = N'unique_index_name',
@role_name = NULL,
@supports_net_changes = 1
GO

Remarque : La requête précédente est requise pour les sources sur site et les sources basées sur le cloud. Si vous utilisez MS-Replication pour les sources sur site, vous n’avez pas besoin d’exécuter la requête précédente.

Pour chaque table qui ne possède ni de clé primaire ni de clé unique, exécutez la requête suivante :

exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO

Remarque : La requête précédente nécessite à la fois des sources sur site et des sources basées sur le cloud.

MySQL

Dans MySQL, la variable système binlog_row_image contrôle les images des lignes dans les fichiers binaires. Pour plus d'informations, consultez la section sur la variable binlog_row_image du site Web de MySQL. AWS DMS nécessite de définir binlog_row_image sur FULL et binlog_format sur ROW.

MySQL enregistre toutes les colonnes à la fois dans l’image d’avant et dans l’image d’après. Pour confirmer le niveau de journalisation maximal dans les binlogs, vous devez définir binlog_row_image sur FULL dans la base de données source.

Informations connexes

Comment puis-je utiliser les filtres de source dans mes tâches AWS DMS ?

Utilisation du mappage de tables pour spécifier les paramètres des tâches

Utilisation des filtres de source