Category: AWS Database Migration Service*


OracleDBからPostgreSQLへの移行

 

Knievel Co は、アマゾン ウェブ サービスのデータベースエンジニアです。

このブログ記事では、Oracle データベースを PostgreSQL に移行する方法の概要について説明します。データベース移行の2つの主要部分は、スキーマの変換とデータの複製です。)AWS スキーマ変換ツール (AWS SCT) と AWS Database Migration Service (AWS DMS) を使用して、これら 2 つの部分に取り組む方法について説明します。

SCT と DMSについて説明する前に、予備的な手順を実行する必要があります。これらは、すべての移行に役立つことが判明しています。移行を容易にする方法の 1 つは、移行の前に、通常更新フェーズと呼ばれるものを行うことです。このフェーズでは、Oracle データベース内のオブジェクトのインベントリを作成し、いくつかの決定を下します。

最初に、不要になったオブジェクトを削除します。オブジェクトの移行にかかる時間は誰も気にかけませんが、無駄にしないでください。また、不要になった履歴データを削除することもできます。一時的なテーブルや過去のメンテナンス時のテーブルのバックアップコピーなど、不要なデータを複製するために時間を無駄にすることはありません。次に、LOB、CLOB、LONG などに保存されているフラットファイルおよび長い文字列を Amazon S3 または Amazon Dynamo DB に移動します。このプロセスではクライアントソフトウェアの変更が必要となりますが、データベースが簡素化されサイズが削減されることで、システム全体がより効率的になります。最後に、PL/SQL パッケージとプロシージャを移動します。特にビジネスロジックを含むものをクライアントソフトウェアに戻してみます。これらのオブジェクトは、SCT が変換できない場合は手動で変更する必要があります。

次の手順は、異なるデータベースエンジン (この場合は Oracle から PostgreSQL へ) に移行するための手順です。別のプラットフォームに移動していない場合は、データベースを移動するためのより適切なネイティブツールやその他のテクニックがあります。

  1. ターゲットデータベースでスキーマを作成します。
  2. ターゲットデータベースの外部キーとセカンダリインデックスを削除し、トリガーを無効にします。
  3. データを複製するためのDMSタスクを設定します (全ロードと変更データキャプチャ (CDC))。
  4. 全ロードフェーズが完了したらタスクを停止し、外部キーとセカンダリインデックスを再作成します。
  5. DMS タスクを有効にします。
  6. ツールとソフトウェアを移行し、トリガーを有効にします。

ターゲットデータベースでスキーマを作成します。

移行するスキーマを確認して、移行を開始します。このケースでは、AWS スキーマ変換ツール (AWS SCT) を使用して分析を実行します。アプリケーションを起動するときは、ソースが Oracle でターゲットが PostgreSQL となる新しいプロジェクトを作成する必要があります。再接続したら、左側で移行するスキーマの名前を選択します。スキーマ名を右クリックし、[スキーマの変換] を選択します。次に、[View / Assessment Report View] を選択します。

AWS SCT 評価レポートは、Oracle データベースを PostgreSQL に変換するために必要な作業の高レベルな概要を示します。以下に示しているのは、評価レポートの具体的な例です。

 

このレポートは、各オブジェクトタイプごとに手動で変換するために必要な手作業を示しています。一般的に、パッケージ、プロシージャ、関数には解決すべきいくつかの問題があります。AWS SCT では、これらのオブジェクトを修正する理由を説明し、その方法のヒントを示します。

スキーマが自動的に変換されない場合の、問題を解決するためのヒントを次に示します。

  • ソースの Oracle データベースのオブジェクトを変更して、AWS SCT がそれらをターゲットの PostgreSQL に変換できるようにします。
  • スキーマをそのまま変換し、AWT SCT によって生成されたスクリプトを手動で変更してから、それらをターゲットの PostgreSQL データベースに適用してみてください。
  • 変換できないオブジェクトを無視して、機能を別の AWS サービスまたは同等のものに置き換えます。

スキーマの変換機能を改善すると、反復プロセスを経てレポートとスキーマを再生成できます。[Action Items] ビューには、変換プロセスを実行する際に生じる問題のリストが表示されます。変換されたスキーマの結果が満足のいくものであれば、それらをターゲットの PostgreSQL データベースに適用することができます。

ターゲットデータベースのスキーマを参照し、列のデータ型、オブジェクト名などを簡単ににチェックすることをお勧めします。ソースおよびターゲットのデータ型の詳細については、「AWS Database Migration Service リファレンス」を参照してください。 また、Oracle から PostgreSQL への変換であるため、オブジェクト名が Oracle では大文字で、PostgreSQL では小文字であることが問題となります。

外部キー制約とセカンダリインデックスを削除する。トリガーを無効にする

ターゲット上に必要なスキーマを揃えるするには、ソースから実際のデータを移行するためにスキーマを準備する必要があります。ここでは、AWS Database Migration Service (AWS DMS) を使用します。DMSには、全ロードと変更データキャプチャ (CDC) の 2 つのフェーズがあります。全ロードフェーズでは、テーブルは順不同でロードされます。したがって、ターゲットで制約を有効にすると、いくつかの外部キーで制約違反が発生します。また、全ロード時には表のレプリケーションが遅くなる可能性があるため、セカンダリインデックスを無効にする必要があります。これは、レコードがロードされるときにインデックスを維持する必要があるためです。

ターゲットの PostgreSQL データベースで、クエリを実行してデータベーステーブルの外部キー制約に DDL を生成し、出力を保存します。これを行うための多くのサンプルクエリをオンラインで見つけることができます。次のような情報が表示されます。これを実行すると、後で外部キー制約を再作成するための DDL が提供されます。

ALTER TABLE <テーブル名> ADD CONSTRAINT <制約名> FOREIGN KEY(キー列)REFERENCES <親テーブル名>(キー列)MATCH FULL;

同様に、DDL 生成クエリを実行して、ターゲットデータベース上のすべての外部キー制約を削除します。

ALTER TABLE <テーブル名> DROP CONSTRAINT <制約名>;

ここで、セカンダリインデックスについても同じことを行います。つまり、コマンドを作成し結果を生成してから、セカンダリインデックスを削除します。

次に、トリガーを無効にします。

ALTER TABLE <テーブル名> DISABLE TRIGGER ALL;

ID 列でシーケンスを使用する場合は、ターゲットでシーケンスを作成するときに、次の値をソースデータベースよりも高く設定することをお勧めします。十分なギャップを残して、移行カットオーバーの日付で値がソースのデータベースの値よりも高くなっていることを確認してください。このアプローチによって、移行後のシーケンス ID の競合が回避されます。

