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

Breve descrizione

Esistono diversi motivi per cui le condizioni del filtro di origine potrebbero non funzionare come previsto in un'attività AWS DMS. Ad esempio, il motore che stai utilizzando potrebbe non supportare l'uso delle condizioni del filtro di origine. In alternativa, potresti essere interessato da una o più limitazioni della funzionalità.

Risoluzione

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

Sebbene la maggior parte delle fonti AWS DMS supporti il filtro del codice di origine, alcune fonti come MongoDB o Amazon DocumentDB non supportano questa funzionalità. Consulta la documentazione di AWS DMS sulle fonti per la migrazione dei dati per verificare se ci sono limitazioni al motore di origine che stai utilizzando.

Esamina le limitazioni del filtro di origine di AWS DMS

Esistono diverse limitazioni associate al filtro di origine. Esamina le limitazioni per verificare di utilizzare correttamente la funzione:

• I filtri non calcolano le colonne delle lingue da destra a sinistra.
• I filtri non possono essere applicati alle colonne degli oggetti di grandi dimensioni (LOB).
• I filtri possono essere applicati solo a colonne non modificabili che non vengono aggiornate dopo la creazione. Se applichi filtri di origine a colonne modificabili che possono essere aggiornate dopo la creazione, i filtri di origine potrebbero non funzionare come previsto.

Risoluzione dei problemi relativi ai filtri che smettono di funzionare a pieno carico

Se il problema persiste, verifica in quale fase il filtro sorgente smette di funzionare.

Se il filtro non funziona durante il caricamento completo, segui la seguente procedura:

1.    Verifica che le distinzioni tra maiuscole e minuscole nelle regole di mappatura corrispondano al motore di origine. Ad esempio, i nomi degli oggetti in Oracle e DB2 sono maiuscoli per impostazione predefinita. Allo stesso modo, i nomi degli oggetti in PostgreSQL sono minuscoli. Assicurati che la colonna che stai utilizzando nella tua condizione di filtro corrisponda a qualsiasi distinzione tra maiuscole e minuscole richiesta dal tuo motore di origine.

2.    Quando filtri con tipi di dati di data, accertati di utilizzare i formati richiesti da AWS DMS. Ad esempio, AWS DMS utilizza il formato della data AAAA-MM-GG e il formato dell'ora AAAA-MM-GG HH:MM:SS per il filtraggio.

3.    Riprodurre il problema con il livello di registrazione di inizio su SOURCE_UNLOAD. Quindi, acquisisci la query eseguita da AWS DMS sull'origine per scaricare i dati. Questo è un esempio di un problema di filtro su una tabella Oracle di origine.

Dettagli della tabella:

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

Viene creata un'attività AWS DMS con le regole di mappatura per replicare solo le righe con ENTRY_DATE maggiore o uguale al 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"
            }
          ]
        }
      ]
    }
  ]
}

Pertanto, nessun record viene replicato e i registri delle attività mostrano questi errori:

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

Poiché i registri di debug sono attivati per SOURCE_UNLOAD, i registri delle attività mostrano la query esatta eseguita da AWS DMS sul database di origine:

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)

Nell'output del registro, puoi vedere che AWS DMS esegue questa 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 fornita nelle regole di mappatura perché non corrisponde al formato della data previsto da AWS DMS. Modifica quindi le regole di mappatura in modo che corrispondano al formato della data previsto:

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

Risoluzione dei problemi relativi ai filtri che smettono di funzionare durante la fase CDC

Nota: applica i filtri solo alle colonne non modificabili che non vengono aggiornate dopo la creazione. L'aggiunta di filtri su colonne modificabili può causare risultati imprevisti.

Se le colonne utilizzate nel filtraggio sono colonne non modificabili, è possibile notare che i problemi di filtro si verificano solo durante la fase CDC. Inoltre, questi problemi potrebbero verificarsi solo su istruzioni DML specifiche come UPDATES o DELETES. In questo contesto, assicurarsi di aver abilitato una registrazione sufficiente nella tabella di origine. Segui questi passaggi per assegnare ulteriori registrazioni, a seconda del motore che stai utilizzando:

Oracle

Oracle utilizza la registrazione supplementare per aggiungere ulteriori registri sulle colonne della tabella. Se la colonna che stai filtrando non è una colonna di chiave primaria, assicurati che la registrazione supplementare sia attivata per quella colonna e per le colonne della chiave primaria.

Questo esempio replica una tabella denominata TEST.LOGGING con un ID di chiave primaria e un filtro sulla colonna NAME. Esegui un comando simile al seguente per creare la registrazione supplementare del gruppo di registri:

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 di una tabella, come in questo esempio, non è necessario aggiungere altre registrazioni.

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 REPLICA IDENTITY è impostato sul valore predefinito, PostgreSQL registra i valori precedenti delle colonne della chiave primaria nei registri WAL. Tuttavia, il livello di registrazione predefinito potrebbe non essere sufficiente per DELETES quando si utilizza una colonna di chiave non primaria nel filtro. In questo contesto, effettuare le seguenti operazioni a seconda del plugin utilizzato dall'attività AWS DMS: se viene utilizzato test_decoding:

Impostare REPLICA IDENTITY su full nella tabella. Se non completi questo passaggio, AWS DMS potrebbe inviare tutte le eliminazioni alla tabella di destinazione:

ALTER TABLE tablename REPLICA IDENTITY FULL;

Se si utilizza pglogical:

Imposta REPLICA IDENTITY su full dopo l'aggiunta della tabella al set di repliche. Questo perché pglogical ha una limitazione che impedisce l'aggiunta della tabella a un set di replica se REPLICA IDENTITY è full.

ALTER TABLE tablename REPLICA IDENTITY FULL;

Nota: l'impostazione di REPLICA IDENTITY su full in una tabella aumenta il numero di registri WAL generati nel database di origine. Questo accade perché tutte le colonne vengono quindi registrate in WAL.

SQL Server

Se utilizzi SQL Server, verifica che siano soddisfatti tutti i prerequisiti del CDC di AWS DMS, in particolare i seguenti requisiti di registrazione:

• Per ogni tabella con una chiave primaria, esegui questa query per attivare MS-CDC: Nota: se la replica MS è già utilizzata per le origini locali, ignora questo passaggio. Questo passaggio è necessario per le fonti basate su 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

• Esegui questa query per attivare MS-CDC per ogni tabella con chiavi univoche ma nessuna chiave primaria. Nota: questo passaggio è necessario sia per le origini on-premise che per quelle basate su 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

• Esegui questa query per attivare MS-CDC per ogni tabella senza chiavi primarie o univoche/ Nota: questo passaggio è necessario sia per le origini on-premise che per quelle basate su cloud.

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

MySQL

In MySQL, le immagini di riga nei binlogs sono controllate dalla variabile di sistema binlog_row_image. AWS DMS richiede che binlog_row_image sia impostato su full e binlog_format sia impostato su ROW. Ciò significa che MySQL registra tutte le colonne sia nell'immagine precedente che in quella successiva. Quindi, assicurati che binlog_row_image sia impostato su full nel database di origine per confermare il livello massimo di registrazione nei binlogs.

---

Informazioni correlate

In che modo posso utilizzare i filtri di origine nelle attività AWS DMS?

Utilizzo del mapping delle tabelle per specificare le impostazioni delle attività

Utilizzo dei filtri sorgente