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レプリケーションインスタンスを構成するには、ネットワークを構成します。これを行うと、2つのAWSレプリケーションインスタンスと同じVirtual Private Cloud (VPC) にあるリソース。これは、オンプレミスデータベースを仮想プライベートネットワーク (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 SCTPL/SQL や TSQL などのほとんどのアプリケーションコードを同等のターゲット言語に変換できます。

あなたは得ることができますAWS SCTから無料でダウンロードできますAWS。AWS SCT の詳細については、AWS SCT ユーザーガイドを参照してください。

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

を確認するAWS DMSパブリックドキュメント

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

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

概念実証の実施

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

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

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

  • 方法AWS DMSは、データ型と文字セットの変換を処理します。

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

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

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

いくつかの要因が AWS DMS 移行のパフォーマンスに影響を与えます。

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

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

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

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

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

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

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

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

AWS DMSAmazon 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 別のメモリが含まれます。

AWS DMSR5 および C5 インスタンスクラスのサポート

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では、Multi-AZ インスタンスを選択することで、ストレージの問題が発生した場合の可用性を向上させることができます。

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

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

この番号を変更するには、AWS Management Consoleを選択し、コンソールを開き、タスク] で、タスクの作成や変更を選択し、詳細設定。[Tuning Settings (チューニング設定)] で、[並列にロードするテーブルの最大数] オプションを変更します。

この数を変更するには、AWS CLIを変更するには、MaxFullLoadSubTasksパラメータの下のTaskSettings

並列全ロードの使用

パーティションとサブパーティションに基づいて、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 アドレスです。アウトバウンドエンドポイントのセキュリティグループを選択するときは、レプリケーションインスタンスで使用するものと同じセキュリティグループを選択します。

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

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

以下の図は、Route 53 リゾルバーアーキテクチャを示しています。


                Route 53 リゾルバアーキテクチャ

Route 53 DNS リゾルバーの詳細については、」を参照してください。Route 53 Resolver の使用開始Amazon Route 53 開発者ガイド

Amazon Route 53 Resolver 使用AWS DMS

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

のオンプレミスネームサーバーを作成するにはAWS DMSRoute 53 に基づく

  1. AWS Management Console にサインインし、Route 53 コンソール (https://console.aws.amazon.com/route53/) を開きます。

  2. Route 53 コンソールで、AWSRoute 53 リゾルバーを設定するリージョン。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 リゾルバの詳細については、」を参照してください。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 パフォーマンスの向上

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

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

のモニタリングAWS DMSメトリクスの使用タスク

タスクのメトリックを監視するには、いくつかのオプションがあります。AWS DMSコンソール:

ホストのメトリック

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

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

レプリケーションタスクのメトリクス (受信した変更とコミットされた変更、レプリケーションホストとソース/ターゲットデータベース間のレイテンシーなど) は、CloudWatch メトリクスタブを開きます。

テーブルメトリック

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

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

  • タスクの開始以降の挿入、更新、削除を行います。

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

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

イベントと通知

AWS DMSは、Amazon SNS を使用して通知を提供します。AWS DMSイベントが発生します (レプリケーションインスタンスの作成や削除など)。これらの通知は、Amazon SNS でサポートされている任意の形式で、AWSリージョン。これには、電子メールメッセージ、テキストメッセージ、または 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レプリケーションインスタンスを新しいバージョンにアップグレードする前に、本番作業負荷を実行しているレプリケーションインスタンス。利用可能なバージョンのアップグレードの詳細については、」を参照してください。AWSDMS リリースノート

移行コストの確認

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

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

移行コストの見積りに関する詳細については、以下を参照してください。