DMS タスクを設定してデータをレプリケートする

ターゲットの PostgreSQL データベースでスキーマの準備ができました。これでデータをレプリケートする準備が整いました。これは DMS が入る場所となります。DMS の素晴らしい点は、各テーブルのデータをレプリケートするのではなく、移行する準備ができるまで CDC モードでデータを最新の状態で保持することです。

ソース Oracle データベースの準備:

  • Oracle ログインに必要な権限を確認します。
  • DMS が Oracle ソースデータベースから変更を取得するために必要なサプリメンタルロギングを設定します。
  • ソース Oracle データベースの準備の詳細については、DMS ドキュメントを参照してください。

AWS コンソールで DMS を起動します。最初に、レプリケーションインスタンスを作成する必要があります。レプリケーションインスタンスが DMS タスクを実行します。このインスタンスは、ソース Oracle データベースとターゲット PostgreSQL データベースの両方に接続する中間サーバーです。適切なサイズのサーバーを選択します。特に、複数のタスクの作成、多数のテーブルの移行、またはその両方を行う場合は、適切なサーバーを選択します。

次に、ソースデータベースのエンドポイントとターゲットデータベースのエンドポイントを作成します。Oracle データベースと PostgreSQL データベースの適切な接続情報をすべて入力します。各エンドポイントの作成が完了する前に、接続テストが成功した後で必ずスキーマの更新オプションを選択し、テストを実行 してください。

これで、タスクを作成する準備ができました。タスク名を入力し、作成したレプリケーションインスタンス、およびソースおよびターゲットエンドポイントを選択します。[移行タイプ] で、[既存データの移行と進行中の変更のレプリケート] を使用します。スキーマを事前に作成するためにAWS SCTを使用しているため、[ターゲットテーブル準備モード][何もしない] または [切り詰め] を選択します。

オプション [全ロードの完了後にタスクを停止する] で、[キャッシュされた変更の適用後に停止] を選択します。完全ロードが完了し、キャッシュされた変更が適用された後で、タスクを一時的に停止します。キャッシュされた変更は、テーブル全体のロードプロセスが実行されている間に発生し蓄積された変更です。これは、CDC が適用される直前のステップです。

できれば、ソース Oracle データベースを更新して、LOB を S3、DynamoDB、または別の同様のサービスに移動します。そうでない場合は、LOB を処理する方法についていくつかのオプションがあります。すべてのテーブルの LOB 全体をレプリケートする場合は、[レプリケーションに LOB 列を含める] で、[完全 LOB モード] を選択します。LOB を特定の長さまでレプリケートするのみの場合は、[制限付き LOB モード] を選択します。移行する LOB の長さは、[最大 LOB サイズ (KB)] テキストボックスで指定します。

最後に、[ログ作成の有効化] を選択して、タスクで発生したエラーや警告を確認し、問題のトラブルシューティングを行えるようにすることをお勧めします。[タスクの作成] を選択します。

次に、[テーブルマッピング] で移行するスキーマを選択し、[選択ルールの追加] を選択します。[JSON] タブを選択します。[JSON の編集を有効にする] チェックボックスを選択します。次に、次の JSON 文字列を入力し、スキーマ名 DMS_SAMPLE を使用するスキーマ名に置き換えます。

 

{

 "rules": [

  {

   "rule-type": "selection",

   "rule-id": "1",

   "rule-name": "1",

   "object-locator": {

    "schema-name": "DMS_SAMPLE",

    "table-name": "%"

   },

   "rule-action": "include"

  },

  {

   "rule-type": "transformation",

   "rule-id": "6",

   "rule-name": "6",

   "rule-action": "convert-lowercase",

   "rule-target": "schema",

   "object-locator": {

    "schema-name": "%"

   }

  },

  {

   "rule-type": "transformation",

   "rule-id": "7",

   "rule-name": "7",

   "rule-action": "convert-lowercase",

   "rule-target": "table",

   "object-locator": {

    "schema-name": "%",

    "table-name": "%"

   }

  },

  {

   "rule-type": "transformation",

   "rule-id": "8",

   "rule-name": "8",

   "rule-action": "convert-lowercase",

   "rule-target": "column",

   "object-locator": {

    "schema-name": "%",

    "table-name": "%",

    "column-name": "%"

   }

  }

 ]

}

この JSON 文字列は、PostgreSQL の場合、スキーマ名、テーブル名、列名を小文字に変換します。

タスクが作成されると、自動的に開始されます。タスクを選択して[ステータス] タブをクリックすると、DMS コンソールを使用して進行状況を監視できます。全ロードが完了しキャッシュされた変更が適用されると、タスクは自動的に停止します。

全ロードフェーズが完了したらタスクを停止し、外部キーとセカンダリインデックスを再作成します。

テーブルのロードが完了しました。今度は、ログを確認してタスクにエラーがないことを確認するのがよいでしょう。

タスクの次のフェーズは、ソースデータベースで発生した順序で変更を適用する CDC です。このアプローチは、親テーブルがターゲットデータベース上の子テーブルの前に更新されるため、外部キーを再作成できることを意味します。

必要に応じて生成されたスクリプトを調整して、以前に削除された外部キーとセカンダリインデックスを再作成します。セカンダリインデックスはタスクのこのフェーズで重要となります。このフェーズは重要です。なぜなら、where 句を使用してソースデータベースに対して行われた更新は、ターゲットデータベース上のインデックスのルックアップでもあるからです。更新に欠落しているインデックスがある場合、これらの更新は全テーブルスキャンとして実行されます。

ソースからのデータを更新できるため、移行の切り替えまでトリガーを有効にしないでください。

DMS タスクを有効にする

これで外部キーとセカンダリインデックスが戻ったので、DMS タスクを有効にすることができます。DMS コンソールに移動して、[タスク] を選択します。リストでタスクを選択し、[開始/再開] を選択します。[開始] オプションを選択し、[タスクの開始] を選択します。

ツールとソフトウェアを移行し、トリガーを有効にします。

最後に、カットオーバーポイントがここにあります。ツールとソフトウェアの接続がソースデータベースへのアクセスを停止し、DMS タスクが最後のデータ変更をターゲットデータベースにレプリケートしたら、DMS コンソールで DMS タスクを停止します。次に、ターゲットデータベースでトリガーを有効にします。

ALTER TABLE <テーブル名> ENABLE TRIGGER ALL;

最後のステップは、アプリケーションを新しいターゲット PostgreSQL データベースに再配置して再起動することです。完了です。

