での移行タスクのトラブルシューティングAWS Database Migration Service - AWS Database Migration Service

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

での移行タスクのトラブルシューティングAWS Database Migration Service

以下のトピックでは、AWS Database Migration Service (AWS DMS) を使用した問題のトラブルシューティングについて説明します。これらのトピックは、AWS DMS と選択されたエンドポイントデータベースの両方を使用して、一般的な問題を解決するのに役立ちます。

サポートケースを開いた場合、サポートエンジニアはエンドポイントデータベース設定の 1 つの潜在的な問題を特定する可能性があります。AWSまた、データベースに関する診断情報を返すサポートスクリプトを実行するようにエンジニアに依頼することもできます。このタイプのサポートスクリプトからの診断情報をダウンロード、実行、アップロードする方法の詳細については、「の診断サポート スクリプトでの作業 AWS DMS」を参照してください。

移行タスクの実行が遅い

移行タスクの実行が遅くなる、または後続のタスクの実行が初期タスクより遅くなる原因として、いくつかの問題が考えられます。

移行タスクの実行が遅くなる最も一般的な原因は、AWS DMS レプリケーションのインスタンスに割り当てられているリソースが不十分であることです。インスタンスで実行中のタスクに十分なリソースがあることを確認するには、レプリケーションインスタンスの CPU、メモリ、スワップファイル、および IOPS の使用率を確認します。たとえば、エンドポイントとしての Amazon Redshift を使用した複数のタスクは I/O 集約型です。レプリケーションのインスタンスに対して IOPS を増やすか、より効率的に移行するためにレプリケーションの複数のインスタンス間で作業を分割できます。

レプリケーションのインスタンスサイズの決定に関する詳細については、「」を参照してください。レプリケーションインスタンス用に最適なサイズを選択する.

以下を実行すると、初期の移行のロードがスピードアップします。

  • ターゲットが Amazon RDS DB インスタンスの場合は、ターゲット DB インスタンスのマルチ AZ が有効になっていないことを確認します。

  • ロード中に自動バックアップまたはターゲットデータベースでのログ記録をオフにし、移行の完了後にこれらの機能をオンに戻します。

  • ターゲットでこの機能を使用できる場合は、プロビジョンド IOPS を使用します。

  • 移行データに LOBs が含まれている場合は、タスクが LOB 移行用に最適化されていることを確認します。の最適化の詳細については、「LOBs」を参照してください。ターゲットメタデータのタスク設定

タスクのステータスバーが移動しない

タスクのステータスバーで、タスクの進捗状況を予測できます。この予測の正確さはソースデータベースのテーブル統計の正確さによって異なります。テーブル統計が正確であればあるほど、正確に予測できます。

予測された列の統計がないテーブルが 1 つだけのタスクの場合、AWS DMS は、どのような種類であっても完了率の予測を提供できません。この場合、タスクの状態とロードされた行の表示を使用して、タスクが実行中であり、進行中であることを確認します。

タスクは完了したが、何も移行されなかった

タスクの完了後に何も移行されていない場合は、以下を実行します。

  • エンドポイントを作成したユーザーに、移行するテーブルへの読み取りアクセス権があるかどうかを確認します。

  • 移行するオブジェクトがテーブルかどうかを確認します。ビューの場合は、テーブルマッピングを更新し、オブジェクトロケーターを「view」または「all」に指定します。詳細については、「」を参照してください。 コンソールからのテーブル選択および変換ルールの指定.

外部キーとセカンダリインデックスが見つからない

AWS DMS は、テーブル、プライマリキー、場合によっては一意のインデックスを作成しますが、効率的にソースからデータを移行するために必要ではない他のオブジェクトは作成されません。たとえば、セカンダリインデックス、非プライマリキーの制約、データデフォルトは作成されません。

データベースからセカンダリオブジェクトを移行するには、ソースデータベースと同じデータベースエンジンに移行中の場合、データベースのネイティブツールを使用します。ソースデータベースで使用したものとは異なるデータベースエンジンに移行してセカンダリオブジェクトを移行する場合は、AWS Schema Conversion Tool (AWS SCT) を使用します。

Amazon RDS への接続時に問題が発生する

ソースまたはターゲットとして設定した Amazon RDS DB インスタンスに接続できない理由は複数考えられます。確認する項目は次のとおりです。

  • ユーザー名とパスワードの組み合わせが正しいことを確認します。

  • インスタンスの Amazon RDS コンソールに表示されるエンドポイントの値が、AWS DMS エンドポイントの作成に使用したエンドポイント識別子と同じであることを確認します。

  • インスタンスの Amazon RDS コンソールに表示されるポート値が、AWS DMS エンドポイントに割り当てられたポートと同じであることを確認します。

  • DB インスタンスに割り当てられたセキュリティグループが、Amazon RDS レプリケーションインスタンスからの接続を許可することを確認します。AWS DMS

  • レプリケーションインスタンスと AWS DMS DB インスタンスが同じ Virtual Private Cloud (VPC) にない場合は、DB インスタンスがパブリックにアクセス可能であることを確認します。Amazon RDS

