¿Por qué no funcionan las condiciones del filtro de origen de mi tarea de AWS DMS?

8 minutos de lectura
0

He configurado condiciones de filtro de origen en mi tarea de AWS Database Migration Service (AWS DMS), pero no funcionan correctamente. ¿Cómo puedo solucionar problemas con las condiciones del filtro de origen en mi tarea de AWS DMS?

Descripción corta

Existen varios motivos por los que las condiciones del filtro de origen pueden no funcionar como se esperaba en una tarea de AWS DMS. Por ejemplo, es posible que el motor que está utilizando no admita el uso de condiciones de filtro de origen. O bien, podría verse afectado por una o más de las limitaciones de la función.

Resolución

Comprobar si el motor admite la función de filtrado de orígenes

Aunque la mayoría de las orígenes de AWS DMS admiten el filtrado de orígenes, algunos orígenes como MongoDB o Amazon DocumentDB, no admiten esta función. Consulte la documentación de AWS DMS acerca de Orígenes para la migración de datos para confirmar si hay limitaciones en el motor de origen que está utilizando.

Revisar las limitaciones de filtrado de orígenes de AWS DMS

Existen varias limitaciones asociadas con el filtrado de orígenes. Revise las limitaciones para comprobar que está utilizando la función correctamente:

  • Los filtros no calculan columnas de idiomas de derecha a izquierda.
  • Los filtros no se pueden aplicar a columnas de objetos grandes (large object, LOB).
  • Los filtros solo se pueden aplicar a columnas inmutables que no se actualizan después de crearlas. Si aplica filtros de origen a columnas mutables que se pueden actualizar después de la creación, es posible que los filtros de origen no funcionen como se esperaba.

Solucionar problemas de filtros que dejan de funcionar durante la carga completa

Si el problema persiste, compruebe en qué fase deja de funcionar el filtrado de orígenes.

Si el filtrado no funciona durante la carga completa, siga estos pasos:

1.    Confirme que la distinción entre mayúsculas y minúsculas en las reglas de asignación coincida con la del motor. Por ejemplo, los nombres de objetos en Oracle y DB2 están en mayúsculas, de forma predeterminada. Del mismo modo, los nombres de objetos en PostgreSQL están en minúsculas. Asegúrese de que la columna que está utilizando en su condición de filtrado coincida con cualquier distinción entre mayúsculas y minúsculas requerida por el motor de origen.

2.    Al filtrar con tipos de datos de fecha, compruebe que está utilizando los formatos que requiere AWS DMS. Por ejemplo, AWS DMS utiliza el formato de fecha AAAA-MM-DD y el formato de hora AAAA-MM-DD HH:MM:SS para el filtrado.

3.    Reproduzca el problema con el nivel de registro de depuración en SOURCE_UNLOAD. A continuación, capture la consulta que ejecuta AWS DMS en el origen para descargar los datos. Este es un ejemplo de un problema de filtrado en una tabla de Oracle de origen.

Detalles de la tabla:

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

Se crea una tarea de AWS DMS con las reglas de asignación para replicar solo las filas con un valor de ENTRY_DATE mayor o igual que 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"
            }
          ]
        }
      ]
    }
  ]
}

Por lo tanto, no se replican registros y los registros de tareas muestran estos errores:

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

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

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 resultado del registro, puede ver que AWS DMS ejecuta esta 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 proporcionada en las reglas de asignación porque no coincide con el formato de fecha que espera AWS DMS. Así que debe modificar las reglas de asignación para que coincidan con el formato de fecha esperado:

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

Solucionar problemas de filtros que dejan de funcionar durante la CDC

Nota: Aplique filtros solo a columnas inmutables que no se actualicen tras la creación. Agregar filtros en columnas modificables puede provocar resultados inesperados.