役立つヒント

スキーマを変換しやすくするには、AWS SCT を使用して評価レポートを取得し、アクション項目を反復処理します。ターゲット PostgreSQL スキーマの最終バージョンに到達するまで、ターゲットスキーマを複数回生成する必要があります。
新しいスキーマのクエリが新しいプラットフォームで機能するようにするには、ターゲットシステムでアプリケーションをテストします。AWS SCT は、アプリケーションクエリを PostgreSQL に変換することもできます。詳細については、AWS SCT ドキュメントを参照してください。また、ターゲットシステムの負荷テストを実装して、ターゲットサーバーのサイズとデータベース設定が正しいことを確認します。
前に概要を説明した実際の移行手順を実践し、プロセスを合理化します。上記の手順は単なる出発点に過ぎず、各データベースは一意のものです。

詳細情報

また、次を検討することをお勧めします。

AWS SCT および AWS DMS のドキュメント
DMS のステップバイステップチュートリアル
DMS のベストプラクティス
GitHub の DMS サンプルデータベース
関連するブログ記事: SQL を使用して Oracle から PostgreSQL へユーザー、ロール、および許可をマップする

AWS Migration Hub – エンタープライズアプリケーションの移行の計画と追跡

1週間に約1回、私はシアトルのエグゼクティブブリーフィングセンターで現在の有力なAWSのお客様に話します。一般的に私はイノベーションプロセスに重点を置いていますが、アプリケーションの移行を含む他のトピックについても議論することがあります。企業がアプリケーションポートフォリオを移行する場合、企業は構造化された整然としたやり方でそれを実行したいと考えています。これらのポートフォリオは、通常、何百もの複雑なWindowsおよびLinuxアプリケーション、合理的なデータベースなどで構成されています。お客様は、進め方についてはまだ不確実であることがわかります。これらの顧客と一緒に働く時間を費やした後、彼らの課題は一般的に次の3つの主要カテゴリに分類されることがわかりました。

ディスカバリー – お客様は、各アプリケーションを動かす全ての部分について、深くて完全な理解を得たいと考えています。

サーバー&データベース移行 – オンプレミスのワークロードとデータベースのテーブルをクラウドに転送する必要があります。

追跡/管理 – 大規模なアプリケーションポートフォリオと複数の移行が並行して行われるため、アプリケーション中心の方法で進捗状況を追跡および管理する必要があります。

ここ数年、私たちは最初の2つの課題に取り組む一連のツールを立ち上げました。 AWS Application Discovery Serviceはシステム情報の検出と収集のプロセスを自動化し、AWS Server Migration Serviceはクラウドへのワークロード移行を処理し、AWS Database Migration Serviceは最小のダウンタイムでリレーショナルデータベース、NoSQLデータベース、データウェアハウスを移行します。 RacemiCloudEndureなどのパートナーは、独自の移行ツールも提供しています。

新しいAWS Migration Hub

今日、これらAWSサービスとパートナー移行ツールをAWS Migration Hubに統合しています。ハブは、前述のツールへのアクセスを提供し、移行プロセスをガイドし、Migration Acceleration Program(MAP)で説明されている方法論および原理に従って、各移行の状況を追跡します。

ここにメイン画面があります。移行プロセス(ディスカバリー、移行、および追跡)の概要を示します。

Start discovery」をクリックすると、移行プロセスのフローが表示されます。

ディスカバリー手順をスキップしてすぐに移行を開始することもできます。

AWS移行サービス(Server Migration ServiceまたはDatabase Migration Service)のデータ、パートナーツール、またはAWS Application Discovery Serviceによって収集されたデータを使用し、サーバーリストが作成されます。

自分用の最初のアプリケーションを作成するには、「Group as application」を選択することができます。

移行するアプリケーションを特定したら、そのアプリケーションをHubの「Applications」セクションで追跡できます。

移行ツールは承認されている場合、アプリケーションの移行ステータスページに表示するために、ステータスの更新と結果を自動的にMigration Hubに送信します。ここでは、Racemi DynaCenterCloudEndure Migrationが担当する部分の移行を実施したことがわかります。

Migration Hub Dashboardをチェックすると、移行のステータスを追跡できます。

Migration Hubは、AWSと移行パートナーの移行ツールと連携して動作します。詳しくは、Integrated Partner Toolのリストをご覧ください。

 

今すぐ利用可能

AWS Migration Hubは、必要となる移行ツールが利用可能な様々なAWSリージョンの移行を管理できます。Hub自体は米国西部(オレゴン州)地域で運営されています。Hubは無料です。移行の過程で消費するAWSサービスに対してのみお支払いいただきます。

クラウドへの移行を開始する準備ができていて、何らかの支援が必要な場合は、Migration Accelerationパートナーのサービスを利用してください。これらパートナーは、大規模な移行を繰り返し実践・提供することを通じて移行コンピテンシーを獲得しています。

Jeff;

(翻訳は諸岡が担当しました。原文はこちら)

オンプレミスや Amazon EC2 上の Oracle Database を Amazon Redshift に移行

AWS Database Migration Service (AWS DMS) は、簡単かつ安全なAWSへのデータベース移行の手助けをします。AWS Database Migration Service は広く使われている商用データベースとオープンソースデータベースに対応しています。このサービスはOracleからOracleのような同一プラットフォームでの移行に対応していますし、Oracleから Amazon Aurora や、Microsoft SQL Server からMySQLのような異なるプラットフォーム間での移行にも対応しています。移行元のデータベースは移行中も完全に動作しつづけたままであり、データベースに依存するアプリケーションのダウンタイムを最小限に抑えます。

AWS Database Migration Service を使用したデータレプリケーションは、AWS Schema Conversion Tool (AWS SCT) と緊密に統合されており、異なるプラットフォーム間でのデータベース移行プロジェクトを簡略化します。異なるプラットフォーム間での移行には AWS SCT を使用できますし、同一プラットフォームであれば移行元エンジンの純正スキーマ出力ツールが使えます。

この投稿では、Oracle Database のデータウェアハウスから Amazon Redshift へのデータ移行にフォーカスします。

以前の AWS SCT では、Oracle Database のビューやファンクションなどのカスタムコードを Amazon Redshift と互換性のあるフォーマットに変換できませんでした。ビューとファンクションを変換するには、最初に Oracle Database スキーマをPostgreSQLに変換し、それから Amazon Redshift と互換性のあるビューとファンクションを抽出するスクリプトを実行する必要がありました。

お客様のフィードバックに基づいたアップデートの後、AWS SCT と AWS DMS を使用して Oracle Database のビューとファンクションを Amazon Redshift に移行できるようになりました。