エラーメッセージ: スレッドの接続文字列が正しくありません。正しくないスレッド値「0」

エンドポイントへの接続をテストしているとき、このエラーが頻繁に発生します。このエラーは、接続文字列にエラーがあることを示します。たとえば、ホスト IP アドレスの後のスペースです。もう 1 つは、接続文字列にコピーされた無効な文字です。

ネットワーキングの問題が発生する

最も一般的なネットワーキング問題には、AWS DMS のレプリケーションのインスタンスによって使用される VPC のセキュリティグループが関係しています。デフォルトでは、このセキュリティグループではすべてのポートの 0.0.0.0/0 からの送信を許可するルールがあります。多くの場合、このセキュリティグループを変更するか、独自のセキュリティグループを使用します。その場合は、少なくとも、それぞれのデータベースポートでソースエンドポイントとターゲットエンドポイントへの送信を許可してください。

設定に関連する他の問題には、次のようなものがあります。

  • レプリケーションのインスタンスと、ソースとターゲット両方のエンドポイントが同じ VPC 内にある – エンドポイントが使用するセキュリティグループはレプリケーションのインスタンスからのデータベースポートへの受信を許可する必要があります。レプリケーションインスタンスによって使用されるセキュリティグループに、エンドポイントへの入力があることを確認します。または、エンドポイントにより使用されるセキュリティグループに、レプリケーションインスタンスのプライベート IP アドレスを許可するルールを作成できます。

  • ソースエンドポイントがレプリケーションインスタンス (インターネットゲートウェイを使用) が使用する VPC の外部にある VPC セキュリティグループには、VPC 用ではないトラフィックをインターネットゲートウェイに送信するルーティングルールが含まれている必要があります。–この設定では、エンドポイントへの接続がレプリケーションインスタンス上のパブリック IP アドレスから行われているように見えます。

  • ソースエンドポイントがレプリケーションインスタンス (NAT ゲートウェイを使用) が使用する VPC の外部にある – 単一の Elastic Network Interface にバインドされた単一の Elastic IP アドレスを使用してネットワークアドレス変換 (NAT) ゲートウェイを設定できます。この NAT ゲートウェイは NAT 識別子 (nat-#####) を受け取ります。

    場合によっては、VPC にインターネットゲートウェイではなく NAT ゲートウェイへのデフォルトルートが含まれています。このような場合、レプリケーションインスタンスはインターネットゲートウェイのパブリック IP アドレスを使用してデータベースエンドポイントに接続しているように見えますが、ここで、VPC 外のデータベースエンドポイントへの進入は、レプリケーションインスタンスのパブリック IP アドレスではなく NAT アドレスからの進入を許可する必要があります。

独自のオンプレミスネームサーバーの使用の詳細については、「 独自のオンプレミスネームサーバーの使用 」を参照してください。

全ロード後、CDC が停止する

複数の AWS DMS 設定が互いに競合すると、全ロード移行後に、レプリケーション変更が遅くなるか停止することがあります。

たとえば、[Target table preparation mode] パラメータが [Do nothing] または [Truncate] に設定されているとします。この場合、プライマリインデックスと固有なインデックスの作成を含め、ターゲットテーブルでのセットアップを行わないように AWS DMS に指示しています。ターゲットテーブルでプライマリキーまたは固有なキーを作成していない場合、AWS DMS は更新ごとにテーブル全体のスキャンを実行します。このアプローチは、パフォーマンスに大きな影響を与える可能性があります。

プライマリキー違反エラーは、タスクを再開するときに発生します

このエラーは、以前の移行タスクからのターゲットデータベースにデータが残っている場合に発生することがあります。[Target table preparation mode (ターゲットテーブル作成モード)] オプションが [Do nothing (何もしない)] に設定されている場合、AWS DMS は以前のタスクから挿入されたデータの削除を含め、ターゲットテーブルの準備を行いません。

タスクを再開し、これらのエラーを回避するには、タスクの以前の実行からターゲットテーブルに挿入される行を削除します。

スキーマの初回ロードが失敗する

場合によっては、スキーマの初回ロードが失敗してエラー Operation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails= が発生することがあります。

このような場合、ソースエンドポイントに接続するために AWS DMS が使用するユーザーアカウントには、必要なアクセス許可がありません。

不明なエラーでタスクが失敗する

不明なタイプのエラーの原因はさまざまです。ただし、AWS DMS レプリケーションのインスタンスに割り当てられたリソースが不十分なことに関連した問題である場合がよくあります。

レプリケーションのインスタンスに、移行を実行するのに十分なリソースがあることを確認するには、インスタンスの CPU、メモリ、スワップファイル、および IOPS の使用率を確認します。モニタリングの詳細については、「」を参照してください。AWS Database Migration Service メトリクス.

タスクを再開するとテーブルが最初からロードされる

AWS DMS は、テーブルの最初のロードを完了しなかった場合、テーブルのロードを最初から再開します。タスクが再開されると、AWS DMS は、最初のロードが完了しなかった場合に、テーブルを最初から再ロードします。

タスクあたりのテーブル数が原因で問題が発生する

レプリケーションタスクあたりのテーブル数に制限はありません。ただし、タスクのテーブル数は、簡単に言うと 60,000 未満に制限することをお勧めします。1 つのタスクが 60,000 個超のテーブルを使用すると、多くの場合リソース使用がボトルネックになることがあります。

LOB 列でプライマリキーが作成されると、タスクは失敗します。

FULL LOB モードまたは LIMITED LOB モードでは、AWS DMS は LOB データ型のプライマリキーのレプリケーションをサポートしていません。

DMS は、最初に LOB 列が NULL である行を移行し、後で LOB 列を更新します。したがって、LOB 列にプライマリキーが作成されると、プライマリキーを NULL にできないため、最初の挿入は失敗します。回避策として、別の列をプライマリキーとして追加し、LOB 列からプライマリキーを削除します。

プライマリキーがないターゲットテーブルで重複したレコードが発生する

全ロードおよび CDC タスクを実行すると、プライマリキーまたは一意のインデックスを持たないターゲットテーブルに重複レコードを作成できます。全ロードタスクと CDC タスク中にターゲットテーブルでレコードが重複しないようにするには、ターゲットテーブルにプライマリキーまたは一意のインデックスがあることを確認してください。

ソースエンドポイントが予約済み IP 範囲に収まる

ソースデータベースが 192.168.0.0/24 の予約済み IP 範囲内の IP アドレスを使用している場合、ソースエンドポイント接続テストは失敗します。AWS DMS次のステップは、考えられる回避方法を提供します。

  1. 192.168.0.0/24 のソースデータベースと通信できる予約済み範囲外の Amazon EC2 インスタンスを見つけます。

  2. socat プロキシをインストールして実行します。次に の例を示します。

    yum install socat socat -d -d -lmlocal2 tcp4-listen:database port,bind=0.0.0.0,reuseaddr,fork tcp4:source_database_ip_address:database_port &

EC2 インスタンスの IP アドレスと、AWS DMS エンドポイントに対して前述のデータベースポートを使用します。エンドポイントに、AWS DMS がデータベースポートで通信できるようにするセキュリティグループがあることを確認します。

Oracle に関する問題のトラブルシューティング

ここでは、Oracle データベースで AWS DMS を使用する際に固有の問題のトラブルシューティングについて説明します。

ビューからデータを取得する

ビューからデータを 1 回プルできます。これを継続的なレプリケーションに使用することはできません。ビューからデータを抽出可能にするために、Oracle ソースエンドポイントページの [Advanced (詳細)] セクションの [Extra connection attributes (追加の接続属性)] に次のコードを追加する必要があります。ビューからデータを抽出すると、そのビューはターゲットスキーマのテーブルとして表示されます。

exposeViews=true

Oracle 12c からの LOBs の移行

AWS DMS は、Oracle データベースへの変更をキャプチャするために、Binary Reader と Oracle LogMiner の 2 つのメソッドを使用できます。 デフォルトでは、AWS DMS は Oracle LogMiner を使用して変更をキャプチャします。ただし、Oracle 12c で、Oracle LogMiner は LOB 列をサポートしていません。Oracle 12c での LOB 列の変更をキャプチャするには、Binary Reader を使用します。

Oracle LogMiner と Binary Reader の切り替え

AWS DMS は、ソース Oracle データベースへの変更をキャプチャするために Binary Reader と Oracle LogMiner の 2 つのメソッドを使用できます。 Oracle の [LogMiner] がデフォルトです。Binary Reader を使用して変更をキャプチャするように切り替えるには、次を実行します。

Binary Reader を使用して変更をキャプチャするには

  1. にサインインし、AWS マネジメントコンソールdms/v2/AWS DMS にある コンソールを開きます。https://console.aws.amazon.com/

  2. [エンドポイント] を選択します。

  3. Binary Reader を使用する Oracle ソースエンドポイントを選択します。

  4. Modify.] を選択します。

  5. [Advanced] を選択し、次のコードを追加します。Extra connection attributes.

    useLogminerReader=N
  6. SQL-Plus などの Oracle 開発者用ツールを使用して、Oracle エンドポイントへの接続に使用される AWS DMS ユーザーアカウントに次の追加権限を付与します。

    SELECT ON V_$TRANSPORTABLE_PLATFORM

