Por que as condições do filtro de origem na minha tarefa do AWS DMS não estão funcionando?

Descrição breve

Há vários motivos pelos quais as condições do filtro de origem podem não funcionar conforme o esperado em uma tarefa do AWS DMS. Por exemplo, o mecanismo que você está usando pode não oferecer suporte ao uso de condições de filtro de origem. Ou você pode ser afetado por uma ou mais das limitações do recurso.

Resolução

Verificar se o seu mecanismo oferece suporte ao recurso de filtragem de origens

Embora a maioria das fontes do AWS DMS ofereça suporte à filtragem de origens, algumas origens, como o MongoDB ou o Amazon DocumentDB, não são compatíveis com este recurso. Verifique a documentação do AWS DMS sobre Fontes para migração de dados para confirmar se há limitações para o mecanismo de origem que você está usando.

Analisar as limitações de filtragem de origens do AWS

Existem várias limitações associadas à filtragem de origens. Revise as limitações para verificar se você está usando o recurso corretamente:

• Os filtros não calculam colunas de idiomas com orientação de texto da direita para a esquerda.
• Os filtros não podem ser aplicados a colunas de objetos grandes (LOB).
• Os filtros podem ser aplicados somente a colunas imutáveis que não são atualizadas após a criação. Se você aplicar filtros de origens a colunas mutáveis que podem ser atualizadas após a criação, os filtros de origens podem não funcionar como pretendido.

Solucionar problemas de filtros que param de funcionar em condições de carga total

Se o problema persistir, verifique em que fase a filtragem de origens deixa de funcionar.

Se a filtragem não funcionar sob carga total, siga estas etapas:

1.    Confirme se qualquer diferenciação entre maiúsculas e minúsculas nas regras de mapeamento corresponde ao mecanismo. Por exemplo, os nomes de objetos no Oracle e no DB2 são em maiúsculas, por padrão. Da mesma forma, os nomes de objetos no PostgreSQL usam letras minúsculas. Certifique-se de que a coluna que você está usando em sua condição de filtragem corresponda a qualquer distinção entre maiúsculas e minúsculas exigida pelo mecanismo de origem.

2.    Ao filtrar com tipos de dados de data, verifique se você está usando os formatos exigidos pelo AWS DMS. Por exemplo, o AWS DMS usa o formato de data AAAA-MM-DD e o formato de hora AAAA-MM-DD HH:MM:SS para filtragem.

3.    Reproduza o problema com o nível de registro inicial em SOURCE_UNLOAD. Em seguida, capture a consulta que o AWS DMS executa na origem para descarregar os dados. Este é um exemplo de um problema de filtragem em uma tabela de origem Oracle.

Detalhes da tabela:

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

Uma tarefa do AWS DMS é criada com as regras de mapeamento para replicar somente linhas com ENTRY_DATE maior ou igual a 1/1/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"
            }
          ]
        }
      ]
    }
  ]
}

Portanto, nenhum registro é replicado e os logs de tarefas mostram os seguintes erros:

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

Como os logs de depuração estão ativados para SOURCE_UNLOAD, os logs de tarefas mostram a consulta exata que o AWS DMS executa no banco de dados de origem:

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)

Na saída do log, é possível ver que o AWS DMS executa essa consulta no banco de dados de origem:

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

O AWS DMS não reconhece a data fornecida nas regras de mapeamento porque ela não corresponde ao formato de data esperado pelo AWS DMS. Portanto, modifique as regras de mapeamento para corresponder ao formato de data esperado:

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

Solucionar problemas de filtros que param de funcionar durante o CDC

Observação: aplique filtros somente a colunas imutáveis que não são atualizadas após a criação. Adicionar filtros em colunas alteráveis pode causar resultados inesperados.

Se as colunas usadas na filtragem forem colunas imutáveis, será possível perceber que os problemas de filtragem ocorrem somente durante a fase CDC. Além disso, esses problemas podem ocorrer somente em instruções DML específicas, como UPDATES ou DELETES. Nesse cenário, verifique se você ativou registro em log suficiente na tabela de origem. Siga estas etapas para alocar registros em log adicionais, dependendo do mecanismo que você está usando:

Oracle

A Oracle usa registro em log suplementar para adicionar logs adicionais nas colunas da tabela. Se a coluna que você está filtrando não for uma coluna de chave primária, certifique-se de que o registro suplementar esteja ativado para essa coluna e para as colunas de chave primária.

Este exemplo replica uma tabela chamada TEST.LOGGING com um ID de chave primária e um filtro na coluna NAME. Execute um comando semelhante ao seguinte para criar o log suplementar do grupo de logs:

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

Se o registro suplementar já tiver sido adicionado em todas as colunas de uma tabela, como neste exemplo, não será necessário adicionar mais registros.

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

PostgreSQL

O PostgreSQL usa a propriedade REPLICA IDENTITY para configurar o nível de registro de uma tabela. Quando REPLICA IDENTITY é definido como default, o PostgreSQL registra os valores antigos das colunas da chave primária nos logs WAL. Porém, o nível de registro padrão pode não ser suficiente para DELETES quando uma coluna de chave não primária é usada na filtragem. Nesse cenário, execute as seguintes etapas, dependendo do plug-in usado pela tarefa do AWS DMS: Se test_decoding for usado:

Defina REPLICA IDENTITY como full na tabela. Se você não concluir essa etapa, o AWS DMS poderá enviar todas as exclusões para a tabela de destino:

ALTER TABLE tablename REPLICA IDENTITY FULL;

Se pglogical for usado:

Defina REPLICA IDENTITY como full depois que a tabela for adicionada ao conjunto de replicação. Isso ocorre porque pglogical tem uma limitação que impede que a tabela seja adicionada a um conjunto de replicação se REPLICA IDENTITY estiver cheia.

ALTER TABLE tablename REPLICA IDENTITY FULL;

Observação: definir REPLICA IDENTITY como full em uma tabela aumenta o número de logs WAL gerados no banco de dados de origem. Isso acontece porque todas as colunas são então registradas no WAL.

SQL Server

Se você estiver usando o SQL Server, verifique se todos os pré-requisitos do CDC do AWS DMS foram atendidos, especificamente estes requisitos de registro em log:

• Para cada tabela com uma chave primária, execute esta consulta para ativar o MS-CDC: Observação: se a replicação MS já estiver sendo usada para origens on-premises, ignore esta etapa. Essa etapa é necessária para origens baseadas na nuvem.

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

• Execute essa consulta para ativar o MS-CDC para cada tabela com chaves exclusivas, mas sem chave primária. Observação: esta etapa é necessária para origens on-premises e baseadas na nuvem.

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

• Execute esta consulta para ativar o MS-CDC para cada tabela sem chaves primárias ou exclusivas/ Observação: esta etapa é necessária para origens on-premises e baseadas na nuvem.

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

MySQL

No MySQL, as imagens de linha em logs binários são controladas pela variável de sistema binlog_row_image. O AWS DMS exige que binlog_row_image esteja definido como full e binlog_format esteja definido como ROW. Isso significa que o MySQL registra em log todas as colunas na imagem anterior e na imagem posterior. Portanto, certifique-se de que binlog_row_image esteja definido como full no banco de dados de origem para confirmar o nível máximo de registro nos logs binários.

---

Informações relacionadas

Como uso os filtros de origens em minhas tarefas do AWS DMS?

Usar o mapeamento de tabelas para especificar configurações de tarefas

Usar filtros de origem