次の図は移行手順を示しています。

準備

この移行を開始するには次の手順を実行します。

  • AWS SCT をダウンロード
  • AWS SCT グローバル設定 からデータベースドライバーをダウンロードし、そのパスを設定。
  • 米国西部(オレゴン)リージョンで使用できる Amazon EC2 キーペアを用意。持っていない場合は新しい Amazon EC2 キーペアを作成。

スタックの作成

この投稿では、AWS CloudFormation スタックを起動するために、以下の Launch Stack を使います。起動プロセス中に前述のアーキテクチャも作成されます。結果は AWS DMS コンソールで確認できます。移行が終わると、CloudFormationスタックは破棄できます。

このリンクは米国西部(オレゴン)リージョン (us-west-2) でスタックを開始します。

一部のリソースを使用されている間は料金が発生します。

Launch Stack

スタックを起動して名前を付けるには、次のようにします。

  1. AWSアカウントにまだログインしていない場合はログイン。
  2. Launch Stack を選んで、あらかじめ用意されたCloudFormationテンプレートでCloudFormationコンソールを起動。「次へ」を選択。
  3. スタック名には入力済みのorclrsmigrationを使用するかカスタム名を入力。KeyNameを選択し、Redshiftクラスター用のMasterUserPasswordを入力し、「次へ」を選択。
    Specify Details
  4. 確認ページにて、スタックの起動結果としてCloudFormationが AWS Identity and Access Management (IAM) ロールを作成することを確認。「作成」を選択。
    I acknowledge that AWS CloudFormation might create IAM resources with custom names.
  5. スタック作成の進行状況を確認するには更新ボタンを押し、起動イベントを表示するスタックを選択。
    Eventsタブ
  6. スタックが正常に起動すると、状況はCREATE_IN_PROGRESSからCREATE_COMPLETEに変わります。次のセクションで使用する値を表示するには「出力」を選択。
    Outputsタブ

このCloudFormationテンプレートによって作成されたインフラは、次のセクションで使用されます。以下のテーブルでリストされている値が表示されています。

Schema Conversion Tool での設定

Schema Conversion Tool での設定のために、以下を実行します。

  1. AWS Schema Conversion Tool を開始。
  2. Fileから New Project を選択。New Project ダイアログが表示される。
    New Project dialog
    次のプロジェクト情報を追加。

    Project Name プロジェクト名を入力。コンピュータにローカル保存される
    Location ローカルプロジェクトファイルの保存先を入力
    Data Warehouse (OLAP)
    Source DB Engine Oracle DW
    Target DB Engine Amazon Redshift
  3. AWS Schema Conversion Tool プロジェクトを作成するためOKを選択。
  4. Oracle Database に接続するため、Connect to Oracle DW を選択。

    Connect to Oracle DW ダイアログが表示される。移行元の Oracle Database 接続情報を入力。

    以下の値をフォームに入力。

    Server name <移行元EC2エンドポイントのDNS名>
    Server port 1521
    Oracle SID XE
    User name dms_sample
    Password dms_sample
    Use SSL チェックしない
  5. 移行元のデータベースに正しく接続できるかを確認するため、Test Connection を選択。
  6. 移行元データベースに接続するため、OKを選択。
  7. DMS_SAMPLEデータベースを選び、Nextを選択。
  8. Database Migration Assessment Report を読み、Nextを選択。

  9. Amazon Redshift に接続するため、Connect to Amazon Redshift を選択。

    Connect to Amazon Redshift ダイアログが表示される。移行先のデータベース接続情報を入力。

    以下の値をフォームに入力。

    Server name 移行先RedshiftエンドポイントのDNS名
    Server port 5439
    Database dev
    User name admin
    Password CloudFormationで選ばれたパスワード
    Use SSL チェックしない
  10. 移行先のデータベースにただしく接続できるかを確認するため、Test Connection を選択。
  11. 移行先データベースに接続するため、OKを選択。

スキーマを変換

次にスキーマを変換します。

  1. Viewを選び、Main View を選択。
  2. 移行元のデータベースのスキーマを表示している左側のパネルから変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Convert schema を選択。
  3. AWS Schema Conversion Tool でのスキーマ変換が完了すると、選択されたスキーマがビューやファンクションを含めて移行先の Amazon Redshift クラスター上で表示されます。この時点では、移行先の Amazon Redshift クラスターにスキーマは適用されていません。このウィンドウでスキーマを編集できます。編集したスキーマはプロジェクトの一部として保存されます。変換されたスキーマをデータベースに適用することを選択すると、編集されたスキーマが移行先DBインスタンスに書き込まれます。
  4. 移行先データベースのスキーマを表示する右側のパネルで、変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Applyを選択。

この時点で、データが空の状態のデータベーススキーマが Amazon Redshift クラスター上にできあがります。

データベース移行のために AWS DMS を構成

次にDMSに移ります。

  1. AWSマネジメントコンソールでDMSを選び、「移行の作成」を選択。
  2. 「AWS Database Migration Service へようこそ」ページで「次へ」を選択。
  3. 「レプリケーションインスタンスの作成」ページが表示される。

    このページで以下の値を入力し、「次へ」を選択。

    名前 8から16文字のASCII文字によるレプリケーションインスタンスの名前(/、”、@を除く)
    説明 レプリケーションインスタンスの説明を入力
    インスタンスクラス dms.t2.medium
    VPC 使いたい Amazon Virtual Private Cloud (Amazon VPC) を選択。移行元または移行先または両方があるVPCを使う
    Multi-AZ いいえ
    パブリックアクセス可能 チェック
  4. 「アドバンスト」タブはデフォルトのままで、「次へ」を選択。

データベースエンドポイントの設定

  1. ソースエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン oracle
    サーバー名 <移行元EC2エンドポイントのDNS名>
    ポート 1521
    SSLモード none
    ユーザー名 dms_sample
    パスワード dms_sample
  2. ターゲットエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン redshift
    サーバー名 <RedshiftエンドポイントのDNS名>
    ポート 5439
    SSLモード none
    ユーザー名 admin
    パスワード CloudFormationで選ばれたパスワード

レプリケーションインスタンスが正しく作成された後に「テストの実行」を選ぶことで、エンドポイントへの接続をテストできます。

タスクの作成

「タスクの作成」ページでタスクのオプションを設定します。

以下のテーブルはタスクの設定について説明しています。