エラー: Oracle CDC は停止しました。122301 Oracle CDC の最大再試行カウンターを超えました。

このエラーは、AWS DMS が変更をキャプチャするために使用できるようになる前に、必要な Oracle アーカイブログがサーバーから削除されると発生します。データベースサーバーのログリテンションポリシーを増やします。データベースの場合、ログの保持を延長するために、以下の手順を実行します。Amazon RDSたとえば、以下のコードを使用すると、Amazon RDS DB インスタンスでのログの保持が 24 時間に延長されます。

exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

Oracle ソースエンドポイントにサプリメンタルロギングを自動的に追加する

デフォルトでは、AWS DMS のサプリメンタルロギングはオフになっています。Oracle ソースエンドポイントのサプリメンタルロギングを自動的にオンにするには、以下の手順を実行します。

Oracle ソースエンドポイントにサプリメンタルロギングを追加するには

  1. にサインインし、AWS マネジメントコンソールdms/v2/AWS DMS にある コンソールを開きます。https://console.aws.amazon.com/

  2. [エンドポイント] を選択します。

  3. サプリメンタルロギングを追加する Oracle ソースエンドポイントを選択します。

  4. Modify.] を選択します。

  5. [Advanced] を選択し、[Extra connection attributes] テキストボックスに次のコードを追加します。

    addSupplementalLogging=Y
  6. Modify.] を選択します。

