AWS Database Migration Service のベストプラクティス - AWS Database Migration Service

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

AWS Database Migration Service のベストプラクティス

AWS Database Migration Service (AWS DMS) を最も効果的に使用するためには、データ移行の最も効率的な方法に関するこのセクションの推奨事項を参照してください。

AWS Database Migration Service の移行計画

AWS Database Migration Service を使用してデータベース移行を計画するときは、以下の点を考慮してください。

  • ソースとターゲットのデータベースを AWS DMS レプリケーションインスタンスに接続するには、ネットワークを設定します。この操作は、レプリケーションインスタンスと同じ Virtual Private Cloud (VPC) で 2 つの AWS リソースを接続するだけで簡単に行うことができます。これは、仮想プライベートネットワーク (VPN) 経由で Amazon RDS DB インスタンスに接続するなど、より複雑な設定までさまざまです。詳細については、「データベース移行のネットワーク設定」を参照してください。

  • ソースエンドポイントとターゲットエンドポイント— ソースデータベース内のどの情報とテーブルをターゲットデータベースに移行する必要があるかを知っていることを確認します。AWS DMS では、テーブルやプライマリキーの作成など、基本的なスキーマの移行がサポートされています。ただし、AWS DMS は、ターゲットデータベースにセカンダリインデックス、外部キー、ユーザーアカウントなどを自動的に作成しません。ソースおよびターゲットデータベースエンジンによっては、サプリメンタルロギングをセットアップしたり、ソースまたはターゲットデータベースの他の設定を変更したり必要がある場合があります。詳細については、「データ移行のソース」および「データ移行のターゲット」を参照してください。

  • スキーマおよびコード移行— AWS DMS は、スキーマまたはコード変換を実行しません。Oracle SQL Developer、MySQL Workbench、pgAdmin III などのツールを使用して、スキーマを変換できます。異なるデータベースエンジンに既存のスキーマを変換するには、AWS Schema Conversion Tool (AWS SCT) を使用できます。このツールは、ターゲットスキーマを作成でき、スキーマ全体 (テーブル、インデックス、ビューなど) を生成および作成することもできます。このツールを使用して PL/SQL または TSQL を PgSQL や他の形式に変換することもできます。AWS SCT の詳細については、「」を参照してください。AWS SCT ユーザーガイド

  • サポート対象外のデータ型— ソースのデータ型を、ターゲットデータベースのデータ型と同等のデータ型に変換できることを確認します。サポートされているデータ型の詳細については、データストアのソースまたはターゲットのセクションを参照してください。

  • 診断サポートスクリプトの結果— 移行を計画するときは、診断サポートスクリプトを実行することをお勧めします。これらのスクリプトの結果により、移行の失敗の可能性に関する詳細な情報が得られます。

    サポートスクリプトがデータベースで利用可能な場合は、次に説明する対応するスクリプト・トピックのリンクを使用してダウンロードします。スクリプトを確認して確認したら、ローカル環境のスクリプト・トピックで説明されている手順に従ってスクリプトを実行できます。スクリプトの実行が完了したら、結果を確認できます。トラブルシューティングの最初の手順として、これらのスクリプトを実行することをお勧めします。この結果は、AWS Support チームと協力しているときに役立ちます。詳細については、「AWS DMS での診断サポートスクリプトの操作」を参照してください。

  • 移行前の評価移行前の評価は、データベース移行タスクの指定されたコンポーネントを評価し、移行タスクが期待どおりに実行できない問題を特定します。この評価を使用すると、新規または変更されたタスクを実行する前に、潜在的な問題を特定できます。事前移行評価の使用の詳細については、「」を参照してください。タスクの移行前評価の有効化と操作

スキーマの変換

AWS DMS は、スキーマまたはコード変換を実行しません。異なるデータベースエンジンに既存のスキーマを変換する場合、AWS SCT を使用できます。AWS SCT は、ソースオブジェクト、テーブル、インデックス、ビュー、トリガー、およびその他のシステムオブジェクトをターゲットデータ定義言語 (DDL) 形式に変換します。AWS SCT を使用して、PL/SQL または TSQL などのほとんどのアプリケーションコードを同等のターゲット言語に変換することもできます。

AWS SCT は、AWS から無料でダウンロードできます。AWS SCT の詳細については、「」を参照してください。AWS SCT ユーザーガイド

ソースおよびターゲットエンドポイントが同じデータベースエンジンの場合は、Oracle SQL Developer、MySQL Workbench、または PgAdmin4 などのツールを使用して、スキーマを起動できます。

AWS DMS パブリックドキュメントの確認

最初の移行前に、ソースエンドポイントとターゲットエンドポイントの AWS DMS パブリックドキュメントページを参照することを強くお勧めします。このドキュメントは、移行の前提条件を特定し、開始する前に現在の制限事項を理解するのに役立ちます。詳細については、「AWS DMS エンドポイントの操作」を参照してください。