タスク名 タスク名を入力
ソースエンドポイント 使用する移行元エンドポイントを選択
ターゲットエンドポイント 使用する移行先エンドポイントを選択
レプリケーションインスタンス 使用するレプリケーションインスタンスを選択
移行タイプ Migrate existing data
作成時にタスクを開始 チェックする

「ターゲットテーブル作成モード」は「何もしない」を選択。

「テーブルマッピング」ではdms_sampleを選び、Add selection rule を押して、「タスクの作成」を選択。

タスクの監視

タスクの作成で「作成時にタスクを開始」を選んだ場合、「タスクの作成」を選択するとすぐにデータ移行が開始されます。AWSマネジメントコンソールから実行中のタスクを選ぶことで、タスクの統計と監視の情報を表示できます。次のスクリーンショットはデータベース移行のテーブル統計を表しています。

まとめ

この投稿では Oracle Database の商用環境をビューやファンクションとともに Amazon Redshift に移行することがいかに簡単であるかをご紹介しました。


翻訳はソリューションアーキテクト柴田(シバタツ)が担当しました。原文は Migrating Oracle Database from On-Premises or Amazon EC2 Instances to Amazon Redshift です。

Oracle Database を Amazon Aurora に移行する方法

この投稿では、商用データベースから Amazon Aurora への移行を容易にするために AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) をどのように使えるかの概要をお伝えします。今回は、Oracleから Amazon Aurora with MySQL Compatibility への移行にフォーカスします。

データベースエンジンの変更は不安を伴うかもしれません。しかし、Amazon Aurora のようなスケーラビリティやコスト効果の高いフルマネージドサービスのバリュープロポジションは、それに挑戦する価値を生み出します。その手順を簡単にするツールがある場合は特にです。データベースをあるエンジンからほかのものに移行するとき、主に2つのことを考慮する必要があります。スキーマとコードオブジェクトの変換と、データ自身の移行と変換です。幸いにも、データベースの変換と移行の両方を容易にするツールをAWSは用意しています。

AWS Schema Conversion Tool は移行元データベースのスキーマとカスタムコードの大部分を新しい移行先データベースと互換性のあるフォーマットに自動的に変換することで、異なるプラットフォーム間でのデータベース移行をシンプルにします。このツールが変換するカスタムコードには、ビューやストアドプロシージャ、ファンクションを含みます。このツールで自動変換できない一部のコードは明確に示されるので、ユーザー自身でそれを変換することができます。AWS Database Migration Service は最小限のダウンタイムでデータを簡単かつ安全に移行することを手助けします。

すばらしい! では、どこから始まれば良いのでしょう?

AWS SCT での移行手順

通常、移行の最初のステップは実現可能性と作業量のアセスメントです。現行のOracleからAuroraにデータベースを移行するために要する作業量の大枠な概要を AWS SCT は生成することができます。SCTはいくつかのOS上で動作しますが、このブログではWindows上で動かします。SCTをダウンロードするためには、マニュアルの AWS Schema Conversion Tool のインストールと更新 をご覧ください。SCTのマニュアル全体を見たい場合は AWS Schema Conversion Tool とは からご覧ください。

この投稿ではSCTのイストールや構成については触れませんが、注意点は移行元と移行先のデータベースにSCTを接続するために、OracleとMySQLのドライバーをインストールする必要があることです。移行元のOracleに接続した後、スキーマのいずれかを右クリックしてアセスメントレポートを作成できます。アセスメントレポートはこのスキーマがどれくらいOracleからAuroraに自動変換されるのかと、自動変換後に残された作業量がどれくらいなのかの概要を教えてくれます。以下がレポートの例です。

Database Objects with Conversion Actions for Amazon Aurora

アセスメントレポートに加えて、SCTは各オブジェクトがどれくらい正確に変換されるかも教えてくれます。もしあるオブジェクトが変換できない場合、SCTはその理由と、状況を改善するためのヒントを教えてくれます。

Database Objects with Conversion Actions for Amazon Aurora

スキーマの100%がOracleからAuroraに変換されない場合、いくつかの方法で状況を改善できます。

  • 移行元のOracleのデータベース上のオブジェクトを変更して、SCTでAuroraに変換できるようにする
  • スキーマをひとまず変換し、SCTによって生成されたスクリプトを変更してからAuroraデータベースに適用する
  • 変換できないオブジェクトを無視し、移行先でそれらを置き換えるか無視する。たとえば、Oracleのsys.dbms_randomパッケージを呼び出すファンクションがあるとします。このパッケージはAuroraには存在しません。この問題を解決するには以下のことができます。
    • ランダム値の生成をアプリケーションコードに移し、それをパラメーターとしてファンクションに渡します。この変更は、変換前の移行元データベースまたは変換後の移行先データベースで行うことができます。
    • SCTで生成されたコードを、MySQLに存在するRAND()ファンクションを使うように変更し、新しいコードをAuroraデータベースに適用します。

その他の例として、一意の識別子を生成するためにOracleのシーケンスを使っているとします。Auroraはシーケンスをサポートしていないので、修正するために以下を実行してください。

  • 自動的に一意の識別子を生成するAuroraのauto-increment機能を使う。この方法で行く場合は、Auroraデータベースにスキーマを作成した後で、移行先のテーブルを変更するためのスクリプトを作成することをお勧めします。
  • 一意の識別を生成する何か別の方法(ファンクションや類似のもの)を作成し、シーケンスを参照している部分を新しいファンクションで置き換える。これは変換前に移行元のOracle上で実施することも、移行先のAuroraで実施することもできます。
  • 両方の手法を使う必要があるかもしれません。

一般的に、移行の一環としてSCTを使うための良い取り組み方には以下を含みます。

  • SCTアセスメントレポートを作成し、移行のギャップを埋める計画を立てる。もし移行候補となる複数のシステムがある場合は、どのシステムから最初に取り組むべきかの決定に役立ちます。
  • Action Items を確認し、変換に失敗した各項目の適切な処理を決定する。
  • 新しいAuroraデータベースに対してアプリケーションをテストしながら、AWS Database Migration Service と連携して新しいスキーマにデータをロードし、この処理を繰り返す

AWS DMS での移行手順

AWS DMS は移行元のOracleデータベースから移行先の新しいAuroraデータベースにデータをロードするときに使えます。DMSの素晴らしい点は、データを丸ごとロードすることに加えて、実行中のトランザクションをキャプチャして適用することです。カットオーバーの準備が整うまで、Oracleの移行元データベースとAuroraの移行先データベースを同期させつづけます。このアプローチによって、移行を完了させるために必要な停止時間を大幅に短縮することができます。DMSマイグレーションには、移行元エンドポイントであるOracle、移行先エンドポイントであるAurora、レプリケーションサーバー、タスクを含みます。