LOB の変更がキャプチャされない

現在、LOB の変更をキャプチャするには、テーブルに AWS DMS のプライマリキーがあることが必要です。を含むテーブルにプライマリキーがない場合、LOB の変更をキャプチャするために実行できるアクションがいくつかあります。LOBs

  • テーブルにプライマリキーを追加します。この手順は、ID 列を追加し、トリガーを使用してシーケンスを入力するだけです。

  • プライマリキーとしてシステム生成 ID を含むテーブルのマテリアライズドビューを作成し、テーブルではなくマテリアライズドビューを移行します。

  • ロジカルスタンバイを作成し、テーブルにプライマリキーを追加して、ロジカルスタンバイから移行します。

エラー: ORA-12899: 列の値が大きすぎる column-name

エラー「ORA-12899: 列の値が大きすぎます column-name" は、多くの場合、いくつかの問題が原因で発生します。

このような問題のいずれかでは、ソースデータベースとターゲットデータベースで使用される文字セットに不一致があります。

これらの別の問題については、2 つのデータベース間で国内言語サポート (NLS) 設定が異なる可能性があります。このエラーの一般的な原因は、ソースデータベースの NLS_LENGTH_SEMANTICS パラメータが CHAR に設定されており、ターゲットデータベースの NLS_LENGTH_SEMANTICS パラメータが BYTE に設定されていることです。

NUMBER のデータ型が誤って解釈される

Oracle NUMBER データ型は、NUMBER の精度とスケールに応じて、AWS DMS のさまざまなデータ型に変換されます。このような変換は「」に記載されています。Oracle のソースデータ型. NUMBER 型の変換方法によっては、Oracle のソースエンドポイントの追加の接続属性の使用に影響を及ぼす場合があります。これらの追加の接続属性については、「」に記載されています。AWS DMS のソースとして Oracle を使用する場合の追加の接続属性.

全ロード中に見つからないレコード

全ロードを実行すると、AWS DMS はデータベースレベルで開いているトランザクションを探し、トランザクションがコミットされるのを待ちます。たとえば、タスク設定 TransactionConsistencyTimeout=600 に基づいて、AWS DMS は、開いているトランザクションがテーブルマッピングに含まれていないテーブル上にある場合でも 10 分間待機します。ただし、開いているトランザクションがテーブルのマッピングに含まれているテーブルにあり、トランザクションがコミットされていない場合、ターゲットテーブルの結果にレコードがありません。

開いているトランザクションのコミットに時間がかかることがわかっている場合は、TransactionConsistencyTimeout タスク設定を変更して待機時間を延長できます。

また、FailOnTransactionConsistencyBreached タスク設定のデフォルト値は false です。 つまり、AWS DMS は引き続き他のトランザクションを適用しますが、開いているトランザクションは見逃されます。開いているトランザクションが時間内に閉じない場合にタスクを失敗させる場合は、FailOnTransactionConsistencyBreachedtrue に設定できます。

に関する問題のトラブルシューティングMySQL

データベースでの AWS DMS の使用に固有の問題のトラブルシューティングについては、以下を参照してください。MySQL

バイナリログ作成が無効化されるため、Amazon RDS DB インスタンスのエンドポイントの CDC タスクが失敗する

自動バックアップが無効になっているため、この問題は Amazon RDS DB インスタンスで発生します。バックアップ保持期間を 0 以外の値に設定することで自動バックアップを有効にすることができます。

ターゲット MySQL インスタンスへの接続は、タスクの実行中に接続が切断されます

ターゲットから切断される LOBs のタスクがある場合は、タスクログに次のタイプのエラーが表示されることがあります。MySQL

