¿Por qué han dejado de funcionar las condiciones de filtrado de origen de mi tarea de AWS DMS?

Solución

Comprobación de si el motor es compatible con la característica de filtrado de origen

La mayoría de los orígenes de AWS DMS son compatibles con el filtrado de origen. Sin embargo, MongoDB o Amazon DocumentDB con compatibilidad con MongoDB no admiten la característica de filtrado de origen. Para obtener más información, consulte Sources for data migration.

Las siguientes limitaciones pueden afectar al filtrado de origen:

• Los filtros no calculan las columnas en el caso de los idiomas que se escriben de derecha a izquierda.
• No puede aplicar filtros a las columnas de objetos grandes (LOB).
• Solo puede aplicar filtros a las columnas fijas que no se pueden actualizar una vez creadas. Si aplica filtros de origen a columnas fijas que se pueden actualizar una vez creadas, es posible que los filtros de origen no funcionen.

Solución de problemas cuando los filtros no funcionan durante la carga completa

Determine la fase en la que no funciona el filtrado de origen.

Si el filtrado de origen no funciona durante la carga completa, tome estas medidas:

• Confirme que la distinción entre mayúsculas y minúsculas en las reglas de asignación coincida con el motor de origen.
• Cuando filtre los tipos de datos de fecha, utilice los formatos que requiere AWS DMS.
• Ejecute el nivel de registro de depuración en SOURCE_UNLOAD para reproducir el problema. A continuación, capture la consulta que AWS DMS ejecuta en el origen para descargar los datos.

Ejemplo de un problema de filtrado en una tabla de origen de Oracle:

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

Cree una tarea de AWS DMS con reglas de asignación configuradas para replicar solo las filas que tengan un valor en ENTRY_DATE igual o posterior al 01/01/2022.

Ejemplo de tarea:

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

Para asegurarse de que no se haya replicado ningún registro y de que los errores aparezcan en los registros de tareas, ejecute la siguiente consulta:

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

Dado que los registros de depuración están activados para SOURCE_UNLOAD, los registros de tareas muestran exactamente la consulta que AWS DMS ejecuta en la base de datos de origen.

Ejemplo de consulta:

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)

En el siguiente resultado de registro, AWS DMS ejecuta la consulta en la base de datos de origen:

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

AWS DMS no reconoce la fecha en las reglas de asignación. Por lo tanto, la fecha no coincide con el formato de fecha que espera AWS DMS.

Para modificar las reglas de asignación de modo que coincidan con el formato de fecha esperado, ejecute la siguiente consulta:

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

Solución de problemas por filtros que no funcionan durante la captura de datos de cambios (CDC)

Cuando filtra columnas fijas, los problemas de filtrado solo ocurren durante la fase de CDC. Los problemas pueden ocurrir solo en instrucciones específicas del lenguaje de manipulación de datos (DML), como UPDATES o DELETES. Asegúrese de activar suficientes registros en la tabla de origen.

Para asignar registros adicionales, utilice uno de Oracle, PostgreSQL o Microsoft SQL Server.

Oracle

Oracle usa registros complementarios para agregar registros adicionales en las columnas de tablas. Si la columna que está filtrando no es una columna de clave principal, active los registros complementarios para la columna y las columnas de claves principales.

En el siguiente ejemplo se replica una tabla denominada TEST.LOGGING que tiene un identificador de clave principal y un filtro en la columna NAME. Para crear los registros complementarios del grupo de registros, ejecute el siguiente comando:

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

Si ya se han agregado registros complementarios en todas las columnas de la tabla, no añada más registros.

Ejemplo con registros complementarios ya agregados:

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

PostgreSQL

PostgreSQL usa la propiedad REPLICA IDENTITY para configurar el nivel de registro para una tabla. Si define REPLICA IDENTITY como DEFAULT, PostgreSQL registrará los valores anteriores de las columnas de la clave principal en los registros de escritura anticipada (WAL). Sin embargo, si usa una columna de clave no principal, es posible que el nivel de registro predeterminado no sea suficiente para las eliminaciones.

Asegúrese de que la tarea de AWS DMS utilice el complemento configurado para una de las siguientes propiedades:

Si usa test_decoding, defina REPLICA IDENTITY como FULL:

ALTER TABLE tablename REPLICA IDENTITY FULL;

Nota: Si no define REPLICA IDENTITY como FULL, AWS DMS podría enviar todas las eliminaciones a la tabla de destino.

Si usa pglogical, defina REPLICA IDENTITY como FULL después de añadir la tabla al conjunto de replicación:

ALTER TABLE tablename REPLICA IDENTITY FULL;

Nota: Si define REPLICA IDENTITY como FULL, pglogical incluirá una limitación para que no pueda añadir una tabla a un conjunto de replicación. También estará aumentando la cantidad de registros de WAL que se generan en la base de datos de origen. Si la cantidad de registros de WAL aumenta, todas las columnas se registrarán en WAL.

Microsoft SQL Server

Compruebe si cumple los siguientes requisitos de registro de AWS DMS CDC para activar MS-CDC.

Por cada tabla que tenga una clave principal, ejecute la siguiente consulta:

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 consulta anterior es obligatoria en el caso de los orígenes basados en la nube.

Por cada tabla que tenga claves únicas y ninguna clave principal, ejecute la siguiente consulta:

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 consulta anterior es obligatoria tanto para los orígenes locales como para los basados en la nube. Si usa MS-Replication para los orígenes locales, no hace falta que ejecute la consulta anterior.

Por cada tabla que no tenga claves principales ni únicas, ejecute la siguiente consulta:

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

Nota: La consulta anterior requiere tanto orígenes locales como basados en la nube.

MySQL

En MySQL, la variable de sistema binlog_row_image controla las imágenes de fila en binlogs. Para obtener más información, consulte binlog_row_image en el sitio web de MySQL. AWS DMS require que defina binlog_row_image como FULL y binlog_format como ROW.

MySQL registra todas las columnas tanto en la imagen anterior como en la posterior. Para confirmar el nivel máximo de registro en los binlogs, debe configurar binlog_row_image como FULL en la base de datos de origen.

Información relacionada

¿Cómo utilizo los filtros de origen en mis tareas de AWS DMS?

Using table mapping to specify task settings

Using source filters