OracleからAuroraに移行するとき、既存データを移行し、進行中の更新をレプリケーションするタスクを構成したいでしょう。これにより、データ全体の移行中に実行されたトランザクションをキャプチャするようにDMSに指示します。データ全体がロードされると、DMSはキャプチャされたトランザクションの適用を開始し、OracleとAuroraのデーベースの同期を開始します。Auroraをカットオーバーする準備ができたら、アプリケーションを停止し、残ったトランザクションをDMSに適用させ、新しいAuroraデータベースに接続するアプリケーションを開始するだけです。

DMSを使用してOracleからAuroraに移行する場合、考慮すべき点がいくつかあります。

サプリメンタルロギング。 DMSが移行元のOracleから更新をキャプチャするにはサプリメンタルロギングを有効にする必要があります。詳細な手順については、DMSのマニュアルを参照してください。

DMSの3つのフェーズ。 データを移行し、進行中の更新をキャプチャするとき、DMSは3つのフェーズを経ています。

  • バルクロード: バルクロードフェーズで、DMSはn個のテーブルを一度にまとめてロードします。デフォルトでは n = 8 です。この値はDMSマネジメントコンソールまたは AWS CLI を利用して変更できます。
  • キャッシュされたトランザクションの適用: バルクロードフェーズにDMSは移行元データベースへの更新をキャプチャします。あるテーブルのバルクロードが完了すると、DMSはバルクロードの一部であるかのようにキャッシュされた更新をできるだけ速くそのテーブルに適用します。
  • トランザクションとしての適用: すべてのテーブルのバルクロードが完了すると、DMSはキャプチャされた更新を単一のテーブルの更新ではなく、トランザクションとして適用し始めます。

セカンダリインデックス。 状況によっては、性能上の理由からDMSのバルクロードフェーズにセカンダリインデックスを削除したくなるかもしれません。バルクフェーズ中にセカンダリインデックスの一部またはすべてを削除することを選ぶ場合は、移行を一時停止して、トランザクションとしての適用フェーズでそれらを追加しなおす必要があります。すべてのテーブルのフルロードが完了した後であれば、移行を安全に一時停止することができます。

外部キー、トリガーなど。 バルクロードはテーブル単位で行われるため、バルクロードやキャッシュされたトランザクションの適用フェーズでは移行先のAurora内の外部キーに違反する可能性があります。initstmt=SET FOREIGN_KEY_CHECKS=0 をAuroraエンドポイントの追加接続属性として加えることで、外部キー検査を無効にすることができます。一般的に、データのバルクロードを中断したり悪影響を与える可能性のあるものにどう対処するかの戦略を策定する必要があります。たとえば、問題を回避するために、移行のカットオーバーフェーズになるまでトリガーの実装を延期することができます。

データ型。 新しいデータベースエンジンに移行するときには、どのようなデータ型がサポートされているかと、移行元のデータ型を移行先の新しいデータ型にどう変更するかを理解することが重要です。これについては、移行元のOracleのデータ型移行先のAuroraのデータ型をマニュアルで確認すべきです。

性能。 移行の全体的な性能は、移行元のOracle内のデータ量、種類、分散に依存しています。 AWS Database Migration Service Best Practices ホワイトペーパーに移行性能を最適化するためのいくつかの推奨事項が載っています。

手順をおさらいすると、

  1. SCTアセスメントレポートを使用して課題の概要を知ることができます。Auroraへの移行候補が複数ある場合は、どれから最初に取り組むべきかの決定に役立ちます。
  2. 処理の前後に必要となるかもしれない移行手順を洗い出すために、DMSを使用して移行先スキーマの作成とロードを実践します。
  3. 移行先のシステムでアプリケーションをテストして、新しい環境で期待通りに動作することを確認します。負荷やネットワーク環境を含む本番環境と同等の構成でテストしてみてください。
  4. スキーマの生成、データのロード、後処理の手順の適用、移行元と移行先システムの同期、カットオーバーに必要な手順などの実際の移行を実践します。
  5. SCTもDMSをシステム全体を一度に移行することを求めません。システムを短期間で効率的に移行するため、また必要であれば再構築するために、これらのツールを使用することができます。

実際の移行を開始する前に、SCTとDMSの両方のドキュメントを通して読むことをお勧めします。また、Step-by-Step ウォークスルーAWS Database Migration Service Best Practices ホワイトペーパー を読むこともお勧めします。

ツールの使い方を知るためにサンプルデータベースを使用したいのであれば、AWS GitHub リポジトリ で見つけることができます。

この投稿は特定の状況に必要な可能性のあるすべての手順や考慮事項を解説するものではありませんが、SCTとDMSを使用してプロプライエタリなOracleデータベースの足かせをどう緩められるかについての良いアイデアを提供しました。それでは幸せな移行を!


翻訳はソリューションアーキテクト柴田(シバタツ)が担当しました。原文は How to Migrate Your Oracle Database to Amazon Aurora です。

【AWS Database Blog】AWS Database Migration Service におけるイベント通知

こんにちは。ソリューションアーキテクトの江川です。本日は、AWS のプロダクトマネージャーである Eran Schitzer が、AWS Database Blogに投稿したEvents and Notifications in AWS Database Migration Service を翻訳してご紹介します。


先日、AWS Database Migration Service (AWS DMS) に新機能が追加され、Amazon Simple Notification Service (Amazon SNS)を介して、Email や テキストメッセージ、HTTP エンドポイントへの通知といった形で、DMS のイベント通知を受け取れるようになりました。

お客様は2種類のイベント(DMS インスタンスに関連するイベントと、レプリケーションタスクに関連するイベント)をサブスクライブし、通知を受信できます。DMS インスタンスに関連するイベントには、可用性、設定変更、作成、削除、メンテナンスに関するイベントが含まれます。例えば、DMS インスタンスがメンテナンスにより停止すると、通知がトリガーされます。

レプリケーションタスクに関連するイベントには、タスクの開始、停止、終了、Full Load の完了、CDC の開始などのイベントが含まれます。例えば、移行タスクとしてすべてのデータを移行し終えると、“Full Load completed” という通知がトリガーされます。もし、タスクが Full Load に続けて、CDC を実行する(つまり、Full Load が開始してからのデータの変更をレプリケーションする)設定となっていた場合は、続けて “CDC started” という通知がトリガーされます。

