Pourquoi les conditions de filtre de source dans ma tâche AWS DMS ne fonctionnent-elles pas ?

Brève description

Il existe plusieurs raisons pour lesquelles les conditions de filtre de source peuvent ne pas fonctionner comme prévu dans une tâche AWS DMS. Par exemple, le moteur que vous utilisez ne prend peut-être pas en charge l'utilisation des conditions de filtre de source. Ou, vous pouvez être affecté par une ou plusieurs des limitations de la fonction.

Solution

Vérifier si votre moteur prend en charge la fonction de filtrage des sources

Bien que la plupart des sources AWS DMS prennent en charge le filtrage des sources, certaines sources telles que MongoDB ou Amazon DocumentDB ne prennent pas en charge cette fonction. Consultez la documentation AWS DMS sur les sources pour la migration des données pour confirmer si le moteur source que vous utilisez présente des limitations.

Examiner les limitations du filtrage des sources d'AWS DMS

Il existe plusieurs limitations associées au filtrage des sources. Examinez les limitations pour vérifier que vous utilisez la fonction correctement :

• Les filtres ne calculent pas les colonnes de langues de droite à gauche.
• Les filtres ne peuvent pas être appliqués aux colonnes LOB (Large Object).
• Les filtres peuvent être appliqués uniquement aux colonnes immuables qui ne sont pas mises à jour après leur création. Si vous appliquez des filtres de source à des colonnes mutables qui peuvent être mises à jour après la création, ils peuvent ne pas fonctionner comme prévu.

Résoudre le problème des filtres qui cessent de fonctionner pendant un chargement complet

Si votre problème persiste, vérifiez à quelle phase le filtrage de la source cesse de fonctionner.

Si le filtrage ne fonctionne pas pendant le chargement complet, suivez ces étapes :

1.    Confirmez que la sensibilité à la casse dans les règles de mappage correspond au moteur source. Par exemple, les noms d'objets dans Oracle et DB2 sont en majuscules, par défaut. De même, les noms d'objets dans PostgreSQL sont en minuscules. Assurez-vous que la colonne que vous utilisez dans votre condition de filtrage correspond à la sensibilité à la casse requise par votre moteur source.

2.    Lorsque vous filtrez avec des types de données date, vérifiez que vous utilisez les formats requis par AWS DMS. Par exemple, AWS DMS utilise le format de date AAAA-MM-JJ et le format d'heure AAAA-MM-JJ HH:MM:SS pour le filtrage.

3.    Reproduisez le problème avec un niveau de journalisation de débogage sur SOURCE_UNLOAD. Ensuite, capturez la requête qu'AWS DMS exécute sur la source pour décharger les données. Voici un exemple de problème de filtrage sur une table Oracle source.

Détails de la table :

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

Une tâche AWS DMS est créée avec les règles de mappage pour répliquer uniquement les lignes dont la date ENTRY_DATE est supérieure ou égale à 01/01/2022 :

{
  "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"
            }
          ]
        }
      ]
    }
  ]
}

Ainsi, aucun enregistrement n'est répliqué, et les journaux de la tâche montrent ces erreurs :

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 de tâches montrent la requête exacte qu'AWS DMS exécute sur la base de données source :

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 du journal, vous pouvez voir qu'AWS DMS exécute cette 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 fournie dans les règles de mappage car elle ne correspond pas au format de date attendu par AWS DMS. Modifiez donc les règles de mappage pour qu'elles correspondent au format de date attendu :

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

Résoudre les problèmes des filtres qui cessent de fonctionner pendant la CDC

Remarque : appliquez des filtres uniquement aux colonnes immuables qui ne sont pas mises à jour après leur création. L'ajout de filtres sur des colonnes modifiables peut entraîner des résultats inattendus.

Si les colonnes que vous utilisez dans le filtrage sont des colonnes immuables, vous pouvez noter que les problèmes de filtrage se produisent uniquement pendant la phase de CDC. De même, ces problèmes peuvent se produire uniquement sur des instructions DML spécifiques telles que UPDATES (MISES À JOUR) ou DELETES (SUPPRESSIONS). Dans ce scénario, assurez-vous que vous avez activé une journalisation suffisante sur la table source. Suivez ces étapes pour allouer une journalisation supplémentaire, en fonction du moteur que vous utilisez :

