내 AWS DMS 작업의 소스 필터 조건이 작동하지 않는 이유는 무엇입니까?

간략한 설명

소스 필터 조건이 AWS DMS 작업에서 예상대로 작동하지 않을 수 있는 몇 가지 이유가 있습니다. 예를 들어 사용 중인 엔진이 소스 필터 조건의 사용을 지원하지 않을 수 있습니다. 또는 기능의 제한 사항 중 하나 이상의 영향을 받을 수 있습니다.

해결 방법

엔진이 소스 필터링 기능을 지원하는지 확인

대부분의 AWS DMS 소스는 소스 필터링을 지원하지만 MongoDB 또는 Amazon DocumentDB와 같은 일부 소스는 이 기능을 지원하지 않습니다. 데이터 마이그레이션을 위한 소스에 대한 AWS DMS 설명서를 확인하여 사용 중인 소스 엔진에 제한 사항이 있는지 확인하십시오.

AWS DMS 소스 필터링 제한 사항 검토

소스 필터링과 관련된 몇 가지 제한 사항이 있습니다. 제한 사항을 검토하여 기능을 올바르게 사용하고 있는지 확인합니다.

• 필터는 오른쪽에서 왼쪽으로 쓰는 언어의 열을 계산하지 않습니다.
• 필터는 LOB(대용량 객체) 열에 적용할 수 없습니다.
• 필터는 생성 후 업데이트되지 않는 변경할 수 없는 열에만 적용할 수 있습니다. 생성 후 업데이트할 수 있는 변경 가능한 열에 소스 필터를 적용하면 소스 필터가 의도한 대로 작동하지 않을 수 있습니다.

전체 로드 중에 작동을 멈추는 필터 문제 해결

문제가 지속되면 소스 필터링이 작동을 중지하는 단계를 확인하십시오.

전체 로드 중에 필터링이 작동하지 않는 경우 다음 단계를 수행합니다.

1.    매핑 규칙의 대소문자 구분이 소스 엔진과 일치하는지 확인합니다. 예를 들어, Oracle 및 DB2의 개체 이름은 기본적으로 대문자입니다. 마찬가지로 PostgreSQL의 객체 이름은 소문자입니다. 필터링 조건에서 사용 중인 열이 소스 엔진에 필요한 대소문자 구분과 일치하는지 확인합니다.

2.    날짜 데이터 유형으로 필터링할 때 AWS DMS에 필요한 형식을 사용하고 있는지 확인합니다. 예를 들어, AWS DMS는 필터링에 YYYY-MM-DD 날짜 형식과 YYYY-MM-DD HH:MM:SS 시간 형식을 사용합니다.

3.    SOURCE_UNLOAD의 데뷔 로깅 수준 문제를 재현합니다. 그런 다음, AWS DMS가 소스에서 실행하는 쿼리를 캡처하여 데이터를 언로드합니다. 이는 소스 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

AWS DMS 작업은 ENTRY_DATE가 2022/01/01 이상인 행만 복제하는 매핑 규칙으로 생성됩니다.

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

따라서 레코드가 복제되지 않고 작업 로그에 다음 오류가 표시됩니다.

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

SOURCE_UNLOAD에 대해 디버그 로그가 켜져 있으므로 작업 로그는 AWS DMS가 소스 데이터베이스에서 실행하는 정확한 쿼리를 표시합니다.

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)

로그 출력에서 AWS DMS가 소스 데이터베이스에서 이 쿼리를 실행하는 것을 볼 수 있습니다.

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

AWS DMS가 예상하는 날짜 형식과 일치하지 않기 때문에 AWS DMS는 매핑 규칙에 제공된 날짜를 인식하지 못합니다. 따라서 예상 날짜 형식과 일치하도록 매핑 규칙을 수정합니다.

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

CDC 중에 작동을 멈추는 필터 문제 해결

참고: 생성 후 업데이트되지 않는 변경할 수 없는 열에만 필터를 적용하십시오. 변경 가능한 열에 필터를 추가하면 예기치 않은 결과가 발생할 수 있습니다.