[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 08S01 NativeError: 2013 Message: [MySQL][ODBC 5.3(w) Driver][mysqld-5.7.16-log]Lost connection to MySQL server during query [122502] ODBC general error.
[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 2006 Message: [MySQL][ODBC 5.3(w) Driver]MySQL server has gone away [122502] ODBC general error.

この場合、タスク設定の一部を調整する必要がある場合があります。

タスクが MySQL ターゲットから切断される問題を解決するには、以下の操作を行います。

  • 最大の LOB を保持するために、十分に大きい値に設定された データベース変数 max_allowed_packetがあることを確認します。

  • 以下の変数が大きいタイムアウト値に設定されていることを確認します。これらの変数ごとに、少なくとも 5 分の値を使用することをお勧めします。

    • net_read_timeout

    • net_write_timeout

    • wait_timeout

    • interactive_timeout

互換エンドポイントへの自動コミットを追加するMySQL

互換ターゲットエンドポイントに自動コミットを追加するにはMySQL

  1. にサインインし、AWS マネジメントコンソールdms/v2/AWS DMS にある コンソールを開きます。https://console.aws.amazon.com/

  2. [エンドポイント] を選択します。

  3. 自動コミットを追加する MySQL 互換ターゲットエンドポイントを選択します。

  4. Modify.] を選択します。

  5. [Advanced] を選択し、[Extra connection attributes] テキストボックスに次のコードを追加します。

    Initstmt= SET AUTOCOMMIT=1
  6. Modify.] を選択します。

ターゲット MySQL 互換エンドポイントで外部キーを無効化する

で外部キーのチェックを無効にするには、ターゲット MySQL、、または エンドポイントの [Advanced (詳細)] セクションの [MySQLExtra Connection Attributes (追加の接続属性)Amazon Aurora MySQL 互換エディション] に以下を追加します。MariaDB

ターゲット MySQL 互換エンドポイントで外部キーを無効にするには

  1. にサインインし、AWS マネジメントコンソールdms/v2/AWS DMS にある コンソールを開きます。https://console.aws.amazon.com/

  2. [エンドポイント] を選択します。

  3. 外部キーを無効にする MySQL、Aurora MySQL、または MariaDB ターゲットエンドポイントを選択します。

  4. Modify.] を選択します。

  5. [Advanced] を選択し、[Extra connection attributes] テキストボックスに次のコードを追加します。

    Initstmt=SET FOREIGN_KEY_CHECKS=0
  6. Modify.] を選択します。

文字が疑問符に置き換えられる

この問題を引き起こす可能性がある最も一般的な状況は、AWS DMS がサポートしない文字セットでソースエンドポイントの文字がエンコードされている場合です。たとえば、バージョン 3.1.1 より前の AWS DMS エンジンバージョンは UTF8MB4 文字セットをサポートしていませんでした。

「Bad event」ログエントリ

移行ログの [Bad event] のエントリは通常、ソースデータベースエンドポイントで、サポートされていないデータ定義言語 (DDL) オペレーションが試行されたことを指します。サポートされていない DDL オペレーションは、レプリケーションインスタンスがスキップできないイベントを引き起こすため、不正なイベントが記録されます。

この問題を修正するには、タスクを最初から再開します。これにより、テーブルが再ロードされ、サポートされていない DDL オペレーションが発行された後、ある時点で変更のキャプチャが開始されます。

5.5 の変更データキャプチャMySQL

AWS DMS 互換データベースの Amazon RDS 変更データキャプチャ (CDC) には、全イメージ行ベースのバイナリログ作成が必要です。これは、MySQL バージョン 5.5 以前ではサポートされていません。MySQLCDC を使用するには、AWS DMS DB インスタンスを Amazon RDS バージョン 5.6 にアップグレードする必要があります。MySQL

DB インスタンスのバイナリログ保持を延長するAmazon RDS

AWS DMS では、変更データキャプチャのバイナリログファイルを保持する必要があります。DB インスタンスでログの保持を延長するには、以下の手順を使用します。Amazon RDS以下の例では、バイナリログの保持を 24 時間に延長します。

call mysql.rds_set_configuration('binlog retention hours', 24);

ログメッセージ: ソースデータベースからの一部の変更は、ターゲットデータベースに適用されても効果がありません。

が AWS DMS データベースの列の値を既存の値に更新すると、MySQL のメッセージが zero rows affected から返されます。MySQL この動作は、Oracle や SQL Server などの他のデータベースエンジンとは異なります。これらのエンジンは、置き換えの値が現在の値と同じであっても 1 行を更新します。

エラー: 識別子が長すぎます

以下のエラーは識別子が長すぎるときに発生します。

TARGET_LOAD E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 1059 Message: MySQLhttp://ODBC 5.3(w) Driverhttp://mysqld-5.6.10Identifier name 'name' is too long 122502 ODBC general error. (ar_odbc_stmt.c:4054)

場合によっては、ターゲットデータベースにテーブルとプライマリキーを作成するように AWS DMS を設定します。このような場合、DMS は現在、ソースデータベースで使用されたのと同じ名前をプライマリキーに使用しません。代わりに、DMS はテーブル名に基づいてプライマリキー名を作成します。テーブル名が長いと、作成された自動生成される識別子が、MySQL で許可される制限よりも長くなる場合があります。

この問題を解決する現在の方法は、まずターゲットデータベースのテーブルとプライマリキーを事前に作成することです。次に、[Target table preparation mode (ターゲットテーブル作成モード)] が [Do nothing (何もしない)] または [Truncate (切り捨て)] に設定されているタスクを使って、ターゲットテーブルを入力します。