移行中に、AWS DMS に関する問題のトラブルシューティングに役立つ公開ドキュメントがあります。ドキュメントのトラブルシューティングページは、AWS DMS と選択したエンドポイントデータベースの両方を使用して一般的な問題を解決するのに役立ちます。詳細については、「AWS Database Migration Service での移行タスクのトラブルシューティング」を参照してください。

PoC (概念実証) の実行

データベース移行の初期段階で環境の問題を発見するために、小規模なテスト移行を実行することをお勧めします。これにより、より現実的な移行時間ラインを設定することもできます。さらに、AWS DMS がネットワーク経由でデータベースのスループットを処理できるかどうかを測定するために、本格的なテスト移行を実行する必要があります。この間、最初の全負荷と継続的なレプリケーションのベンチマークと最適化を推奨します。これにより、ネットワークの遅延を把握し、全体的なパフォーマンスを測定するのに役立ちます。

この時点で、データプロファイルとデータベースの規模を理解する機会もあります。たとえば、次のようなものがあります。

  • 大型、中型、小型のテーブルの数です。

  • AWS DMS がデータ型と文字セットの変換を処理する方法。

  • ラージオブジェクト (LOB) 列を持つテーブルの数。

  • テスト移行の実行に要する時間。

AWS DMS 移行のパフォーマンスの向上

AWS DMS 移行のパフォーマンスに影響を及ぼす要因はいくつかあります。

  • ソースのリソース可用性。

  • 利用可能なネットワークスループット。

  • レプリケーションサーバーのリソース容量。

  • ターゲットの変更取り込み機能。

  • ソースデータのタイプとディストリビューション。

  • 移行するオブジェクトの数。

パフォーマンスを向上させるには、次のベストプラクティスの一部またはすべてを使用します。これらのプラクティスを使用できるかどうかは、特定のユースケースによって異なります。いくつかの制限があります。

適切なレプリケーション・サーバのプロビジョニング

AWS DMS は、Amazon EC2 インスタンスで実行されるマネージドサービスです。このサービスは、ソースデータベースに接続してソースデータを読み取り、ターゲットデータベースが使用できるようにデータをフォーマットし、ターゲットデータベースにデータをロードします。

この処理のほとんどはメモリ内で行われます。ただし、大きいトランザクションではディスクでのバッファリングが必要になることがあります。キャッシュされたトランザクションとログファイルもディスクに書き込まれます。以下のセクションでは、レプリケーションサーバーを選択するときに考慮すべき点について説明します。

CPU

AWS DMS は、異機種混在の移行向けに設計されていますが、同機種混在の移行もサポートしています。同種移行を実行するには、まず各ソースデータ型を同等の AWS DMS データ型に変換します。次に、各 AWS DMS タイプのデータをターゲットデータ型に変換します。これらの変換の参照は、各データベースエンジンのAWS DMS ユーザーガイド

AWS DMS がこれらの変換を最適に実行するには、変換が発生したときに CPU が使用可能である必要があります。CPU に過負荷がかかり、CPU リソースが不足すると、移行が遅くなり、他の副作用を引き起こす可能性があります。

レプリケーションインスタンスクラス

サービスのテストや小規模な移行の場合、いくつかの小さいインスタンスクラスで十分です。移行に多数のテーブルが関与する場合や、複数の同時レプリケーションタスクを実行する予定の場合、大きいインスタンスを 1 つ使用することを検討してください。サービスがかなりの量のメモリと CPU を消費するため、インスタンスを大きくすると良い考えです。

T2 タイプインスタンスは、適度なベースラインパフォーマンスを実現したり、ワークロードの必要に応じて非常に高いパフォーマンスまでバーストする機能を実現できるように設計されています。常時または一貫して CPU をフルに使用するわけではないが、バーストが必要なことがあるワークロード向けに用意されています。T2 インスタンスは、ウェブサーバー、開発者環境、小規模データベースなどの汎用ワークロードに適しています。移行が遅い場合のトラブルシューティングで T2 インスタンスタイプを使用している場合は、CPU 使用率ホストメトリックスを確認します。そのインスタンスタイプのベースラインを超過しているかどうかが表示されます。

この C4 インスタンスクラスは、大量の演算を行うワークロードで最高レベルのプロセッサパフォーマンスを実現するように設計されています。パケット毎秒 (PPS) が非常に大きく、ネットワークのストレスが少なく、ネットワークレイテンシーが低くなります。AWS DMS は、特に異機種間 (例: Oracle から PostgreSQL) で移行やレプリケーションを実行する場合に、CPU に対する負荷が大きくなる場合があります。C4 インスタンスは、このような状況に適しています。

R4 インスタンスクラスは、メモリ負荷の大きいワークロード用に最適化されたメモリです。AWS DMS を使用する高スループットトランザクションシステムの継続的な移行やレプリケーションが原因で、大量の CPU やメモリを消費することがあります。R4 インスタンスは、vCPU 別のメモリが含まれます。

R5 および C5 インスタンスクラスに対する AWS DMS サポート

