AWS DMS タスクのソースフィルタ条件が機能しなくなっているのはなぜですか?

解決策

エンジンがソースフィルタリング機能をサポートしているかどうかを確認する

AWS DMS ソースの多くはソースフィルタリングに対応しています。ただし、MongoDB または MongoDB と互換性がある Amazon DocumentDB では、ソースフィルタリング機能に対応していません。詳細については、「Sources for data migration」を参照してください。

次の制限がソースフィルタリングに影響する可能性があります。

• フィルタは、右から左に記述する言語の列を計算しません。
• フィルタは、ラージオブジェクト (LOB) 列には適用できません。
• フィルタは、作成後に更新できない固定列にのみ適用できます。作成後に更新できる固定列にソースフィルターを適用すると、ソースフィルターが機能しない可能性があります。

フルロード時に機能しないフィルターのトラブルシューティング

どのフェーズでソースフィルタリングが機能しないのかを特定します。

フルロード中にソースフィルタリングが機能しない場合は、次の操作を実行します。

• マッピングルールの大文字と小文字の区別がソースエンジンと一致していることを確認します。
• 日付データタイプをフィルタリングするときは、AWS DMS が必要とする形式を使用します。
• 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

ENTRY_DATE が 2022 年 1 月 1 日以上の行のみをレプリケートするように設定したマッピングルールで、AWS DMS タスクを作成します。

タスクの例:

{    
 "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 や DELETE などの特定のデータ操作言語 (DML) ステートメントでのみ発生する可能性があります。必ずソーステーブルで十分なロギングを有効にしてください。

追加のロギングを割り当てる際は、Oracle、PostgreSQL、またはMicrosoft SQL Serverのいずれかを使用します。

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 を DEFAULT に設定すると、PostgreSQL はプライマリキーの列の古い値を先書きログ (WAL) に記録します。ただし、プライマリキー以外の列を使用する場合、デフォルトのロギングレベルでは削除に対して十分でない可能性があります。

AWS DMS タスクが、以下のプロパティのいずれかに設定されているプラグインを使用していることを確認してください。

test_decoding を使用する場合は、REPLICA IDENTITY を FULL に設定します。

ALTER TABLE tablename REPLICA IDENTITY FULL;

注: REPLICA IDENTITY を FULL に設定しない場合、AWS DMS はすべての削除をターゲットテーブルに送信する可能性があります。

pglogical を使用する場合は、テーブルをレプリケーションセットに追加した後に REPLICA IDENTITY を FULL に設定します。

ALTER TABLE tablename REPLICA IDENTITY FULL;

注: REPLICA IDENTITY を FULL に設定すると、pglogical にはテーブルをレプリケーションセットに追加できないという制限が付きます。また、ソースデータベースで生成される WAL ログの数も増加します。WAL ログの数が増加すると、すべての列が WAL にログ記録されます。

Microsoft SQL Server

MS-CDC を有効にするために、以下の AWS DMS CDC ログ要件をすべて満たしていることを確認します。

プライマリキーを持つすべてのテーブルについて、次のクエリを実行します。

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

**注:**前述のクエリは、クラウドベースのソースで必要です。

ユニークキーを持つがプライマリキーがないすべてのテーブルについて、次のクエリを実行します。

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-Replication を使用する場合、前述のクエリを実行する必要はありません。

プライマリキーまたはユニークキーを持つすべてのテーブルについて、次のクエリを実行します。

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

注: 前出のクエリは、オンプレミスとクラウドベースの両方のソースを必要とします。

MySQL

MySQL では、binlog_row_image システム変数がバイナリログの行イメージを制御します。詳細については、MySQL ウェブサイトの「binlog_row_image」を参照してください。AWS DMS では、binlog_row_image を FULL に設定し、binlog_format を ROW に設定する必要があります。

MySQL は、ビフォアイメージとアフターイメージの両方で、すべての列を記録します。バイナリログの最大ロギングレベルを確認するには、ソースデータベースに binlog_row_image FULL を設定する必要があります。

関連情報

AWS DMS タスクでソースフィルターを使用するにはどうすればよいですか?

Using table mapping to specify task settings

Using source filters