エラー: サポートされていない文字セットによりフィールドデータ変換が失敗しました

以下のエラーは、サポートされていない文字セットによりフィールドデータ変換が失敗した場合に発生します。

"[SOURCE_CAPTURE ]E: Column 'column-name' uses an unsupported character set [120112] A field data conversion failed. (mysql_endpoint_capture.c:2154)

3.1.1 より前の AWS DMS エンジンバージョンでは、テーブルまたはデータベースが UTF8MB4 エンコーディングを使用しているため、このエラーが頻繁に発生します。これらのエンジンバージョンは UTF8MB4 文字セットをサポートしていませんでした。さらに、接続に関係したデータベースのパラメータを確認します。これらのパラメータの設定には、次のコマンドを使用できます。

SHOW VARIABLES LIKE '%char%';

Error: Codepage 1252 to UTF8 [120112] A field data conversion failed

ソース MySQL データベースにコードページ-1252 以外の文字が含まれている場合、移行中に次のエラーが発生することがあります。

[SOURCE_CAPTURE ]E: Error converting column 'column_xyz' in table 'table_xyz with codepage 1252 to UTF8 [120112] A field data conversion failed. (mysql_endpoint_capture.c:2248)

回避策として、ソース CharsetMapping エンドポイントで追加の接続属性 MySQL を使用して、文字セットマッピングを指定できます。この追加の接続属性を追加する場合は、最初から AWS DMS 移行タスクを再起動する必要があります。

たとえば、ソース文字セットが MySQL または utf8 である latin1 ソースエンドポイントでは、次の追加の接続属性を使用できます。65001 は UTF8 コードページ識別子です。

CharsetMapping=utf8,65001 CharsetMapping=latin1,65001

に関する問題のトラブルシューティングPostgreSQL

データベースでの AWS DMS の使用に固有の問題のトラブルシューティングについては、以下を参照してください。PostgreSQL

切り捨てられる JSON データ型

AWS DMS は、PostgreSQL の JSON データ型を LOB データ型の列として扱います。つまり、制限付き LOB モードを使用するときの LOB のサイズ制限が、JSON データに適用されます。

たとえば、制限付き LOB モードが 4,096 KB に設定されているとします。この場合、4,096 KB を超える JSON データは 4,096 KB の制限で切り捨てられ、PostgreSQL の検証テストに合格しません。

次のログ情報は、LOB モード設定が制限され検証に失敗したために切り捨てられた JSON を示しています。

03:00:49 2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt 2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt.c:2415)  03:00:49 2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, Error while executing the query [1022502] (ar_odbc_stmt.c:2421) 2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, Error while executing the query [1022502] (ar_odbc_stmt.c:2421)

ユーザー定義のデータ型の列が正しく移行されない

ソースからレプリケートする場合、PostgreSQL はユーザー定義のデータ型を持つ列とは別に、すべての列に対して同じデータ型のターゲットテーブルを作成します。AWS DMSこのような場合、データ型はターゲットで「character varying」として作成されます。

エラー: 作成用のスキーマが選択されていません

場合によっては、"SQL_ERROR SqlState: 3F000 NativeError: 7 Message: ERROR: no schema half been selected in create in" というエラーが表示されることがあります。

このエラーは、JSON テーブルマッピングにスキーマのワイルドカード値が含まれていても、ソースデータベースがその値をサポートしていない場合に発生することがあります。

CDC を使用してテーブルの削除と更新がレプリケートされない

ソーステーブルにプライマリキーがない場合、変更データキャプチャ (CDC) 中の削除および更新オペレーションは無視されます。AWS DMS は、プライマリキーを持つ PostgreSQL テーブルの変更データキャプチャ (CDC) をサポートします。

テーブルにプライマリキーがない場合、先書き (WAL) ログにはデータベース行の前イメージは含まれません。この場合、AWS DMS はテーブルを更新できません。削除オペレーションをレプリケートする場合は、ソーステーブルにプライマリキーを作成します。

Truncate ステートメントが伝達されない

変更データキャプチャ (CDC) を使用する場合、AWS DMS は TRUNCATE オペレーションをサポートしません。

による DDL のキャプチャを防止するPostgreSQL

次の [PostgreSQLExtra Connection Attribute (追加の接続属性)] ステートメントを追加することで、 ターゲットエンドポイントが DDL ステートメントをキャプチャするのを防止できます。[Extra Connection Attribute (追加の接続属性)] パラメータは、ソースエンドポイントの [Advanced (詳細)] タブで利用可能です。

captureDDLs=N

DDL キャプチャ用のデータベースオブジェクトを作成するスキーマの選択

DDL キャプチャに関連したデータベースオブジェクトをどのスキーマで作成するかを制御できます。次の [Extra Connection Attribute (追加の接続属性)] ステートメントを追加します。[Extra Connection Attribute (追加の接続属性)] パラメータは、ターゲットエンドポイントの [Advanced (詳細)] タブで利用可能です。

ddlArtifactsSchema=xyzddlschema

