MongoDBからDynamoDBへの移行、パート2

図6： 詳細設定

図7に示すように、IAMユーザー（dvohra）としてログインする前に作成された暗号化キー（dms）に設定する必要があるKMSマスターキーを除くデフォルト設定は、すべてのレプリケーションインスタンスに適しています。[次へ]をクリックします。

図7： 詳細設定>次へ

図8に示すメッセージに示すように、レプリケーションインスタンスの作成が開始されます。レプリケーションインスタンスの作成中に、次にデータベースエンドポイントを指定します。ただし、レプリケーションインスタンスが作成されるまで、データベースエンドポイントをテストすることはできません。

図8： 作成中のレプリケーションインスタンス

ソースエンジンの場合 、 mongodbを選択します 図9に示すように、データベース。

図9： ソースエンジンをmongodbとして選択する

ターゲットエンジンの場合 、 dynamodbを選択します 図10に示すように、データベース。

図10： ターゲットエンジンをdynamodbとして選択する

エンドポイント識別子 ソースデータベースとターゲットデータベースの両方のデフォルトとして保持できますが、他の接続パラメータを指定する必要があります。 ソースデータベース接続の詳細について 、サーバー名を指定します Dockerを使用してMongoDBレプリカセットが開始されるCoreOSEC2インスタンスのプライベートIP（最初の記事「MongoDBからDynamoDBへの移行、パート1」の図21）として、ポートを指定します 27017として（図11を参照）。 SSLモードの場合は「なし」を選択します および認証モード 。 データベース名を指定します テストとして 認証メカニズムを選択します デフォルトとして 。

図11： ソースデータベース接続の詳細

ソースデータベースエンジンの場合、 mongodb 、メタデータモードを選択します ドキュメントとして オプション_idを別の列として選択します 、図12に示すように。テストの実行 ボタンは、ソースデータベースとターゲットデータベースの接続をテストするために使用され、レプリケーションインスタンスが作成されるまで有効になりません。

図12： ソースエンジンのその他の設定

役割ARNをコピーします dms-vpc-roleの場合 図13に示すように、IAMコンソールから。ロールARNは、DMS移行のターゲットデータベース接続を定義するために使用されます。

図13： ロールARNのコピー

ロールARNをコピーしてサービスアクセスロールARNに貼り付けます 図14に示すように、フィールド。

図14： サービスアクセスロールARN

レプリケーションインスタンスが作成されると、図15に示すように、同じことを示すメッセージが表示されます。

図15： レプリケーションインスタンスが作成されました

ターゲットデータベースについては、[テストの実行]をクリックします 接続をテストします。接続が確立されると、「接続が正常にテストされました」というメッセージが表示されます（図16を参照）。

図16： ターゲットデータベース接続は正常にテストされました

同様に、[テストの実行]をクリックします ソースデータベースの場合、図17に示すように、接続が確立されると、「接続が正常にテストされました」というメッセージが表示されます。

図17： ソースデータベース接続は正常にテストされました

データベースエンドポイントで[次へ]をクリックします 、図18に示すように。

図18： データベースエンドポイント>次へ

次に、タスクの作成で移行タスクを構成します ページ。タスクは、タスク名、タスクの説明、ソースエンドポイント、ターゲットエンドポイント、レプリケーションインスタンス、移行タイプ、タスク設定、テーブルマッピング、詳細設定など、いくつかの設定で構成されます。 タスク名のデフォルト設定 およびソースエンドポイントの変更不可能な設定 、ターゲットエンドポイント 、レプリケーションインスタンス 、および移行タイプ 図19に示します。

図19： タスク設定の作成

適切な説明を追加し、移行タイプを選択します 図20に示すドロップダウンリストから。移行タイプのさまざまなオプションは、既存のデータを移行するです。 、既存のデータを移行し、進行中の変更を複製する 、およびデータの変更のみを複製する 。進行中の変更を複製するためのプロビジョニングを使用して既存のデータをMongoDBからDynamoDBに移行するには、[既存のデータを移行して進行中の変更を複製する]を選択します 。一度作成された移行タスクには、移行タイプを除いて、後で変更されるプロビジョニングがあります。 設定。移行タスクの作成後に変更することはできません。したがって、永続的な設定であると想定して、移行タイプを選択してください。

図20： 移行タイプの選択