R5 インスタンスクラスは、メモリ最適化インスタンスであり、メモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンスを実現するように設計されています。AWS DMS を使用する高スループットトランザクションシステムの継続的な移行やレプリケーションが原因で、大量の CPU やメモリを消費することがあります。R5 インスタンスは、vCPU あたり R4 よりも 5% の追加メモリを提供し、最大サイズは 768 GiB のメモリを提供します。さらに、R5 インスタンスは GiB あたりの価格を 10% 向上させ、R4 に比べて CPU パフォーマンスを 20% 向上させます。

C5 インスタンスクラスは、コンピューティング集約型のワークロード向けに最適化されており、コスト効率の高い高パフォーマンスを低コストで提供します。これにより、ネットワークパフォーマンスが大幅に向上します。Elastic Network Adapter(ENA)は、C5 インスタンスに、最大 25 Gbps のネットワーク帯域幅と最大 14 Gbps の専用帯域幅を提供します。AWS DMS は、特に異機種間 (例: Oracle から PostgreSQL) で移行やレプリケーションを実行する場合に、CPU に対する負荷が大きくなる場合があります。C5 インスタンスは、このような状況に適しています。

ストレージ

インスタンスクラスに応じて、レプリケーションサーバーには 50 GB または 100 GB のデータストレージが付属しています。このストレージは、ロード中に収集されるログファイルおよびキャッシュされた変更に使用されます。ソースシステムがビジー状態であるか、トランザクションが大きい場合は、ストレージを増やす必要があります。レプリケーションサーバー上で複数のタスクを実行している場合は、ストレージを増やす必要がある場合もあります。ただし、通常はデフォルトの金額で十分です。

AWS DMS のすべてのストレージボリュームは GP2 または汎用ソリッドステートドライブ (SSD) です。GP2 ボリュームには、1 秒あたり 3 つの I/O 操作数 (IOPS) という基本パフォーマンスがあり、クレジットベースで最大 3,000 IOPS のバーストが可能です。経験則として、ReadIOPSおよびWriteIOPSレプリケーションインスタンスのメトリクス。これらの値の合計が、そのボリュームの基本パフォーマンスを超えないようにしてください。

マルチ AZ

マルチ AZ インスタンスを選択すると、ストレージ障害から移行を保護できます。ほとんどの移行は一時的なものであり、長期間実行することを意図していません。継続的なレプリケーションの目的で AWS DMS を使用する場合、マルチ AZ インスタンスを選択すると、ストレージの問題が発生した場合の可用性が向上します。

複数のテーブルを並列にロードする

デフォルトでは AWS DMS は、一度に 8 つのテーブルをロードします。dms.c4.xlarge またはより大きなインスタンスなどの大量レプリケーションサーバーを使用する際、これを少し増やすことによりパフォーマンスがある程度向上する場合があります。ただし、ある時点で並列処理を増やすことによりパフォーマンスが低下します。dms.t2.medium などのレプリケーションサーバーが比較的小さい場合は、並行してロードされるテーブルの数を減らすことをおすすめします。

AWS マネジメントコンソールでこの数を変更するには、コンソールを開き、[タスク] を選択後、タスクの作成または変更を選択してから、[Advanced Settings (詳細設定)] を選択します。[Tuning Settings (チューニング設定)] で、[並列にロードするテーブルの最大数] オプションを変更します。

AWS CLI を使用してこの数を変更するには、TaskSettingsMaxFullLoadSubTasks パラメータを変更します。

並列全ロードの使用

パーティションとサブパーティションに基づいて、Oracle、Microsoft SQL Server、MySQL、Sybase、および IBM Db2 LUW ソースからの並列ロードを使用できます。これを行うと、全体の負荷持続時間が改善されます。さらに、AWS DMS 移行タスクの実行中に、大きなテーブルまたはパーティション化されたテーブルの移行を高速化できます。これを行うには、テーブルをセグメントに分割し、同じ移行タスクでセグメントを並列にロードします。

並列ロードを使用するには、タイプのテーブルマッピングルールを作成します。table-settingsparallel-loadオプション。内table-settingsルールで、並行してロードする 1 つ以上のテーブルの選択条件を指定します。選択条件を指定するには、typeの要素parallel-load以下のいずれかの設定に設定します。

  • partitions-auto

  • subpartitions-auto

  • partitions-list

  • ranges

  • none

これらの設定の詳細については、「」を参照してください。テーブル設定とコレクション設定のルールとオペレーション

インデックス、トリガー、参照整合性制約の操作