への移行後に Oracle テーブルが見つからないPostgreSQL

この場合、テーブルとデータには、引き続き一般にアクセスできます。

Oracle のデフォルトは大文字のテーブル名で、PostgreSQL のデフォルトは小文字のテーブル名です。Oracle から PostgreSQL への移行を実行する場合は、タスクのテーブルマッピングセクションで特定の変換ルールを指定することをお勧めします。これらは、テーブル名を変換するための変換ルールです。

変換ルールを使用せずにテーブルを移行し、テーブル名の大文字と小文字を変換する場合、それらを参照するときはテーブル名を引用符で囲みます。

ReplicationSlotDiskUsage ETL ワークロードなどの長時間のトランザクション中に が増加して restart_lsn が前に進まない

論理レプリケーションが有効な場合、トランザクションあたりのメモリに保持される変更の最大数は 4 MB です。その後、変更はディスクに書き込まれます。結果として ReplicationSlotDiskUsage が増加し、トランザクションが完了または中止され、ロールバックが終了するまで restart_lsn は続行されません。トランザクションが長くなるため、ロールバックに時間がかかることがあります。

したがって、論理レプリケーションが有効な場合は、長時間実行されるトランザクションは避けてください。代わりに、トランザクションをいくつかの小さいトランザクションに分割してみてください。

ソースとしてビューを使用したタスクで行がコピーされない

ビューを移行するには、table-typeall または view に設定します。 詳細については、「 コンソールからのテーブル選択および変換ルールの指定」を参照してください。

ビューをサポートするソースは以下のとおりです。

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • IBM Db2 LUW

  • SAP Adaptive Server Enterprise (ASE)

Microsoft SQL Server に関する問題のトラブルシューティング

ここでは、Microsoft SQL Server データベースで AWS DMS を使用する際に固有の問題のトラブルシューティングについて説明します。

AWS DMS ユーザーアカウントの CDC 使用を特別に許可する

で使用されるユーザーアカウントでは、変更データキャプチャ (CDC) の使用時に正しく動作するために、SQL Server の AWS DMS ロールが必要です。SysAdmin

SQL Server データベースの変更キャプチャエラー

変更データキャプチャ (CDC) 中のエラーは、前提条件の 1 つが満たされていないことを示している可能性があります。たとえば、最も一般的に見過ごされる前提条件は、完全データベースバックアップです。タスクログは以下のエラーで、この欠落を示します。

SOURCE_CAPTURE E: No FULL database backup found (under the 'FULL' recovery model). To enable all changes to be captured, you must perform a full database backup. 120438 Changes may be missed. (sqlserver_log_queries.c:2623)

SQL Server を Microsoft SQL Server データベースの AWS DMS のソースとしての使用 のソースとして使用するための前提条件を確認します。

IDENTITY 列が存在しない

AWS DMS では、ターゲットスキーマの作成時に IDENTITY 列をサポートしていません。初期ロードの完了後に追加する必要があります。

エラー: SQL Server は公開をサポートしていません

以下のエラーは、SQL Server Express をソースエンドポイントとして使用する際に生成されます。

RetCode: SQL_ERROR SqlState: HY000 NativeError: 21106 Message: This edition of SQL Server does not support publications.

AWS DMS は現在、ソースまたはターゲットとして SQL Server Express をサポートしていません。

ターゲットに変更が表示されない

AWS DMS では、変更を一貫してキャプチャするために、ソース SQL Server データベースが「FULL」または「BULK LOGGED」データ復旧モデルのいずれかであることが必要です。「SIMPLE」モデルはサポートされていません。

SIMPLE 復旧モデルは、ユーザーがデータベースを復旧するのに必要な最低限の情報を記録します。すべての非アクティブのログエントリは、チェックポイントが発生すると自動的に切り捨てられます。

すべての オペレーションがログに記録されます。ただし、チェックポイントが発生するとすぐにログは自動的に切り捨てられます。この切り捨ては、ログが再利用できるようになり、古いログエントリは上書きできることを意味します。ログエントリが上書きされると、変更内容をキャプチャできません。この問題は、AWS DMS が SIMPLE データ復旧モデルをサポートしていないためです。SQL Server をソースとして使用するためのその他の前提条件については、「Microsoft SQL Server データベースの AWS DMS のソースとしての使用」を参照してください。

パーティションにまたがってマッピングされる不均一テーブル

変更データキャプチャ (CDC) 中に、AWS DMS がテーブルに対して CDC を適切に実行できない場合、特殊な構造を持つテーブルの移行は中断されます。次のようなメッセージが発行されます。

[SOURCE_CAPTURE ]W: Table is not uniformly mapped across partitions. Therefore - it is excluded from CDC (sqlserver_log_metadata.c:1415) [SOURCE_CAPTURE ]I: Table has been mapped and registered for CDC. (sqlserver_log_metadata.c:835)

SQL Server テーブルで CDC を実行する場合、AWS DMS は SQL Server の tlog を解析します。各 tlog レコードで、AWS DMS は変更中に挿入、更新、または削除されたカラムのデータを含む 16 進値を解析します。