Si las columnas que utiliza en el filtrado son columnas inmutables, puede observar que los problemas de filtrado solo ocurren durante la fase de CDC. Además, estos problemas pueden ocurrir solo en instrucciones DML específicas, como UPDATES o DELETES. En este escenario, asegúrese de haber habilitado el registro suficiente en la tabla de origen. Siga estos pasos para asignar registros adicionales, según el motor que esté utilizando:

Oracle

Oracle utiliza el registro complementario para agregar registros adicionales en las columnas de la tabla. Si la columna que está filtrando no es una columna de clave principal, asegúrese de que el registro complementario esté activado para esa columna y las columnas de clave principal.

En este ejemplo se replica una tabla denominada TEST.LOGGING con un ID de clave principal y un filtro en la columna NAME. Ejecute un comando similar al siguiente para crear el registro complementario del grupo de registros:

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

Si ya se han agregado registros suplementarios en todas las columnas de una tabla, como en este ejemplo, no es necesario agregar más registros.

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

PostgreSQL

PostgreSQL usa la propiedad REPLICA IDENTITY para configurar el nivel de registro de una tabla. Cuando REPLICA IDENTITY se establece en el valor predeterminado, PostgreSQL registra los valores antiguos de las columnas de clave principal en los registros de WAL. Sin embargo, es posible que el nivel de registro predeterminado no sea suficiente para DELETES cuando se utiliza una columna de clave no principal en el filtrado. En este escenario, lleve a cabo los siguientes pasos según el complemento que utilice la tarea de AWS DMS: Si se usa test_decoding:

Establezca el valor de REPLICA IDENTITY como full (completo) en la tabla. Si no completa este paso, AWS DMS podría enviar todas las eliminaciones a la tabla de destino:

ALTER TABLE tablename REPLICA IDENTITY FULL;

Si se usa pglogical:

Establezca REPLICA IDENTITY como full (completo) después de agregar la tabla al conjunto de replicación. Esto se debe a que pglogical tiene una limitación que impide que la tabla se agregue a un conjunto de replicación si el valor de REPLICA IDENTITY es full (completo).

ALTER TABLE tablename REPLICA IDENTITY FULL;

Nota: Si se establece el valor de REPLICA IDENTITY en full (completo) en una tabla, aumenta el número de registros de WAL que se generan en la base de datos de origen. Esto ocurre porque todas las columnas se registran en WAL.

SQL Server

Si utiliza SQL Server, compruebe que se cumplan todos los requisitos previos de CDC de AWS DMS, específicamente los siguientes requisitos de registro:

  • Para cada tabla con una clave principal, ejecute esta consulta para activar MS-CDC: Nota: Si la replicación de MS ya se usa para orígenes locales, omita este paso. Este paso es obligatorio para orígenes basados en la nube.
exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL,
@supports_net_changes = 1
GO
  • Ejecute esta consulta para activar MS-CDC en todas las tablas con claves únicas pero sin clave principal. Nota: Este paso es obligatorio tanto para orígenes locales como para orígenes basados en la nube.
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
  • Ejecute esta consulta para activar MS-CDC en todas las tablas sin claves principales o únicas/ Nota: Este paso es obligatorio tanto para orígenes locales como para orígenes basados en la nube.
exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO

MySQL

En MySQL, las imágenes de fila en binlogs se controlan mediante la variable de sistema binlog_row_image. AWS DMS requiere que el valor binlog_row_image esté establecido en full (completo) y binlog_format en ROW. Esto significa que MySQL registra todas las columnas tanto en la imagen anterior como en la imagen posterior. Por lo tanto, asegúrese de que el valor de binlog_row_image esté establecido en full (completo) en la base de datos de origen para confirmar el nivel máximo de registro en los binlogs.


Información relacionada

¿Cómo se usan los filtros de origen en las tareas de AWS DMS?

Using table mapping to specify task settings (Usar la asignación de tablas para especificar la configuración de tareas)

Using source filters (Uso de filtros de origen)

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace 2 años