Oracle

Oracle utilise la journalisation supplémentaire pour ajouter des journaux supplémentaires pour les colonnes de la table. Si la colonne que vous filtrez n'est pas une colonne de clé primaire, assurez-vous que la journalisation supplémentaire est activée pour cette colonne et les colonnes de clé primaire.

Cet exemple réplique une table nommée TEST.LOGGING avec un ID de clé primaire et un filtre sur la colonne NAME (NOM). Exécutez une commande similaire à la suivante pour créer la journalisation supplémentaire du groupe de journaux :

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

Si la journalisation supplémentaire est déjà ajoutée pour toutes les colonnes d'une table, comme dans cet exemple, il n'est pas nécessaire d'ajouter d'autres journalisations.

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

PostgreSQL

PostgreSQL utilise la propriété REPLICA IDENTITY (IDENTITÉ DE RÉPLICA) pour configurer le niveau de journalisation d'une table. Lorsque REPLICA IDENTITY (IDENTITÉ DE RÉPLICA) est défini sur défaut, PostgreSQL enregistre les anciennes valeurs des colonnes de la clé primaire dans les journaux WAL. Toutefois, le niveau de journalisation par défaut peut ne pas être suffisant pour DELETES (SUPPRESSIONS) lorsque vous utilisez une colonne de clé non primaire dans le filtrage. Dans ce scénario, effectuez les étapes suivantes en fonction du plugin utilisé par la tâche AWS DMS : Si test_decoding est utilisé :

Définissez REPLICA IDENTITY (IDENTITÉ DE RÉPLICA) sur full (complet) sur la table. Si vous n'effectuez pas cette étape, AWS DMS pourrait envoyer toutes les suppressions à la table cible :

ALTER TABLE tablename REPLICA IDENTITY FULL;

Si pglogical est utilisé :

Définissez REPLICA IDENTITY (IDENTITÉ DE RÉPLICA) sur full (complet) après l'ajout de la table au jeu de réplication. Cela est dû au fait que pglogical a une limitation qui empêche l'ajout de la table à un jeu de réplication si REPLICA IDENTITY (IDENTITÉ DE RÉPLICA) est full (complet).

ALTER TABLE tablename REPLICA IDENTITY FULL;

Remarque : le fait de définir REPLICA IDENTITY (IDENTITÉ DE RÉPLICA) sur full (complet) pour une table augmente le nombre de journaux WAL qui sont générés pour la base de données source. Cela se produit parce que toutes les colonnes sont alors journalisées dans WAL.

SQL Server

Si vous utilisez SQL Server, vérifiez que toutes les conditions préalables d'AWS DMS CDC sont remplies, en particulier les exigences de journalisation suivantes :

• Pour chaque table avec une clé primaire, exécutez cette requête pour activer MS-CDC : Remarque : si MS-Replication est déjà utilisé pour les sources sur site, passez cette étape. Cette étape est requise pour les sources basées sur le cloud.

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

• Exécutez cette requête pour activer MS-CDC pour chaque table avec des clés uniques, mais sans clé primaire. Remarque : cette étape est requise pour les sources sur site et dans le cloud.

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

• Exécutez cette requête pour activer MS-CDC pour chaque table sans clé primaire ou unique. Remarque : cette étape est requise pour les sources sur site et dans le cloud.

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

MySQL

Dans MySQL, les images de lignes dans les journaux binaires sont contrôlées par la variable système binlog_row_image. AWS DMS exige que binlog_row_image soit défini sur full (complet) et que binlog_format soit défini sur ROW (LIGNE). Cela signifie que MySQL enregistre toutes les colonnes dans l'image avant et l'image après. Assurez-vous donc que binlog_row_image est défini sur full (complet) pour la base de données source afin de confirmer le niveau de journalisation maximum dans les journaux binaires.

---

Informations connexes

Comment utiliser des filtres de source dans mes tâches AWS DMS ?

Utilisation du mappage de table pour spécifier les paramètres d'une tâche

Utilisation des filtres de source