さらに、AWS DMS ではイベントが様々なカテゴリに分類されており、ユーザーは AWS DMS コンソール、AWS DMS API を使って、そのカテゴリをサブスクライブできます。サブスクライブすることにより、そのカテゴリに関するイベントが起きた際に、通知されます。例えば、特定のレプリケーションインスタンスについての “creation(作成)”カテゴリをサブスクライブした場合、レプリケーションインスタンスが作成されているなどのような、レプリケーションインスタンスに影響を与える creation に関連したイベントが起きた際はいつでも通知がなされます。

下記の一覧は、現時点で DMS レプリケーションインスタンスについてサブスクライブできるカテゴリを示しています。

  • Configuration change(設定変更)—レプリケーションインスタンスの設定が変更されています
  • Creation(作成)—レプリケーションインスタンスが作成されています
  • Deletion(削除)—レプリケーションインスタンスが削除されています
  • Maintenance(メンテナンス)—レプリケーションインスタンスのオフラインメンテナンスが実行中です
  • Low storage—レプリケーションインスタンスの空きストレージが少なくなっています
  • Failover(フェイルオーバー)—Multi-AZ インスタンスのフェイルオーバーに関連するイベント。フェイルオーバーの有効化、開始、完了など。
  • Failure(失敗)—レプリケーションインスタンスで、ストレージ障害やネットワーク障害が発生しました

下記の一覧は、現時点で DMS レプリケーションタスクについてサブスクライブできるカテゴリを示しています。

  • State change— レプリケーションタスクが開始もしくは停止されました
  • Creation(作成)—レプリケーションタスクが作成されました
    Deletion(削除)—レプリケーションタスクが削除されました
  • Failure(失敗)—レプリケーションタスクが失敗しました

AWS DMS によるイベントとイベントカテゴリの一覧は、ドキュメントのイベントと通知の使用を参照してください。

AWS DMS イベントをサブスクライブするには、以下の通り行います。

  1. Amazon SNS トピックを作成します。このトピックには、どんなタイプの通知を受け取りたいか、受け取るアドレスや電話番号を設定します。
  2. AWS マネジメントコンソール、AWS CLI, もしくは AWS DMS API を通じて、AWS DMS イベント通知のサブスクライブを行います。
  3. AWS DMS のイベント通知を受け取るための承認メールもしくは SMS メッセージを受け取り、E メール、SMS メッセージ内のリンクをクリックして、サブスクライブの確認を行います。

サブスクライブしたことを確認すると、AWS DMS コンソールの Event Subscriptions セクションにて、お客様のサブスクリプションのステータスが更新されます。

そして、イベント通知の受信が開始されます。

コンソールを使ったテーブルマッピングについての詳細は、DMS ドキュメントを参照ください。

AWS Database Migration Service 全般に関する詳細は、こちらのウェブサイトを参照ください。

AWS Database Migration Service – 現在も増え続けているこれまでの移行数 20,000 件

AWS Database Migration Service について初めてブログ (AWS Database Migration Service) を投稿したのは 1 年ほど前のことです。その時点で AWS ユーザー 1,000 人がすでに AWS への移行の一部として同サービスを使用していました。簡単に説明すると、AWS Database Migration Serviceスキーマ変換ツール (SCT) は、AWS のお客様が高価な独自のデータベースやデータウェアハウスから、リレーショナルデータをよりコスト効率の良い Amazon AuroraAmazon Redshift、MySQL、MariaDB、PostgreSQL といったクラウドベースのデータベースやデータウェアハウスに、ダウンタイムを最低限に抑えた状態で移行できるようにサポートします。ユーザーの皆様からは、その柔軟性とコスト効率に優れた点において良い評価を頂いています。たとえば Amazon Aurora に移行すると、商用データベースに掛かる 10 分の 1 のコストで MySQL と PostgreSQL との互換性を持つデータベースにアクセスすることができます。Expedia、Thomas Publishing、Pega、Veoci といった企業による使用事例は AWS Database Migration Services Customer Testimonials でご覧いただけます。

独自の移行数 20,000 件
AWS のお客様は、これまでに AWS Database Migration Service を使用して 20,000 件もの独自のデータベースを AWS に移行しており、現在もその数は上昇する一方です (2016 年 9 月の移行数は 10,000 件を記録)。昨年はいくつもの新機能を DMS と SCT に追加しました。概要は次をご覧ください。

詳細
移行を始めるには、まず最近のオンラインセミナーなどを参考にして詳細情報をご覧ください。シャードからスケールアップへの移行 – 複数の独立した要素にわたりデータベースをシャードし、それぞれを別のホストで実行するなどして、リレーショナルワークロードに対応できるようにスケールアウトする方法を選択したお客様もいらっしゃいます。そうしたお客様は、移行の一環として 2 つ以上のシャードを 1 つの Aurora インスタンスにまとめ、複雑さを軽減し信頼性を高めながらコスト節約を実現しています。この方法を行うには、こちらのブログ記事オンラインセミナーの録画プレゼンテーションをご覧ください。Oracle や SQL Server から Aurora への移行 – その他のお客様は Oracle や SQL Server といった商用データベースから Aurora に移行しています。この方法を行うには、こちらのプレゼンテーションオンラインセミナーの録画を併せてご覧ください。AWS Database Blog ではその他にも多数の役に立つブログを公開しています。

  • シャーディングしたシステムを Aurora で統合しリソース消費を低減 -「シャーディングしたシステムを 1 つの Aurora インスタンスに統合したり、Aurora で実行しているシャード数を減らすことでコストを節約できることがあります。このブログでは、まさにその方法を説明しています。」
  • Oracle データベースを Amazon Aurora に移行 – 「このブログでは AWS スキーマ変換ツール (AWS SCT) と AWS Database Migration Service (AWS DMS) を使用して、商用データベースを Amazon Aurora に移行しやすくするための概要を提供しています。このブログ記事では Oracle から MySQL との互換性がある Amazon Aurora への移行に焦点を当てました。」
  • AWS スキーマ変換ツールと AWS Database Migration Service を使用しているクロスエンジンデータベースレプリケーション -「AWS SCT はソースデータベーススキーマを自動変換することで異種データベースを移行しやすくします。さらに、AWS SCT はビューや関数など大方のカスタムコードをターゲットデータベースと互換性のある形式に変換します。」
  • データベースの移行—移行前に知っておくべきことは? -「おめでとうございます! データベースをクラウドに移行するように、上司や CIO を説得できたようですね。もしかすると、ご自身が上司または CIO なのかもしれませんが、どちらにせよバンドワゴン効果をぜひご活用ください。率先してデータベースを移行するユーザーは稀です。ここでのポイントは、ご利用されているアプリケーションを新しい環境やプラットフォーム、テクノロジー (アプリケーションの更新) に移行することです。
  • データベース移行のスクリプト -「AWS DMS コンソールまたは AWS CLI、AWS SDK を使用してデータベース移行を実施できます。このブログでは AWS CLI での移行に注目します。」