タスク設定を選択します ターゲットテーブル準備モードの場合 、フルロードが完了したらタスクを停止します 、レプリケーションにLOB列を含める 、およびロギングを有効にする （図21を参照）。

図21： タスク設定

詳細設定をクリックします 、図22に示すように、制御テーブルを含む詳細設定を構成します。 設定と調整 設定。デフォルトの詳細設定が保持される場合があります。

図22： 詳細設定

テーブルマッピング 、図23に示すように、選択ルールを構成します。含めるを含む少なくとも1つの選択ルール アクションが必要です。 スキーマ名を選択します （テスト）DMSソースMongoDBで。スキーマ名は、 testであるMongoDBデータベース名と同じです。 。 テーブル名は次のようになりますを指定します ‘％’は、すべてのテーブルを選択します。 テーブル コレクションとも呼ばれます MongoDBで。 アクションを選択します 含める 、これには、選択ルールによって選択されたオブジェクトが含まれます。除外アクションは、包含アクションの後に処理されます。

図23： テーブルマッピング

ソースからターゲットに転送されるレコードの数とタイプを制限するソースフィルターも構成できます。 選択ルールの追加をクリックします 、図24に示すように。

図24： 選択ルールを追加

変換ルールを追加して、大文字/小文字を作成したり、プレフィックス/サフィックス変換を追加/削除したりできます。ロギングが有効になっている場合、DMSはCloudWatchにログオンするためのロールを作成します。タスクを作成すると、CloudWatchにアクセスしてログに記録するために必要なアクセス許可が暗黙的に付与されます。 タスクの作成をクリックします 、図25に示すように。

図25： タスクの作成

移行タスクの作成が開始されます（図26を参照）。最初は、ステータス 「作成」です。ステータスは自動的に更新され、更新ボタンをクリックしてステータスを定期的に更新するオプションも提供されます。

図26： 移行タスクの作成が開始されます

タスクが作成されると、ステータス 準備完了になります 、図27に示すように。

図27： タスクステータス準備完了

図28に示すように、CloudWatchアクセスとロギングのIAMロールが自動的に作成されます。

図28： CloudWatchログのIAMロール

移行の実行

移行タスクを実行するには、[開始/再開]をクリックします 、図29に示すように。

図29： タスクの開始/再開

タスクのステータスは開始中になります 、図30に示すように。

図30： タスクの開始

タスクの実行が完了すると、テーブルが読み込まれます 列には、ロードされたテーブルの数が1、ステータスとしてリストされます。 停止になります 、完了率 100を示す必要があります 、図31に示すように。タイプとして 列は、移行タイプがフルロードおよび継続的なレプリケーションであることを示しています 。

図31： フルロードが完了しました

読み込まれたテーブルに加えて 列、テーブルの読み込み 、キューに入れられたテーブル 、およびテーブルエラー 図32に示すように、リストにも表示されます。

図32： テーブルの読み込み、キューに入れられたテーブル、エラーのあるテーブルはすべて0

DynamoDBでは、 wlslog 表には、図33に示すように、7つの項目がリストされています。他の2つの表、 awsdms_apply_exceptions およびawsdms_full_load_exceptions 、また自動的に作成されます。 awsdms_apply_exceptionsテーブルは、エラーの名前と説明、エラーが発生したときに実行されていたステートメント、タスクの名前、テーブルの所有者、テーブルの名前、例外の時刻など、例外の詳細を提供します。 awsdms_full_load_exceptionsテーブルは、フルロード後に生成された例外に関する情報を提供します。

図33： wlslogテーブルには7つのアイテムがリストされています

_idをクリックします ドキュメントを表示するには（ _doc 図34に示すように、属性値）。

図34： DynamoDBに保存されているアイテムのドキュメント

DynamoDBフィルターを使用して、検索をフィルター処理できます。例として、特定の _idを検索します _idを指定する フィールドとして、 Stringを選択します フィールドタイプとして、フィルタ演算子として「=」を選択し、 _idを指定します 図35に示すように、を検索します。検索の開始をクリックします。 。

図35： フィルタの適用

_idのDynamoDBテーブルの行データ 指定されたものが一覧表示されます（図36を参照）。

図36： 特定の_idのフィルタリングされたデータ

移行タスクがデータベースの移行を完了すると、タスクのステータスは停止になります。 、ただし、移行エンドポイントはまだアクティブ 、図37に示すように。

図37： 移行が完了してタスクが停止した後もエンドポイントがアクティブ

