Perché le condizioni del filtro di origine nella mia attività AWS DMS non funzionano più?

Risoluzione

Verifica se il tuo motore supporta la funzione di filtro del codice sorgente

La maggior parte delle sorgenti AWS DMS supporta il filtraggio delle fonti. Tuttavia, MongoDB o Amazon DocumentDB compatibili con MongoDB non supportano la funzionalità di filtro del codice sorgente. Per ulteriori informazioni, consulta Sorgenti per la migrazione dei dati.

Le seguenti limitazioni potrebbero influire sul filtraggio delle fonti:

• I filtri non calcolano colonne di lingue da destra a sinistra.
• Non è possibile applicare filtri alle colonne LOB (Large Object).
• Puoi applicare filtri solo a colonne fisse che non puoi aggiornare dopo averle create. Se applichi filtri di origine a colonne fisse che puoi aggiornare dopo averle create, i filtri di origine potrebbero non funzionare.

Risolvi i problemi relativi ai filtri che non funzionano a pieno carico

Determina in quale fase non funziona il filtro alla fonte.

Se il filtro del codice sorgente non funziona durante il caricamento completo, esegui le seguenti azioni:

• Verifica che la distinzione tra maiuscole e minuscole nelle regole di mappatura corrisponda al motore di origine.
• Quando filtri i tipi di dati relativi alle date, utilizza i formati richiesti da AWS DMS.
• Esegui il livello di registrazione del debug su SOURCE_UNLOAD per riprodurre il problema. Quindi, acquisisci la query che AWS DMS esegue sull'origine per scaricare i dati.

Esempio di problema di filtro su una tabella Oracle di origine:

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

Crea un'attività AWS DMS con regole di mappatura configurate per replicare solo le righe con ENTRY_DATE maggiore o uguale a 01/01/2022.

Attività di esempio:

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

Per assicurarti che nessun record venga replicato e che gli errori vengano visualizzati nei log delle attività, esegui la seguente query:

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

Poiché i log di debug sono attivati per SOURCE_UNLOAD, i log delle attività mostrano l'esatta query eseguita da AWS DMS sul database di origine.

Query di esempio:

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)

Nel seguente output di log, AWS DMS esegue la query sul database di origine:

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

AWS DMS non riconosce la data nelle regole di mappatura. Pertanto, la data non corrisponde al formato di data previsto da AWS DMS.

Per modificare le regole di mappatura in modo che corrispondano al formato di data previsto, esegui la seguente query:

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

Risolvi i problemi relativi ai filtri che non funzionano durante l'acquisizione dei dati di modifica (CDC)

Quando si filtrano le colonne fisse, i problemi di filtro si verificano solo durante la fase CDC. I problemi possono verificarsi solo su specifiche istruzioni DML (Data Manipulation Language), come UPDATES o DELETES. Assicurati di attivare una registrazione sufficiente nella tabella dei sorgenti.

Per allocare registrazioni aggiuntive, usa una registrazione Oracle, PostgreSQL o Microsoft SQL Server.

Oracle

Oracle utilizza la registrazione supplementare per aggiungere altri log nelle colonne della tabella. Se la colonna filtrata non è una colonna chiave primaria, attiva la registrazione supplementare per la colonna e le colonne chiave primaria.

L'esempio seguente replica una tabella denominata TEST.LOGGING con un ID di chiave primaria e un filtro nella colonna NAME. Per creare la registrazione supplementare del gruppo di log, esegui il comando seguente:

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

Se la registrazione supplementare è già stata aggiunta a tutte le colonne della tabella, non aggiungerne altre.

Esempio con registrazione supplementare già aggiunta:

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

PostgreSQL

PostgreSQL utilizza la proprietà REPLICA IDENTITY per configurare il livello di registrazione per una tabella. Quando si imposta REPLICA IDENTITY su DEFAULT, PostgreSQL registra i vecchi valori delle colonne della chiave primaria nei log write-ahead (WAL). Tuttavia, quando si utilizza una colonna chiave non primaria, il livello di registrazione predefinito potrebbe non essere sufficiente per le eliminazioni.

Assicurati che l'attività AWS DMS utilizzi il plug-in impostato su una delle seguenti proprietà:

Se usi test_decoding, imposta REPLICA IDENTITY su FULL:

ALTER TABLE tablename REPLICA IDENTITY FULL;

Nota: Se non imposti REPLICA IDENTITY su FULL, AWS DMS potrebbe inviare tutte le eliminazioni alla tabella di destinazione.

Se usi pglogical, imposta REPLICA IDENTITY su FULL dopo aver aggiunto la tabella al set di replica:

ALTER TABLE tablename REPLICA IDENTITY FULL;

Nota: Quando si imposta REPLICA IDENTITY su FULL, pglogical include una limitazione in modo che non sia possibile aggiungere una tabella a un set di replica. Si aumenta anche il numero di log WAL generati nel database di origine. Quando il numero di log WAL aumenta, tutte le colonne vengono registrate in WAL.

Microsoft SQL Server

Verifica di soddisfare tutti i seguenti requisiti di registrazione AWS DMS CDC per attivare MS-CDC.

Per ogni tabella con una chiave primaria, esegui la seguente query:

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

Nota: La query precedente è obbligatoria per le fonti basate su cloud.

Per ogni tabella con chiavi univoche ma nessuna chiave primaria, esegui la seguente query:

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

Nota: La query precedente è obbligatoria sia per le fonti locali che per quelle basate sul cloud. Se si utilizza MS-Replication per origini locali, non è necessario eseguire la query precedente.

Per ogni tabella che non ha chiavi primarie o univoche, esegui la seguente query:

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

Nota: La query precedente richiede sia fonti locali che basate sul cloud.

MySQL

In MySQL, la variabile di sistema binlog_row_image controlla le immagini delle righe nei binlog. Per ulteriori informazioni, consulta binlog_row_image sul sito Web MySQL. AWS DMS richiede di impostare binlog_row_image su FULL e binlog_format su ROW.

MySQL registra tutte le colonne sia nell'immagine precedente che in quella successiva. Per confermare il livello massimo di registrazione nei binlog, è necessario impostare binlog_row_image su FULL nel database di origine.

Informazioni correlate

How do I use source filters in my AWS DMS tasks?

Using table mapping to specify task settings

Utilizzo dei filtri di origine