マニュアルには 5 つの便利なガイドが含まれています。

ハンズオンラボもご提供しています。参加するには登録が必要です。(ハンズオンラボは英語のみの場合があります。)

ではサミットでお会いしましょう
DMS チームは今後開催予定の AWS サミットにいくつも参加する予定です。皆さんに直接お会いしてデータベース移行について語り合えることを楽しみにしています。

Jeff;

AWS Database Migration Service (DMS)が一般公開に!利用可能リージョンも拡大

WS000009みなさんは、現在リレーショナルデータをオンプレミスのOracle, SQL Server, MySQL, MariaDB, PostgreSQLといったデータベースに保存されていますか?それらのデータをAWSクラウドに実質的なダウンタイム無しで移動させ、スケールアウト可能というメリット、効率化されたオペレーション、複数のデータストレージが用意されている環境に移行する事に興味はありませんか?

もしそうであれば、新しい AWS Database Migration Service (DMS) こそ、みなさんのためのサービスです!去年の秋に開催されたAWS re:Inventで最初の発表がなされ、すでにお客様により1,000を超えるオンプレミスのデータベースがAWSに移行されています。お客様はテラバイト級のデータベースを動かしたままクラウドに移行する事が可能になります。データベースプラットフォームを変えずに移行することも可能ですし、要件により適切な別のデータベースプラットフォームに移行することも可能です。新しいデータベースプラットフォームへの移行を、システム全体のクラウド移行とともに実施する場合は、AWS Schema Conversion Tool がみなさんのスキーマやストアドプロシージャを新しいプラットフォーム用に変換する事をお手伝いします。

AWS Database Migration ServiceはレプリケーションインスタンスをAWS上にセットアップすることで稼動を開始します。このインスタンスはソースデータベースからデータをアンロードし、ターゲットのデータベースにロードします。これは”on-going replicaion”をサポートしており、ダウンタイムを最小にする形でのマイグレーションをサポートします。加えて、DMSは、データ型変換や異機種間データ移動(例:OracleからAurora)といった多くの煩雑な処理を代行してくれます。このサービスはレプリケーションの状況やインスタンスをモニターしており、なにか発生した場合はユーザに通知するとともに、自動的に代替となるインスタンスをプロビジョンします。

DMSは多様なマイグレーションシナリオおよびネットワーク接続のオプションをサポートしています。1つのエンドポイント(※ソースもしくはターゲットのデータベースサーバ)はAWS上にある必要がありますが、他はオンプレミスでも、EC2上のデータベースでもRDSでもかまいません。ソースとターゲットは両方が同じVirtual Private Cloud (VPC)上にあっても良いですし、別々のVPC上でもかまいません(AWS上で稼動するデータベースを別のVPC上に移すようなケース)。オンプレミスのデータベースに対してもパブリックインターネット経由で接続するか(インターネットVPNを使うことも可能です)、AWS Direct Connectで接続することが可能です。

データベースをマイグレーションする

数クリックでマイグレーションをセットアップすることが可能です!ターゲットデータベースを作成して、データベーススキーマを移行し、データレプリケーションプロセスをセットアップし、最後にマイグレーションを実行するだけです。ターゲットデータベースがソースの内容に完全にキャッチアップできたら、あとは本番環境から利用するデータベースを切り替えるだけです。

AWS Database Migration Service コンソールを選択して、”Create Migration“をクリックします。(AWS Migration Serviceコンソールは、AWSマネジメントコンソールのデータベースのセクションに「DMS」と書かれたアイコンで表示されています)

 

コンソールにはマイグレーションプロセスのオーバービューが表示されています:

Nextをクリックして、レプリケーションインスタンス作成に必要なパラメータを入力します:

このブログポストでは、既存のVPCを選択し、”Publicly accessible”のチェックを外しています。同僚の社員が、私のためにEC2上に”オンプレミスDB”役のデータベースをセットアップしてくれているからです(訳注:オンプレミスのサーバと、VPNやDirect Connectを使わずにグローバルIP経由で接続するような場合は、ここでPublic accessibleをオンにする必要があります):

レプリケーションインスタンスが作成されると、ソース、ターゲットの両データベースのエンドポイントを指定し、”Run test“をクリックしてエンドポイントに問題なくアクセスできるかを確認します。(正直に告白すると、テストをパスするために自分のセキュリティグループ設定を何度か修正するることで時間を費やしました)

そしてマイグレーションタスクを作成します。Migration typeのところで、”migrate existing data(既存データの一括ロード)”,”migrate and then replicate(一括コピーをした後に、継続的に差分レプリケーション)”,”replicate going forward(差分レプリケーションのみ実行)”の3種類から選択が可能です。

Task Settingsをクリックすることで、追加のオプションを選択可能です(LOBというのはラージオブジェクトのことです):

マイグレーションタスクが準備完了になりました。タスクを選択してStart/Resumeボタンを押すことですぐに実行することが可能です:

実行中の状況を確認することが可能です。また表へのアクセスの統計情報(Table statistics)によって、何が起こっているのかを把握することが可能です(この図はテスト用の表を使った結果なので、あまりエキサイティングな図ではないですが):

 ここまで来たら、あとはデータの正当性をチェックし、アプリケーションを新しいエンドポイントに向けるだけです。上記は一括ロードの例ですが、継続的なレプリケーション(ongoing replication)を選択することも可能です。

AWS Database Migration Serviceは多様なオプションを提供しており、上記はあくまで少し機能を紹介したに過ぎません。例えば、特定の表だけをマイグレーションしたり、複数の異なるレプリケーションタスクを作成し、それぞれ個別に実行することも可能です。DMSのドキュメントを読まれることを強く推奨します。マイグレーションを始めて行う人向けの良いガイドになっています。

多くのデータベースを移行する必要があり、作業を自動化したい場合は、AWS Command Line Interface (CLI) もしくはDatabase Migration Service APIを利用することができます。

費用と稼動リージョン

AWS Database Migration Serviceは US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney) の各リージョンに存在します。そして本日より利用可能です!(私達は他のリージョンへの拡張を今後数ヶ月で検討しています)

Jeff;

原文:https://aws.amazon.com/jp/blogs/aws/aws-database-migration-service/

翻訳:下佐粉 昭(@simosako