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

所要時間3分

AWS Database Migration Service (AWS DMS) タスクでソースフィルタ条件を設定しましたが、正しく動作しません。AWS DMS タスクでソースフィルタ条件に関する問題をトラブルシューティングするにはどうすればよいですか?

簡単な説明

AWS DMS タスクでソースフィルタ条件が期待どおりに動作しない理由はいくつかあります。例えば、使用しているエンジンがソースフィルター条件の使用をサポートしていない場合があります。または、機能の 1 つまたは複数の制限の影響を受けている可能性があります。

解決方法

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

ほとんどの 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

ENTRY_DATEが2022年01月01日以降の行のみをレプリケートするマッピングルールで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 や DELETES などの特定の DML ステートメントでのみ発生する可能性があります。このシナリオでは、ソーステーブルで十分なロギングが有効になっていることを確認します。以下の手順で、使用するエンジンによって追加のロギングを割り当てます。

Oracle

Oracleでは、サプリメンタル・ロギングを使用して、表の列にログを追加します。フィルタリングするカラムがプライマリキーカラムでない場合、そのカラムとプライマリキーカラムに対してサプリメントロギングが有効であることを確認します。

この例では、TEST.LOGGINGというテーブルを、プライマリキーID、Column NAMEに対するフィルターでレプリケートしています。以下のようなコマンドを実行して、ロググループのサプリメンタルロギングを作成します。

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 では、バイナリログの行イメージは binlog_row_image システム変数によって制御されます。AWS DMS では、binlog_row_image が full に設定され、binlog_format が ROW に設定されている必要があります。これは、MySQLが、ビフォアイメージとアフターイメージの両方ですべてのカラムをログに記録することを意味します。そのため、ソースデータベースで binlog_row_image が full に設定されていることを確認して、binlog の最大ログレベルを確認してください。