インデックス、トリガーおよび参照整合性制約は、移行パフォーマンスに影響を及ぼすことがあるため、移行が失敗する原因になります。これらが移行に及ぼす影響は、レプリケーションタスクが全ロードタスクであるか、継続的なレプリケーション (変更データキャプチャ (CDC) タスクであるかによって異なります。

全ロードタスクの場合は、プライマリキーインデックス、参照整合性制約、データ操作言語 (DML) トリガーを削除することをお勧めします。または、全ロードタスクが完了するまで、その作成を遅延させることができます。全ロードタスク中はインデックスは不要であり、インデックスが存在する場合、インデックスはメンテナンスのオーバーヘッドが発生します。全ロードタスクは一度にテーブルのグループをロードするため、参照整合性の制約に違反します。同様に、挿入、更新、および削除トリガーは、たとえば、以前に一括ロードされたテーブルに対して行の挿入がトリガーされた場合にエラーを引き起こす可能性があります。他のタイプのトリガーも、追加された処理のためにパフォーマンスに影響を及ぼします。

データ量が比較的少なく、追加の移行時間が重要でない場合は、全ロードタスクの前にプライマリキーとセカンダリインデックスを作成できます。参照整合性の制約とトリガーを常にオフにします。

全ロードと CDC タスクの場合は、CDC フェーズの前にセカンダリインデックスを追加することをお勧めします。AWS DMS は論理的なレプリケーションを使用するため、DML オペレーションをサポートするセカンダリインデックスを配置して、完全なテーブルスキャンを防止してください。CDC フェーズの前にレプリケーションタスクを一時停止して、そのタスクを再開する前にインデックスを作成後、トリガーを作成し、参照整合性制約を作成することができます。

バックアップとトランザクションログ記録を無効にする

Amazon RDS データベースに移行する場合、カットオーバーの準備ができるまでは、ターゲットのバックアップとマルチ AZ を無効にすることをお勧めします。同様に、Amazon RDS 以外のシステムに移行する場合、カットオーバーまではターゲットのロギングを無効にすることをお勧めします。

複数のタスクを使用する

時には、単一の移行のために複数のタスクを使用することでパフォーマンスが向上します。共通のトランザクションに関与しないテーブルのセットがある場合、複数のタスクに移行を分割できる場合があります。 トランザクションの整合性はタスク内に維持されます。したがって、個別のタスクのテーブルが、共通のトランザクションに関与しないことが重要です。また、各タスクはそれぞれ独立してトランザクションのストリームを読み込みため、ソースデータベースに過度のストレスをかけないよう注意が必要です。

複数のタスクを使用して、レプリケーションの別々のストリームを作成できます。これにより、ソース上の読み取り、レプリケーションインスタンス上のプロセス、およびターゲットデータベースへの書き込みを並列化することができます。

変更処理の最適化

デフォルトでは、AWS DMS は、トランザクションの完全性を維持する [トランザクションモード] で、変更を処理します。トランザクションの完全性を一時的に失効できる場合は、代わりに [最適化バッチ] オプションを使用できます。このオプションでは、効率的にトランザクションがグループ化され、効率化のためにバッチに適用します。バッチ最適化適用オプションを使用すると、ほとんどの場合、参照整合性制約に違反します。したがって、移行プロセス中にこれらの制約をオフにし、カットオーバープロセスの一部として再度オンにすることをお勧めします。

独自のオンプレミスネームサーバーの使用

通常、AWS DMS レプリケーションインスタンスは Amazon EC2 インスタンスのドメインネームシステム (DNS) リゾルバーを使用してドメインエンドポイントを解決します。ただし、Amazon Route 53 リゾルバーを使用する場合は、独自のオンプレミスネームサーバーを使用して特定のエンドポイントを解決できます。このツールを使用すると、インバウンドおよびアウトバウンドエンドポイント、転送ルール、およびプライベート接続を使用して、オンプレミスと AWS の間でクエリを実行できます。オンプレミスのネームサーバーを使用する利点には、セキュリティが強化され、ファイアウォールの背後にある使いやすさが挙げられます。

インバウンドエンドポイントがある場合は、オンプレミスの DNS クエリを使用して、AWS ホストドメインを解決できます。エンドポイントを設定するには、リゾルバーを提供する各サブネットの IP アドレスを割り当てます。オンプレミスの DNS インフラストラクチャと AWS との間の接続を確立するには、AWS Direct Connect または仮想プライベートネットワーク (VPN) を使用します。

アウトバウンドエンドポイントは、オンプレミスのネームサーバーに接続します。ネームサーバーは、許可リストに含まれ、アウトバウンドエンドポイントに設定された IP アドレスへのアクセスを許可します。ネームサーバーの IP アドレスがターゲットの IP アドレスです。アウトバウンドエンドポイントのセキュリティグループを選択するときは、レプリケーションインスタンスで使用するものと同じセキュリティグループを選択します。

選択したドメインをネームサーバーに転送するには、転送ルールを使用します。アウトバウンドエンドポイントは、複数の転送ルールを処理できます。転送ルールの範囲は、仮想プライベートクラウド (VPC) です。VPC に関連付けられた転送ルールを使用することで、AWS クラウドの論理的に分離されたセクションをプロビジョニングできます。この論理的に分離されたセクションでは、仮想ネットワークで AWS リソースを起動できます。

オンプレミスの DNS インフラストラクチャ内でホストされるドメインは、アウトバウンド DNS クエリを設定する条件付き転送ルールとして構成できます。これらのドメインの 1 つに対してクエリが実行されると、ルールによって構成されたサーバーに DNS リクエストを転送する試みがトリガーされます。ここでも、AWS Direct Connect または VPN を介したプライベート接続が必要です。

Route 53 Resolver アーキテクチャを次の図に示します。


                Route 53 Resolver アーキテクチャ

Route 53 DNS Resolver の詳細については、「」を参照してください。Route 53 Resolver の使用を開始する()Amazon Route 53 開発者ガイド

AWS DMS での Amazon Route 53 Resolver の使用

AWS DMS 用のオンプレミスネームサーバーを作成して、エンドポイントを解決するには、Amazon Route 53 Resolver

Route 53 に基づいて AWS DMS 用のオンプレミスネームサーバーを作成するには

  1. AWS マネジメントコンソールにサインインし、Route 53 コンソール (https://console.aws.amazon.com/route53/

  2. Route 53 コンソールで、Route 53 リゾルバーを設定する AWS リージョンを選択します。Route 53 リゾルバは、リージョンに固有のものです。

  3. クエリ方向 (インバウンド、アウトバウンド、またはその両方) を選択します。

  4. インバウンドクエリの設定を指定します。

    1. エンドポイント名を入力し、VPC を選択します。

    2. VPC 内からサブネットを 1 つ以上割り当てます (たとえば、可用性のため 2 つを選択します)。

    3. エンドポイントとして使用する特定の IP アドレスを割り当てるか、Route 53 リゾルバーで自動的に割り当てます。

  5. VPC 内のワークロードが DNS クエリを DNS インフラストラクチャにルーティングできるように、オンプレミスドメインのルールを作成します。

  6. オンプレミス DNS サーバーの 1 つ以上の IP アドレスを入力します。

  7. ルールを送信します。

すべてが作成されると、VPC はインバウンドおよびアウトバウンドルールに関連付けられ、トラフィックのルーティングを開始できます。

Route 53 Resolver の詳細については、「」を参照してください。Route 53 Resolver の使用を開始する()Amazon Route 53 開発者ガイド

ラージバイナリオブジェクト (LOB) の移行

一般的に AWS DMS は LOB データを 2 つのフェーズに移行します。

  1. AWS DMS は、ターゲットテーブルに新しい行を作成し、その行に関連する LOB 値を除くすべてのデータを入力します。

  2. AWS DMS は、ターゲットテーブルの行を LOB データで更新します。

この LOB の移行プロセスでは、移行中はターゲットテーブルのすべての LOB 列で null が許容されるようにする必要があります。これは、ソーステーブルの LOB 列で null が許容されていない場合にも該当します。AWS DMS がターゲットテーブルを作成すると、LOB 列はデフォルトで NULL に設定されます。インポートやエクスポートなどの他のメカニズムを使用してターゲットテーブルを作成することがあります。このような場合は、移行タスクを開始する前に LOB 列で null が許容されることを確認してください。

この要件には 1 つの例外があります。Oracle ソースから Oracle ターゲットへの同種移行を実行し、[制限付き LOB モード] を選択しているとします。この場合、すべての LOB 値を含めて、行全体が一度に入力されます。このような場合、AWS DMS では、必要に応じて、ターゲットテーブルの LOB 列を null 許容制約なしで作成できます。

制限付き LOB モードの使用

AWS DMS は、移行に LOB 値が含まれている場合に、パフォーマンスと利便性のバランスをとる 2 つのメソッドを使用します。

  1. [制限付き LOB モード] は、すべての LOB 値をユーザー指定のサイズ制限 (デフォルトは 32 KB) に移行します。サイズ制限を超える LOB 値は、手動で移行する必要があります。[制限付き LOB モード]、すべての移行タスクのデフォルトで、通常最高のパフォーマンスが得られます。ただし、LOB の最大サイズパラメーターの設定が正しいことを確認します。すべてのテーブルの最大 LOB サイズにこのパラメーターを設定します。

  2. [完全 LOB モード] は、サイズに関係なくテーブル内のすべての LOB データを移行します。[完全 LOB モード] は、テーブル内のすべての LOB データを移動する際の利便性を提供しますが、そのプロセスがパフォーマンスに重大な影響を与える可能性があります。

PostgreSQL など、一部のデータベースエンジンに対して、AWS DMS は JSON データ型を LOB のように扱います。選択した場合、必ず確認してください。制限付き LOB モードとすると、LOB の最大サイズオプションは、JSON データが切り捨てられない値に設定されています。

AWS DMS は、大きなオブジェクトのデータ型 (BLOB、CLOB、NCLOB) の使用を完全にサポートするようになりました。以下のソースエンドポイントは、完全に LOB サポートされています。

  • Oracle

  • Microsoft SQL Server

  • ODBC

以下のターゲットエンドポイントは、完全に LOB サポートされています。

  • Oracle

  • Microsoft SQL Server

以下のターゲットエンドポイントには、制限付きの LOB サポートがあります。このターゲットエンドポイントに無制限の LOB サイズは使用できません。

  • Amazon Redshift

  • Amazon S3

完全な LOB サポートがあるエンドポイントについては、LOB データ型にサイズ制限を設定できます。

LOB パフォーマンスの向上

AWS DMS エンジンバージョン 3.1.x では、いくつかの方法で LOB データの読み込みを改善できます。LOB データの移行中は、後でさまざまな LOB 最適化設定を指定できます。

テーブル単位の LOB 設定

テーブルごとの LOB 設定を使用すると、テーブルの一部またはすべてのタスクレベルの LOB 設定を上書きできます。これを行うには、定義するlob-settingstable-settingsルール。以下は、いくつかの大きなLOB値を含むテーブルの例です。

SET SERVEROUTPUT ON CREATE TABLE TEST_CLOB ( ID NUMBER, C1 CLOB, C2 VARCHAR2(4000) ); DECLARE bigtextstring CLOB := '123'; iINT; BEGIN WHILE Length(bigtextstring) <= 60000 LOOP bigtextstring := bigtextstring || '000000000000000000000000000000000'; END LOOP; INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue'); END; / SELECT * FROM TEST_CLOB; COMMIT

次に、移行タスクを作成し、新しいlob-settingsルール。-bulk-max-siz値は、最大 LOB サイズ (KB) を決定します。指定されたサイズより大きいと切り捨てられます。

{ "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "HR", "table-name": "TEST_CLOB" }, "rule-action": "include" }, { "rule-type": "table-settings", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "HR", "table-name": "TEST_CLOB" }, "lob-settings": { "mode": "limited", "bulk-max-size": 16 } ] }

この AWS DMS タスクがFullLobMode : trueでは、テーブルごとの LOB 設定により、AWS DMS がこの特定のテーブルの LOB データを 16,000 に切り捨てます。タスクログを確認して、これを確認できます。

721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table 'HR.TEST_CLOB' was truncated to length 16384

インライン LOB 設定

AWS DMS タスクを作成すると、LOB モードによって LOB の処理方法が決定されます。

完全な LOB モードと限定された LOB モードでは、それぞれ独自のメリットとデメリットがあります。インライン LOB モードは、フル LOB モードと制限付き LOB モードの両方の利点を組み合わせています。

小 LOB と大 LOB の両方をレプリケートする必要があり、ほとんどの LOB が小さい場合は、インライン LOB モードを使用できます。このオプションを選択すると、フルロード時に AWS DMS タスクによって小さな LOB がインラインで転送されるため、より効率的です。AWS DMS タスクは、ソーステーブルからルックアップを実行して大きな LOB を転送します。

変更処理中に、ソーステーブルからのルックアップを実行して、小規模および大規模の LOB の両方をレプリケートします。

インライン LOB モードを使用する場合、AWS DMS タスクはすべての LOB サイズをチェックし、インラインで転送するサイズを決定します。指定されたサイズよりも大きい LOB は、完全 LOB モードを使用してレプリケートされます。したがって、ほとんどの LOB が指定の設定よりも大きいことがわかっている場合は、このオプションを使用しない方がよいでしょう。代わりに、無制限の LOB サイズを許可します。

このオプションは、タスク設定の属性を使用して構成します。InlineLobMaxSizeです。これは、FullLobModeは、 に設定されます。true。のデフォルト値InlineLobMaxSizeは 0 です。指定できる範囲は 1 KB ~ 2 GB です。

たとえば、以下の AWS DMS タスク設定を使用できます。ここでは、設定InlineLobMaxSizeの値を 5 に設定すると、5,000 以下のすべての LOB がインラインで転送されます。

{ "TargetMetadata": { "TargetSchema": "", "SupportLobs": true, "FullLobMode": true, "LobChunkSize": 64, "LimitedSizeLobMode": false, "LobMaxSize": 32, "InlineLobMaxSize": 5, "LoadMaxFileSize": 0, "ParallelLoadThreads": 0, "ParallelLoadBufferSize":0, "BatchApplyEnabled": false, "TaskRecoveryTableEnabled": false}, . . . }

行のフィルタリングを使用して大規模なテーブルを移行する場合のパフォーマンスの向上

大規模なテーブルを移行する際のパフォーマンスを向上させるために、複数のタスクに移行を分割することができます。行フィルタリングを使用して複数のタスクへの移行を分割するには、キーまたはパーティションキーを使用します。たとえば、1〜8,000,000 の整数プライマリキー ID がある場合、行フィルタリングを使用して 8 つのタスクを作成し、それぞれ 100 万レコードを移行できます。

コンソールで行フィルタリングを適用するには、コンソールを開き、[タスクをクリックし、新しいタスクを作成します。[テーブルマッピング] セクションで、[Selection Rule (選択ルール)] の値を追加します。次に、(2 つの値の間で) より小さいか等しい、より大きいか等しい、等しいまたは範囲条件の列フィルタを追加できます。列フィルタについての詳細は、「 コンソールからのテーブル選択ルールおよび変換ルールを指定する」を参照してください。

または、日付で分割された大きなパーティションテーブルがある場合は、日付に基づいてデータを移行することもできます。たとえば、月別にパーティション化されたテーブルがあり、現在の月のデータのみが更新されたとします。この場合、静的な毎月のパーティションごとに全ロードタスクを作成し、現在更新されているパーティションに対して全ロード (CDC) タスクを作成することができます。

継続的なレプリケーション

AWS DMS は、ソースとターゲットのデータベースを同期させたまま、データの継続的なレプリケーションを行います。これは、限られた量のデータ定義言語 (DDL) ステートメントのみをレプリケートします。AWS DMS は、インデックス、ユーザー、権限、ストアドプロシージャ、およびテーブルデータに直接関係しない他のデータベースの変更などの項目を反映しません。

進行中のレプリケーションを使用する予定の場合は、Multi-AZオプションは、レプリケーションインスタンスを作成するときに使用します。選択することによりMulti-AZでは、レプリケーションインスタンスの高可用性とフェイルオーバーサポートが提供されます。ただし、このオプションによって、パフォーマンスに影響を及ぼす可能性があり、ターゲットシステムに変更を適用するときにレプリケーションの速度が遅くなる可能性があります。

ソースデータベースまたはターゲットデータベースをアップグレードする前に、これらのデータベースで実行されている AWS DMS タスクをすべて停止することをお勧めします。アップグレードが完了したら、タスクを再開します。

継続的なレプリケーションでは、ソースデータベースシステムと AWS DMS レプリケーションインスタンス間のネットワーク帯域幅を特定することが重要です。進行中のレプリケーション中にネットワークがボトルネックを引き起こさないことを確認します。

また、ソース・データベース・システムの 1 時間あたりの変更率とアーカイブ・ログ生成率を特定することも重要です。これにより、進行中のレプリケーション中に得られるスループットを把握できます。

ソースデータベースのロードを縮小する

AWS DMSは、ソースデータベースでいくつかのリソースを使用します。全ロードタスク中、AWS DMS は、並行処理される各テーブルのソーステーブルのテーブル全体のスキャンを実行します。また、移行の一環として作成する各タスクは、CDC プロセスの一部としてソースに変更を問い合わせます。AWS DMS で、Oracle などの一部のソースの CDC を実行する場合は、データベースの変更ログに書き込むデータ量を増やす必要がある場合があります。

ソースデータベースに過度に負荷を負わせている場合は、移行のタスクの数または、タスクごとのテーブルの数を減らしてください。各タスクは独立してソースの変更を取得するため、タスクを統合することで変更キャプチャの作業負荷を減らすことができます。

ターゲット・データベースのボトルネックの軽減

移行中に、ターゲット・データベースの書き込みリソースと競合するプロセスをすべて削除してください。

  • 不要なトリガーをオフにします。

  • 最初のロード時にセカンダリインデックスをオフにし、進行中のレプリケーション時に後でセカンダリインデックスをオンに戻します。

  • Amazon RDS データベースを使用する場合、カットオーバーまではバックアップとマルチ AZ を無効にすることをお勧めします。

  • 非 RDS システムに移行する場合、カットオーバーまではターゲットのログをオフにすることをお勧めします。

移行中のデータ検証の使用

データがソースからターゲットに正確に移行されたことを確認するため、データの検証を使用することを強くお勧めします。タスクのデータ検証を有効にすると、AWS DMS は、テーブルに対して全ロードが実行された後で、ソースデータとターゲットデータの比較をすぐに開始します。

データ検証は、AWS DMS がソースとターゲットのエンドポイントでサポートしている次のデータベースで動作します。

  • Oracle

  • PostgreSQL

  • MySQL

  • MariaDB

  • Microsoft SQL Server

  • Amazon Aurora MySQL 互換版

  • Amazon Aurora PostgreSQL 互換版

  • IBM Db2 LUW

詳細については、「AWS DMS データの検証」を参照してください。

メトリックスを使用した AWS DMS タスクのモニタリング

AWS DMS コンソールを使用してタスクのメトリックスをモニタリングするには、いくつかのオプションがあります。

ホストメトリクス

ホストメトリックは、CloudWatch メトリクスタブで、特定のレプリケーションインスタンスごとに選択します。ここでは、レプリケーションインスタンスが適切なサイズであるかどうかを監視できます。

レプリケーションタスクのメトリクス

受信およびコミットされた変更、レプリケーションホストとソース/ターゲットデータベースの間のレイテンシーなど、レプリケーションタスクのメトリクスについては、CloudWatch メトリクスタブで、特定のタスクごとに選択します。

テーブルメトリック

個々のテーブルメトリックスは、テーブル統計タブを開きます。これらのメトリックには、次の数値が含まれます。

  • フルロード中にロードされた行。

  • タスクの開始以降の挿入、更新、削除。

  • タスク開始以降の DDL 操作

メトリクスのモニタリングの詳細については、「」を参照してください。AWS DMS タスクのモニタリング

イベントと通知

AWS DMS は、Amazon SNS を使用して、AWS DMS イベントが発生したときに (レプリケーションインスタンスの作成や削除など) 通知を送信します。AWS リージョンに対して Amazon SNS でサポートされる任意の形式で、これらの通知を使用できます。これには、電子メールメッセージ、テキストメッセージ、または HTTP エンドポイントへの呼び出しが含まれます。

詳細については、「AWS Database Migration Service でのイベントと通知の使用」を参照してください。

タスクログを使用して、移行の問題のトラブルシューティングをする

場合によっては、AWS DMS で、タスクログでのみ表示可能な問題が発生することがあります。特に、データ切り捨て問題または外部キー違反による行の拒否は、タスクログに書き込まれます。そのため、データベースを移行するときは、タスクログを確認することが重要です。タスクログを表示するには、Amazon CloudWatch をタスク作成の一環として設定します。

詳細については、「」を参照してください。Amazon CloudWatch を使用したレプリケーションタスクのモニタリング

Oracle ターゲットのユーザーおよびスキーマの変更

Oracle をターゲットとして使用する場合、AWS DMS は、ターゲットエンドポイントのユーザーが所有するスキーマにデータを移行します。

たとえば、という名前のスキーマを移行する場合を考えます。PERFDATAを Oracle ターゲットエンドポイントに追加し、ターゲットエンドポイントのユーザー名がMASTER。AWS DMS は Oracle ターゲットにMASTERと、データ入力MASTERからデータベースオブジェクトを持つスキーマPERFDATA

この動作をオーバーライドするには、スキーマ変換を指定します。たとえば、PERFDATAスキーマオブジェクトをPERFDATAスキーマを使用する場合は、次の変換を使用します。

{ "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "PERFDATA" }, "rule-target": "schema", "rule-action": "rename", "value": "PERFDATA" }

変換の詳細については、「 JSON を使用するテーブル選択ルールと変換ルールの指定」を参照してください。

Oracle ターゲットのテーブルスペースとインデックスのテーブルスペースの変更

Oracle をターゲットとして使用する場合、AWS DMS はすべてのテーブルとインデックスをターゲットのデフォルトのテーブルスペースに移行します。たとえば、ソースが Oracle ではないデータベースエンジンだとします。すべてのターゲットテーブルとインデックスは、同じデフォルトのテーブルスペースに移行されます。

この動作をオーバーライドするには、対応するテーブルスペース変換を指定します。たとえば、テーブルとインデックスをソースのスキーマから名付けられた Oracle ターゲットのテーブルとインデックスのテーブルスペースに移行するとします。この場合、次のような変換を使用できます。ここでは、ソース内のスキーマの名前はINVENTORYターゲット内の該当するテーブルとインデックスのテーブルスペースは、INVENTORYTBLおよびINVENTORYIDX

{ "rule-type": "transformation", "rule-id": "3", "rule-name": "3", "rule-action": "rename", "rule-target": "table-tablespace", "object-locator": { "schema-name": "INVENTORY", "table-name": "%", "table-tablespace-name": "%" }, "value": "INVENTORYTBL" }, { "rule-type": "transformation", "rule-id": "4 "rule-name": "4", "rule-action": "rename", "rule-target": "index-tablespace", "object-locator": { "schema-name": "INVENTORY", "table-name": "%", "index-tablespace-name": "%" }, "value": "INVENTORYIDX" }

変換の詳細については、「 JSON を使用するテーブル選択ルールと変換ルールの指定」を参照してください。

Oracle がソースとターゲットの両方である場合、Oracle ソースの追加の接続属性を設定することで、既存のテーブルまたはインデックステーブルスペースの割り当てを保持できます。enableHomogenousTablespace=true。詳細については、「AWS DMS のソースとして Oracle を使用する場合の追加の接続属性」を参照してください。

レプリケーション・インスタンス・バージョンのアップグレード

AWS では、新機能とパフォーマンスの強化を含め、新しいバージョンの AWS DMS レプリケーションエンジンソフトウェアを定期的にリリースしています。レプリケーションエンジンソフトウェアの各バージョンには、独自のバージョン番号があります。レプリケーションインスタンスを新しいバージョンにアップグレードする前に、本番作業負荷を実行している既存のバージョンの AWS DMS レプリケーションインスタンスをテストすることが重要です。利用可能なバージョンのアップグレードの詳細については、「」を参照してください。AWS DMS リリースノート

移行コストの確認

AWS Database Migration Service、AWS にデータベースを簡単かつ安全に移行します。料金は、レプリケーションインスタンスおよび追加のログストレージに対してのみ発生します。各データベース移行インスタンスには、スワップ領域、レプリケーションログ、およびほとんどのレプリケーション用のデータキャッシュに十分なストレージが含まれており、インバウンドデータ転送は無料です。

初期ロード時またはピークロード時にさらに多くのリソースが必要になる場合があります。クラウド監視メトリックを使用して、レプリケーションインスタンスのリソース使用率を詳細に監視できます。その後、使用状況に基づいてレプリケーションインスタンスのサイズをスケールアップおよびスケールダウンできます。

移行コストの推定に関する詳細については、「」を参照してください。