필터링에 사용하는 열이 변경할 수 없는 열인 경우 필터링 문제는 CDC 단계에서만 발생합니다. 또한 이러한 문제는 UPDATES 또는 DELETES와 같은 특정 DML 문에서만 발생할 수 있습니다. 이 시나리오에서는 원본 테이블에서 충분한 로깅을 활성화했는지 확인합니다. 사용 중인 엔진에 따라 추가 로깅을 할당하려면 다음 단계를 따릅니다.

Oracle

Oracle은 보충 로깅을 사용하여 테이블 열에 추가 로그를 추가합니다. 필터링하는 열이 프라이머리 키 열이 아닌 경우 해당 열과 프라이머리 키 열에 대해 보충 로깅이 활성화되어 있는지 확인합니다.

이 예에서는 프라이머리 키 ID와 NAME 열에 대한 필터를 사용하여 TEST.LOGGING이라는 테이블을 복제합니다. 다음과 유사한 명령을 실행하여 로그 그룹 보충 로깅을 생성합니다.

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

이 예와 같이 테이블의 모든 열에 추가 로깅이 이미 추가되어 있으면 더 이상 로깅을 추가할 필요가 없습니다.

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

PostgreSQL

PostgreSQL은 REPLICA IDENTITY 속성을 사용하여 테이블의 로깅 수준을 구성합니다. REPLICA IDENTITY가 기본값으로 설정되면 PostgreSQL은 WAL 로그에 프라이머리 키 열의 이전 값을 기록합니다. 그러나 필터링에서 프라이머리 키가 아닌 열을 사용하는 경우 기본 로깅 수준이 DELETES에 충분하지 않을 수 있습니다. 이 시나리오에서는 AWS DMS 작업이 사용 중인 플러그인에 따라 다음 단계를 수행합니다. test_decoding을 사용하는 경우:

테이블에서 REPLICA IDENTITY를 full로 설정합니다. 이 단계를 완료하지 않으면 AWS DMS가 모든 삭제를 대상 테이블로 보낼 수 있습니다.

ALTER TABLE tablename REPLICA IDENTITY FULL;

pglogical을 사용하는 경우:

테이블이 복제 세트에 추가된 후 REPLICA IDENTITY를 full로 설정합니다. 이는 pglogical에 REPLICA IDENTITY가 full인 경우 테이블이 복제 세트에 추가되는 것을 방지하는 제한이 있기 때문입니다.

ALTER TABLE tablename REPLICA IDENTITY FULL;

참고: 테이블에서 REPLICA IDENTITY를 full로 설정하면 소스 데이터베이스에서 생성되는 WAL 로그 수가 증가합니다. 이러한 현상은 모든 열이 WAL에 기록되기 때문에 발생합니다.

SQL Server

SQL Server를 사용하는 경우 모든 AWS DMS CDC 사전 요구 사항, 특히 다음 로깅 요구 사항이 충족되는지 확인합니다.

• 프라이머리 키가 있는 모든 테이블에 대해 다음 쿼리를 실행하여 MS-CDC를 켭니다. 참고: MS-Replication이 이미 온프레미스 소스에 사용되는 경우 이 단계를 건너뜁니다. 이 단계는 클라우드 기반 소스에 필요합니다.

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

• 이 쿼리를 실행하여 고유 키가 있지만 프라이머리 키가 없는 모든 테이블에 대해 MS-CDC를 켭니다. 참고: 이 단계는 온프레미스 및 클라우드 기반 소스 모두에 필요합니다.

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

• 이 쿼리를 실행하여 프라이머리 키 또는 고유 키가 없는 모든 테이블에 대해 MS-CDC를 켭니다. 참고: 이 단계는 온프레미스 및 클라우드 기반 소스 모두에 필요합니다.

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

MySQL

MySQL에서 binlogs의 행 이미지는 binlog_row_image 시스템 변수에 의해 제어됩니다. AWS DMS를 사용하려면 binlog_row_image가 full로 설정되고 binlog_format이 ROW로 설정되어야 합니다. 즉, MySQL은 이전 이미지와 이후 이미지 모두에 모든 열을 기록합니다. 따라서 소스 데이터베이스에서 binlog_row_image를 full로 설정하여 binlogs의 최대 로깅 수준을 확인해야 합니다.

---

관련 정보

AWS DMS 태스크에서 소스 필터를 사용하려면 어떻게 해야 합니까?

테이블 매핑을 사용하여 작업 설정 지정

소스 필터 사용