移行の再開

停止した移行タスクは、再開または再開される場合があります。タスクを再開または再開する理由のいくつかを次に示します。

• 既存のコレクションに新しいドキュメントが追加されました （テーブルとも呼ばれます ）DMSソースのMongoDBデータベース内
• 新しいコレクション（テーブル）がMongoDBデータベースに追加されました
• 移行は、さまざまな選択規則を使用して再実行する必要があります。これは、たとえば、変換規則を使用してテーブルプレフィックスを追加する必要がある場合に必要になる可能性があります。

例として、さらに3つのドキュメントを wlslogに追加します。 MongoCLIのコレクション。

doc8 = {"timestamp":"Apr 8, 2014 7:06:23 PM PDT",
   "category":"Notice","type":"WebLogicServer",
   "servername":"AdminServer","code":"BEA-000360",
   "msg":"Server in RUNNING mode"}
doc9 = {"timestamp":"Apr 8, 2014 7:06:24 PM PDT",
   "category":"Notice","type":"WebLogicServer",
   "servername":"AdminServer","code":"BEA-000365",
   "msg":"Server Stopping"}
doc10 = {"timestamp":"Apr 8, 2014 7:06:25 PM PDT",
   "category":"Notice","type":"WebLogicServer",
   "servername":"AdminServer","code":"BEA-000361",
   "msg":"Server Resumed"}
db.wlslog.insert([doc8,doc9,doc10])

図38の出力が示すように、3つのドキュメントが追加されます。

図38： さらに3つのドキュメントを追加する

開始/再開をクリックします 図39に示すように、停止したタスクを再開します。

図39： 停止したタスクの開始/再開

タスクの開始 ダイアログには、2つのオプションがあります：開始 または再起動 。 開始 オプションはタスクを開始し、DMSソースに追加された新しいテーブルまたはコレクションをロードします。 開始 オプションは、前回の実行で部分的にしかロードされなかったテーブルもロードします。 開始 オプションは、ターゲットデータベースにすでに完全にロードされているテーブルにデータ（新旧）をロードしません。 再起動 オプションは、タスクを再開し、ターゲットデータベース内の既存のデータを削除して、フルロードを再開します。事実上、再起動 オプションは、DMSソースに追加された新しいテーブルをロードすることに加えて、既存のテーブルに追加された新しいデータをロードします。既存のテーブルに新しいデータを追加したため、再起動を選択する必要があります オプションを選択し、タスクの開始をクリックします 、図40に示すように。

図40： タスクの再開

タスクが再起動し、ターゲットデータベース内の既存のテーブルを削除し、ソースデータベースからすべてのデータをロードしてデータベースをターゲットにします。データの読み込みが完了すると、タスクのステータスは読み込みが完了になります。 （図41を参照）。

図41： ロードが完了しました

図42に示すように、DynamoDBの更新ボタンをクリックします。

図42： wlslogテーブルのデータを更新する

リストされている項目の数は、図43に示すように、タスクを再開する前の7つではなく、10つです。追加した3つの新しいアイテムにより、アイテムの合計は10になります。

図43： 新しいアイテムを追加してデータを更新した後の10個のアイテムのリスト

移行された新しいデータは、別のプレフィックスによって実行された1でロードされたデータとは区別されます。 1回の実行でロードされたデータには、プレフィックス 59401が付いています。 _id内 2回の実行でロードされたデータには、プレフィックス 59402が付いています。 。 フィルター 図44に示すように、オプションを使用して新しいデータのみを一覧表示できます。

図44： データをフィルタリングして、3つの新しいアイテムのみを一覧表示する

タスクのステータスは再び停止になります 図45に示すように、新しいデータが移行された後。

図45： フルロードが完了すると、ステータスは停止になります

移行の削除

移行を削除するには、移行を選択して削除をクリックします （図46を参照）。

図46： 削除

削除タスクで ダイアログで、削除をクリックします 、図47に示すように。

図47： タスク検証を削除

タスクのステータスは削除中になります 、図48に示すように、タスクが削除される前。

図48： タスクの削除

タスクを削除しても、使用されているDMSエンドポイントは削除されません。これは、新しいタスクが作成される可能性があることを意味します。

結論

2つの記事で、AWS DatabaseMigrationServiceを使用したMongoDBデータベースのDynamoDBテーブルへの移行について説明しました。