16 進レコードを解析するために、AWS DMS は SQL Server システムテーブルからテーブルメタデータを読み取ります。これらのシステムテーブルは、特別に構造化されたテーブルカラムが何であるかを識別し、「xoffset」や「null bit position」などの内部プロパティの一部を表示します。

AWS DMS では、メタデータがテーブルのすべての未加工パーティションで同じであることを想定しています。しかし、特別に構造化されたテーブルでは、すべてのパーティションに同じメタデータがない場合があります。このような場合、AWS DMS はそのテーブルの CDC を中断して、変更を誤って解析しないようにし、ターゲットに誤ったデータを提供できます。回避策は次のとおりです。

  • テーブルにクラスター化されたインデックスがある場合は、インデックスの再構築を実行します。

  • テーブルにクラスター化されたインデックスがない場合は、クラスター化されたインデックスをテーブルに追加します (必要に応じて後で削除できます)。

に関する問題のトラブルシューティングAmazon Redshift

データベースでの AWS DMS の使用に固有の問題のトラブルシューティングについては、以下を参照してください。Amazon Redshift

別の Amazon Redshift リージョンの AWS クラスターへのロード

レプリケーションインスタンスとは異なる AWS リージョンの Amazon Redshift クラスターにロードすることはできません。AWS DMSDMS では、レプリケーションインスタンスと Amazon Redshift クラスターが同じリージョンにある必要があります。

エラー: リレーション「awsdms_apply_exceptions」がすでに存在します

エラー "リレーション「awsdms_apply_exceptions」がすでに存在します" は、Redshift エンドポイントが PostgreSQL エンドポイントとして指定されている場合に頻繁に発生します。この問題を解決するには、エンドポイントを変更し、[Target engine] を「redshift」に変更します。

名前が「awsdms_changes」で始まるテーブルのエラー

「awsdms_changes」で始まる名前のテーブルエラーメッセージは、同じ Amazon Redshift クラスターにデータをロードしようとする 2 つのタスクが同時に実行される場合に発生します。一時テーブルに名前が付けられる方法のため、同じテーブルを更新する場合、同時に実行されるタスクは競合する場合があります。

dms.awsdms_changes000000000XXXX のような名前のクラスター内のテーブルを参照する

AWS DMS は、Amazon S3 に保存されているファイルからデータがロードされているときに一時テーブルを作成します。これらの一時テーブルの名前にはそれぞれ、プレフィックス dms.awsdms_changes が付けられます。 これらのテーブルは、AWS DMS が最初にロードされたとき、そして最終的なターゲットテーブルに配置される前にデータを保存できるように必要です。

での作業に必要なアクセス許可Amazon Redshift

で AWS DMS を使用するには、Amazon Redshift へのアクセスに使用するユーザーアカウントに次のアクセス許可が必要です。Amazon Redshift

  • CRUD (選択、挿入、更新、削除)

  • 一括ロード

  • 作成、変更、削除 (タスクの定義によって必要な場合)

をターゲットとして使用するための前提条件を確認するには、「Amazon Redshift」を参照してください。Amazon Redshift のターゲットとしての AWS Database Migration Service データベースの使用

に関する問題のトラブルシューティングAmazon Aurora MySQL

データベースでの AWS DMS の使用に固有の問題のトラブルシューティングについては、以下を参照してください。Amazon Aurora MySQL

エラー: CHARACTER SET UTF8 フィールドが「,」で切り取られています。行が「\n」で切り取られています

ターゲットとして Amazon Aurora MySQL を使用している場合、ログに次のようなエラーが表示されることがあります。このタイプのエラーは通常、SQL_MODE パラメータの一部に ANSI_QUOTES があることを示します。SQL_MODE パラメータの一部として ANSI_QUOTES がある場合、二重引用符が引用符のように処理され、タスクを実行するときに問題が発生する可能性があります。

このエラーを修正するには、SQL_MODE パラメータから ANSI_QUOTES を削除します。

2016-11-02T14:23:48 [TARGET_LOAD ]E: Load data sql statement. load data local infile "/rdsdbdata/data/tasks/7XO4FJHCVON7TYTLQ6RX3CQHDU/data_files/4/LOAD000001DF.csv" into table `VOSPUSER`.`SANDBOX_SRC_FILE` CHARACTER SET UTF8 fields terminated by ',' enclosed by '"' lines terminated by '\n'( `SANDBOX_SRC_FILE_ID`,`SANDBOX_ID`, `FILENAME`,`LOCAL_PATH`,`LINES_OF_CODE`,`INSERT_TS`,`MODIFIED_TS`,`MODIFIED_BY`, `RECORD_VER`,`REF_GUID`,`PLATFORM_GENERATED`,`ANALYSIS_TYPE`,`SANITIZED`,`DYN_TYPE`, `CRAWL_STATUS`,`ORIG_EXEC_UNIT_VER_ID` ) ; (provider_syntax_manager.c:2561)