AWS Database Migration Service - ユーザーガイド

Transcription

1 AWS Database Migration Service ユーザーガイド

2 AWS Database Migration Service: ユーザーガイド Copyright 2018 Amazon Web Services, Inc. and/or its affiliates. All rights reserved. Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by Amazon.

3 Table of Contents AWS Database Migration Service とは... 1 AWS DMS が実行する移行タスク... 1 基本レベルでの AWS DMS の仕組み... 2 AWS DMS の詳細... 4 AWS DMS の概要... 4 コンポーネント... 5 ソース... 9 ターゲット 他の AWS サービスで使用する AWS CloudFormation のサポート ARN の構築 セットアップ AWS にサインアップする IAM ユーザーを作成する AWS Database Migration Service での移行計画 開始方法 データベースの移行開始 ステップ 1: [Welcome] ステップ 2: レプリケーションのインスタンスを作成する ステップ 3: ソースとターゲットのエンドポイントを指定する ステップ 4: タスクを作成する タスクをモニタリングする セキュリティ 必要な IAM アクセス許可 CLI および API の IAM ロール FGAC Fine-Grained Access Control リソース名を使用したアクセスの制御 タグを使用したアクセスの制御 暗号化キーを設定する ネットワークセキュリティ SSL の使用 AWS Database Migration Service で SSL を使用する場合の制限 証明書の管理 MySQL 互換 PostgreSQL または SQL Server のエンドポイントでの SSL の有効化 Oracle エンドポイントでの SSL のサポート データベースのパスワードの変更 制限 AWS Database Migration Service の制限 レプリケーションインスタンス レプリケーションインスタンスの詳細 パブリックおよびプライベートレプリケーションインスタンス AWS DMS メンテナンス AWS DMS メンテナンスウィンドウ レプリケーションエンジンのバージョン レプリケーションインスタンスバージョンの廃止 レプリケーションインスタンスのエンジンバージョンのアップグレード レプリケーションインスタンスのためのネットワークのセットアップ データベース移行のネットワーク設定 レプリケーションサブネットグループの作成 暗号化キーを設定する レプリケーションインスタンスの作成 レプリケーションインスタンスの変更 レプリケーションインスタンスを再起動する レプリケーションインスタンスの削除 iii

4 サポートされている DDL ステートメント エンドポイント データ移行のソース ソースとして Oracle を使用する SQL Server をソースとして使用する Azure SQL データベースのソースとしての使用 PostgreSQL のソースとしての使用 ソースとしての MySQL の使用 SAP ASE のソースとしての使用 ソースとしての MongoDB の使用 Amazon S3 のソースとしての使用 IBM Db2 をソースとして使用する データ移行のターゲット Oracle のターゲットとしての使用 ターゲットとしての SQL Server の使用 ターゲットとしての PostgreSQL の使用 ターゲットとしての MySQL の使用 ターゲットとしての Amazon Redshift の使用 ターゲットとしての SAP ASE の使用 ターゲットとしての Amazon S3 の使用 ターゲットとしての Amazon DynamoDB の使用 ソースおよびターゲットエンドポイントの作成 タスク タスク評価レポートの作成 タスクの作成 タスク設定 LOB サポートの設定 複数のタスクの作成 継続的なレプリケーション用のタスク CDC 開始ポイントから開始するレプリケーション タスクの変更 タスク実行中のテーブルの再ロード AWS マネジメントコンソール テーブルマッピング コンソールからのテーブルマッピングによりテーブル選択および変換を指定する JSON を使用するテーブルマッピングによりテーブル選択および変換を指定する ソースフィルタの使用 タスクのモニタリング タスクのステータス タスク実行中のテーブルの状態 Amazon CloudWatch を使用したレプリケーションモニタリングタスク データ移行サービスメトリクス レプリケーションインスタンスのメトリクス レプリケーションタスクのメトリクス AWS DMS ログを管理する AWS CloudTrail を使用した AWS DMS API コールのログ作成 CloudTrail 内の AWS DMS 情報 AWS DMS ログファイルエントリの概要 タスクの検証 レプリケーションタスクの統計 トラブルシューティング 制約事項 リソースのタグ付け API イベントと通知の使用 AWS DMS イベントのカテゴリおよびイベントメッセージ AWS DMS イベント通知へサブスクライブする iv

5 AWS マネジメントコンソール AWS DMS API AWS DMS と Snowball を使用した大規模データストアの移行 プロセスの概要 AWS DMS と AWS Snowball を使用したデータ移行の詳しい手順 ステップ 1: AWS Snowball ジョブを作成する ステップ 2: SCT をインストールする ステップ 3: SCT DMS エージェントをインストールおよび設定する ステップ 4: AWS Snowball Edge デバイスをロック解除する ステップ 5: 新しい AWS SCT プロジェクトを作成する ステップ 6: AWS SCT プロファイルを設定する ステップ 7: DMS エージェントを登録する ステップ 8: ソースデータベースドライバーをインストールする ステップ 9: Amazon S3 バケットにアクセスするように AWS SCT を設定する ステップ 10: ローカルの DMS タスクを作成する ステップ 11: ローカルの DMS タスクを実行およびモニタリングする ステップ 11: AWS Snowball アプライアンスを管理する Snowball から Amazon S3 へ トラブルシューティング 移行タスクの実行の遅れ タスクのステータスバーが動かない 外部キーとセカンダリインデックスが見つからない Amazon RDS 接続問題 エラーメッセージ: スレッドの接続文字列が正しくありません 正しくないスレッド値 ネットワーキングの問題 全ロード後 CDC が停止する タスクを再開時のプライマリキー制約違反エラー スキーマの初回ロードが失敗する 不明なエラーが発生してタスクが失敗する タスクを再開するとテーブルが最初からロードされる タスクあたりのテーブル数 Oracle 固有の問題のトラブルシューティング ビューからデータを取得する Oracle 12c から LOB を移行する Oracle LogMiner と Binary Reader の切り替え エラー: Oracle CDC は停止しました Oracle CDC の最大再試行カウンタを超えまし た Oracle ソースエンドポイントにサプリメンタルロギングを自動的に追加する LOB の変更がキャプチャされない エラー: ORA-12899: 列 <column-name> の値が大きすぎる NUMBER のデータ型が誤って解釈される MySQL 固有の問題のトラブルシューティング バイナリログ作成が無効化されるため Amazon RDS DB インスタンスのエンドポイントの CDC タスクが失敗する ターゲット MySQL のインスタンスへの接続は タスクの実行中に接続が切断されます MySQL 互換エンドポイントへの自動コミットを追加する MySQL 互換ターゲットエンドポイントで外部キーを無効化する 文字が疑問符に置き換えられる [Bad event] ログのエントリ MySQL 5.5 の変更データキャプチャ Amazon RDS DB インスタンスのバイナリログ保持を延長する ログメッセージ: ソースデータベースからの一部の変更は ターゲットデータベースに適用され ても効果がありません エラー: 識別子が長すぎます エラー: サポートされていない文字セットによりフィールドデータ変換が失敗しました Error: Codepage 1252 to UTF8 [120112] A field data conversion failed PostgreSQL 固有の問題のトラブルシューティング v

6 切り捨てられる JSON データ型 ユーザー定義のデータ型の列が正しく移行されない エラー: 作成用のスキーマが選択されていません CDC を使用時 テーブルへの削除や更新がレプリケートされない TRUNCATE ステートメントが反映されない PostgreSQL の DDL キャプチャを防止する DDL キャプチャ用のデータベースオブジェクトを作成するスキーマの選択 PostgreSQL に移行した後 Oracle テーブルが存在しない ソースとしてビューを使用したタスクで行がコピーされない Microsoft SQL Server 固有の問題のトラブルシューティング AWS DMS ユーザーアカウントの CDC 使用を特別に許可する SQL Server データベースの変更キャプチャエラー IDENTITY 列が存在しない エラー: SQL Server は公開をサポートしていません ターゲットに変更が表示されない Amazon Redshift 固有の問題のトラブルシューティング AWS DMS レプリケーションのインスタンスとは異なるリージョンの Amazon Redshift クラス ターにロードする エラー: リレーション awsdms_apply_exceptions がすでに存在します 名前が awsdms_changes で始まるテーブルのエラー dms.awsdms_changes xxxx のような名前のクラスターのテーブルを参照する Amazon Redshift での作業に必要なアクセス許可 Amazon Aurora MySQL 固有の問題のトラブルシューティング エラー: CHARACTER SET UTF8 フィールドが, で切り取られています 行が \n で切り 取られています ベストプラクティス パフォーマンスの向上 レプリケーションインスタンスのサイズ設定 ソースデータベースのロードを削減する タスクログを使用する スキーマ変換 ラージバイナリオブジェクト (LOB) の移行 制限付き LOB モードの使用 継続的なレプリケーション Oracle ターゲットのユーザーおよびスキーマの変更 大規模なテーブルを移行する場合のパフォーマンスの向上 リファレンス AWS DMS データ型 リリースノート AWS DMS リリースノート AWS DMS リリースノート AWS DMS リリースノート AWS DMS リリースノート AWS DMS リリースノート AWS DMS リリースノート AWS DMS リリースノート ドキュメント履歴 以前の更新 AWS の用語集 vi

7 AWS DMS が実行する移行タスク AWS Database Migration Service と は AWS Database Migration Service (AWS DMS) は リレーショナルデータベース データウェアハウ ス NoSQL データベース 他の種類のデータストアを移行しやすくするクラウドサービスです AWS DMS を使用して オンプレミスのインスタンス間 またはクラウドセットアップとオンプレミスセット アップの組み合わせの間で AWS クラウドにデータを移行できます AWS DMS を使用すると 1 回限りの移行を実行でき 継続的な変更をレプリケートしてソースと ターゲットの同期を維持することができます データベースエンジンを変更する場合 AWS Schema Conversion Tool (AWS SCT) を使用してデータベーススキーマを新しいプラットフォームに変換でき ます 次に AWS DMS を使用してデータを移行します AWS DMS は AWS クラウドの一部であるた め AWS のサービスが提供するコスト効率性 市場投入の迅速化 セキュリティ 柔軟性を手に入れるこ とができます AWS DMS をサポートする AWS リージョンの詳細については AWS DMS レプリケーションインスタ ンスを使用する (p. 57) を参照してください データベース移行のコストについては AWS Database Migration Service の料金表ページを参照してください AWS DMS が実行する移行タスク AWS DMS は 移行プロジェクトに関係する難しいタスクや単調なタスクの多くを引き受けます 従来のソリューションでは 容量分析の実行 ハードウェアおよびソフトウェアの調達 システムのイ ンストールと管理 インストールのテストとデバッグが必要です AWS DMS は 移行に必要なすべ てのハードウェアおよびソフトウェアのデプロイ 管理 モニタリングを自動的に管理します AWS DMS 設定プロセスを開始してから数分以内に稼働状態にすることができます AWS DMS では 実際のワークロードに合わせて必要に応じて移行リソースをスケールアップ (または スケールダウン) できます たとえば ストレージを追加する必要があると判断した場合 割り当てら れたストレージを簡単に増やして 移行を再開 (通常は数分以内に) することができます 一方 設定し たリソース容量に使用していないものがあることがわかった場合 実際のワークロードに合わせてダウ ンサイジングを簡単に行うことができます AWS DMS は従量制モデルを採用しています 前払いの購入コストや継続的なメンテナンス費用が必要 な従来のライセンスモデルとは異なり 使用した AWS DMS リソースに対してのみお支払いいただきま す AWS DMS は ハードウェアとソフトウェア ソフトウェアのパッチ適用 エラーレポートなど 移行 サーバーをサポートするすべてのインフラストラクチャを自動的に管理します AWS DMS は 自動フェイルオーバーを提供します プライマリレプリケーションサーバーが何らかの 理由で停止した場合 バックアップレプリケーションサーバーがサービスをほとんどまたはまったく中 断させることなく引き継ぐことができます AWS DMS では 現在実行しているデータベースエンジンよりおそらくコスト効果の高い最新の データベースエンジンに切り替えることができます たとえば AWS DMS では Amazon RDS ま たは Amazon Aurora により提供されるマネージド型データベースサービスを活用できます また は Amazon Redshift により Amazon DynamoDB などの NoSQL プラットフォームにより または Amazon S3 などの低コストのストレージプラットフォームにより提供されるマネージド型データウェア ハウスに移行できます 逆に 古いインフラストラクチャから移行するが 同じデータベースエンジン を引き続き使用する場合 AWS DMS によりそのプロセスもサポートされます 1

8 基本レベルでの AWS DMS の仕組み AWS DMS は Oracle Microsoft SQL Server MySQL MariaDB PostgreSQL Db2 LUW SAP MongoDB Amazon Aurora など 現在データソースとして広く使用されているほぼすべ ての DBMS エンジンをサポートします AWS DMS は Oracle Microsoft SQL Server PostgreSQL MySQL Amazon Redshift SAP ASE S3 Amazon DynamoDB など 使用可能なターゲットエンジンを広範にサポートしています サポートされている任意のデータソースから サポートされている任意のデータターゲットに移行でき ます AWS DMS は サポートされているエンジン間での完全に異種のデータ移行をサポートしていま す AWS DMS により データ移行は安全に保たれます 保存データは AWS Key Management Service (AWS KMS) 暗号化によって暗号化されます 移行時は Secure Socket Layer (SSL) を使用して ソー スからターゲットに移動する転送中のデータを暗号化できます 基本レベルでの AWS DMS の仕組み 突き詰めると AWS DMS はレプリケーションソフトウェアを実行する AWS クラウド内のサーバーで す お客様は ソースとターゲットの接続を作成し 抽出元とロード先を AWS DMS に指示します そ の後 このサーバーで実行するタスクをスケジュールし データを移動します AWS DMS は テーブル と関連付けられたプライマリキーがターゲットに存在しない場合はそれらを作成します 必要に応じて ターゲットテーブルを手動で事前に作成することができます または AWS SCT を使用して ターゲッ トテーブル インデックス ビュー トリガーなどの一部またはすべてを作成できます 以下の図は AWS DMS プロセスを示したものです AWS DMS プロセスを実行するには (開始と終了) 1. 移行プロジェクトを開始するには ソースとターゲットのデータストアを識別します これらのデー タストアは 前述のどのデータエンジンにも配置できます 2. ソースとターゲットの両方で データベースへの接続情報を指定する AWS DMS 内のエンドポイント を設定します エンドポイントは 適切な ODBC ドライバを使用してソースおよびターゲットと通信 します 3. レプリケーションインスタンスをプロビジョンします このインスタンスは AWS DMS がレプリ ケーションソフトウェアを使用して自動的に設定するサーバーです 4. レプリケーションタスクを作成します このタスクは 移行する実際のデータテーブルと適用する データ変換ルールを指定します AWS DMS は レプリケーションタスクの実行を管理し 移行プロ セスにおけるステータスを示します 詳細については 以下をご覧ください 2

9 基本レベルでの AWS DMS の仕組み AWS の他のサービスをすでに利用している方が初めて AWS DMS を利用する場合は まず AWS Database Migration Service の詳細 (p. 4) を参照してください このセクションでは AWS DMS の主要なコンポーネントと移行のセットアップと実行の全体的なプロセスについて詳しく説明していま す データベースエンジンを切り替える場合 AWS Schema Conversion Tool を使用すると テーブル インデックス ほとんどのアプリケーションコードなどの既存のデータベーススキーマをターゲットプ ラットフォームに変換できます 移行戦略の設計が必要な可能性のある関連する AWS のサービスの詳細については AWS クラウド製 品 を参照してください アマゾン ウェブ サービスでは 数多くのデータベースサービスを提供しています ご利用の環境に最適 なサービスについてのガイダンスは AWS でのデータベースの実行 を参照してください すべての AWS 製品の概要については クラウドコンピューティングとは を参照してください 3

10 AWS DMS の概要 AWS Database Migration Service の 詳細 AWS Database Migration Service (AWS DMS) は ソースデータストアからターゲットデータストアへ のデータの移行に使用できるウェブサービスです この 2 つのデータストアはエンドポイントと呼ばれ ます 移行は 同じデータベースエンジンを使用するソースエンドポイントとターゲットエンドポイン ト (Oracle データベースと Oracle データベースなど) の間で行うことができます 移行は 異なるデー タベースエンジンを使用するソースエンドポイントとターゲットエンドポイント (Oracle データベースと PostgresSQL データベースなど) の間で行うこともできます AWS DMS を使用する唯一の要件は エン ドポイントの 1 つが AWS のサービス上にあることです AWS DMS を使用して オンプレミスのデータ ベースから別のオンプレミスのデータベースに移行することはできません データベース移行のコストについては AWS Database Migration Service の料金表ページ を参照して ください 次のトピックを使用して AWS DMS についての理解を深めます トピック AWS DMS の概要 (p. 4) AWS Database Migration Service のコンポーネント (p. 5) AWS Database Migration Service のソース (p. 9) AWS Database Migration Service のターゲット (p. 10) 他の AWS サービスで AWS DMS を使用する (p. 11) AWS DMS の概要 データベース移行を実行するには AWS DMS はソースデータストアに接続し ソースデータを読み取 り ターゲットデータストアが使用できるようにデータをフォーマットします 次に ターゲットデータ ストアにデータをロードします この処理のほとんどはメモリ内で行われますが 大きいトランザクショ ンではディスクへのバッファリングが必要になることがあります キャッシュされたトランザクションと ログファイルもディスクに書き込まれます 大まかに述べると AWS DMS を使用するときは 次の操作を行います レプリケーションサーバーを作成します データストアに関する接続情報を持つソースエンドポイントとターゲットエンドポイントを作成しま す ソースデータストアとターゲットデータストアの間でデータを移行するには 1 つ以上の移行タスクを 作成します タスクは 3 つの主なフェーズで構成できます 既存のデータの全ロード キャッシュされた変更の適用 4

11 コンポーネント 継続的なレプリケーション ソースの既存のデータがターゲットに移動される全ロード移行時 AWS DMS はソースデータストア上 のテーブルからターゲットデータストア上のテーブルにデータをロードします 全ロードの進行中 ロー ドするテーブルに加えられた変更はすべてレプリケーションサーバーにキャッシュされます これらが キャッシュされた変更点です AWS DMS は 特定のテーブルの全ロードが開始されるまで そのテーブ ルの変更をキャプチャしない点に注意することが重要です つまり 変更キャプチャが開始されるポイン トは 個々のテーブルごとに異なります 特定のテーブルの全ロードが完了すると AWS DMS はすぐにそのテーブルのキャッシュされた変更を適 用し始めます すべてのテーブルがロードされると AWS DMS は継続的なレプリケーションフェーズの トランザクションとして変更を収集し始めます AWS DMS がキャッシュされた変更をすべて適用する と テーブルはトランザクション面で一貫したものになります この時点で AWS DMS は継続的なレプ リケーションフェーズに移り 変更がトランザクションとして適用されます 継続的なレプリケーションフェーズの開始時 トランザクションのバックログにより ソースデータベー スとターゲットデータベースの間に通常いくらかの遅延が発生します このトランザクションバックログ が終わると 移行は最終的に安定した状態になります この時点で アプリケーションをシャットダウン して 残りのトランザクションをターゲットに適用できるようにし ターゲットデータベースをポイント するようになったアプリケーションを起動できます AWS DMS は 移行の実行に必要なターゲットスキーマオブジェクトを作成します ただし AWS DMS は最小限のアプローチを採用するため データの効率的な移行に必要なオブジェクトのみ作成します つ まり AWS DMS は テーブル プライマリキー 場合によっては一意のインデックスを作成しますが 効率的にソースからデータを移行するために必要ではない他のオブジェクトは作成されません たとえ ば セカンダリインデックス 非プライマリキーの制約 データデフォルトは作成されません ほとんどの場合 移行を実行するとき ソーススキーマの大部分またはすべても移行します 同機種間移 行 (同じエンジンタイプの 2 つのデータベース間) を実行する場合 エンジンのネイティブツールを使用し てスキーマ自体 (データなし) をエクスポートおよびインポートすることによりスキーマを移行します 移行が異機種間 (異なるエンジンタイプを使用する 2 つのデータベース間) の場合 AWS Schema Conversion Tool (AWS SCT) を使用して完全なターゲットスキーマを自動的に生成できます このツール を使用した場合 全ロード フェーズと キャッシュされた変更の適用 フェーズの間は 外部キーの 制約など テーブル間の依存関係をすべて無効にする必要があります パフォーマンスが問題になる場合 は 移行プロセス中にセカンダリインデックスを削除または無効にすると役立ちます AWS SCT の詳細 については AWS SCT ドキュメントの AWS Schema Conversion Tool を参照してください AWS Database Migration Service のコンポーネント このセクションでは AWS DMS の内部コンポーネントと データ移行におけるそのコンポーネントの動 作について説明します AWS DMS の基礎となるコンポーネントを理解することで 効率的にデータを移 行し 問題のトラブルシューティング時および調査時に優れた洞察を得ることができます AWS DMS の移行は レプリケーションインスタンス ソースエンドポイントとターゲットエンドポイン ト およびレプリケーションタスクの 3 つのコンポーネントで構成されます AWS DMS 移行を作成す るには 必要なレプリケーションインスタンス エンドポイント タスクを AWS リージョンに作成しま す レプリケーションインスタンス 大まかに説明すると AWS DMS レプリケーションインスタンスは 1 つ以上のレプリケーションタ スクをホストするマネージド Amazon Elastic Compute Cloud (Amazon EC2) インスタンスです 関連付けられたいくつかのレプリケーションタスクを実行するレプリケーションインスタンスの例を 以下の図に示します 5

12 コンポーネント 移行の特性とレプリケーションサーバーの容量に応じて 1 つのレプリケーションインスタンスを使 用して 1 つ以上のレプリケーションタスクをホストできます AWS DMS では ユースケースに最 適な設定を選択できるように さまざまなレプリケーションインスタンスが用意されています レプ リケーションインスタンスのさまざまなクラスの詳細については 移行に適した AWS DMS レプリ ケーションインスタンスを選択する (p. 58) を参照してください AWS DMS では Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上にレプリケーション インスタンスが作成されます サービスのテストや小規模な移行の場合 いくつかの小さいインスタ ンスクラスで十分です 移行に多数のテーブルが関与する場合や 複数の同時レプリケーションタス クを実行する予定の場合 大きいインスタンスを 1 つ使用することを検討してください AWS DMS はかなりのメモリと CPU を消費する可能性があるため このアプローチが推奨されます 選択した Amazon EC2 インスタンスクラスに応じて レプリケーションインスタンスには 50 GB ま たは 100 GB のデータストレージが付属しています ほとんどのお客様にとって 通常このストレー ジ容量は十分な量です ただし 移行で大規模なトランザクションや大量のデータ変更が発生する場 合は 基本ストレージの割り当てを増やします 変更データキャプチャ (CDC) によって データが ディスクに書き込まれる可能性があります これは ターゲットから変更が書き込まれる速度によっ て異なります AWS DMS は マルチ AZ 配置を使用して高可用性およびフェイルオーバーサポートを提供します マルチ AZ 配置では AWS DMS によって異なるアベイラビリティーゾーンにレプリケーションイン スタンスのスタンバイレプリカが自動的にプロビジョンされて維持されます プライマリレプリケー ションインスタンスは 同期的にスタンバイレプリカにレプリケートされます プライマリレプリ ケーションインスタンスに障害が発生するか 応答しない場合 スタンバイ状態で中断時間をでき る限り抑えて 実行中のタスクを再開します プライマリはその状態を常にスタンバイにレプリケー ションしているため マルチ AZ 配置ではパフォーマンス上のオーバーヘッドが発生します AWS DMS レプリケーションインスタンスの詳細については AWS DMS レプリケーションインス タンスを使用する (p. 57) を参照してください 6

13 コンポーネント エンドポイント AWS DMS は エンドポイントを使用してソースまたはターゲットのデータストアにアクセスしま す 特定の接続情報はデータストアによって異なりますが 一般的にエンドポイントを作成するとき は次の情報を指定します エンドポイントタイプ ソースまたはターゲット エンジンタイプ データベースエンジンのタイプ (例: Oracle Postgres または Amazon S3) サーバー名 AWS DMS が到達可能なサーバー名または IP アドレス ポート データベースサーバー接続に使用されるポート番号 暗号化 SSL モード (接続を暗号化するために使用する場合) 認証情報 必要なアクセス権限を持つアカウントのユーザー名とパスワード AWS DMS コンソールを使用してエンドポイントを作成する場合は コンソールでエンドポイント接 続をテストする必要があります DMS タスクでエンドポイントを使用する前に テストが成功してい る必要があります 接続情報と同様に 特定のテスト基準はエンジンの種類によって異なります 一 般的に AWS DMS では 指定されたサーバー名とポートにデータベースが存在すること 提供され た認証情報を使用して 移行を実行するために必要なアクセス許可を持つデータベースに接続できる ことを検証します 接続テストが成功した場合 AWS DMS では テーブル定義やプライマリ/一意の キー定義を含むスキーマ情報をダウンロードして格納します この情報は タスク設定時に後に使用 することができます 複数のレプリケーションタスクで単一のエンドポイントを使用することができます たとえば 別々 に移行する同じソースデータベースにホストされている 2 つの論理的に異なるアプリケーションがあ るとします アプリケーションテーブルのセットごとに 1 つずつ 2 つのレプリケーションタスクを 作成しますが 両方のタスクで同じ AWS DMS エンドポイントを使用できます エンドポイントの動作をカスタマイズするには 追加接続属性を使用します これらの属性は ログ の詳細 ファイルサイズ およびその他のパラメータなど さまざまな動作を制御できます デー タストアのエンジンタイプにはそれぞれ 使用可能な追加接続属性があります データストアごと の追加接続属性は データストアのソースセクションまたはターゲットセクションにあります サ ポートされているソースとターゲットデータストアのリストについては AWS Database Migration Service のソース (p. 9) と AWS Database Migration Service のターゲット (p. 10) を参照 してください AWS DMS エンドポイントの詳細な情報については AWS DMS エンドポイントの使用 (p. 84) を参照してください レプリケーションタスク AWS DMS レプリケーションタスクを使用して 一連のデータをソースエンドポイントからターゲッ トエンドポイントに移動します レプリケーションタスクの作成は 移行を開始する前に最後に実行 する必要があります レプリケーションタスクの作成時に以下のタスク設定を指定します レプリケーションインスタンス タスクをホストして実行するインスタンス ソースエンドポイント ターゲットエンドポイント 移行タイプのオプション 移行タイプは以下のいずれかになります 全ロード (既存データの移行) 既存のデータをコピーできる長さの停止が許容される場合は こ のオプションが適しています このオプションでは ソースデータベースからターゲットデータ ベースにデータがそのまま移行され 必要に応じてテーブルが作成されます 全ロード + CDC (既存のデータを移行して 継続的な変更をレプリケート) このオプションで は ソースで変更をキャプチャしながら 全データロードが実行されます 全ロードが完了する と キャプチャされた変更がターゲットに適用されます 最終的に 変更の適用は安定した状態 に到達します この時点で アプリケーションをシャットダウンし 残りの変更がターゲットに 移動するようにした後 ターゲットをポイントするアプリケーションを再起動できます 7

14 コンポーネント CDC のみ (データ変更のみレプリケート) 状況によっては AWS DMS 以外の方法を使用して既 存のデータをコピーした方が効率的なことがあります たとえば 同機種間移行では 一括デー タのロードにネイティブエクスポート/インポートツールを使用した方が効率的なことがありま す この状況では AWS DMS を使用し 一括ロードを開始したときから変更をレプリケートし て ソースデータベースとターゲットデータベースの同期を保つことができます 移行タイプのオプションの詳細な説明については タスクの作成 (p. 197) を参照してくださ い ターゲットテーブル作成モードのオプション ターゲットテーブルモードの詳細な説明について は タスクの作成 (p. 197) を参照してください 何もしない AWS DMS ではターゲットテーブルがターゲットで事前に作成されていることを前 提とします ターゲット上のテーブルを削除 AWS DMS はターゲットテーブルを削除して再作成します 切り捨て ターゲットでテーブルを作成済みである場合 AWS DMS は移行の開始前にそれらを 切り捨てます テーブルが存在しない場合 このオプションを選択すると AWS DMS は不足し ているテーブルを作成します LOB モードのオプション LOB モードの詳細な説明については AWS DMS タスクのソースデー タベースの LOB サポートの設定 (p. 218) を参照してください LOB 列を含めない LOB 列は移行対象から除外されます 完全 LOB モード サイズに関係なく LOB 全体を移行します AWS DMS は 最大 LOB サイ ズパラメータで制御されるチャンクの単位で LOB を移行します このモードは制限付き LOB モードを使用するよりも低速です 制限付き LOB モード LOB を最大 LOB サイズパラメータで指定された値まで切り詰めます こ のモードは完全 LOB モードを使用するよりも高速です テーブルマッピング 移行するテーブルを示す データの変換 スキーマ テーブル および列の名前を変更する データ検証 CloudWatch ログ記録 タスクを使用してソースエンドポイントからターゲットエンドポイントにデータを移行します タ スク処理はレプリケーションインスタンスで実行されます ログ記録要件 制御テーブルデータ エ ラー処理など 移行するテーブルとスキーマ および特別な処理を指定します 概念的には AWS DMS レプリケーションタスクは 次の図に示すように 2 つの異なる機能を実行し ます 全ロードプロセスは 簡単に理解できます データは ソースから一括抽出で抽出され ターゲット に直接ロードされます AWS DMS コンソールの [詳細設定] で 抽出して並列にロードするテーブル の数を指定できます AWS DMS タスクの詳細については AWS DMS タスクの使用 (p. 193) を参照してください 8

15 ソース 継続的なレプリケーションまたは変更データキャプチャ (CDC) AWS DMS タスクを使用して ターゲットへのデータの移行中にソースデータストアへの継続的な変 更をキャプチャすることもできます ソースエンドポイントから継続的な変更をレプリケートすると きに AWS DMS が使用する変更キャプチャプロセスは データベースエンジンのネイティブ API を使 用することでデータベースログへの変更を収集します CDC プロセスで レプリケーションタスクは メモリ内のバッファを使用して転送中のデータを保持 することによって ソースからターゲットへの変更をストリーミングするように設計されています 何らかの理由でメモリ内バッファが枯渇すると レプリケーションタスクによって ディスク上の キャッシュの変更は保留中に変更されます この状況は たとえば AWS DMS がソースからの変更 をターゲットに適用できるよりも速く取得している場合に発生します この場合 タスクのターゲッ トレイテンシーが タスクのソースレイテンシーを超えていることがわかります これを確認するには AWS DMS コンソールでタスクに移動し [Task Monitoring (タスク監視)] タブ を開きます CDCLatencyTarget グラフと CDCLatencySource グラフは ページの下部に表示されま す ターゲットのレイテンシーを示すタスクがある場合は アプリケーションの速度を上げるために 必要なターゲットエンドポイントのチューニングがある可能性があります 上記で説明したように レプリケーションタスクでは タスクログ用のストレージも使用されます 通常 レプリケーションインスタンスで事前設定されているディスク容量では 十分に変更をログ記 録および反映することができます 追加のディスク容量が必要な場合 (例: 詳細なデバッグを使用して 移行の問題を調査する場合) レプリケーションインスタンスを変更してより多くの容量を割り当てる ことができます スキーマおよびコード移行 AWS DMS は スキーマまたはコード変換を実行しません ソースとターゲットが同じデータベー スエンジンの場合 Oracle SQL Developer MySQL Workbench または pgadmin III などのツール を使用して スキーマを起動できます 異なるデータベースエンジンに既存のスキーマを変換する場 合 AWS SCT を使用できます このツールは ターゲットスキーマを作成でき スキーマ全体 (テー ブル インデックス ビューなど) を生成および作成することもできます AWS SCT を使用して PL/ SQL または TSQL を PgSQL や他の形式に変換することもできます AWS SCT の詳細については AWS Schema Conversion Tool を参照してください 可能な限り AWS DMS はターゲットスキーマを自動的に作成するように試みます 場合によって は AWS DMS はスキーマを作成することができません たとえば セキュリティ上の理由から AWS DMS はターゲット Oracle スキーマを作成しません MySQL データベースターゲットの場合 追加の 接続属性を使用にすることにより AWS DMS がすべてのオブジェクトと指定されたデータベースお よびスキーマに移行したり ソース上でスキーマを検出したときに各データベースおよびスキーマを 自動的に作成したりするようにできます AWS Database Migration Service のソース AWS Database Migration Service を使用したデータ移行のソースエンドポイントとして 以下のデータス トアを使用できます オンプレミスおよび EC2 インスタンスデータベース Enterprise Standard Standard One および Standard Two エディションの Oracle バージョン 10.2 以 降 11g 12.1 まで Enterprise Standard Workgroup および Developer エディションの Microsoft SQL Server バージョ ン R および 2016.Web および Express エディションはサポートさ れていません MySQL バージョン MariaDB (MySQL 互換データソースとしてサポートされています). PostgreSQL バージョン 9.4 以降. 9

16 ターゲット MongoDB バージョン 2.6.x およ 3.x 以降. SAP Adaptive Server Enterprise (ASE) バージョン 以降. Db2 LUW のバージョン: バージョン 9.7 すべての Fix Pack がサポートされています バージョン 10.1 すべての Fix Pack がサポートされています Version 10.5 Fix Pack 5 を除くすべての Fix Pack がサポートされています Microsoft Azure Azure SQL データベース. Amazon RDS インスタンスデータベース および Amazon S3 Oracle バージョン 11g (バージョン v1 以降) および 12c (Enterprise Standard Standard One Standard Two エディション) Enterprise Standard Workgroup および Developer エディションの Microsoft SQL Server バージョ ン 2008R Web および Express エディションはサポートされていません MySQL バージョン MariaDB (MySQL 互換データソースとしてサポートされています). PostgreSQL 9.4 以降.変更データキャプチャ (CDC) は バージョン 以降と 以降でのみサポー トされます CDCに必要な rds.logical_replication パラメータは これらのバージョン以降での みサポートされています Amazon Aurora (MySQL 互換データソースとしてサポートされています). Amazon S3 AWS Database Migration Service のターゲット AWS Database Migration Service を使用したデータ移行のターゲットエンドポイントとして 以下のデー タストアを使用できます オンプレミスおよび Amazon EC2 インスタンスデータベース Enterprise Standard Standard One および Standard Two エディションの Oracle バージョン 10g 11g 12c Enterprise Standard Workgroup および Developer エディションの Microsoft SQL Server バージョ ン R および 2016.Web および Express エディションはサポートさ れていません MySQL バージョン MariaDB (MySQL 互換データターゲットとしてサポートされています) PostgreSQL バージョン 9.4 以降 SAP Adaptive Server Enterprise (ASE) バージョン 以降 Amazon RDS インスタンスデータベース Amazon Redshift Amazon DynamoDB Amazon S3 Oracle バージョン 11g (バージョン v1 以降) および 12c (Enterprise Standard Standard One Standard Two エディション) Enterprise Standard Workgroup および Developer エディションの Microsoft SQL Server バージョ ン 2008R Web および Express エディションはサポートされていません MySQL バージョン

17 他の AWS サービスで使用する MariaDB (MySQL 互換データターゲットとしてサポートされています) PostgreSQL バージョン 9.4 以降 MySQL と互換性がある Amazon Aurora PostgreSQL との互換性を持つ Amazon Aurora Amazon Redshift Amazon S3 Amazon DynamoDB 他の AWS サービスで AWS DMS を使用する 他のいくつかの AWS のサービスで AWS DMS を使用することができます Amazon EC2 インスタンスまたは Amazon RDS DB インスタンスをデータ移行のターゲットとして使用 できます AWS スキーマ変換ツール (AWS SCT) を使用して ソーススキーマと SQL コードを同等のターゲット スキーマと SQL コードに変換できます Amazon S3 をデータのストレージサイトとして使用することも 大量のデータを移行する際の中間ス テップとして Amazon S3 を使用することもできます AWS CloudFormation を使用して インフラストラクチャの管理または導入用の AWS リソースを設定 できます たとえば レプリケーションインスタンス タスク 証明書 エンドポイントなどの AWS DMS リソースをプロビジョンできます 必要なすべての AWS リソースを説明するテンプレートを作成 すれば AWS CloudFormation がお客様に代わってこれらのリソースのプロビジョンや設定を処理しま す AWS DMS による AWS CloudFormation のサポート AWS CloudFormation を使用して AWS Database Migration Service リソースをプロビジョンできま す AWS CloudFormation は インフラストラクチャの管理またはデプロイ用に AWS のリソースのモデ ル化とセットアップを支援するサービスです たとえば レプリケーションインスタンス タスク 証明 書 エンドポイントなどの AWS DMS リソースをプロビジョニングできます 必要なすべての AWS リ ソースを説明するテンプレートを作成すれば AWS CloudFormation がお客様に代わってこれらのリソー スのプロビジョンや設定を処理します 開発者またはシステム管理者は これらのリソースのコレクションを作成および管理し 繰り返し行わ れる移行タスクや 組織へのリソースのデプロイに使用できます AWS CloudFormation の詳細について は AWS CloudFormation ユーザーガイド の AWS CloudFormation 概念 を参照してください AWS DMS は AWS CloudFormation を使用した次の AWS DMS リソースの作成をサポートします AWS::DMS::Certificate AWS::DMS::Endpoint AWS::DMS::EventSubscription AWS::DMS::ReplicationInstance AWS::DMS::ReplicationSubnetGroup AWS::DMS::ReplicationTask AWS DMS の Amazon リソースネーム (ARN) の構築 AWS CLI または AWS Database Migration Service API を使用してデータベース移行を自動化する場 合 Amazon リソースネーム (ARN) の使用方法について知っておく必要があります Amazon Web 11

18 ARN の構築 Services で作成されたリソースは 一意の識別子である ARN によって特定されます AWS CLI または AWS DMS API を使用してデータベース移行をセットアップする場合は 操作するリソースの ARN を指定 する必要があります AWS DMS リソースの ARN には以下の構文を使用します arn:aws:dms:<region>:<account number>:<resourcetype>:<resourcename> この構文の説明は次のとおりです <region> は us-west-2 などの AWS DMS リソースが作成された AWS リージョンの ID です 以下の表に ARN を作成するときに使用する必要のある AWS リージョンの名前とその値を示します サービス対象 名前 アジアパシフィック (東京) リージョン ap-northeast-1 アジアパシフィック (ソウル) リージョン ap-northeast-2 アジアパシフィック (ムンバイ) リージョン ap-south-1 アジアパシフィック (シンガポール) リージョン ap-southeast-1 アジアパシフィック (シドニー) リージョン ap-southeast-2 カナダ (中部) リージョン ca-central-1 欧州 (フランクフルト) リージョン eu-central-1 欧州 (アイルランド) リージョン eu-west-1 欧州 (ロンドン) リージョン eu-west-2 南米 (サンパウロ) リージョン sa-east-1 米国東部 (バージニア北部) リージョン us-east-1 米国東部 (オハイオ) リージョン us-east-2 米国西部 (北カリフォルニア) リージョン us-west-1 米国西部 (オレゴン) リージョン us-west-2 <account number> はダッシュ記号が省略されたアカウント番号です アカウント番号を見つけるに は で自分の AWS アカウントにログインし [My Account/Console (アカウン ト/コンソール)] [My Account (アカウント)] の順に選択します <resourcetype> は AWS DMS リソースのタイプです 次の表は 特定の AWS DMS リソースの ARN を構築するときに使用する必要があるリソースタイプを 示しています AWS DMS リソースタ イプ ARN 形式 レプリケーションイン スタンス arn:aws:dms:<region>: <account>:rep: <resourcename> エンドポイント arn:aws:dms:<region>:<account>:endpoint: <resourcename> 12

19 ARN の構築 AWS DMS リソースタ イプ ARN 形式 レプリケーションタス ク arn:aws:dms:<region>:<account>:task:<resourcename> サブネットグループ arn:aws:dms:<region>:<account>:subgrp:<resourcename> <resourcename> は AWS DMS リソースに割り当てられたリソース名です これは生成された任意 の文字列です 以下の表に示しているのは AWS DMS リソースの ARN の例です AWS アカウントは 作成リージョンは 米国東部 バージニア北部 リソース名は次のようになっているとします リソースタイプ サンプル ARN レプリケーションイン スタンス arn:aws:dms:useast-1: :rep:qlxqz64mh7cxf4qcqmgrvyvxai エンドポイント arn:aws:dms:useast-1: :endpoint:d3hmz2igucgff3ntaxuxgf6s5a レプリケーションタス ク arn:aws:dms:useast-1: :task:2pvremwnpgyjcvu2ibptoytiv4 サブネットグループ arn:aws:dms:us-east-1: :subgrp:test-tag-grp 13

20 AWS にサインアップする AWS Database Migration Service の セットアップ AWS Database Migration Service (AWS DMS) を初めて使用する場合は 事前に以下のタスクをすべて実 行してください 1. AWS にサインアップする (p. 14) 2. IAM ユーザーを作成する (p. 14) 3. AWS Database Migration Service での移行計画 (p. 16) AWS にサインアップする アマゾン ウェブ サービス AWS にサインアップすると AWS アカウントが AWS 内のすべてのサービ ス AWS DMS など に自動的にサインアップされます 料金が発生するのは 実際に使用したサービス の分のみです AWS DMS は 使用したリソース分のみお支払いいただくだけで利用可能です 作成した AWS DMS レ プリケーションインスタンスはライブとなります (サンドボックスで実行されるわけではありません) イ ンスタンスを終了するまで AWS DMS の標準使用料が発生します AWS DMS の使用料の詳細について は AWS DMS 製品ページを参照してください AWS の新規のお客様である場合は AWS DMS の使用 を無料で開始できます 詳細については AWS 無料利用枠 を参照してください AWS アカウントを閉じた場合 アカウントに関連付けられたすべての AWS DMS リソースおよび設定は 2 日後に削除されます これらのリソースには すべてのレプリケーションインスタンス ソースおよび ターゲットのエンドポイント設定 レプリケーションタスク および SSL 証明書が含まれます 2 日後に AWS DMS を再度使用する場合は 必要なリソースを再作成します 既に AWS アカウントをお持ちの場合は次のタスクに進んでください AWS アカウントをお持ちでない場合は 次に説明する手順に従ってアカウントを作成してください AWS にサインアップするには 1. を開き [AWS アカウントの作成] を選択します 2. オンラインの手順に従います 次のタスクで AWS アカウント番号が必要となるので メモしておいてください IAM ユーザーを作成する AWS のサービス AWS DMS など の場合は サービスにアクセスする際に認証情報を提供する必要が あります このため サービスのリソースにアクセスする権限があるかどうかがサービスによって判定 されます コンソールを使用するにはパスワードが必要です AWS アカウントのアクセスキーを作成し て コマンドラインインターフェイスまたは API にアクセスすることができます ただし AWS アカウ ントの認証情報を使って AWS にアクセスすることはお勧めしません 代わりに AWS Identity and Access Management IAM を使用することをお勧めします IAM ユーザーを作成して 管理権限を使ってこの 14

21 IAM ユーザーを作成する ユーザーを IAM グループに追加するか 管理権限を付与します これで 特殊な URL と IAM ユーザーの 認証情報を使って AWS にアクセスできます AWS にサインアップしても ご自分の IAM ユーザーをまだ作成していない場合は IAM コンソールを使 用して作成できます 自分用の IAM ユーザーを作成し そのユーザーを管理者グループに追加するには 1. AWS アカウント E メールアドレスとパスワードを使用して で AWS アカウントのルートユーザー として IAM コンソールにサインインします Note 以下の管管管 IAM ユーザーの使用に関するベストプラクティスに従い ルートユーザー認証情 報を安全な場所に保管しておくことを強くお勧めします ルートユーザーとしてサインイン して 少数のアカウントおよびサービス管理タスクのみを実行します 2. コンソールのナビゲーションペインで [Users] を選択後 [Add user] を選択します 3. [User name] に Administrator と入力します 4. [AWS マネジメントコンソール access] の横のチェックボックスをオンにし [Custom password] を選 択して 新しいユーザーのパスワードをテキストボックスに入力します オプションとして [Require password reset] (パスワードのリセットの強制) を選択し ユーザーが次回サインインしたときに新し いパスワードを作成することを強制できます 5. [Next: Permissions] を選択します 6. [Set permissions ] ページで [Add user to group] を選択します 7. [Create group] を選択します 8. [グループの作成] ダイアログボックスで [グループ名] に Administrators と入力します 9. [ポリシーのフィルタ] で [AWS 管理のジョブ機能] チェックボックスをオンにします 10. ポリシーリストで [AdministratorAccess] のチェックボックスをオンにします 次に [Create group] を選択します 11. グループのリストに戻り 新しいグループのチェックボックスをオンにします 必要に応じて [Refresh] を選択し リスト内のグループを表示します 12. [Next: Review] を選択して 新しいユーザーに追加するグループメンバーシップのリストを表示しま す 続行する準備ができたら [Create user] を選択します この同じプロセスを繰り返して新しいグループとユーザーを作成し AWS アカウントのリソースへのアク セス権をユーザーに付与できます ポリシーを使用して特定の AWS リソースに対するユーザーのアクセ ス権限を制限する方法については アクセス管理 と ポリシーの例 を参照してください 新規の IAM ユーザーとしてサインインするには AWS コンソールからサインアウトし 次の URL を使 用します このとき your_aws_account_id はハイフンを除いた AWS アカウント番号です たとえ ば AWS アカウント番号が であれば AWS アカウント ID は となり ます 作成した IAM ユーザー名とパスワードを入力します サインインすると ナビゲーションバーに your_aws_account_id が表示されます サインページの URL に AWS アカウント ID を含めない場合は アカウントのエイリアスを作成しま す IAM ダッシュボードで [カスタマイズ] を選択し エイリアス (会社名など) を入力します アカウント エイリアスを作成した後 サインインするには 次の URL を使用します 15

22 AWS Database Migration Service での移行計画 アカウントの IAM ユーザーのサインインリンクを確認するには IAM コンソールを開き ダッシュボード の [AWS Account Alias] の下を確認します AWS Database Migration Service での移行計画 AWS Database Migration Service を使用してデータベース移行を計画するときは 以下の点を考慮してく ださい ソースとターゲットのデータベースを AWS DMS レプリケーションインスタンスに接続するネットワー クを設定する必要があります これは 同じ VPC 内にある 2 つの AWS リソースをより複雑な設定にレ プリケーションインスタンスとして接続する (オンプレミスデータベースを VPN 経由で Amazon RDS DB インスタンスに接続するなど) のと同じくらい簡単です 詳細については データベース移行の ネットワーク設定 (p. 66) を参照してください ソースとターゲットのエンドポイント ソースデータベース内のどの情報とテーブルをターゲットデー タベースに移行する必要があるかを知っている必要があります AWS DMS では テーブルとプライ マリキーの作成を含む 基本的なスキーマの移行がサポートされています ただし AWS DMS では ターゲットデータベースのセカンダリインデックス 外部キー ユーザーアカウントなどは自動的に 作成されません ソースおよびターゲットデータベースエンジンによっては サプリメンタルロギン グをセットアップしたり ソースまたはターゲットデータベースの他の設定を変更したり必要がある点 に注意してください 詳細については データ移行のソース (p. 84) と データ移行のターゲッ ト (p. 146) を参照してください スキーマ/コードの移行 AWS DMS では スキーマまたはコードの変換が実行されません Oracle SQL Developer MySQL Workbench または pgadmin III などのツールを使用してスキーマを変換できま す 異なるデータベースエンジンに既存のスキーマを変換する場合 AWS スキーマ変換ツールを使用 できます このツールは ターゲットスキーマを作成でき スキーマ全体 (テーブル インデックス ビューなど) を生成および作成することもできます このツールを使用して PL/SQL または TSQL を PgSQL や他の形式に変換することもできます AWS スキーマ変換ツールの詳細については AWS ス キーマ変換ツール を参照してください サポートされていないデータ型 ソースの一部のデータ型は ターゲットデータベースのデータ型と同 等のデータ型に変換する必要があります サポートされているデータ型の詳細については データスト アのソースまたはターゲットセクションを参照してください 16

23 データベースの移行開始 AWS Database Migration Service の 使用開始 AWS Database Migration Service (AWS DMS) は AWS にデータベースを簡単かつ安全に移行しま す Oracle MySQL PostgreSQL などの最も広く使用されている 市販のオープンソースデータベース 間でデータを移行できます このサービスでは Oracle から Oracle など 同機種間の移行をサポートし ているほか Oracle から PostgreSQL MySQL から Oracle など 異なるデータベースプラットフォーム 間の異機種の移行もサポートしています AWS Database Migration Service を使用したデータベース移行のコストについては AWS Database Migration Service の料金表ページ を参照してください トピック AWS Database Migration Service によるデータベースの移行開始 (p. 17) ステップ 1: [Welcome] (p. 17) ステップ 2: レプリケーションのインスタンスを作成する (p. 18) ステップ 3: ソースとターゲットのエンドポイントを指定する (p. 22) ステップ 4: タスクを作成する (p. 25) タスクをモニタリングする (p. 29) AWS Database Migration Service によるデータベー スの移行開始 データベース移行はいくつかの方法で開始することができます AWS DMS コンソールウィザードを選択 してこのプロセスの各手順を実行するか ナビゲーションペインで該当するタスクを選択して各手順を実 行することができます また AWS CLI を使用することもできます AWS DMS で CLI を使用する方法に ついては AWS CLI for AWS DMS を参照してください ウィザードを使用するには AWS DMS コンソールのナビゲーションペインで [Getting started (開始方法)] を選択します ウィザードを使用して 最初のデータ移行を作成できます ウィザードプロセスの後で 移行のすべてのプロセスを実行するレプリケーションのインスタンスを割り当て ソースとターゲット データベースを指定してから どのテーブルとレプリケーションプロセスを使用するかを定義したタスク または一連のタスクを作成します AWS DMS は レプリケーションのインスタンスを作成し 移行中の データでタスクを実行します または ナビゲーションペインから項目を選択して AWS DMS を使用したデータベース移行の各コン ポーネントを作成することもできます データベース移行では 以下の操作を行う必要があります AWS Database Migration Service のセットアップ (p. 14) で概説しているタスクを完了する 移行のすべてのプロセスを実行するレプリケーションインスタンスを割り当てる ソースとターゲットのデータベースエンドポイントを指定する 使用するテーブルとレプリケーションプロセスを定義するタスクまたはタスクセットを作成する ステップ 1: [Welcome] AWS DMS コンソールウィザードを使用してデータベース移行を開始した場合は AWS DMS を使用した データベース移行のプロセスを説明する [Welcome (ようこそ)] ページが表示されます 17

24 ステップ 2: レプリケーションのインスタンスを作成する コンソールの [Welcome] ページからデータベースの移行を開始するには [Next (次へ)] を選択します ステップ 2: レプリケーションのインスタンスを作 成する データベースの移行の最初のタスクは 割り当てるタスクを実行するのに十分なストレージと処理能力を 持つレプリケーションのインスタンスを作成し ソースデータベースからターゲットデータベースにデー タを移行することです このインスタンスの必要なサイズは 移行する必要のあるデータの量 および インスタンスが実行するタスクにより異なります レプリケーションインスタンスの詳細については AWS DMS レプリケーションインスタンスを使用する (p. 57) を参照してください 以下の手順では AWS DMS コンソールウィザードを選択したことを前提とします このステップ は AWS DMS コンソールのナビゲーションペインで [Replication instances (レプリケーションインスタ ンス)] [Create replication instance (レプリケーションインスタンスの作成)] を順に選択して実行すること もできます AWS コンソールを使用してレプリケーションインスタンスを作成するには 1. ナビゲーションペインで [レプリケーションインスタンス] をクリックします 2. [Create Replication Instance] を選択します 3. [Create replication instance] ページで レプリケーションのインスタンス情報を指定します 次の表 で設定について説明します 18

25 ステップ 2: レプリケーションのインスタンスを作成する 使用するオプション 操作 名前 8 16 の印刷可能な ASCII 文字 (/ を除く) を含 むレプリケーションインスタンス名を入力します 名前 は 選択したリージョンのアカウントで一意でなければ なりません わかりやすい名前にするには リージョンや 実行中のタスクなどの情報を名前に含めます (例: west2mysql2mysql-instance1) 説明 レプリケーションインスタンスの簡単な説明を入力しま す インスタンスクラス 移行に必要な設定を使用してインスタンスのクラスを選 択します 正常に移行を完了するために インスタンス には十分なストレージ ネットワーク 処理能力が必要 であることに注意してください 移行に最適なインスタ ンスのクラスを決定する方法に関する詳細については AWS DMS レプリケーションインスタンスを使用す る (p. 57) を参照してください レプリケーションエンジンのバージョ ン デフォルトでは レプリケーションインスタンスは最新 バージョンの AWS DMS レプリケーションエンジンソフ トウェアを実行します このデフォルトをそのまま使用す ることをお勧めします ただし 必要に応じて 以前のエ ンジンバージョンを選択できます 19

26 ステップ 2: レプリケーションのインスタンスを作成する 4. 使用するオプション 操作 VPC 使用する Amazon Virtual Private Cloud (Amazon VPC) を選択します ソースまたはターゲットデータベースが VPC にある場合 その VPC を選択します ソースまたは ターゲットデータベースが別の VPC にある場合 それら が共にパブリックサブネットにあり パブリックにアク セス可能であることを確認してから レプリケーションイ ンスタンスが配置される VPC を選択します レプリケー ションインスタンスが ソース VPC のデータにアクセス できるようにする必要があります ソースもターゲット データベースも VPC にない場合は レプリケーションイ ンスタンスを配置する VPC を選択します マルチ AZ オプションのパラメータを使用して フェイルオーバー のサポート用に別のアベイラビリティーゾーンにレプリ ケーションインスタンスのスタンバイレプリカを作成しま す 変更データキャプチャ (CDC) または 進行中のレプ リケーションを使用する場合は このオプションを有効に する必要があります パブリックアクセス可能 レプリケーションインスタンスをインターネットからアク セス可能にする場合は このオプションを選択します 必要がある場合は [Advanced] タブを選択して 次に示す通り ネットワークおよび暗号化設定の値 を設定します 次の表で設定について説明します 20

27 ステップ 2: レプリケーションのインスタンスを作成する 使用するオプション 操作 Allocated storage (GB) ストレージは主に ログファイルと キャッシュされたト ランザクションで消費されます キャッシュされたトラン ザクションでは ストレージは キャッシュされたトラン ザクションをディスクに書き込む必要がある場合にのみ使 用されます そのため AWS DMS では大量のストレージ は使用されませんが 次のような場合は例外です 膨大なトランザクションをロードする サイズの大きな テーブル サイズの大きなテーブルをロードするには時 間がかかります そのため サイズの大きなテーブルを ロードする間 キャッシュされたトランザクションが書 き込まれる可能性が高くなります キャッシュされたトランザクションをロードする前に停 止するよう設定されているタスク この場合 すべての テーブルのロードが完了するまで すべてのトランザ クションがキャッシュされます この設定では キャッ シュされたトランザクションにより かなりの量のスト レージが消費されることがあります Amazon Redshift にロードされるテーブルを使用する設 定になっているタスク ただし Amazon Aurora がター ゲットのときは この設定は問題にはなりません ほとんどの場合 ストレージのデフォルトの割り当てで十 分です ただし ストレージ関連のメトリクスに注意を払 い デフォルトの割り当てよりも消費量が多い場合はスト レージを拡張することをおすすめします レプリケーションサブネットグループ レプリケーションインスタンスを作成する選択した VPC でレプリケーションサブネットグループを選択します ソースデータベースが VPC にある場合は レプリケー ションインスタンスの場所として ソースデータベースを 含むサブネットグループを選択します レプリケーション サブネットグループの詳細については レプリケーショ ンサブネットグループの作成 (p. 71) を参照してくだ さい アベイラビリティーゾーン ソースデータベースが配置されているアベイラビリティー ゾーンを選択します VPC セキュリティグループ レプリケーションのインスタンスが VPC 内で作成され ます ソースデータベースが VPC にある場合は データ ベースが存在する DB インスタンスへのアクセス権を提供 する VPC セキュリティグループを選択します KMS マスターキー 使用する暗号化キーを選択して レプリケーションのス トレージと接続情報を暗号化します (デフォルト) aws/ dms を選択する場合 アカウントおよびリージョンに関連 付けられたデフォルトの AWS Key Management Service (AWS KMS) キーが使用されます 説明とアカウント番号 が キーの ARN とともに表示されます 暗号化キーの使 用の詳細については 暗号化キーの設定と KMS のアク セス許可の指定 (p. 45) を参照してください 21

28 ステップ 3: ソースとターゲッ トのエンドポイントを指定する 5. [Maintenance] 設定を指定します 次の表で設定について説明します メンテナンス設定の詳細につい ては AWS DMS メンテナンスウィンドウ (p. 60) を参照してください 使用するオプション 操作 Auto minor version upgrade 選択すると メンテナンスの時間帯に レプリケーション インスタンスに自動的にマイナーエンジンアップグレード が適用されます Maintenance window 週 1 回のシステムメンテナンスを実行できる時間帯 (世界 標準時 (UTC)) を選択します デフォルト: 1 週間のうちのランダムな日に起こる リー ジョンあたり 8 時間の範囲からランダムに選択された 30 分の時間窓 6. [Create replication instance] を選択します ステップ 3: ソースとターゲットのエンドポイント を指定する レプリケーションのインスタンスが作成される間 ソースおよびターゲットデータストアを指定できま す ソースおよびターゲットデータストアには Amazon Elastic Compute Cloud (Amazon EC2) インスタ ンス Amazon Relational Database Service (Amazon RDS) DB インスタンス またはオンプレミスデータ ベースを使用できます 以下の手順では AWS DMS コンソールウィザードを選択したことを前提とします このステップは コ ンソールのナビゲーションペインで [Endpoints (エンドポイント)AWS DMS] [Create endpoint (エンドポ イントの作成)] の順に選択することでも実行できます コンソールウィザードを使用するときは ソース エンドポイントとターゲットエンドポイントの両方を同じページで作成します コンソールウィザードを 使用しないときは 各エンドポイントを個別に作成します AWS コンソールを使用して ソースまたはターゲットデータベースエンドポイントを指定するに は 1. [ソースおよびターゲットデータベースエンドポイントの接続] ページで ソースまたはターゲット データベースの接続情報を指定します 次の表で設定について説明します 22

29 ステップ 3: ソースとターゲッ トのエンドポイントを指定する 使用するオプション 操作 エンドポイント識別子 エンドポイントを識別するのに使用する名前を入力し ます 名前に oracle-source または PostgreSQLtarget などのエンドポイントの種類を含めることができ ます 名前はすべてのレプリケーションインスタンスに対 して一意である必要があります 23

30 ステップ 3: ソースとターゲッ トのエンドポイントを指定する 2. 使用するオプション 操作 ソースエンジンとターゲットエンジン エンドポイントであるデータベースエンジンのタイプを選 択します サーバー名 サーバー名を入力します オンプレミスデータベースの場 合 IP アドレスまたはパブリックホスト名にすることが できます Amazon RDS DB インスタンスの場合 DB イ ンスタンスのエンドポイント (DNS 名) とすることができ ます たとえば mysqlsrvinst.abcd uswest-2.rds.amazonaws.com とします ポート データベースが使用するポートを入力します SSL モード このエンドポイントの接続暗号化を有効にする場合 は SSL モードを選択します 選択したモードにより 証 明書 およびサーバー証明書情報の提供を求められること があります ユーザー名 データ移行を許可するために必要な権限を持つユーザー 名を入力します 必要な権限の詳細については このユー ザーガイドの ソースまたはターゲットデータベースエン ジンに対するセキュリティセクション を参照してくださ い パスワード 必要な権限のあるアカウントのパスワードを入力します パスワード内に特殊文字 ("+" や "&" など) を使用する場合 は パスワード全体を中かっこ "" で囲みます 必要がある場合は 次に示す通り [Advanced] タブを選択して 接続文字列および暗号化キーの値を 設定します [テストの実行] を選択して エンドポイントの接続をテストできます 24

31 ステップ 4: タスクを作成する 使用するオプション 操作 追加の接続属性 追加の接続パラメータをここに入力します 追加の接続属 性の詳細については データストアのドキュメントセク ションを参照してください KMS マスターキー 使用する暗号化キーを選択して レプリケーションのスト レージと接続情報を暗号化します (デフォルト) aws/dms を選択する場合 アカウントおよびリージョンに関連付け られたデフォルトの AWS Key Management Service (AWS KMS) キーが使用されます 暗号化キーの使用の詳細につ いては 暗号化キーの設定と KMS のアクセス許可の指 定 (p. 45) を参照してください ステップ 4: タスクを作成する タスクを作成して 移行するテーブルを指定し ターゲットスキーマを使用してデータをマッピングし ターゲットデータベースに新しいテーブルを作成します タスク作成の一環として 移行のタイプ (既存 25

32 ステップ 4: タスクを作成する のデータの移行 既存のデータの移行と継続的な変更のレプリケート または データ変更のみのレプリ ケート) を選択できます AWS DMS を使用して ソースデータベースとターゲットデータベース間のデータの正確なマッピング を指定できます マッピングを指定する前に ソースデータベースとターゲットデータベースのデータ型 マッピングのドキュメントセクションを必ず確認してください [Create task] ページでタスク情報の指定が完了するとすぐに タスクを開始することができます また は タスク情報の指定が完了したら [Dashboard] ページからタスクを開始することもできます 以下の手順では AWS DMS コンソールウィザードを選択し コンソールウィザードを使用してレプリ ケーションインスタンスの情報とエンドポイントを指定したことを前提とします このステップは AWS DMS コンソールのナビゲーションペインで [Tasks (タスク)] [Create task (タスクの作成)] を順に選択し て実行することもできます 移行タスクを作成するには 1. [Create Task] ページで タスクオプションを指定します 次の表で設定について説明します 使用するオプション 操作 タスク名 タスクの名前を入力します タスクの説明 タスクの説明を入力します ソースエンドポイント 使用するソースエンドポイントを表示します ターゲットエンドポイント 使用するターゲットエンドポイントを表示します 26

33 ステップ 4: タスクを作成する 2. 使用するオプション 操作 レプリケーションインスタンス 使用するレプリケーションインスタンスを表示します 移行タイプ 使用する移行方法を選択します 既存のデータのみをター ゲットデータベースへ移行するか 移行したデータに加え て継続的な変更もターゲットデータベースに送信するかを 選択できます 作成時にタスクを開始 このオプションが選択されていると タスクは作成直後に 始まります 次に示すように [Task Settings] タブを選択して ターゲットテーブルの値 LOB サポートを指定し て ログ作成を有効にします 表示されるタスク設定は 選択した移行タイプの値によって異なりま す たとえば [既存のデータの移行] を選択すると 次のオプションが表示されます 使用するオプション 操作 ターゲットテーブル作成モード 何もしない - ターゲットテーブルのデータとメタデータは 変更されません ターゲット上のテーブルを削除 - テーブルは削除され 代 わりに新しいテーブルが作成されます 切り捨て - テーブルは テーブルのメタデータに影響を与 えないで切り捨てられます レプリケーションに LOB 列を含める LOB 列を含めない - LOB 列は移行対象から除外されま す 完全 LOB モード - サイズに関係なく LOB 全体を移行し ます LOB は LOB チャンクサイズによって制御される チャンクの単位で移行されます この方法は制限付き LOB モードを使用するよりも低速です 制限付き LOB モード - LOB を 最大 LOB サイズ まで切 り詰めます この方法は完全 LOB モードを使用するより も高速です 27

34 ステップ 4: タスクを作成する 使用するオプション 操作 最大 LOB サイズ (KB) 制限付き LOB モードでは 最大 LOB サイズの設定を超え る LOB 列は指定した最大 LOB サイズまで切り捨てられま す ログ作成の有効化 Amazon CloudWatch でログ作成を有効にします [既存のデータの移行とレプリケート] を [移行タイプ] で選択した場合 次のオプションが表示されま す 使用するオプション 操作 ターゲットテーブル作成モード 何もしない - ターゲットテーブルのデータとメタデータは 変更されません ターゲット上のテーブルを削除 - テーブルは削除され 代 わりに新しいテーブルが作成されます 切り捨て - テーブルは テーブルのメタデータに影響を与 えないで切り捨てられます 28

35 タスクをモニタリングする 使用するオプション 操作 全ロードの完了後にタスクを停止する 停止しない - タスクを停止しないで キャッシュされた変 更をすぐに適用したら そのまま続行します キャッシュされた変更を適用する前に停止する - キャッ シュされた変更を適用する前に タスクを停止します こ れにより 変更の適用を高速化できるセカンダリインデッ クスを追加できます キャッシュされた変更を適用した後に停止する - キャッ シュされた変更を適用した後に タスクを停止します ト ランザクショナルな適用を使用する場合 これにより 外 部キーやトリガーなどを追加できます レプリケーションに LOB 列を含める LOB 列を含めない - LOB 列は移行対象から除外されま す 完全 LOB モード - サイズに関係なく LOB 全体を移行し ます LOB は LOB チャンクサイズによって制御される チャンクの単位で移行されます この方法は制限付き LOB モードを使用するよりも低速です 制限付き LOB モード - LOB を 最大 LOB サイズ まで切 り詰めます この方法は完全 LOB モードを使用するより も高速です 最大 LOB サイズ (KB) 制限付き LOB モードでは 最大 LOB サイズの設定を超え る LOB 列は指定した最大 LOB サイズまで切り捨てられま す ログ作成の有効化 Amazon CloudWatch でログ作成を有効にします 3. 次に示す通り [テーブルマッピング] タブを選択して スキーママッピングの値およびマッピング方 法を設定します [カスタム] を選択した場合 ターゲットスキーマとテーブル値を指定できます テーブルマッピングの詳細については テーブルマッピングを使用して タスクの設定を指定す る (p. 224) を参照してください 4. タスクの設定を完了したら [タスクの作成] を選択します タスクをモニタリングする 作成時に [作成時にタスクを開始] を選択した場合 タスクは [タスクの作成] を選択するとすぐにデー タの移行を開始します AWS マネジメントコンソールから実行中のタスクを選択することにより タスク 29

36 タスクをモニタリングする の統計とモニタリング情報を表示できます 次のスクリーンショットはデータベースの移行のテーブルの 統計を表示します モニタリングの詳細については AWS DMS タスクのモニタリング (p. 241) を参 照してください 30

37 必要な IAM アクセス許可 AWS Database Migration Service の セキュリティ AWS Database Migration Service (AWS DMS) は 複数のプロセスを使用して移行中にデータを保護し ます このサービスは AWS アカウントに固有の AWS Key Management Service (KMS) キーを使用し て レプリケーションインスタンスにより使用されるストレージとエンドポイント接続情報を暗号化しま す Secure Sockets Layer (SSL) がサポートされています AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合 AWS Database Migration Service を使用するには適切なアクセ ス許可も必要になります レプリケーションインスタンスで使用する Amazon Virtual Private Cloud (Amazon VPC) サービスをベース とする VPC は すべてのポートですべてのトラフィックが VPC を退出 (送信) するのを許可するルールを 持つセキュリティグループに関連付ける必要があります このアプローチでは ソースおよびターゲット データベースエンドポイントで適切な受信が有効になっている限り レプリケーションインスタンスから それらのエンドポイントへの通信が許可されます データベース移行ログを表示する場合 使用している IAM ロールの適切な Amazon CloudWatch ログアク セス許可が必要になります トピック AWS DMS を使用するのに必要な IAM アクセス許可 (p. 31) AWS CLI と AWS DMS API で使用する IAM ロールを作成する (p. 34) リソース名とタグを使用したファイングレインアクセスコントロール (p. 38) 暗号化キーの設定と KMS のアクセス許可の指定 (p. 45) AWS Database Migration Service のネットワークセキュリティ (p. 46) AWS Database Migration Service で SSL を使用する (p. 47) データベースのパスワードの変更 (p. 55) AWS DMS を使用するのに必要な IAM アクセス許 可 AWS DMS を使用するには 特定の IAM アクセス許可と IAM ロールを使用する必要があります IAM ユーザーとしてサインインして AWS DMS を使用する場合 アカウント管理者は このセクションで示す ポリシーを AWS DMS の実行に使用する IAM ユーザー グループ またはロールにアタッチする必要が あります IAM アクセス許可の詳細については IAM ユーザーガイド を参照してください 以下のアクセス許可セットでは AWS DMS にアクセスし AWS KMS IAM Amazon Elastic Compute Cloud (Amazon EC2) および Amazon CloudWatch などの AWS の他のサービスで必要とされる特定のア クションを実行するためのアクセス権限が付与されます CloudWatch は AWS DMS 移行をリアルタイ ムでモニタリングし 移行の進行状況を示すメトリクスを収集および追跡します CloudWatch ログを使 用すると タスクの問題をデバッグできます Note タグ付けを使用して AWS DMS リソースへのアクセスをさらに制限できます タグ付けを使用 して AWS DMS リソースへのアクセスを制限する方法については リソース名とタグを使用し たファイングレインアクセスコントロール (p. 38) を参照してください "Version": " ", 31

38 必要な IAM アクセス許可 "Statement": [ "Effect": "Allow", "Action": "dms:*", "Resource": "*", "Effect": "Allow", "Action": [ "kms:listaliases", "kms:describekey" ], "Resource": "*", "Effect": "Allow", "Action": [ "iam:getrole", "iam:passrole", "iam:createrole", "iam:attachrolepolicy" ], "Resource": "*", "Effect": "Allow", "Action": [ "ec2:describevpcs", "ec2:describeinternetgateways", "ec2:describeavailabilityzones", "ec2:describesubnets", "ec2:describesecuritygroups", "ec2:modifynetworkinterfaceattribute", "ec2:createnetworkinterface", "ec2:deletenetworkinterface" ], "Resource": "*", "Effect": "Allow", "Action": [ "cloudwatch:get*", "cloudwatch:list*" ], "Resource": "*", "Effect": "Allow", "Action": [ "logs:describeloggroups", "logs:describelogstreams", "logs:filterlogevents", "logs:getlogevents" ], "Resource": "*", "Effect": "Allow", "Action": [ "redshift:describe*", "redshift:modifyclusteriamroles" ], "Resource": "*" ] 32

39 必要な IAM アクセス許可 これらの権限の内訳は それぞれの権限が必要な理由を理解するうえで役立ちます このセクションは ユーザーが AWS DMS API オペレーションを呼び出すことを許可するために必要で す "Effect": "Allow", "Action": "dms:*", "Resource": "*" このセクションは 利用可能な KMS キーとエイリアスをユーザーがリストし コンソールに表示するこ とを許可するために必要です KMSkey ARN が既知で CLI のみを使用する場合 このエントリは必要で はありません "Effect": "Allow", "Action": [ "kms:listaliases", "kms:describekey" ], "Resource": "*" このセクションは エンドポイントとともにロール ARN を渡す必要がある特定のエンドポイントタイプ に必要です さらに 必要な AWS DMS ロールが事前に作成されていない場合 AWS DMS コンソール はそのロールを作成することができます すべてのロールが事前に設定されている場合 必要なものは iam:getrole および iam:passrole のみです ロールの詳細については AWS CLI と AWS DMS API で 使用する IAM ロールを作成する (p. 34) を参照してください "Effect": "Allow", "Action": [ "iam:getrole", "iam:passrole", "iam:createrole", "iam:attachrolepolicy" ], "Resource": "*" AWS DMS は EC2 インスタンスを作成し 作成されるレプリケーションインスタンス用のネットワークを 設定する必要があるため このセクションが必要です これらのリソースはお客様のアカウント内に存在 するため お客様に代わってこれらのアクションを実行できる必要があります "Effect": "Allow", "Action": [ "ec2:describevpcs", "ec2:describeinternetgateways", "ec2:describeavailabilityzones", "ec2:describesubnets", "ec2:describesecuritygroups", "ec2:modifynetworkinterfaceattribute", "ec2:createnetworkinterface", "ec2:deletenetworkinterface" ], 33

40 CLI および API の IAM ロール "Resource": "*" このセクションは ユーザーがレプリケーションインスタンスのメトリクスを表示することを許可するた めに必要です "Effect": "Allow", "Action": [ "cloudwatch:get*", "cloudwatch:list*" ], "Resource": "*" このセクションは ユーザーがレプリケーションログを表示することを許可するために必要です "Effect": "Allow", "Action": [ "logs:describeloggroups", "logs:describelogstreams", "logs:filterlogevents", "logs:getlogevents" ], "Resource": "*" このセクションは Redshift をターゲットとして使用する場合に必要です これにより AWS DMS は Redshift クラスターが AWS DMS に対して適切に設定されていることを検証できます "Effect": "Allow", "Action": [ "redshift:describe*", "redshift:modifyclusteriamroles" ], "Resource": "*" AWS DMS コンソールは AWS DMS コンソールを使用する際に AWS アカウントに自動的にアタッチさ れる複数のロールを作成します AWS Command Line Interface (AWS CLI) または AWS DMS API を移行 に使用する場合 これらのロールをアカウントに追加する必要があります これらのロールの追加の詳細 については AWS CLI と AWS DMS API で使用する IAM ロールを作成する (p. 34) を参照してくだ さい AWS CLI と AWS DMS API で使用する IAM ロール を作成する AWS CLI または AWS DMS API をデータベース移行に使用する場合 AWS DMS の機能を使用する前に 3 つの IAM ロールを AWS アカウントに追加する必要があります これらのロールのうち 2 つは dms-vpcrole と dms-cloudwatch-logs-role です Amazon Redshift をターゲットデータベースとして使用し ている場合 IAM ロール dms-access-for-endpoint も AWS アカウントに追加する必要があります 管理ポリシーの更新は自動です IAM ロールでカスタムポリシーを使用する場合 このドキュメントで管 理ポリシーの更新事項がないか定期的に確認してください 管理ポリシーの詳細は get-policy コマン ドと get-policy-version コマンドを組み合わせて使用して表示できます 34

41 CLI および API の IAM ロール たとえば 次の get-policy コマンドはロールの情報を取得します aws iam get-policy --policy-arn arn:aws:iam::aws:policy/service-role/ AmazonDMSVPCManagementRole コマンドから返される情報は 次のとおりです "Policy": "PolicyName": "AmazonDMSVPCManagementRole", "Description": "Provides access to manage VPC settings for AWS managed customer configurations", "CreateDate": " T16:33:19Z", "AttachmentCount": 1, "IsAttachable": true, "PolicyId": "ANPAJHKIGMBQI4AEFFSYO", "DefaultVersionId": "v3", "Path": "/service-role/", "Arn": "arn:aws:iam::aws:policy/service-role/amazondmsvpcmanagementrole", "UpdateDate": " T16:29:57Z" 次の get-policy-version コマンドは ポリシー情報を取得します aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/service-role/ AmazonDMSVPCManagementRole --version-id v3 コマンドから返される情報は 次のとおりです "PolicyVersion": "CreateDate": " T16:29:57Z", "VersionId": "v3", "Document": "Version": " ", "Statement": [ "Action": [ "ec2:createnetworkinterface", "ec2:describeavailabilityzones", "ec2:describeinternetgateways", "ec2:describesecuritygroups", "ec2:describesubnets", "ec2:describevpcs", "ec2:deletenetworkinterface", "ec2:modifynetworkinterfaceattribute" ], "Resource": "*", "Effect": "Allow" ], "IsDefaultVersion": true 35

42 CLI および API の IAM ロール AmazonDMSCloudWatchLogsRole および AmazonDMSRedshiftS3Role 管理ポリシーの情報を取得す る場合も同じコマンドを使用できます Note データベースの移行に AWS DMS コンソールを使用する場合 これらのロールは AWS アカウン トに自動的に追加されます 次の手順では dms-vpc-role dms-cloudwatch-logs-role および dms-access-forendpoint の各 IAM ロールを作成します AWS CLI または AWS DMS API で使用する dms-vpc-role IAM ロールを作成するには 1. 次の IAM ポリシーを含む JSON ファイルを作成します JSON ファイルに dmsassumerolepolicydocument.json という名前を付けます ] "Version": " ", "Statement": [ "Effect": "Allow", "Principal": "Service": "dms.amazonaws.com", "Action": "sts:assumerole" 次のコマンドを使用して AWS CLI でロールを作成します aws iam create-role --role-name dms-vpc-role --assume-role-policy-document file:// dmsassumerolepolicydocument.json 2. 次のコマンドを使用して AmazonDMSVPCManagementRole ポリシーを dms-vpc-role にアタッチ します aws iam attach-role-policy --role-name dms-vpc-role --policy-arn arn:aws:iam::aws:policy/service-role/amazondmsvpcmanagementrole AWS CLI または AWS DMS API で使用する dms-cloudwatch-logs-role IAM ロールを作成す るには 1. 次の IAM ポリシーを含む JSON ファイルを作成します JSON ファイルに dmsassumerolepolicydocument2.json という名前を付けます "Version": " ", 36

43 CLI および API の IAM ロール ] "Statement": [ "Effect": "Allow", "Principal": "Service": "dms.amazonaws.com", "Action": "sts:assumerole" 次のコマンドを使用して AWS CLI でロールを作成します aws iam create-role --role-name dms-cloudwatch-logs-role --assume-role-policy-document file://dmsassumerolepolicydocument2.json 2. 次のコマンドを使用して AmazonDMSCloudWatchLogsRole ポリシーを dms-cloudwatch-logsrole にアタッチします aws iam attach-role-policy --role-name dms-cloudwatch-logs-role --policy-arn arn:aws:iam::aws:policy/service-role/amazondmscloudwatchlogsrole Amazon Redshift をターゲットデータベースとして使用する場合 IAM ロール dms-access-forendpoint を作成して Amazon S3 (S3) へのアクセスを可能にする必要があります Amazon Redshift をターゲットデータベースとして使用するための dms-access-forendpoint IAM ロールを作成するには 1. 次の IAM ポリシーを含む JSON ファイルを作成します JSON ファイルに dmsassumerolepolicydocument3.json という名前を付けます "Version": " ", "Statement": [ "Sid": "1", "Effect": "Allow", "Principal": "Service": "dms.amazonaws.com", "Action": "sts:assumerole", "Sid": "2", "Effect": "Allow", "Principal": "Service": "redshift.amazonaws.com", "Action": "sts:assumerole" ] 37

44 FGAC Fine-Grained Access Control 2. 次のコマンドを使用して AWS CLI でロールを作成します aws iam create-role --role-name dms-access-for-endpoint --assume-role-policy-document file://dmsassumerolepolicydocument3.json 3. 次のコマンドを使用して AmazonDMSRedshiftS3Role ポリシーを dms-access-for-endpoint ロールにアタッチします aws iam attach-role-policy --role-name dms-access-for-endpoint \ --policy-arn arn:aws:iam::aws:policy/service-role/amazondmsredshifts3role AWS CLI または AWS DMS API を使用するための IAM ポリシーが設定されている必要があります リソース名とタグを使用したファイングレインアク セスコントロール ARN ベースのリソース名とリソースタグを使用して AWS DMS リソースへのアクセスを管理できます これを行うには 許可されたアクションを定義するか 条件ステートメントを IAM ポリシーに含めます リソース名を使用したアクセスの制御 IAM ユーザーアカウントを作成し AWS DMS リソースの Amazon リソースネーム (ARN) に基づいてポ リシーを割り当てることができます 次のポリシーでは ARN arn:aws:dms:us-east-1: :rep:doh67ztoxglixmihkitv を使用し て AWS DMS レプリケーションインスタンスへのアクセスを拒否します "Version": " ", "Statement": [ "Action": [ "dms:*" ], "Effect": "Deny", "Resource": "arn:aws:dms:us-east-1: :rep:doh67ztoxglixmihkitv" ] たとえば 次のコマンドは ポリシーが有効になっていると失敗します $ aws dms delete-replication-instance --replication-instance-arn "arn:aws:dms:us-east-1: :rep:doh67ztoxglixmihkitv" A client error (AccessDeniedException) occurred when calling the DeleteReplicationInstance operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:deletereplicationinstance on resource: arn:aws:dms:useast-1: :rep:doh67ztoxglixmihkitv 38

45 リソース名を使用したアクセスの制御 $ aws dms modify-replication-instance --replication-instance-arn "arn:aws:dms:us-east-1: :rep:doh67ztoxglixmihkitv" A client error (AccessDeniedException) occurred when calling the ModifyReplicationInstance operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:modifyreplicationinstance on resource: arn:aws:dms:useast-1: :rep:doh67ztoxglixmihkitv AWS DMS エンドポイントとレプリケーションタスクへのアクセスを制限する IAM ポリシーを指定するこ ともできます 以下のポリシーでは エンドポイントの ARN を使用して AWS DMS エンドポイントへのアクセスを制限 します "Version": " ", "Statement": [ "Action": [ "dms:*" ], "Effect": "Deny", "Resource": "arn:aws:dms:us-east-1: :endpoint:d6e37ybxtnhoa6xrqszcugx" ] たとえば 次のコマンドは エンドポイントの ARN を使用するポリシーが有効になっていると失敗しま す $ aws dms delete-endpoint --endpoint-arn "arn:aws:dms:us-east-1: :endpoint:d6e37ybxtnhoa6xrqszcugx" A client error (AccessDeniedException) occurred when calling the DeleteEndpoint operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:deleteendpoint on resource: arn:aws:dms:us-east-1: :endpoint:d6e37ybxtnhoa6xrqszcugx $ aws dms modify-endpoint --endpoint-arn "arn:aws:dms:us-east-1: :endpoint:d6e37ybxtnhoa6xrqszcugx" A client error (AccessDeniedException) occurred when calling the ModifyEndpoint operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:modifyendpoint on resource: arn:aws:dms:us-east-1: :endpoint:d6e37ybxtnhoa6xrqszcugx 以下のポリシーでは タスクの ARN を使用して AWS DMS タスクへのアクセスを制限します "Version": " ", "Statement": [ "Action": [ "dms:*" 39

46 タグを使用したアクセスの制御 ] ], "Effect": "Deny", "Resource": "arn:aws:dms:us-east-1: :task:uo3yr4n47dxh3att4ymwoit" たとえば 次のコマンドは タスクの ARN を使用するポリシーが有効になっていると失敗します $ aws dms delete-replication-task --replication-task-arn "arn:aws:dms:us-east-1: :task:uo3yr4n47dxh3att4ymwoit" A client error (AccessDeniedException) occurred when calling the DeleteReplicationTask operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:deletereplicationtask on resource: arn:aws:dms:us-east-1: :task:uo3yr4n47dxh3att4ymwoit タグを使用したアクセスの制御 AWS DMS は お客様が定義するポリシーで利用できる一般的なキーと値ペアのセットを定義します それ以外のタグ付けの要件はありません AWS DMS リソースのタグ付けの詳細については AWS Database Migration Service でのリソースへのタグ付け (p. 258) を参照してください 以下のリストは AWS DMS で使用できる標準タグを示しています aws:currenttime リクエストの日時を表し 一時的な条件に基づいてアクセス制限を許可します aws:epochtime このタグは上記の aws:currenttime タグと似ていますが 現在の時刻が Unix エポッ クからの経過秒数で表されることが異なります aws:multifactorauthpresent これはリクエストが多要素認証を介して署名されたかどうかを示すブール タグです aws:multifactorauthage 多要素認証トークンの期間 (秒) へのアクセスを提供します aws:principaltype - 現在のリクエストに対するプリンシパルのタイプ (ユーザー アカウント フェデ レーティッドユーザーなど) へのアクセスを提供します aws:sourceip - リクエストを発行するユーザーのソース IP アドレスを表します aws:useragent リソースをリクエストしているクライアントアプリケーションに関する情報を提供し ます aws:userid リクエストを発行しているユーザーの ID へのアクセスを提供します aws:username リクエストを発行しているユーザーの名前へのアクセスを提供します dms:instanceclass レプリケーションインスタンスホストのコンピューティングサイズへのアクセスを 提供します dms:storagesize - ストレージボリュームサイズ (GB) へのアクセスを提供します 独自のタグを定義することもできます お客様が定義するタグは AWS Tagging サービスで保持される 単純なキー/値のペアで レプリケーションインスタンス エンドポイント タスクを含め AWS DMS リ ソースに追加できます これらのタグはポリシーの IAM 条件 ステートメントを介してマッチングさ れ 特定の条件付きタグを使用して参照されます タグキーにはプレフィックスとして dms リソー スタイプ および tag が付きます 以下にタグ形式を示します dms:resource type-tag/tag key=tag value 40

47 タグを使用したアクセスの制御 たとえば タグ stage=production を含むレプリケーションインスタンスに対してのみ API コールの成 功を許可するポリシーを定義するとします 次の条件ステートメントは 指定されたタグを持つリソース に一致します "Condition": "streq": "dms:rep-tag/stage":"production" 次のタグを このポリシー条件に一致するレプリケーションインスタンスに追加します stage production AWS DMS リソースに既に割り当てられているタグに加えて 特定のリソースに適用できるタグキーと値 を制限するポリシーを記述することもできます この場合 タグのプレフィックスは req です たとえば 次のポリシーステートメントは ユーザーが特定のリソースに割り当てることができるタグ を 許可される値の特定のリストに制限します "Condition": "streq": "dms:req-tag/stage": [ "production", "development", "testing" ] 以下のポリシー例では リソースタグに基づいて AWS DMS リソースへのアクセスを制限します 次のポリシーでは タグの値が Desktop タグキーが Env のレプリケーションインスタンスへのア クセスを制限します "Version": " ", "Statement": [ "Action": [ "dms:*" ], "Effect": "Deny", "Resource": "*", "Condition": "StringEquals": "dms:rep-tag/env": [ "Desktop" ] ] 次のコマンドは タグの値が Desktop で タグキーが Env の場合にアクセスを制限する IAM ポリ シーに基づいて 成功または失敗します 41

48 タグを使用したアクセスの制御 $ aws dms list-tags-for-resource --resource-name arn:aws:dms:us-east-1: :rep:46dhou7jojyojxwdoznfen --endpoint-url "TagList": [ "Value": "Desktop", "Key": "Env" ] $ aws dms delete-replication-instance --replication-instance-arn "arn:aws:dms:us-east-1: :rep:46dhou7jojyojxwdoznfen" A client error (AccessDeniedException) occurred when calling the DeleteReplicationInstance operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:deletereplicationinstance on resource: arn:aws:dms:useast-1: :rep:46dhou7jojyojxwdoznfen $ aws dms modify-replication-instance --replication-instance-arn "arn:aws:dms:us-east-1: :rep:46dhou7jojyojxwdoznfen" A client error (AccessDeniedException) occurred when calling the ModifyReplicationInstance operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:modifyreplicationinstance on resource: arn:aws:dms:useast-1: :rep:46dhou7jojyojxwdoznfen $ aws dms add-tags-to-resource --resource-name arn:aws:dms:us-east-1: :rep:46dhou7jojyojxwdoznfen --tags Key=CostCenter,Value=1234 A client error (AccessDeniedException) occurred when calling the AddTagsToResource operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:addtagstoresource on resource: arn:aws:dms:useast-1: :rep:46dhou7jojyojxwdoznfen $ aws dms remove-tags-from-resource --resource-name arn:aws:dms:us-east-1: :rep:46dhou7jojyojxwdoznfen --tag-keys Env A client error (AccessDeniedException) occurred when calling the RemoveTagsFromResource operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:removetagsfromresource on resource: arn:aws:dms:useast-1: :rep:46dhou7jojyojxwdoznfen 次のポリシーでは タグの値が Desktop タグキーが Env の AWS DMS エンドポイントへのアク セスを制限します "Version": " ", "Statement": [ "Action": [ "dms:*" ], "Effect": "Deny", "Resource": "*", "Condition": "StringEquals": "dms:endpoint-tag/env": [ "Desktop" 42

49 タグを使用したアクセスの制御 ] ] 次のコマンドは タグの値が Desktop で タグキーが Env の場合にアクセスを制限する IAM ポリ シーに基づいて 成功または失敗します $ aws dms list-tags-for-resource --resource-name arn:aws:dms:us-east-1: :endpoint:j2yczpngolfy52344izwa6i "TagList": [ "Value": "Desktop", "Key": "Env" ] $ aws dms delete-endpoint --endpoint-arn "arn:aws:dms:us-east-1: :endpoint:j2yczpngolfy52344izwa6i" A client error (AccessDeniedException) occurred when calling the DeleteEndpoint operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:deleteendpoint on resource: arn:aws:dms:useast-1: :endpoint:j2yczpngolfy52344izwa6i $ aws dms modify-endpoint --endpoint-arn "arn:aws:dms:us-east-1: :endpoint:j2yczpngolfy52344izwa6i" A client error (AccessDeniedException) occurred when calling the ModifyEndpoint operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:modifyendpoint on resource: arn:aws:dms:useast-1: :endpoint:j2yczpngolfy52344izwa6i $ aws dms add-tags-to-resource --resource-name arn:aws:dms:us-east-1: :endpoint:j2yczpngolfy52344izwa6i --tags Key=CostCenter,Value=1234 A client error (AccessDeniedException) occurred when calling the AddTagsToResource operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:addtagstoresource on resource: arn:aws:dms:useast-1: :endpoint:j2yczpngolfy52344izwa6i $ aws dms remove-tags-from-resource --resource-name arn:aws:dms:us-east-1: :endpoint:j2yczpngolfy52344izwa6i --tag-keys Env A client error (AccessDeniedException) occurred when calling the RemoveTagsFromResource operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:removetagsfromresource on resource: arn:aws:dms:useast-1: :endpoint:j2yczpngolfy52344izwa6i 次のポリシーでは タグの値が Desktop タグキーが Env のレプリケーションタスクへのアクセス を制限します 43

50 タグを使用したアクセスの制御 "Version": " ", "Statement": [ "Action": [ "dms:*" ], "Effect": "Deny", "Resource": "*", "Condition": "StringEquals": "dms:task-tag/env": [ "Desktop" ] ] 次のコマンドは タグの値が Desktop で タグキーが Env の場合にアクセスを制限する IAM ポリ シーに基づいて 成功または失敗します $ aws dms list-tags-for-resource --resource-name arn:aws:dms:us-east-1: :task:rb7n24j2xbups3rfabztg3 "TagList": [ "Value": "Desktop", "Key": "Env" ] $ aws dms delete-replication-task --replication-task-arn "arn:aws:dms:us-east-1: :task:rb7n24j2xbups3rfabztg3" A client error (AccessDeniedException) occurred when calling the DeleteReplicationTask operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:deletereplicationtask on resource: arn:aws:dms:useast-1: :task:rb7n24j2xbups3rfabztg3 $ aws dms add-tags-to-resource --resource-name arn:aws:dms:us-east-1: :task:rb7n24j2xbups3rfabztg3 --tags Key=CostCenter,Value=1234 A client error (AccessDeniedException) occurred when calling the AddTagsToResource operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:addtagstoresource on resource: arn:aws:dms:useast-1: :task:rb7n24j2xbups3rfabztg3 $ aws dms remove-tags-from-resource --resource-name arn:aws:dms:us-east-1: :task:rb7n24j2xbups3rfabztg3 --tag-keys Env A client error (AccessDeniedException) occurred when calling the RemoveTagsFromResource operation: User: arn:aws:iam:: :user/dmstestusr is not authorized to perform: dms:removetagsfromresource on resource: arn:aws:dms:useast-1: :task:rb7n24j2xbups3rfabztg3 44

51 暗号化キーを設定する 暗号化キーの設定と KMS のアクセス許可の指定 AWS DMS では レプリケーションインスタンスによって使用されるストレージと エンドポイントの 接続情報を暗号化します レプリケーションインスタンスにより使用されるストレージを暗号化するた め AWS DMS は AWS アカウントに固有の AWS Key Management Service (KMS) キーを使用します こ のキーは KMS で表示し 管理できます アカウント (aws/dms) でデフォルトの KMS キーを使用できま す あるいは カスタム KMS キーを作成できます 既存の KMS キーがある場合 暗号化にそのキーを使 用することもできます レプリケーションインスタンスの初回起動時に [Create Replication Instance] ページの [Advanced] セク ションで カスタム KMS マスターキーを選択していない場合は デフォルトの KMS キー (aws/dms) が作成されます デフォルトの KMS キーを使用する場合 移行用の IAM ユーザーアカウントにはアク セス許可として kms:listaliases と kms:describekey のみを付与する必要があります デフォル トの KMS キーの使用に関する詳細については AWS DMS を使用するのに必要な IAM アクセス許 可 (p. 31) を参照してください カスタム KMS キーを使用するには 次のオプションの 1 つを使用して カスタム KMS キーにアクセス許 可を割り当てます 移行に使用する IAM ユーザーアカウントを KMS カスタムキーのキー管理者/キーユーザーとして追加 します これにより 必要な KMS のアクセス許可が IAM ユーザーアカウントに付与されるように確 認できます このアクションは AWS DMS を使用するために IAMユーザーアカウントに付与する必要 がある IAMのアクセス許可に追加して実行されることに注意してください キーユーザーへのアクセ ス権限の付与の詳細については キーユーザーに CMK の使用を許可する を参照してください カスタム KMS キーに対するキー管理者/キーユーザーとして IAM ユーザーアカウントを追加したくない 場合 AWS DMS を使用するために IAM ユーザーアカウントに付与する必要がある IAM のアクセス許 可に 次のアクセス許可を追加で付与してください, "Effect": "Allow", "Action": [ "kms:listaliases", "kms:describekey", "kms:creategrant", "kms:encrypt", "kms:reencrypt*" ], "Resource": "*" AWS DMS は KMS キーのエイリアスで動作しませんが KMS キーの情報を指定する場合 KMS キーの Amazon Resource Number (ARN) を使用できます 独自の KMS キーを作成して KMS キーへのアクセス をユーザーに許可する方法の詳細については KMS 開発者ガイド を参照してください KMS キー識別子を指定しない場合 AWS DMS はデフォルトの暗号化キーを使用します KMS によっ て AWS アカウント用に AWS DMS のデフォルトの暗号化キーが作成されます AWS アカウントに は AWS のリージョンごとにデフォルトの暗号化キーがあります AWS DMS リソースの暗号化に使用される KMS キーを管理するには KMS を使用します KMS は AWS マネジメントコンソールのコンソールホームページで [Identity & Access Management] を選択 し ナビゲーションペインで [Encryption Keys] を選択することにより表示できます KMS は 安全で可 用性の高いハードウェアとソフトウェアを組み合わせて クラウド向けに拡張されたキー管理システムを 提供します KMS を使用して 暗号化キーを作成し それらのキーの使用方法を制御するポリシーを定 義できます KMS は AWS CloudTrail をサポートしているため キーの使用を監査して キーが適切に使 用されていることを検証できます KMS キーは AWS DMS およびサポートされている AWS のサービス 45

52 ネットワークセキュリティ (Amazon RDS Amazon Simple Storage Service (Amazon S3) Amazon Redshift Amazon Elastic Block Store (Amazon EBS) など) と組み合わせて使用できます KMS キーを使用して AWS DMS リソースを作成した後にリソースの暗号化キーを変更することはできま せん AWS DMS リソースを作成する場合は 必ず暗号化キー要件を調べてください AWS Database Migration Service のネットワークセ キュリティ AWS Database Migration Service を使用するときに作成するネットワークのセキュリティ要件は ネット ワークの構成方法によって異なります AWS DMS のネットワークセキュリティの一般的なルールは次の とおりです レプリケーションインスタンスは ソースとターゲットのエンドポイントにアクセスできる必要があり ます レプリケーションインスタンスのセキュリティグループには データベースポートでデータベー スエンドポイントへの送信をインスタンスに許可するネットワーク ACL またはルールが必要です データベースエンドポイントには レプリケーションインスタンスからの受信アクセスを許可するネッ トワーク ACL およびセキュリティグループルールを含める必要があります これは 構成に応じて レ プリケーションインスタンスのセキュリティグループ プライベート IP アドレス パブリック IP アド レス または NAT ゲートウェイのパブリックアドレスを使用して実現できます ネットワークで VPN トンネルが使用されている場合 NAT ゲートウェイとして機能する EC2 インスタ ンスは レプリケーションインスタンスにそのゲートウェイを通じたトラフィックの送信を許可するセ キュリティグループを使用する必要があります デフォルトでは AWS DMS レプリケーションインスタンスにより使用される VPC セキュリティグルー プに すべてのポートで /0 への送信を許可するルールがあります このセキュリティグループを 変更するか 独自のセキュリティグループを使用する場合 少なくとも 対応するデータベースポートで ソースおよびターゲットエンドポイントへの送信が許可される必要があります データベース移行に使用できるネットワーク構成には それぞれ固有のセキュリティ上の考慮事項があり ます すべてのデータベース移行コンポーネントが 1 つの VPC にある設定 (p. 66) エンドポイントで使 用されるセキュリティグループは データベースポートでレプリケーションインスタンスからの進入を 許可する必要があります レプリケーションインスタンスによって使用されるセキュリティグループで エンドポイントへの受信が許可されることを確認してください または エンドポイントにより使用さ れるセキュリティグループに レプリケーションインスタンスのプライベート IP アドレスにアクセスを 許可するセキュリティルールを作成できます 2 つの VPC がある設定 (p. 67) レプリケーションインスタンスで使用されるセキュリティグループ には VPC の範囲とデータベースの DB ポートに関するルールが必要です AWS Direct Connect または VPN を使用した VPC へのネットワークの設定 (p. 67) VPC からオン プレミス VPN へのトンネルに向かうトラフィックを許可する VPN トンネル この設定では 特定の IP アドレスまたは範囲に向かうトラフィックを VPC からオンプレミス VPN へのトラフィックをブリッ ジできるホストに送信するルーティングルールが VPC に含まれています この場合 レプリケーション インスタンスのプライベート IP アドレスまたはセキュリティグループから NAT インスタンスへのトラ フィックを許可する必要がある独自のセキュリティグループ設定が NAT ホストに含まれています インターネットを使用した VPC へのネットワークの設定 (p. 67) VPC セキュリティグループに は VPC に向かわないトラフィックをインターネットゲートウェイに送信するルーティングルールが含 まれている必要があります この設定では エンドポイントへの接続がレプリケーションインスタンス 上のパブリック IP アドレスから行われているように見えます ClassicLink を使用して VPC 内に存在しない Amazon RDS DB インスタンスを VPC 内の DB インスタ ンスに設定 (p. 68) ソースまたはターゲットの Amazon RDS DB インスタンスが VPC 内になく 46

53 SSL の使用 レプリケーションインスタンスが存在する VPC とセキュリティグループを共有していない場合 プロキ シサーバーを設定し ClassicLink を使用してソースおよびターゲットのデータベースに接続できます ソースエンドポイントがレプリケーションインスタンスで使用されている VPC の外にあり NAT の ゲートウェイを使用している 単一の Elastic Network Interface にバインドされた単一の Elastic IP ア ドレスを使用してネットワークアドレス変換 (NAT) ゲートウェイを設定し NAT 識別子 (nat-#####) を 受け取るようにできます インターネットゲートウェイではなくその NAT ゲートウェイへのデフォルト ルートが VPC に含まれている場合 レプリケーションインスタンスはインターネットゲートウェイの パブリック IP アドレスを使用してデータベースエンドポイントに接続しているように見えます この場 合 VPC 外のデータベースエンドポイントへの進入は レプリケーションインスタンスのパブリック IP アドレスではなく NAT アドレスからの進入を許可する必要があります AWS Database Migration Service で SSL を使用す る Secure Sockets Layer (SSL) を使用することで ソースおよびターゲットエンドポイントへの接続を暗号 化できます これを行うには AWS DMS マネジメントコンソールまたは AWS DMS API を使用してエ ンドポイントに証明書を割り当てます AWS DMS コンソールを使用して証明書を管理することもできま す すべてのデータベースが同じ方法で SSL を使用するわけではありません MySQL と互換性がある Amazon Aurora は SSL のエンドポイントとして サーバー名 クラスター内のプライマリインスタンス のエンドポイントを使用します Amazon Redshift エンドポイントではすでに SSL 接続が使用されている ため AWS DMS によりセットアップされた SSL 接続は必要ありません Oracle エンドポイントには追 加の手順が必要です 詳細については Oracle エンドポイントでの SSL のサポート (p. 51) を参照 してください トピック AWS Database Migration Service で SSL を使用する場合の制限 (p. 48) 証明書の管理 (p. 48) MySQL 互換 PostgreSQL または SQL Server のエンドポイントでの SSL の有効化 (p. 49) Oracle エンドポイントでの SSL のサポート (p. 51) エンドポイントに証明書を割り当てるには ルート証明書を指定するか エンドポイントにデプロイされ るサーバー SSL 証明書の署名に使用された ルートに導く (証明書バンドルとして) 中間 CA 証明書チェー ンを指定します 証明書は PEM 形式の X509 ファイルとしてのみ受け入れられます 証明書をインポー トすると エンドポイントにその証明書を指定するために使用できる Amazon リソースネーム (ARN) を受 け取ります Amazon RDS を使用している場合 Amazon RDS によって提供されたルート CA と証明書バ ンドルを でダウンロードできま す SSL 証明書認証に使用する SSL モードは 複数の中から選択できます none 接続は暗号化されていません このオプションは安全ではありませんが 必要なオーバーヘッド が小さくなります require 接続は SSL (TLS) を使用して暗号化されますが CA 検証は行われません このオプションは 安全性が高まりますが 必要なオーバーヘッドが増えます verify-ca 接続は暗号化されています このオプションは安全性が高まりますが 必要なオーバーヘッ ドが増えます このオプションでは サーバー証明書が認証されます verify-full 接続は暗号化されています このオプションは安全性が高まりますが 必要なオーバーヘッ ドが増えます このオプションでは サーバー証明書が認証され サーバーのホスト名が証明書のホス ト名属性と一致することが確認されます 47

54 AWS Database Migration Service で SSL を使用する場合の制限 すべての SSL モードがすべてのデータベースエンドポイントで機能するわけではありません 次の表は 各データベースエンジンでサポートされている SSL モードを示しています DB エンジン none require verify-ca verify-full MySQL/MariaDB/ Amazon Aurora MySQL デフォルト値 サポート外 サポート対象 サポート対象 Microsoft SQL Server デフォルト値 サポート対象 サポート外 サポート対象 PostgreSQL デフォルト値 サポート対象 サポート対象 サポート対象 Amazon Redshift デフォルト値 SSL が有効でな い SSL が有効でな い SSL が有効でな い Oracle デフォルト値 サポート外 サポート対象 サポート外 SAP ASE デフォルト値 SSL が有効でな い SSL が有効でな い サポート対象 MongoDB デフォルト値 サポート対象 サポート外 サポート対象 Db2 LUW デフォルト値 サポート外 サポート対象 サポート外 AWS Database Migration Service で SSL を使用する 場合の制限 Amazon Redshift ターゲットエンドポイントへの SSL 接続はサポートされていません AWS DMS は S3 バケットを使用してデータを Redshift データベースに転送します この転送は Amazon Redshift に よってデフォルトで暗号化されます SSL が有効な Oracle エンドポイントで CDC タスクを実行すると SQL タイムアウトが発生すること があります この問題がある場合 CDC カウンターは想定どおりの数字にならないため タスク設定の ChangeProcessingTuning セクションの MinimumTransactionSize パラメーターを 100 からより 小さい値に変更します MinimumTransactionSize パラメーターの詳細については 変更処理の チューニング設定 (p. 212) を参照してください 証明書は.PEM および.SSO (Oracle ウォレット) 形式でのみインポートできます サーバー SSL 証明書が中間 CA によって署名されている場合 中間 CA からルート CA に向かう証明書 チェーン全体が単一の.PEM ファイルとしてインポートされることを確認してください サーバーで自己署名証明書を使用している場合 SSL モードとして [require] を選択します require SSL モードは サーバーの SSL 証明書を暗黙的に信頼し 証明書が CA により署名されたことの検証を 試みません 証明書の管理 DMS コンソールを使用すると SSL 証明書を表示および管理できます DMS コンソールを使用して証明 書をインポートすることもできます 48

55 MySQL 互換 PostgreSQL または SQL Server のエンドポイントでの SSL の有効化 MySQL 互換 PostgreSQL または SQL Server のエ ンドポイントでの SSL の有効化 新しく作成したエンドポイントまたは既存のエンドポイントに SSL 接続を追加できます SSL を使用する AWS DMS エンドポイントを作成するには 1. AWS マネジメントコンソールにサインインし [AWS Database Migration Service] を選択します Note AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合 AWS DMS にアクセスするには適切なアクセス許可が必要です データベース移行に必要な アクセス許可の詳細については AWS DMS を使用するのに必要な IAM アクセス許 可 (p. 31) を参照してください ナビゲーションペインで [Certificates] を選択します [Import Certificate] を選択します 4. エンドポイントへの接続の暗号化に使用する証明書をアップロードします Note 5. エンドポイントを作成または変更するときに [Create database endpoint (データベースエン ドポイントの作成)] ページで [Add new CA certificate (新しい CA 証明書の追加)] を選択する ことにより AWS DMS コンソールを使用して証明書をアップロードすることもできます ステップ 3: ソースとターゲットのエンドポイントを指定する (p. 22) での説明に従って エンドポ イントを作成します SSL を使用するように既存の AWS DMS エンドポイントを変更するには: 1. AWS マネジメントコンソールにサインインし [AWS Database Migration Service] を選択します Note AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合 AWS DMS にアクセスするには適切なアクセス許可が必要です データベース移行に必要な 49

56 MySQL 互換 PostgreSQL または SQL Server のエンドポイントでの SSL の有効化 アクセス許可の詳細については AWS DMS を使用するのに必要な IAM アクセス許 可 (p. 31) を参照してください 2. ナビゲーションペインで [Certificates] を選択します 3. [Import Certificate] を選択します 4. エンドポイントへの接続の暗号化に使用する証明書をアップロードします Note エンドポイントを作成または変更するときに [Create database endpoint (データベースエン ドポイントの作成)] ページで [Add new CA certificate (新しい CA 証明書の追加)] を選択する ことにより AWS DMS コンソールを使用して証明書をアップロードすることもできます 5. ナビゲーションペインで [Endpoints] を選択し 変更するエンドポイントを選択して [Modify] を選択 します 6. [SSL mode] を選択します [verify-ca] モードまたは [verify-full] モードを選択した場合 次に示すように使用する CA 証明書を指 定する必要があります 7. [Modify] を選択します 8. エンドポイントが変更されている場合 エンドポイントを選択して [Test connection] を選択し SSL 接続が機能しているかどうかを調べます ソースおよびターゲットエンドポイントを作成したら これらのエンドポイントを使用するタスクを作成 します タスクの作成の詳細については ステップ 4: タスクを作成する (p. 25) を参照してください 50

57 Oracle エンドポイントでの SSL のサポート Oracle エンドポイントでの SSL のサポート AWS DMS の Oracle エンドポイントでは none と verify-ca の SSL モードがサポートされていま す Oracle エンドポイントで SSL を使用するには.pem 証明書ファイルの代わりにエンドポイント用の Oracle ウォレットをアップロードする必要があります トピック Oracle SSL への既存の証明書の使用 (p. 51) Oracle SSL への自己署名証明書の使用 (p. 52) Oracle SSL への既存の証明書の使用 既存の Oracle クライアントインストールを使用して CA 証明書ファイルから Oracle ウォレットファイル を作成するには 以下の手順を実行します AWS DMS で Oracle SSL に既存の Oracle クライアントインストールを使用するには 1. 以下のコマンドを実行して ORACLE_HOME システム変数を dbhome_1 ディレクトリの場所に設定 します prompt>export ORACLE_HOME=/home/user/app/user/product/12.1.0/dbhome_1 2. LD_LIBRARY_PATH システム変数に $ORACLE_HOME/lib を追加します prompt>export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib 3. $ORACLE_HOME/ssl_wallet に Oracle Wallet 用のディレクトリを作成します prompt>mkdir $ORACLE_HOME/ssl_wallet 4. CA 証明書.pem ファイルを ssl_wallet ディレクトリに配置します Amazon RDS のお客様は から RDS CA 証明書ファイルをダウ ンロードできます 5. 以下のコマンドを実行して Oracle Wallet を作成します prompt>orapki wallet create -wallet $ORACLE_HOME/ssl_wallet -auto_login_only prompt>orapki wallet add -wallet $ORACLE_HOME/ssl_wallet -trusted_cert cert $ORACLE_HOME/ssl_wallet/ca-cert.pem -auto_login_only ここまでの手順を完了したら ImportCertificate API で certificate-wallet パラメーターを指定してウォ レットファイルをインポートできます Oracle エンドポイントの作成または変更時に SSL モードとして verify-ca を選択すると インポートされたウォレット証明書を使用できます 51

58 Oracle エンドポイントでの SSL のサポート Note Oracle ウォレットはバイナリファイルです AWS DMS ではこれらのファイルがそのまま使用さ れます Oracle SSL への自己署名証明書の使用 Oracle SSL に自己署名証明書を使用するには 以下の手順を実行します AWS DMS で Oracle SSL に自己署名証明書を使用するには 1. 自己署名証明書で使用するディレクトリを作成します mkdir <SELF_SIGNED_CERT_DIRECTORY> 2. 前の手順で作成したディレクトリに移動します cd <SELF_SIGNED_CERT_DIRECTORY> 3. ルートキーを作成します openssl genrsa -out self-rootca.key 前の手順で作成したルートキーを使用して ルート証明書に自己署名します openssl req -x509 -new -nodes -key self-rootca.key -sha256 -days out self-rootca.pem 5. Oracle データベース用の Oracle ウォレットディレクトリを作成します mkdir $ORACLE_HOME/self_signed_ssl_wallet 6. 新しい Oracle ウォレットを作成します orapki wallet create -wallet $ORACLE_HOME/self_signed_ssl_wallet -pwd <password> -auto_login_local 7. Oracle ウォレットにルート証明書を追加します orapki wallet add -wallet $ORACLE_HOME/self_signed_ssl_wallet -trusted_cert -cert self-rootca.pem -pwd <password> 8. Oracle ウォレットの内容のリストを表示します リストにはルート証明書が含まれます orapki wallet display -wallet $ORACLE_HOME/self_signed_ssl_wallet 9. ORAPKI ユーティリティを使用して証明書署名リクエスト (CSR) を生成します orapki wallet add -wallet $ORACLE_HOME/self_signed_ssl_wallet -dn "CN=dms" -keysize sign_alg sha256 -pwd <password> 10. 次のコマンドを実行します openssl pkcs12 -in ewallet.p12 -nodes -out nonoracle_wallet.pem 11. 共通名として dms を指定します 52

59 Oracle エンドポイントでの SSL のサポート openssl req -new -key nonoracle_wallet.pem -out certrequest.csr 12. 証明書の署名を取得します openssl req -noout -text -in self-signed-oracle.csr grep -i signature 13. ステップ 12 が sha256withrsaencryption の場合は 以下のコードを実行します openssl x509 -req -in self-signed-oracle.csr -CA self-rootca.pem -CAkey self-rootca.key -CAcreateserial -out self-signed-oracle.crt -days 365 -sha ステップ 12 が md5withrsaencryption の場合は 以下のコードを実行します openssl x509 -req -in certrequest.csr -CA self-rootca.pem -CAkey self-rootca.key -CAcreateserial -out certrequest.crt -days 365 -sha 証明書をウォレットに追加します orapki wallet add -wallet $ORACLE_HOME/self_signed_ssl_wallet -user_cert -cert certrequest.crt -pwd <password> 16. sqlnet.ora ファイル ($ORACLE_HOME/network/admin/sqlnet.ora) を設定します WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = <ORACLE_HOME>/self_signed_ssl_wallet) ) ) SQLNET.AUTHENTICATION_SERVICES = (NONE) SSL_VERSION = 1.0 SSL_CLIENT_AUTHENTICATION = FALSE SSL_CIPHER_SUITES = (SSL_RSA_WITH_AES_256_CBC_SHA) 17. Oracle リスナーを停止します lsnrctl stop 18. listener.ora ファイル ($ORACLE_HOME/network/admin/listener.ora) に SSL のエントリを追加しま す SSL_CLIENT_AUTHENTICATION = FALSE WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = <ORACLE_HOME>/self_signed_ssl_wallet) ) ) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = <SID>) (ORACLE_HOME = <ORACLE_HOME>) 53

60 Oracle エンドポイントでの SSL のサポート (SID_NAME = <SID>) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(port = 1521)) (ADDRESS = (PROTOCOL = TCPS)(HOST = localhost.localdomain)(port = 1522)) (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) ) ) 19. tnsnames.ora ファイル ($ORACLE_HOME/network/admin/tnsnames.ora) を設定します <SID>= (DESCRIPTION= (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP)(HOST = localhost.localdomain)(port = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <SID>) ) ) <SID>_ssl= (DESCRIPTION= (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCPS)(HOST = localhost.localdomain)(port = 1522)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <SID>) ) ) 20. Oracle リスナーを再起動します lsnrctl start 21. Oracle リスナーの状態を表示します lsnrctl status 22. sqlplus と SSL tnsnames エントリを使用して localhost からデータベースへの SSL 接続をテストし ます sqlplus -L <ORACLE_USER>@<SID>_ssl 23. SSL を使用して正常に接続したことを確認します SELECT SYS_CONTEXT('USERENV', 'network_protocol') FROM DUAL; SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') tcps 24. 現在のディレクトリを自己署名証明書のあるディレクトリに変更します cd <SELF_SIGNED_CERT_DIRECTORY> 54

61 データベースのパスワードの変更 25. AWS DMS で使用される新しいクライアント Oracle ウォレットを作成します orapki wallet create -wallet./ -auto_login_only 26. Oracle ウォレットに自己署名証明書を追加します orapki wallet add -wallet./ -trusted_cert -cert rootca.pem -auto_login_only 27. AWS DMS で使用される Oracle ウォレットの内容のリストを表示します リストには自己署名証明書 が含まれます orapki wallet display -wallet./ 28. 作成した Oracle ウォレットを AWS DMS にアップロードします データベースのパスワードの変更 ほとんどの状況では ソースまたはターゲットエンドポイント用のデータベースのパスワードを変更する のは簡単です 移行またはレプリケーションタスクで現在使用しているエンドポイント用のデータベース のパスワードを変更する必要がある場合 そのプロセスは少し複雑になります 以下の手順は その方法 を示しています 移行またはレプリケーションタスクでエンドポイント用のデータベースのパスワードを変更する には 1. AWS マネジメントコンソールにサインインし [AWS DMS] を選択します AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合 AWS DMS にアクセスするには適切な アクセス許可が必要です 必要なアクセス権限の詳細については AWS DMS を使用するのに必要 な IAM アクセス許可 (p. 31) を参照してください ナビゲーションペインで [Tasks] を選択します データベースのパスワードを変更するエンドポイントを使用するタスクを選択してから [Stop] を選 択します タスクが停止されている間 データベースの操作に使用するネイティブツールを使用して エンドポ イント用のデータベースのパスワードを変更できます DMS マネジメントコンソールに戻り ナビゲーションペインから [Endpoints] を選択します パスワードを変更したデータベースのエンドポイントを選択してから [Modify] を選択します [Password] ボックスに新しいパスワードを入力し [Modify] を選択します ナビゲーションペインから [Tasks] を選択します 9. 先ほど停止したタスクを選択してから [Start/Resume] を選択します 10. タスクを続行する方法に応じて [Start] または [Resume] のいずれかを選択してから [Start task] を 選択します 55

62 AWS Database Migration Service の制限 AWS Database Migration Service の 制限 以下で AWS Database Migration Service (AWS DMS) でのリソース制限と命名に関する制約について説 明します AWS DMS が移行できるデータベースの最大サイズは ソース環境 ソースデータベースのデータのディ ストリビューション ソースシステムの使用頻度によって異なります ご利用のシステムが AWS DMS の候補となるかどうかを調べる最善の方法は テストすることです 設定を実行するため徐々に開始しま す 次にいくらか複雑なオブジェクトを追加し 最後にテストとしてフルロードをお試しください AWS Database Migration Service の制限 各 AWS アカウントでは リージョンごとに 作成できる AWS DMS リソースの数に対して制限がありま す リソースの制限に達すると リソースを作成するための追加の呼び出しは 例外が発生して失敗しま す ストレージの 6 TB の制限は DMS レプリケーションインスタンスに適用されます ターゲットとソース の同期が間に合わない場合に変更をキャッシュするためや ログ情報を保存するために このストレージ は使用されます この制限はターゲットサイズには適用されないため ターゲットエンドポイントは 6 TB よりも大きくなることがあります 次の表に AWS DMS リソースとリージョンごとの制限を示します リソース デフォルトの制限 レプリケーションインスタンス 20 ストレージの合計容量 6 TB イベントサブスクリプション 20 レプリケーションサブネットグループ 20 レプリケーションサブネットグループあたりのサブネット 20 エンドポイント 100 タスク 200 インスタンスごとのエンドポイント 20 56

63 AWS DMS レプリケーションインス タンスを使用する AWS DMS レプリケーションインスタンスを作成すると AWS DMS では Amazon Virtual Private Cloud (Amazon VPC) サービスに基づいて VPC の Amazon Elastic Compute Cloud (Amazon EC2) インスタン スにレプリケーションインスタンスが作成されます このレプリケーションインスタンスを使用して データベース移行を実行します [Multi-AZ] オプションを選択した場合 レプリケーションインスタンスは マルチ AZ 配置を使用して高可用性およびフェイルオーバーサポートを提供します マルチ AZ 配置では AWS DMS によって異なるアベイラビリティーゾーンにレプリケーションインスタ ンスの同期スタンバイレプリカが自動的にプロビジョニングされて維持されます プライマリレプリケー ションインスタンスは 同期的にアベイラビリティーゾーン間でスタンバイレプリカにレプリケートさ れます このアプローチでは データの冗長性が確保されて I/O のフリーズは排除されるため レイテン シーのスパイクは最小限に抑えられます AWS DMS はレプリケーションインスタンスを使用してソースデータストアに接続し ソースデータを読 み取り ターゲットデータストアが使用できるようにデータをフォーマットします レプリケーションイ ンスタンスもターゲットデータストアにデータをロードします この処理のほとんどはメモリ内で行われ ます ただし 大きいトランザクションではディスクでのバッファリングが必要になることがあります キャッシュされたトランザクションとログファイルもディスクに書き込まれます AWS DMS レプリケーションインスタンスは 次の AWS リージョンで作成できます サービス対象 名前 アジアパシフィック (東京) リージョン ap-northeast-1 アジアパシフィック (ソウル) リージョン ap-northeast-2 アジアパシフィック (ムンバイ) リージョン ap-south-1 アジアパシフィック (シンガポール) リージョン ap-southeast-1 アジアパシフィック (シドニー) リージョン ap-southeast-2 カナダ (中部) リージョン ca-central-1 欧州 (フランクフルト) リージョン eu-central-1 欧州 (アイルランド) リージョン eu-west-1 欧州 (ロンドン) リージョン eu-west-2 南米 (サンパウロ) リージョン sa-east-1 57

64 レプリケーションインスタンスの詳細 サービス対象 名前 米国東部 (バージニア北部) リージョン us-east-1 米国東部 (オハイオ) リージョン us-east-2 米国西部 (北カリフォルニア) リージョン us-west-1 米国西部 (オレゴン) リージョン us-west-2 AWS DMS では AWS GovCloud (米国) という特殊な AWS リージョンがサポートされています この リージョンは 米国政府機関および関係者のために より機密性の高いワークロードをクラウドに移行す ることを目的に設けられています AWS GovCloud (米国) は 米国政府の特定の規制とコンプライアンス の要件に対応しています AWS GovCloud (米国) の詳細については AWS GovCloud (米国) とは を参 照してください 以下で レプリケーションインスタンスの詳細について参照してください トピック 移行に適した AWS DMS レプリケーションインスタンスを選択する (p. 58) パブリックおよびプライベートレプリケーションインスタンス (p. 60) AWS DMS メンテナンス (p. 60) レプリケーションエンジンバージョンの操作 (p. 63) レプリケーションインスタンスのためのネットワークのセットアップ (p. 65) レプリケーションインスタンスのための暗号化キーの設定 (p. 73) レプリケーションインスタンスの作成 (p. 73) レプリケーションインスタンスの変更 (p. 77) レプリケーションインスタンスを再起動する (p. 80) レプリケーションインスタンスの削除 (p. 81) AWS DMS によりサポートされている DDL ステートメント (p. 83) 移行に適した AWS DMS レプリケーションインス タンスを選択する AWS DMS では Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでレプリケーションイン スタンスが作成されます 現在 AWS DMS ではレプリケーションインスタンス向けに T2 C4 R4 の Amazon EC2 インスタンスクラスがサポートされています T2 インスタンスは ベースラインレベルの CPU パフォーマンスを提供しながら そのベースライン レベルを超えてバーストする機能を備えるように設計された 低コストのスタンダードインスタンス です これらのインスタンスは データベース移行プロセスの開発 設定 およびテストに適していま す また CPU のバースト能力を利用できる定期的データ移行タスクにも適しています この C4 インスタンスクラスは 大量の演算を行うワークロードで最高レベルのプロセッサパフォーマ ンスを実現するように設計されています パケット毎秒 (PPS) が非常に大きく ネットワークのストレ スが少なく ネットワークレイテンシーが低くなります AWS DMS は 特に異機種間 (例: Oracle から PostgreSQL) で移行やレプリケーションを実行する場合に CPU に対する負荷が大きくなる場合があり ます C4 インスタンスは このような状況に適しています R4 インスタンスクラスは メモリ負荷の大きいワークロード用に最適化されたメモリです DMS を使 用する高スループットトランザクションシステムの継続的な移行やレプリケーションが原因で 大量の CPU やメモリを消費することがあります R4 インスタンスは vcpu 別のメモリが含まれます 58

65 レプリケーションインスタンスの詳細 レプリケーションインスタンスごとに メモリと vcpu の固有の設定があります 次の表は 各レプリ ケーションインスタンスタイプの設定を示しています 価格については AWS Database Migration サービ スの料金表ページを参照してください レプリケーションインスタンスタイプ vcpu メモリ (GB) dms.t2.micro 1 1 dms.t2.small 1 2 dms.t2.medium 2 4 dms.t2.large 2 8 dms.c4.large dms.c4.xlarge dms.c4.2xlarge 8 15 dms.c4.4xlarge dms.r4.large dms.r4.xlarge dms.r4.2xlarge 8 61 dms.r4.4xlarge dms.r4.8xlarge 汎用 コンピューティング最適化 メモリを最適化 移行に最適なレプリケーションインスタンスクラスを判断しやすいように AWS DMS レプリケーション インスタンスで使用する変更データキャプチャ (CDC) プロセスを見ていきましょう 全ロード + CDC タスク (一括ロードと継続的なレプリケーション) を実行していると想定します この場 合 タスクにはメタデータやその他の情報を格納する独自の SQLite リポジトリがあります AWS DMS で全ロードを開始する前に 次のステップを実行します AWS DMS は ソースエンジンのトランザクションログから移行するテーブルの変更 (キャッシュされ た変更と呼ばれる) のキャプチャを開始します 全ロードが完了すると これらのキャッシュされた変 更が収集され ターゲットに適用されます キャッシュされた変更のボリュームに応じて これらの変 更は メモリから直接適用できます ここで これらの変更から設定しきい値まで収集されます また は ディスクから適用して 変更がメモリに保持できないときに書き込まれるようにすることもできま す キャッシュされた変更が適用されると AWS DMS はデフォルトでターゲットインスタンスに対してト ランザクション適用を開始します 適用済みのキャッシュされた変更フェーズと継続的なレプリケーションフェーズで AWS DMS は 受信 データと送信データ用に 2 つのストリームバッファを使用します AWS DMS はソーターと呼ばれる重要 なコンポーネントも使用します これは 別のメモリバッファです ソーターコンポーネントの 2 つの重 要な用途 (他のコンポーネントを含む) は次のとおりです 59

66 パブリックおよびプライベート レプリケーションインスタンス すべてのトランザクションを追跡し 関連するトランザクションのみを送信バッファに転送します これにより トランザクションはソース上と同じコミットの順番で転送されます 見てわかるように このアーキテクチャには AWS DMS の CDC 用の 3 つの重要なメモリバッファがあ ります これらのバッファのいずれでメモリ負荷が生じた場合 移行でパフォーマンス上の問題が発生 し 障害が起きる可能性があります 1 秒あたりのトランザクション数 (TPS) が多い高負荷のワークロードをこのアーキテクチャに接続する と R4 インスタンスの追加メモリが役立つことがわかります R4 インスタンスを使用すると 多数のト ランザクションをメモリに保持し 継続的なレプリケーション中のメモリプレッシャーの問題を回避でき ます パブリックおよびプライベートレプリケーションイ ンスタンス レプリケーションのインスタンスに インスタンスがソースデータベースとターゲットデータベースへの 接続に使用するパブリックまたはプライベート IP アドレスがあるかどうかを指定できます プライベートレプリケーションインスタンスには レプリケーションネットワーク外からアクセスでき ないるプライベート IP アドレスがあります ソースとターゲットのデータベースの両方が VPN AWS Direct Connect VPC ピア接続を使用してレプリケーションインスタンスの VPC に接続されている同じ ネットワーク内にある場合 レプリケーションインスタンスにはプライベート IP アドレスが必要です VPC ピア接続は 同じネットワーク内にあるかのように各 VPC のプライベート IP アドレスを使用して ルーティングできるようにする 2 つの VPC 間のネットワーキング接続です VPC のピア接続の詳細に ついては Amazon VPC ユーザーガイド の VPC ピア接続 を参照してください AWS DMS メンテナンス AWS DMS では AWS DMS リソースのメンテナンスを定期的に実行します 通常 メンテナンスにはレ プリケーションインスタンスやレプリケーションインスタンスのオペレーティングシステム (OS) の更新 が伴います AWS CLI または AWS DMS API を使用して メンテナンスウィンドウを管理し メンテナン スの更新を確認できます AWS DMS コンソールでは 現在この作業はサポートされていません メンテナンス項目の適用時には AWS DMS でご使用のレプリケーションインスタンスを少しの間オフラ インにする必要があります リソースのオフラインを必要とするメンテナンスには 特定のオペレーティ ングシステムやインスタンスのパッチが含まれます セキュリティやインスタンスの信頼性に関連する パッチのみ 必須のパッチ適用として自動的にスケジューリングされます このようなパッチは頻繁に発 生するものではありません (通常 1 年に 1 2 回) また メンテナンスウィンドウのごく一部以上が必要 になることは 非常に稀な場合に限られます [Auto minor version upgrade] コンソールオプションを選択 して マイナーバージョンの更新が自動的に適用されるようにします AWS DMS メンテナンスウィンドウ すべての AWS DMS レプリケーションインスタンスには週次のメンテナンスウィンドウが用意されてお り その期間内に 利用可能なシステムの変更が適用されます メンテナンスウィンドウは 変更やソフ トウェアのパッチなどが実行されるタイミングをコントロールする機会と考えることができます 特定の週の間にメンテナンスが必要であると AWS DMS が判断する場合 メンテナンスは レプリケー ションインスタンスの作成時に選択した 30 分のメンテナンス時間中に行われます AWS DMS は 30 分 60

67 AWS DMS メンテナンスウィンドウ のメンテナンス時間中にほとんどのメンテナンスを完了します ただし 大規模な変更の場合より長い時 間がかかる場合があります レプリケーションインスタンスを作成したときに選択した 30 分のメンテナンスウィンドウは AWS リー ジョンごとに割り当てられた 8 時間の中で選択されます レプリケーションインスタンスの作成時に希望 のメンテナンスウィンドウを指定しない場合 AWS DMS では ランダムに選択した曜日にメンテナンス ウィンドウを割り当てます マルチ AZ 配置を使用するレプリケーションインスタンスの場合 メンテナ ンスを完了するにはフェイルオーバーが必要になる場合があります AWS DMS をサポートしている各 AWS リージョンのメンテナンスウィンドウの一覧を次の表に示しま す サービス対象 時間ブロック アジアパシフィック (シド ニー) リージョン 12:00 20:00 UTC アジアパシフィック (東京) リージョン 13:00 21:00 UTC アジアパシフィック (ムンバ イ) リージョン 17:30 01:30 UTC アジアパシフィック (ソウル) リージョン 13:00 21:00 UTC アジアパシフィック (シンガ ポール) リージョン 14:00 22:00 UTC カナダ (中部) リージョン 06:29 14:29 UTC 欧州 (フランクフルト) リー ジョン 23:00 07:00 UTC 欧州 (アイルランド) リージョ ン 22:00 06:00 UTC 欧州 (ロンドン) リージョン 06:00 14:00 UTC 南米 (サンパウロ) リージョン 00:00 08:00 UTC 米国東部 (バージニア北部) リージョン 03:00 11:00 UTC 米国東部 (オハイオ) リージョ ン 03:00 11:00 UTC 米国西部 (北カリフォルニア) リージョン 06:00 14:00 UTC 米国西部 (オレゴン) リージョ ン 06:00 14:00 UTC AWS GovCloud (米国) 06:00 14:00 UTC 既存の移行タスクにおけるメンテナンスの効果 インスタンスで AWS DMS 移行タスクが実行されている場合 パッチが適用されると次のイベントが発生 します 61

68 AWS DMS メンテナンスウィンドウ 移行タスクのテーブルで継続的な変更フェーズ (CDC) のレプリケートを実行している場合 AWS DMS は パッチが適用されている間 タスクを一時停止します その後 パッチが適用されると 移行は中 断されたところから再開します パッチの適用時に AWS DMS がテーブルを移行中の場合 AWS DMS はテーブルの移行を再開します メンテナンスウィンドウ設定の変更 AWS マネジメントコンソール AWS CLI または AWS DMS API を使用して メンテナンスウィンドウ の時間を変更できます AWS コンソールを使用したメンテナンスウィンドウ設定の変更 メンテナンスウィンドウの時間枠は AWS マネジメントコンソール を使用して変更できます AWS コンソールを使用して優先メンテナンスウィンドウを変更するには 1. AWS マネジメントコンソール にサインインして AWS DMS を選択します 2. ナビゲーションペインで [Replication instances] を選択します 3. 変更するレプリケーションインスタンスを選択してから [Modify] を選択します 4. [Maintenance] セクションを展開し メンテナンスウィンドウの日時を選択します 5. [Apply changes immediately] を選択します 6. [Modify] を選択します CLI を使用したメンテナンスウィンドウ設定の変更 必要なメンテナンスウィンドウを調整するには 以下のパラメータを指定して AWS CLI modifyreplication-instance コマンドを使用します --replication-instance-identifier --preferred-maintenance-window Example 次の AWS CLI の例では メンテナンスウィンドウを火曜日の午前 4:00 4:30 UTC に設定します aws dms modify-replication-instance \ --replication-instance-identifier myrepinstance \ --preferred-maintenance-window Tue:04:00-Tue:04:30 62

69 レプリケーションエンジンのバージョン API を使用したメンテナンスウィンドウ設定の変更 必要なメンテナンスウィンドウを調整するには 以下のパラメータを指定して AWS DMS API の ModifyReplicationInstance アクションを使用します ReplicationInstanceIdentifier = myrepinstance PreferredMaintenanceWindow = Tue:04:00-Tue:04:30 Example 次のコード例では メンテナンスウィンドウを火曜日の午前 4:00 4:30 UTC に設定します &DBInstanceIdentifier=myrepinstance &PreferredMaintenanceWindow=Tue:04:00-Tue:04:30 &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version= &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/ /us-east-1/dms/aws4_request &X-Amz-Date= T192732Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3 レプリケーションエンジンバージョンの操作 レプリケーションエンジンは レプリケーションインスタンス上で実行され 指定する移行タスクを実行 する AWS DMS コアソフトウェアです AWS では 新機能とパフォーマンスの強化を含め 新しいバー ジョンの AWS DMS レプリケーションエンジンソフトウェアを定期的にリリースしています レプリケー ションエンジンソフトウェアの各バージョンには 他のバージョンと区別するための独自のバージョン番 号があります 新しいレプリケーションインスタンスを作成する際 特に指定がない場合は 最新の AWS DMS エンジ ンバージョンが実行されます 詳細については AWS DMS レプリケーションインスタンスを使用す る (p. 57) を参照してください 現在実行しているレプリケーションインスタンスがある場合は 最新のエンジンバージョンにアップグ レードできます (AWS DMS ではエンジンバージョンのダウングレードはサポートされていません) レプ リケーションエンジンバージョンのリストを含む詳細については 次のセクションを参照してください レプリケーションインスタンスバージョンの廃止 時折 AWS DMS によってレプリケーションインスタンスの以前のバージョンが廃止されることがありま す 2018 年 4 月 2 日以降 AWS DMS では新しいレプリケーションインスタンスのバージョン の作 成が無効になります このバージョンは 2016 年 3 月 15 日に AWS DMS で最初にサポートされて以降 機能 セキュリティ 信頼性が強化された後続のバージョンに置き換えられてきました 2018 年 8 月 5 日の 0:00 (UTC) 以降 バージョン で実行されるすべての DMS レプリケーションイ ンスタンスは 各インスタンスに指定されたメンテナンスウィンドウ中に使用可能な最新バージョンに自 動アップグレードされるようにスケジュールされます それより前のご都合のよいときにインスタンスを アップグレードすることをお勧めします レプリケーションインスタンスのアップグレードを開始するには レプリケーションインスタンスのエ ンジンバージョンのアップグレード (p. 64) の手順を使用します 63

70 レプリケーションインスタンスのエ ンジンバージョンのアップグレード レプリケーションインスタンスのアップグレードを選択したときに実行されている移行タスクについて は アップグレードが完了すると アップグレード時の全ロードフェーズのテーブルが最初から再ロード されます 他のすべてのテーブルのレプリケーションは アップグレードが完了すると中断することなく 再開されます バージョン からインスタンスをアップグレードする場合は AWS DMS レプリケー ションインスタンスの使用可能な最新バージョンで現在の移行タスクをすべてテストすることをお勧めし ます レプリケーションインスタンスのエンジンバージョン のアップグレード AWS では 新機能とパフォーマンスの強化を含め 定期的に新しいバージョンの AWS DMS レプリケー ションエンジンソフトウェアをリリースしています 利用可能な AWS DMS エンジンバージョンの概要を 以下に示します バージョン 概要 2.4.x Oracle インデックステーブルスペースのレプリケーションのサポート S3 エンドポイントを使用したクロスアカウントアクセスをサポートするため の既定アクセス ACL のサポート 2.3.x AWS DMS ソースとしての S3 のサポート AWS DMS ソースのみとしての Oracle のテーブルスペースのレプリケーショ ンのサポート Oracle のソース AWS DMS ソースのみとしての Oracle アクティブデータ ガードスタンバイのサポート 2.2.x AWS DMS ソースまたは AWS DMS ターゲットとしての Microsoft SQL Server 2016 のサポート AWS DMS ソースまたは AWS DMS ターゲットとしての SAP ASE 16 のサ ポート AWS DMS ソースのみとしての Microsoft Azure で実行されている Microsoft SQL Server のサポート 既存のデータの完全移行を実行できます ただし 変更データキャプチャ (CDC) は使用できません 1.9.x AWS DMS レプリケーションエンジンソフトウェアの累積リリース コンソールを使用したエンジンバージョンのアップグレード AWS マネジメントコンソール を使用して AWS DMS レプリケーションインスタンスをアップグレードで きます コンソールを使用してレプリケーションインスタンスをアップグレードするには にある AWS DMS コンソールを開きます ナビゲーションペインで [Replication instances] を選択します レプリケーションエンジンを選択し [Modify] を選択します [Replication engine version] でバージョン番号を選択し [Modify] を選択します Note レプリケーションインスタンスタイプのアップグレードには数分間かかります インスタンスが 使用可能になると ステータスは available に変わります 64

71 レプリケーションインスタンスの ためのネットワークのセットアップ CLI を使用したエンジンバージョンのアップグレード 次のように AWS CLI を使用して AWS DMS レプリケーションインスタンスをアップグレードできます AWS CLI を使用してレプリケーションインスタンスをアップグレードするには 1. 次のコマンドを使用して レプリケーションインスタンスの Amazon リソースネーム (ARN) を確認し ます aws dms describe-replication-instances \ --query "ReplicationInstances[*]. [ReplicationInstanceIdentifier,ReplicationInstanceArn,ReplicationInstanceClass]" 2. 出力で アップグレードするレプリケーションインスタンスの ARN を書き留めます たとえ ば arn:aws:dms:us-east-1: :rep:6efqqo6u6edprcpklnpl2sceey などで す 次のコマンドを使用して 使用可能なレプリケーションインスタンスバージョンを調べます aws dms describe-orderable-replication-instances \ --query "OrderableReplicationInstances[*].[ReplicationInstanceClass,EngineVersion]" 3. 出力で レプリケーションインスタンスクラスに使用できるエンジンバージョン番号を書き留めま す この情報はステップ 1 の出力に表示されます 次のコマンドを使ってレプリケーションインスタンスをアップグレードします aws dms modify-replication-instance \ --replication-instance-arn arn \ --engine-version n.n.n 前述の arn を 前のステップで書き留めた実際のレプリケーションインスタンス ARN に置き換えま す n.n.n を 目的のエンジンバージョン番号に置き換えます たとえば などです Note レプリケーションインスタンスタイプのアップグレードには数分間かかります 次のコマンドを 使用して レプリケーションインスタンスのステータスを表示できます aws dms describe-replication-instances \ --query "ReplicationInstances[*]. [ReplicationInstanceIdentifier,ReplicationInstanceStatus]" レプリケーションインスタンスが使用可能になると ステータスは available に変わります レプリケーションインスタンスのためのネットワー クのセットアップ AWS DMS は 常に Amazon Virtual Private Cloud (Amazon VPC) に基づいて VPC にレプリケーションイ ンスタンスを作成します レプリケーションインスタンスがある VPC を指定します アカウントと AWS リージョンにデフォルトの VPC を使用するか 新しい VPC を作成することができます VPC では 少な くとも 1 つのアベイラビリティーゾーンにある 2 つのサブネットが必要です 65

72 データベース移行のネットワーク設定 VPC でレプリケーションインスタンスに割り当てられた Elastic Network Interface (ENI) は VPC からの 退出 (送信) をすべてのポートですべてのトラフィックに許可するルールを持つセキュリティグループに関 連付けられている必要があります このアプローチでは ソースおよびターゲットデータベースエンドポ イントで適切な送信ルールが有効になっている限り レプリケーションインスタンスからそれらのエンド ポイントへの通信が許可されます すべてのアドレスへの送信をすべてのポートで許可するデフォルト設 定をエンドポイントに使用することをお勧めします ソースおよびターゲットエンドポイントは VPC に接続するか VPC 内に配置されることにより VPC 内にあるレプリケーションインスタンスにアクセスします データベースエンドポイントには レプリ ケーションインスタンスからの受信アクセスを許可するネットワークアクセスコントロールリスト (ACL) およびセキュリティグループルール (該当する場合) を含める必要があります 使用しているネットワーク 設定に応じて レプリケーションインスタンスの VPC セキュリティグループ レプリケーションインス タンスのプライベートまたはパブリック IP アドレス あるいは NAT ゲートウェイのパブリック IP アドレ スを使用することができます これらの接続によって データ移行に使用するネットワークが形成されま す データベース移行のネットワーク設定 AWS Database Migration Service では さまざまなネットワーク設定を使用できます データベース移行 に使用されるネットワークの一般的な設定を以下に示します トピック すべてのデータベース移行コンポーネントが 1 つの VPC にある設定 (p. 66) 2 つの VPC がある設定 (p. 67) AWS Direct Connect または VPN を使用した VPC へのネットワークの設定 (p. 67) インターネットを使用した VPC へのネットワークの設定 (p. 67) ClassicLink を使用して VPC 内に存在しない Amazon RDS DB インスタンスを VPC 内の DB インスタ ンスに設定 (p. 68) すべてのデータベース移行コンポーネントが 1 つの VPC にある 設定 ソースエンドポイント レプリケーションインスタンス ターゲットエンドポイントがすべて同じ VPC に ある場合 データベース移行のネットワークが最もシンプルになります この設定は ソースとターゲッ トのエンドポイントが Amazon RDS DB インスタンスまたは Amazon EC2 インスタンスにある場合に適 しています 次の図は Amazon EC2 インスタンス上のデータベースがレプリケーションインスタンスに接続され データが Amazon RDS DB インスタンスに移行される設定を示しています この設定で使用される VPC セキュリティグループは レプリケーションインスタンスからの受信をデー タベースポートで許可する必要があります これは レプリケーションインスタンスにより使用されるセ キュリティグループにエンドポイントへの送信があることを確認するか レプリケーションインスタンス のプライベート IP アドレスを明示的に許可することにより 行うことができます 66

73 データベース移行のネットワーク設定 2 つの VPC がある設定 ソースエンドポイントとターゲットエンドポイントが別の VPC にある場合 いずれかの VPC でレプリ ケーションインスタンスを作成し VPC ピア接続を使用して 2 つの VPC をリンクすることができます VPC ピア接続は 同じネットワーク内にあるかのように各 VPC のプライベート IP アドレスを使用して ルーティングできるようにする 2 つの VPC 間のネットワーキング接続です 1 つの AWS リージョン 内で VPC を接続するには この方法をお勧めします VPC ピア接続は 自分の VPC 間 または 同じ AWS リージョン内の他の AWS アカウントにある VPC との間に作成できます VPC のピア接続の詳細に ついては Amazon VPC ユーザーガイド の VPC ピア接続 を参照してください 次の図に VPC ピア接続の設定例を示します ここでは VPC 内の Amazon EC2 インスタンスのソース データベースが VPC ピア接続によって VPC に接続されます この VPC には レプリケーションインス タンスと Amazon RDS DB インスタンス上のターゲットデータベースが含まれています この設定で使用される VPC セキュリティグループは レプリケーションインスタンスからの受信をデータ ベースポートで許可する必要があります AWS Direct Connect または VPN を使用した VPC へのネット ワークの設定 リモートネットワークは AWS Direct Connect やソフトウェアまたはハードウェア VPN 接続といった複 数のオプションを使用して VPC に接続できます これらのオプションは 内部ネットワークを AWS ク ラウドに拡張することにより モニタリング 認証 セキュリティ データ 他のシステムなどの既存の オンサイトサービスを統合するためによく使用されます このタイプのネットワーク拡張を使用すること で VPC などの AWS によってホストされたリソースにシームレスに接続できます 次の図は ソースエンドポイントが企業データセンターにあるオンプレミスデータベースである設定を示 しています このデータベースは AWS Direct Connect または VPN を使用することで レプリケーショ ンインスタンスと Amazon RDS DB インスタンス上のターゲットデータベースを含む VPC に接続されま す この設定では VPC セキュリティグループに 特定の IP アドレスまたは範囲を宛先とするトラフィック をホストに送信するルーティングルールが含まれている必要があります このホストは VPC からのトラ フィックをオンプレミスの VPN にブリッジできる必要があります この場合 レプリケーションインスタ ンスのプライベート IP アドレスまたはセキュリティグループから NAT インスタンスへのトラフィックを 許可する必要がある独自のセキュリティグループ設定が NAT ホストに含まれています インターネットを使用した VPC へのネットワークの設定 VPN または AWS Direct Connect を使用して AWS リソースに接続しない場合は インターネットを使用 してデータベースを Amazon EC2 インスタンスまたは Amazon RDS DB インスタンスに移行できます 67

74 データベース移行のネットワーク設定 この設定では ターゲットポイントおよびレプリケーションインスタンスを含むインターネットゲート ウェイを持つ VPC 内にパブリックレプリケーションインスタンスが必要です インターネットゲートウェイを VPC に追加するには Amazon VPC ユーザーガイド の インター ネットゲートウェイをアタッチする を参照してください VPC セキュリティグループには デフォルトでは VPC に向かわないトラフィックをインターネットゲー トウェイに送信するルーティングルールが含まれている必要があります この設定では エンドポイント への接続が プライベート IP アドレスではなくレプリケーションインスタンスのパブリック IP アドレス から行われているかのように見えます ClassicLink を使用して VPC 内に存在しない Amazon RDS DB インスタンスを VPC 内の DB インスタンスに設定 プロキシサーバーと ClassicLink を一緒に使用すると VPC 内に存在しない Amazon RDS DB インスタン スを VPC 内に存在する AWS DMS レプリケーションサーバーおよび DB インスタンスに接続できます &ClassicLink を使用すると EC2-Classic DB インスタンスを同じ AWS リージョンにある自アカウントの VPC にリンクできます リンクを作成すると ソース DB インスタンスはプライベート IP アドレスを使 用して VPC 内のレプリケーションインスタンスと通信できます VPC 内のレプリケーションインスタンスは ClassicLink を使用して EC2-Classic プラットフォーム上の ソース DB インスタンスに直接アクセスできないため プロキシサーバーを使用する必要があります プ ロキシサーバーはソース DB インスタンスを レプリケーションインスタンスとターゲット DB インスタ ンスを含む VPC に接続します プロキシサーバーは ClassicLink を使用して VPC に接続します プロキ シサーバーでのポート転送により VPC 内にあるソース DB インスタンスとターゲット DB インスタンス の間で通信が可能になります AWS Database Migration Service で ClassicLink を使用する プロキシサーバーと組み合わせて ClassicLink を使用すると VPC 内に存在しない Amazon RDS DB イン スタンスを VPC 内に存在する AWS DMS レプリケーションサーバーおよび DB インスタンスに接続でき ます 次の手順は ClassicLink を使用して VPC 内に存在しない Amazon RDS ソース DB インスタンス を AWS DMS レプリケーションインタンスとターゲット DB インスタンスを含む VPC に接続する方法を 示しています VPC で AWS DMS レプリケーションインスタンスを作成します (すべてのレプリケーションインスタ ンスが VPC 内で作成されます) VPC セキュリティグループをレプリケーションインスタンスとターゲット DB インスタンスに関連付け ます 2 つのインスタンスが VPC セキュリティグループを共有している場合 デフォルトで相互に通信 できます 68

75 データベース移行のネットワーク設定 EC2 Classic インスタンスでプロキシサーバーをセットアップします プロキシサーバーと VPC の間に ClassicLink を使用した接続を作成します ソースデータベースとターゲットデータベースの AWS DMS エンドポイントを作成します AWS DMS タスクを作成します ClassicLink を使用して VPC 内にない DB インスタンス上のデータベースを VPC 内の DB インス タンス上の VPC に移行するには 1. ステップ 1: AWS DMS レプリケーションインスタンスを作成します AWS DMS レプリケーションインスタンスを作成して VPC セキュリティグループを割り当てるには: 2. a. AWS マネジメントコンソールにサインインし [AWS Database Migration Service] を選択しま す AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合 AWS DMS にアクセスするには適切なアクセス許可が必要です データベース移行に必要なアクセス許 可の詳細については AWS DMS を使用するのに必要な IAM アクセス許可 (p. 31) を参照して ください b. [Dashboard] ページで [Replication Instance] を選択します ステップ 2: レプリケーションの インスタンスを作成する (p. 18) の手順に従って レプリケーションインスタンスを作成しま す c. AWS DMS レプリケーションインスタンスを作成したら EC2 サービスコンソールを開きます ナビゲーションペインで [Network Interfaces] を選択します d. [DMSNetworkInterface] を選択し [Actions] メニューから [Change Security Groups] を選択しま す e. レプリケーションインスタンスとターゲット DB インスタンスに使用するセキュリティグループ を選択します ステップ2: 前のステップのセキュリティグループをターゲット DB インスタンスに関連付けます セキュリティグループを DB インスタンスと関連付けるには 3. a. Amazon RDS サービスコンソールを開きます ナビゲーションペインで [Instances] を選択しま す b. ターゲット DB インスタンスを選択します [Instance Actions] で [Modify] を選択します c. [Security Group] パラメーターの場合 前のステップで使用されたセキュリティグループを選択し ます d. [Continue] を選択してから [Modify DB Instance] を選択します ステップ 3: NGINX を使用して EC2 Classic インスタンスでプロキシサーバーを設定します EC2 Classic インスタンスを起動するには 選択した AMI を使用します 以下の例は AMI Ubuntu Server LTS (HVM) をベースとしています EC2 Classic インスタンスでプロキシサーバーをセットアップするには a. EC2 Classic インスタンスに接続し 次のコマンドを使用して NGINX をインストールします Prompt> Prompt> Prompt> Prompt> Prompt> Prompt> Prompt> Prompt> Prompt> Prompt> sudo apt-get update sudo wget sudo tar -xvzf nginx tar.gz cd nginx sudo apt-get install build-essential sudo apt-get install libpcre3 libpcre3-dev sudo apt-get install zlib1g-dev sudo./configure --with-stream sudo make sudo make install 69

76 データベース移行のネットワーク設定 b. 次のコードを使用して NGINX デーモンファイル /etc/init/nginx.conf を編集します # /etc/init/nginx.conf Upstart file description "nginx http daemon" author " " start on (filesystem and net-device-up IFACE=lo) stop on runlevel [!2345] env DAEMON=/usr/local/nginx/sbin/nginx env PID=/usr/local/nginx/logs/nginx.pid expect fork respawn respawn limit 10 5 pre-start script $DAEMON -t if [ $? -ne 0 ] then exit $? fi end script exec $DAEMON c. /usr/local/nginx/conf/nginx.conf に NGINX 構成ファイルを作成します 設定ファイルに 以下の 内容を追加します # /usr/local/nginx/conf/nginx.conf - NGINX configuration file worker_processes 1; events worker_connections 1024; stream server listen <DB instance port number>; proxy_pass <DB instance identifier>:<db instance port number>; d. コマンドラインから 次のコマンドを使用して NGINX を起動します Prompt> sudo initctl reload-configuration Prompt> sudo initctl list grep nginx Prompt> sudo initctl start nginx 4. ステップ 4: プロキシサーバーと ターゲット DB インスタンスおよびレプリケーションインスタンス を含むターゲット VPC の間に ClassicLink 接続を作成します プロキシサーバーとターゲット VPC を接続するには ClassicLink を使用します 70

77 レプリケーションサブネットグループの作成 a. EC2 コンソールを開き プロキシサーバーを実行している EC2 Classic インスタンスを選択しま す b. [Actions] で [ClassicLink] を選択し [Link to VPC] を選択します c. この手順で先に使用したセキュリティグループを選択します d. [Link to VPC] を選択します 5. ステップ 5: ステップ 3: ソースとターゲットのエンドポイントを指定する (p. 22) の手順を使用し て AWS DMS エンドポイントを作成します ソースエンドポイントを指定する場合 サーバー名とし て内部 EC2 DNS ホスト名を使用する必要があります 6. ステップ 6: ステップ 4: タスクを作成する (p. 25) の手順を使用して AWS DMS タスクを作成しま す レプリケーションサブネットグループの作成 データベース移行に使用するネットワークの一部として 使用する予定の Amazon Virtual Private Cloud (Amazon VPC) のサブネットを指定する必要があります サブネットとは 指定されたアベイラビリ ティーゾーンにある VPC 内の IP アドレス範囲です これらのサブネットは VPC が存在している AWS リージョンのアベイラビリティーゾーン間で分散できます 選択したサブネットにレプリケーションインスタンスを作成します AWS DMS コンソールを使用するこ とで ソースまたはターゲットのエンドポイントが使用するサブネットを管理できます レプリケーションサブネットグループを作成し 使用するサブネットを定義できます 2 つの異なるアベ イラビリティーゾーンにある少なくとも 1 つのサブネットを指定する必要があります レプリケーションサブネットグループを作成する方法 1. AWS マネジメントコンソール にサインインして AWS Database Migration Service を選択しま す AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合 AWS DMS にアクセスするには適切なアクセス許可が必要です データベース移行に必要なアクセス許可の 詳細については AWS DMS を使用するのに必要な IAM アクセス許可 (p. 31) を参照してくださ い 2. [Navigation] ペインで [Subnet Groups] を選択します 3. [Create Subnet Group] を選択します 4. 以下に示すように [Edit Replication Subnet Group] ページで レプリケーションサブネットグループ 情報を指定します 次の表で設定について説明します 71

78 レプリケーションサブネットグループの作成 使用するオプション 操作 識別子 8 16 の印刷可能な ASCII 文字 (/ を除く) を含む レプリケーションサブネットグループ名を入力します 名 前は 選択した AWS リージョンのアカウントで一意でな ければなりません わかりやすい名前にするには AWS リージョンや実行中のタスクなどの情報を名前に含めます (例: DMS-default-VPC) 説明 レプリケーションサブネットグループの簡単な説明を入力 します VPC データベース移行に使用する VPC を選択します VPC で は 少なくとも 2 つのアベイラビリティーゾーンに少なく とも 1 つのサブネットが必要であることに注意してくださ い 利用可能なサブネット レプリケーションサブネットグループに含めるサブネット を選択します 少なくとも 2 つのアベイラビリティーゾー ンにあるサブネットを選択する必要があります 5. [Add] を選択し サブネットをレプリケーションサブネットグループに追加します 6. [Create] を選択します 72

79 暗号化キーを設定する レプリケーションインスタンスのための暗号化キー の設定 AWS DMS では レプリケーションインスタンスによって使用されるストレージと エンドポイント の接続情報を暗号化します レプリケーションインスタンスで使用されるストレージを暗号化するた め AWS DMS では AWS アカウントに固有のマスターキーを使用します このマスターキーは AWS Key Management Service (AWS KMS) で表示および管理できます ご使用のアカウント (aws/dms) のデ フォルトのマスターキー を使用するか ご自身で作成するカスタムのマスターキーを使用することができ ます 既存の AWS KMS 暗号化キーがある場合は そのキーを暗号化に使用することもできます KMS キー識別子を指定して AWS DMS リソースを暗号化することで 独自の暗号化キーを指定できま す 独自の暗号化キーを指定した場合 データベース移行の実行に使用されるユーザーアカウントがその キーにアクセスできる必要があります 独自の暗号化キーを作成して暗号化キーへのユーザーアクセスを 許可する方法の詳細については AWS KMS開発者ガイド を参照してください KMS キー識別子を指定しない場合 AWS DMS はデフォルトの暗号化キーを使用します KMS によっ て AWS アカウント用に AWS DMS のデフォルトの暗号化キーが作成されます AWS アカウントに は AWS のリージョンごとにデフォルトの暗号化キーがあります AWS DMS リソースの暗号化に使用されるキーを管理するには KMS を使用します KMS は AWS マ ネジメントコンソール コンソールのホームページで [Identity & Access Management] を選択し ナビゲー ションペインで [暗号化キー] を選択することで表示できます KMS は 安全で可用性の高いハードウェアとソフトウェアを組み合わせて クラウド向けに拡張され たキー管理システムを提供します KMS を使用して 暗号化キーを作成し それらのキーの使用方法を 制御するポリシーを定義できます KMS では AWS CloudTrail がサポートされているため キーの使用 を監査して キーが適切に使用されていることを確認できます KMS キーは AWS DMS と Amazon RDS S3 Amazon Elastic Block Store (Amazon EBS) Amazon Redshift などのサポートされている AWS のサービスと組み合わせて使用できます 特定の暗号化キーを使用して AWS DMS リソースを作成すると それらのリソースの暗号化キーを変更す ることはできません AWS DMS リソースを作成する場合は 必ず暗号化キー要件を調べてください レプリケーションインスタンスの作成 データベースの移行の最初のタスクは 割り当てるタスクを実行するのに十分なストレージと処理能力を 持つレプリケーションのインスタンスを作成し ソースデータベースからターゲットデータベースにデー タを移行することです このインスタンスの必要なサイズは 移行する必要のあるデータの量 および インスタンスが実行するタスクにより異なります レプリケーションインスタンスの詳細については AWS DMS レプリケーションインスタンスを使用する (p. 57) を参照してください 以下の手順では AWS DMS コンソールウィザードを選択したことを前提とします また このステップ は AWS DMS コンソールのナビゲーションペインで [Replication instances (レプリケーションインスタ ンス)] [Create replication instance (レプリケーションインスタンスの作成)] の順に選択することによって も実行できます AWS コンソールを使用してレプリケーションインスタンスを作成するには 1. [Create replication instance] ページで レプリケーションのインスタンス情報を指定します 次の表 で設定について説明します 73

80 レプリケーションインスタンスの作成 使用するオプション 操作 名前 8 16 の印刷可能な ASCII 文字 (/ を除く) を含む レプリケーションインスタンス名を入力します 名前は 選択した AWS リージョンのアカウントで一意でなけれ ばなりません わかりやすい名前にするには AWS リー ジョンや実行中のタスクなどの情報を名前に含めます (例: west2-mysql2mysql-instance1) 説明 レプリケーションインスタンスの簡単な説明を入力しま す インスタンスクラス 移行に必要な設定を使用してインスタンスのクラスを選 択します 正常に移行を完了するために インスタンス には十分なストレージ ネットワーク 処理能力が必要 であることに注意してください 移行に最適なインスタ ンスのクラスを決定する方法に関する詳細については AWS DMS レプリケーションインスタンスを使用す る (p. 57) を参照してください レプリケーションエンジンのバージョ ン デフォルトでは レプリケーションインスタンスは最新 バージョンの AWS DMS レプリケーションエンジンソフ トウェアを実行します このデフォルトをそのまま使用す ることをお勧めします ただし 必要に応じて 以前のエ ンジンバージョンを選択できます 74

81 レプリケーションインスタンスの作成 2. 使用するオプション 操作 VPC 使用する Amazon Virtual Private Cloud (Amazon VPC) を選択します ソースまたはターゲットデータベースが VPC にある場合 その VPC を選択します ソースまたは ターゲットデータベースが別の VPC にある場合 それら が共にパブリックサブネットにあり パブリックにアク セス可能であることを確認してから レプリケーションイ ンスタンスが配置される VPC を選択します レプリケー ションインスタンスが ソース VPC のデータにアクセス できるようにする必要があります ソースもターゲット データベースも VPC にない場合は レプリケーションイ ンスタンスを配置する VPC を選択します マルチ AZ オプションのパラメータを使用して フェイルオーバー のサポート用に別のアベイラビリティーゾーンにレプリ ケーションインスタンスのスタンバイレプリカを作成しま す 変更データキャプチャ (CDC) または 進行中のレプ リケーションを使用する場合は このオプションを有効に する必要があります パブリックアクセス可能 レプリケーションインスタンスをインターネットからアク セス可能にする場合は このオプションを選択します 必要がある場合は [Advanced] タブを選択して 次に示す通り ネットワークおよび暗号化設定の値 を設定します 次の表で設定について説明します 75

82 レプリケーションインスタンスの作成 使用するオプション 操作 Allocated storage (GB) ストレージは主に ログファイルと キャッシュされたト ランザクションで消費されます キャッシュされたトラン ザクションでは ストレージは キャッシュされたトラン ザクションをディスクに書き込む必要がある場合にのみ使 用されます したがって AWS DMS では大量のストレー ジを使用しません 例外には次のようなものがあります 膨大なトランザクションをロードする サイズの大きな テーブル サイズの大きなテーブルをロードするには時 間がかかります そのため サイズの大きなテーブルを ロードする間 キャッシュされたトランザクションが書 き込まれる可能性が高くなります キャッシュされたトランザクションをロードする前に停 止するよう設定されているタスク この場合 すべての テーブルのロードが完了するまで すべてのトランザ クションがキャッシュされます この設定では キャッ シュされたトランザクションにより かなりの量のスト レージが消費されることがあります Amazon Redshift にロードされるテーブルを使用する設 定になっているタスク ただし Amazon Aurora がター ゲットのときは この設定は問題にはなりません ほとんどの場合 ストレージのデフォルトの割り当てで十 分です ただし ストレージ関連のメトリクスに注意を払 い デフォルトの割り当てよりも消費量が多い場合はスト レージを拡張することをおすすめします レプリケーションサブネットグループ レプリケーションインスタンスを作成する選択した VPC でレプリケーションサブネットグループを選択します ソースデータベースが VPC にある場合は レプリケー ションインスタンスの場所として ソースデータベースを 含むサブネットグループを選択します レプリケーション サブネットグループの詳細については レプリケーショ ンサブネットグループの作成 (p. 71) を参照してくだ さい アベイラビリティーゾーン ソースデータベースが配置されているアベイラビリティー ゾーンを選択します VPC セキュリティグループ レプリケーションのインスタンスが VPC 内で作成され ます ソースデータベースが VPC にある場合は データ ベースが存在する DB インスタンスへのアクセス権を提供 する VPC セキュリティグループを選択します KMS マスターキー 使用する暗号化キーを選択して レプリケーションのスト レージと接続情報を暗号化します (デフォルト) aws/dms を選択する場合 アカウントおよび AWS リージョンに関 連付けられたデフォルトの AWS Key Management Service (AWS KMS) キーが使用されます 説明とアカウント番号 が キーの ARN とともに表示されます 暗号化キーの使 用の詳細については 暗号化キーの設定と KMS のアク セス許可の指定 (p. 45) を参照してください 76

83 レプリケーションインスタンスの変更 3. [Maintenance] 設定を指定します 次の表で設定について説明します メンテナンス設定の詳細につい ては AWS DMS メンテナンスウィンドウ (p. 60) を参照してください 使用するオプション 操作 Auto minor version upgrade 選択すると メンテナンスの時間帯に レプリケーション インスタンスに自動的にマイナーエンジンアップグレード が適用されます Maintenance window 週 1 回のシステムメンテナンスを実行できる時間帯 (世界 標準時 (UTC)) を選択します デフォルト: 1 週間のうちのランダムな日に起こる AWS リージョンあたり 8 時間の範囲からランダムに選択された 30 分の時間窓 4. [Create replication instance] を選択します レプリケーションインスタンスの変更 インスタンスクラスの変更やストレージの増量など レプリケーションインスタンスの設定を変更できま す レプリケーションインスタンスを変更する際に 変更内容を即時に適用することができます 変更内容を すぐに適用するには AWS マネジメントコンソール で [Apply changes immediately (変更をすぐに適用す る)] オプションを選択するか AWS CLI を呼び出す際に --apply-immediately パラメータを使用する か AWS DMS API を使用する際に ApplyImmediately パラメータを true に設定します 変更の即時適用を選択しない場合 この変更は保留中の変更キューに保存されます 次のメンテナンス ウィンドウ実行中に キューのすべての保留中の変更が適用されます Note 変更の即時適用を選択した場合 保留中の変更キューにあるすべての変更も同様に適用されま す ダウンタイムを必要とする保留中の変更がある場合 [Apply changes immediately] を選択す ると予想外のダウンタイムが発生することがあります AWS コンソールを使用してレプリケーションインスタンスを変更するには 1. AWS マネジメントコンソール にサインインして AWS DMS を選択します 2. ナビゲーションペインで [Replication instances] を選択します 77

84 レプリケーションインスタンスの変更 3. 変更するレプリケーションインスタンスを選択します 次の表は 行うことができる変更を示してい ます 使用するオプション 操作 名前 レプリケーションインスタンスの名前を変更できます 8 16 の印刷可能な ASCII 文字 (/ を除く) を含むレ プリケーションインスタンス名を入力します 名前は 選択した AWS リージョンのアカウントで一意でなけれ ばなりません わかりやすい名前にするには AWS リー ジョンや実行中のタスクなどの情報を名前に含めます (例: west2-mysql2mysql-instance1) インスタンスクラス インスタンスクラスを変更できます 移行に必要な設定 を使用してインスタンスのクラスを選択します インス タンスクラスを変更すると レプリケーションインスタ ンスが再起動されます この再起動は 次のメンテナン スウィンドウ中に行われます または [Apply changes immediately] オプションを選択するとすぐに行われます 移行に最適なインスタンスのクラスを決定する方法に関す る詳細については AWS DMS レプリケーションインス タンスを使用する (p. 57) を参照してください レプリケーションエンジンのバージョ ン レプリケーションインスタンスで使用されているエンジン バージョンをアップグレードできます レプリケーション のエンジンバージョンをアップグレードすると アップグ レード中にレプリケーションインスタンスがシャットダウ ンされます マルチ AZ このオプションを変更して フェイルオーバーのサポート 用に別のアベイラビリティーゾーンにレプリケーションイ ンスタンスのスタンバイレプリカを作成するか このオプ ションを削除できます 変更データキャプチャ (CDC) ま たは継続的なレプリケーションを使用する場合は このオ プションを有効にする必要があります 78

85 レプリケーションインスタンスの変更 使用するオプション 操作 Allocated storage (GB) ストレージは主に ログファイルと キャッシュされたト ランザクションで消費されます キャッシュされたトラン ザクションでは ストレージは キャッシュされたトラン ザクションをディスクに書き込む必要がある場合にのみ使 用されます したがって AWS DMS では大量のストレー ジを使用しません 例外には次のようなものがあります 膨大なトランザクションをロードする サイズの大きな テーブル サイズの大きなテーブルをロードするには時 間がかかります そのため サイズの大きなテーブルを ロードする間 キャッシュされたトランザクションが書 き込まれる可能性が高くなります キャッシュされたトランザクションをロードする前に停 止するよう設定されているタスク この場合 すべての テーブルのロードが完了するまで すべてのトランザ クションがキャッシュされます この設定では キャッ シュされたトランザクションにより かなりの量のスト レージが消費されることがあります Amazon Redshift にロードされるテーブルを使用する設 定になっているタスク ただし Amazon Aurora がター ゲットのときは この設定は問題にはなりません ほとんどの場合 ストレージのデフォルトの割り当てで十 分です ただし ストレージ関連のメトリクスに注意を払 い デフォルトの割り当てよりも消費量が多い場合はスト レージを拡張することをおすすめします VPC セキュリティグループ レプリケーションのインスタンスが VPC 内で作成され ます ソースデータベースが VPC にある場合は データ ベースが存在する DB インスタンスへのアクセス権を提供 する VPC セキュリティグループを選択します Auto minor version upgrade このオプションを選択すると メンテナンスウィンドウ 中にマイナーエンジンアップグレードを自動的にレプリ ケーションインスタンスに適用できます または [Apply changes immediately] オプションを選択するとすぐに適用 できます Maintenance window 週 1 回のシステムメンテナンスを実行できる時間帯 (世界 標準時 (UTC)) を選択します デフォルト: 1 週間のうちのランダムな日に起こる AWS リージョンあたり 8 時間の範囲からランダムに選択された 30 分の時間窓 Apply changes immediately 行った変更をすぐに適用するには このオプションを選択 します 選択した設定によっては このオプションを選択 すると レプリケーションインスタンスが直ちに再起動さ れる可能性があります 79

86 レプリケーションインスタンスを再起動する レプリケーションインスタンスを再起動する AWS DMS レプリケーションインスタンスを再起動して レプリケーションエンジンを再開できます 再 起動すると レプリケーションインスタンスは一時的に機能停止になります その間 インスタンスのス テータスは [Rebooting] に設定されます AWS DMS インスタンスがマルチ AZ 用に構成されている場合 再起動はフェイルオーバーにより実行できます 再起動が完了すると AWS DMS イベントが作成されま す AWS DMS インスタンスがマルチ AZ 配置である場合は ある AWS アベイラビリティーゾーンから別の アベイラビリティーゾーンへのフェイルオーバーを強制的に実行できます AWS DMS インスタンスの フェイルオーバーを強制すると AWS DMS は別のアベイラビリティーゾーンでスタンバイインスタンス に自動的に切り替わります フェイルオーバーを使用した再起動は テスト用に AWS DMS インスタンス の障害をシミュレートするときに役立ちます 再起動の発生時にレプリケーションインスタンスで実行されている移行タスクがある場合 データは失わ れず 再起動が完了するとタスクが再開されます 移行タスクのテーブルがバルクロードの途中の場合 (全ロードフェーズ) DMS はそれらのテーブルの移行を最初から再開します 移行タスクのテーブルが継 続的なレプリケーションフェーズにある場合 再起動が完了するとタスクが再開されます ステータスが [Available] 状態にない場合 AWS DMS レプリケーションインスタンスを再起動することは できません AWS DMS インスタンスは 以前の要求による変更 またはメンテナンスウィンドウのアク ションなど いくつかの理由で使用できない場合があります AWS DMS レプリケーションインスタンス の再起動に必要な時間は 通常短時間です (5 分未満) AWS コンソールを使用したレプリケーションインスタンスの再 起動 レプリケーションインスタンスを再起動するには AWS コンソールを使用します AWS コンソールを使用してレプリケーションインスタンスを再起動するには 1. AWS マネジメントコンソール にサインインして AWS DMS を選択します ナビゲーションペインで [Replication instances] を選択します 再起動するレプリケーションインスタンスを選択します [Reboot] を選択します 5. マルチ AZ 配置のレプリケーションインスタンスを設定し 別の AWS アベイラビリティーゾーンに フェイルオーバーする場合は [レプリケーションインスタンスの再起動] ダイアログボックスで [フェイルオーバーによる再起動を行いますか?] を選択します 6. [Reboot] を選択します CLI を使用してレプリケーションインスタンスを再起動する レプリケーションインスタンスを再起動するには 以下のパラメータを指定して AWS CLI rebootreplication-instance コマンドを使用します --replication-instance-arn Example シンプルな再起動の例 次の AWS CLI の例では レプリケーションインスタンスを再起動します aws dms reboot-replication-instance \ --replication-instance-arn arnofmyrepinstance 80

87 レプリケーションインスタンスの削除 Example フェイルオーバーによるシンプルな再起動の例 次の AWS CLI の例では フェイルオーバーによりレプリケーションインスタンスを再起動します aws dms reboot-replication-instance \ --replication-instance-arn arnofmyrepinstance \ --force-failover API を使用してレプリケーションインスタンスを再起動する レプリケーションインスタンスを再起動するには 以下のパラメータを指定して AWS DMS API の RebootReplicationInstance アクションを使用します ReplicationInstanceArn = arnofmyrepinstance Example シンプルな再起動の例 次のコードの例では レプリケーションインスタンスを再起動します &DBInstanceArn=arnofmyrepinstance &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version= &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/ /us-east-1/dms/aws4_request &X-Amz-Date= T192732Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3 Example フェイルオーバーによるシンプルな再起動の例 次のコード例では レプリケーションインスタンスを再起動し 別の AWS アベイラビリティーゾーンに フェイルオーバーします &DBInstanceArn=arnofmyrepinstance &ForceFailover=true &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version= &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/ /us-east-1/dms/aws4_request &X-Amz-Date= T192732Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3 レプリケーションインスタンスの削除 不要になった AWS DMS レプリケーションインスタンスは削除できます レプリケーションインスタンス を使用する移行タスクがある場合は レプリケーションインスタンスを削除する前に タスクを停止して 削除する必要があります 81

88 レプリケーションインスタンスの削除 AWS アカウントを閉じた場合 アカウントに関連付けられたすべての AWS DMS リソースおよび設定は 2 日後に削除されます これらのリソースには すべてのレプリケーションインスタンス ソースおよび ターゲットのエンドポイント設定 レプリケーションタスク および SSL 証明書が含まれます 2 日後に AWS DMS を再度使用する場合は 必要なリソースを再作成します AWS コンソールを使用したレプリケーションインスタンスの削 除 レプリケーションインスタンスを削除するには AWS コンソールを使用します AWS コンソールを使用してレプリケーションインスタンスを削除するには 1. AWS マネジメントコンソール にサインインして AWS DMS を選択します 2. ナビゲーションペインで [Replication instances] を選択します 3. 削除するレプリケーションインスタンスを選択します 4. [Delete] を選択します 5. ] ダイアログボックスで [Delete] を選択します CLI を使用したレプリケーションインスタンスの削除 レプリケーションインスタンスを削除するには 以下のパラメータを指定して AWS CLI deletereplication-instance コマンドを使用します --replication-instance-arn Example 削除の例 次の AWS CLI の例では レプリケーションインスタンスを削除します aws dms delete-replication-instance \ --replication-instance-arn <arnofmyrepinstance> API を使用したレプリケーションインスタンスの削除 レプリケーションインスタンスを削除するには 以下のパラメータを指定して AWS DMS API の DeleteReplicationInstance アクションを使用します ReplicationInstanceArn = <arnofmyrepinstance> Example 削除の例 次のコードの例では レプリケーションインスタンスを削除します &DBInstanceArn=arnofmyrepinstance &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version= &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/ /us-east-1/dms/aws4_request &X-Amz-Date= T192732Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date 82

89 サポートされている DDL ステートメント &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3 AWS DMS によりサポートされている DDL ステー トメント データ移行プロセス中は ソースデータベース上でデータ定義言語 (DDL) ステートメントを実行できま す これらのステートメントはレプリケーションサーバー上で ターゲットデータベースにレプリケート されます サポートされている DDL ステートメントは以下のとおりです Create table Drop table Rename table Add column Drop column Rename column Change column data type 特定のソースでサポートされている DDL ステートメントについては そのソースについて説明しているト ピックを参照してください 83

90 データ移行のソース AWS DMS エンドポイントの使用 エンドポイントは データストアに関する接続 データストアタイプ および場所情報を提供しま す AWS Database Migration Service はこの情報を使用してデータストアに接続し ソースエンドポイン トからターゲットエンドポイントにデータを移行します 追加の接続属性を使用して エンドポイントの 接続属性をさらに指定できます これらの属性により ログ記録やファイルサイズなどのパラメータを管 理できます 追加の接続属性の詳細については データストアのドキュメントセクションを参照してくだ さい 以下で エンドポイントの詳細について参照してください トピック データ移行のソース (p. 84) データ移行のターゲット (p. 146) ソースおよびターゲットエンドポイントの作成 (p. 189) データ移行のソース AWS Database Migration Service (AWS DMS) では 最もよく利用されているデータエンジンの多く をデータレプリケーションのソースとして使用できます データベースソースには Amazon Elastic Compute Cloud (Amazon EC2) インスタンスまたはオンプレミスのデータベースで実行されている自己管 理型エンジンを使用できます または Amazon Relational Database Service (Amazon RDS) や Amazon S3 などの Amazon が管理するサービス上のデータソースも使用できます AWS DMS の有効なソースには次のものがあります オンプレミスと Amazon EC2 インスタンスのデータベース Enterprise Standard Standard One および Standard Two エディションの Oracle バージョン 10.2 以 降 11g 12.2 まで. Enterprise Standard Workgroup および Developer エディションの Microsoft SQL Server バージョ ン R および 2016.Web および Express エディションはサポートさ れていません MySQL バージョン MariaDB (MySQL 互換データソースとしてサポートされています). PostgreSQL 9.4 以降. SAP Adaptive Server Enterprise (ASE) バージョン 以上 以降 MongoDB バージョン 2.6.x およ 3.x 以降. Db2 LUW のバージョン: バージョン 9.7 すべての Fix Pack がサポートされています バージョン 10.1 すべての Fix Pack がサポートされています Version 10.5 Fix Pack 5 を除くすべての Fix Pack がサポートされています Microsoft Azure AWS DMS では Azure SQL Database をソースとして使用するときに全データのロードがサポートさ れます 変更データキャプチャ (CDC) はサポートされません 84

91 ソースとして Oracle を使用する Amazon RDS インスタンスのデータベース Oracle バージョン 11g (バージョン v1 以降) および 12c (Enterprise Standard Standard One Standard Two エディション) Enterprise および Standard エディションの Microsoft SQL Server バージョン 2008R CDC は Enterprise Edition のすべてのバージョンでサポートさ れています CDC は Standard Edition バージョン 2016 SP1 以降でのみサポートされていま す Web Workgroup Developer Express エディションは AWS DMS ではサポートされていませ ん MySQL バージョン 変更データキャプチャ (CDC) は バージョン 5.6 以降でのみサポー トされます PostgreSQL 9.4 以降.CDC は バージョン 以降と 以降でのみサポートされます CDCに必 要な rds.logical_replication パラメータは これらのバージョン以降でのみサポートされていま す MySQL 互換のデータソースとしてサポートされる MariaDB MySQL と互換性がある Amazon Aurora Amazon S3 AWS DMS では Amazon S3 をソースとして使用する場合に 全データロードおよび変更データキャプ チャ (CDC) がサポートされます トピック AWS DMS のソースとして Oracle データベースを使用する (p. 85) Microsoft SQL Server データベースを AWS DMS のソースとして使用する (p. 99) Microsoft Azure SQL データベースの AWS DMS のソースとしての使用 (p. 110) PostgreSQL データベースの AWS DMS のソースとしての使用 (p. 110) MySQL 互換データベースの AWS DMS のソースとしての使用 (p. 122) SAP ASE データベースを AWS DMS のソースとして使用する (p. 130) AWS DMS のソースとしての MongoDB の使用 (p. 133) AWS DMS ソースとしての Amazon S3 の使用 (p. 138) AWS DMS のソースとして Linux Unix および Windows データベース用の IBM Db2 (Db2 LUW) を 使用する (p. 144) AWS DMS のソースとして Oracle データベースを使 用する AWS DMS を使用して 1 つ以上の Oracle データベースからデータを移行できます Oracle データベース をソースとして使用すると AWS DMS によりサポートされているいずれかのターゲットにデータを移行 できます 自己管理型の Oracle データベースの場合 AWS DMS ではバージョン 10.2 以降 11g 12.2 以前のす べての Oracle データベースエディションがソースの自己管理型データベースとしてサポートされていま す Amazon RDS により提供される Amazon が管理する Oracle データベースの場合 AWS DMS はバー ジョン 11g (バージョン v1 以降) および 12.2 以前のすべての Oracle データベースエディション をサポートしています SSL を使用して Oracle エンドポイントとレプリケーションインスタンスとの接続を暗号化できま す Oracle エンドポイントで SSL を使用する方法の詳細については AWS Database Migration Service で SSL を使用する (p. 47) を参照してください 85

92 ソースとして Oracle を使用する AWS DMS のソースとして Oracle データベースを設定するステップは次のとおりです 1. CDC のみのタスクまたは全ロードと CDC のタスクを作成する場合 Oracle LogMiner または Oracle Binary Reader を選択してデータ変更をキャプチャする必要があります LogMiner または Binary Reader を選択すると それ以降のアクセス許可と設定タスクのいくつかが決定されます LogMiner と Binary Reader の比較については 次のセッションを参照してください 2. AWS DMS の適切なアクセス許可を持つ Oracle ユーザーを作成します 全ロードのみのタスクを作成 する場合 これ以上設定は必要ありません 3. 全ロードと CDC のタスクまたは CDC のみのタスクを作成する場合 LogMiner または Binary Reader 向けに Oracle を設定します 4. 選択した設定に準拠する DMS エンドポイントを作成します Oracle データベースと AWS DMS の使用の詳細については 以下のセクションを参照してください トピック 変更データキャプチャ (CDC) での Oracle LogMiner または Oracle Binary Reader の使用 (p. 86) AWS DMS のソースとして自己管理型 Oracle データベースを使用する (p. 88) Amazon が管理する Oracle データベースを AWS DMS のソースとして使用する (p. 91) Oracle を AWS DMS のソースとして使用する場合の制限 (p. 93) AWS DMS のソースとして Oracle を使用する場合の追加の接続属性 (p. 94) Oracle のソースデータ型 (p. 97) 変更データキャプチャ (CDC) での Oracle LogMiner または Oracle Binary Reader の使用 Oracle には 変更処理を行う際に REDO ログを読み取るための方法として Oracle LogMiner と Oracle Binary Reader の 2 つが用意されています Oracle LogMiner には Oracle のオンラインおよびアーカイ ブ REDO ログファイルへの SQL インターフェイスが用意されています Binary Reader は raw REDO ロ グファイルを直接読み取って解析する AWS DMS 機能です デフォルトでは AWS DMS は変更データキャプチャ (CDC) に Oracle LogMiner を使用します AWS DMS で LogMiner を使用することのメリットは次のとおりです LogMiner では 暗号化オプションや圧縮オプションなど ほとんどの Oracle オプションがサポートさ れています Binary Reader では すべての Oracle オプションがサポートされているわけではありませ ん (特に暗号化と圧縮のオプション) LogMiner には 特に Oracle Binary Reader の直接アクセスセットアップと比較したり REDO ログが Automatic Storage Management (ASM) 上にある場合と比較して シンプルな設定になっています LogMiner は Oracle Transparent Data Encryption (TDE) を含むほとんどの Oracle 暗号化オプションを 完全にサポートします LogMiner は 全ロードおよび継続的レプリケーション (CDC) の両方に対して次の HCC 圧縮タイプをサ ポートします QUERY HIGH ARCHIVE HIGH ARCHIVE LOW QUERY LOW Binary Reader は 継続的 (CDC) レプリケーションではなく 全ロードレプリケーションでのみ QUERY LOW 圧縮をサポートします LogMiner は AWS DMS により使用されるテーブルクラスターをサポートします Binary Reader はサ ポートしません 86

93 ソースとして Oracle を使用する AWS DMS で LogMiner の代わりに Binary Reader を使用することのメリットは次のとおりです 大量の変更を含む移行の場合 LogMiner は Oracle ソースデータベースをホストするコンピュータの I/O や CPU にある程度の影響を及ぼすことがあります アーカイブログはレプリケーションインスタンス にコピーされてそこに記録されるため Binary Reader が I/O や CPU に影響を与える可能性は高くあり ません 大量の変更を含む移行の場合 Oracle LogMiner を使用するより Binary Reader を使用した方が CDC の パフォーマンスが通常はかなり高くなります Binary Reader では Oracle バージョン 12c における LOBS の CDC がサポートされていま す LogMiner ではサポートされていません Binary Reader は 全ロードおよび継続的レプリケーション (CDC) の両方に対して次の HCC 圧縮タイ プをサポートします QUERY HIGH ARCHIVE HIGH ARCHIVE LOW QUERY LOW 圧縮タイプは 全ロードの移行のみでサポートされています 通常 次のいずれかの状況に該当しない限り Oracle データベースの移行には Oracle LogMiner を使用し ます ソース Oracle データベースで複数の移行タスクを実行する必要がある ソース Oracle データベース上の変更の量または REDO ログの量が多い Oracle 12.2 以降のソースエンドポイントから LOB を移行する LOB 列のみを更新する UPDATE ステートメントがワークロードに含まれている場合 Binary Reader を 使用する必要があります これらの更新ステートメントは Oracle LogMiner でサポートされていませ ん ソースが Oracle バージョン 11 であり XMLTYPE および LOB 列で UPDATE ステートメントを実行す る場合 Binary Reader を使用する必要があります これらのステートメントは Oracle LogMiner でサ ポートされていません Oracle 12c では LogMiner により LOB 列がサポートされません Oracle 12c から LOB 列を移行する 場合は Binary Reader を使用する必要があります Oracle ソースデータベースでの変更データキャプチャ (CDC) の設定 全ロードおよび変更データキャプチャ (CDC) または CDC のみのソースエンドポイントとして Oracle を使 用する場合は 追加の接続属性を設定する必要があります この属性は LogMiner と Binary Reader のど ちらを使用してトランザクションログにアクセスするかを指定します ソースエンドポイントを作成する ときに追加の接続属性を指定します 複数の追加の接続属性の設定は セミコロンで区切る必要がありま す デフォルトでは LogMiner が使用されるため その使用を明示的に指定する必要はありません Binary Reader がトランザクションログにアクセスできるようにするには 以下の追加の接続属性を追加します uselogminerreader=n; usebfile=y Oracle ソースデータベースが Oracle 自動ストレージ管理 (ASM) を使用している場合 追加の接続属性に ASM ユーザー名と ASM サーバーアドレスを含める必要があります ソースエンドポイントを作成する場 合 パスワードフィールドには両方のパスワード ソースユーザーパスワード および ASM パスワード が必要です 87

94 ソースとして Oracle を使用する たとえば 次の追加の接続属性形式は Oracle ASM を使用するサーバーにアクセスするために使用され ます uselogminerreader=n;asm_user=<asm_username>;asm_server=<first_rac_server_ip_address>:<port_number>/ +ASM Oracle ソースデータベースが Oracle ASM を使用している場合 ソースエンドポイントパスワードフィー ルドに Oracle ユーザーパスワードと ASM パスワードをカンマで区切って含める必要があります たと えば 以下はパスワードフィールドで機能します <oracle_user_password>,<asm_user_password> Oracle ソースデータベースとしての CDC の制限 Oracle データベースを AWS DMS 変更データキャプチャのソースとして使用する場合は 以下の制限が適 用されます AWS DMS では テーブルメタデータや OBJECT_ID 値の変更など Oracle DBMS_REDEFINITION パッ ケージにより生じた変更がキャプチャされません AWS DMS では BFILE を使用する際 オーバーフローセグメントがあるインデックスで整理される テーブルは CDC モードでサポートされません たとえば LogMiner を使用しないで REDO ログにア クセスする場合などです AWS DMS のソースとして自己管理型 Oracle データベースを使 用する 自己管理型データベースは 自分で構成および制御するデータベースで ローカルのオンプレミスデー タベースインスタンスまたは Amazon EC2 上のデータベースのどちらかです AWS DMS で自己管理型 Oracle データベースを使用する場合にセットアップする必要がある権限と設定を以下に示します AWS DMS の自己管理型 Oracle ソースで必要なユーザーアカウント権限 Oracle データベースを AWS DMS タスクでソースとして使用するには AWS DMS Oracle データベース 定義で指定されたユーザーに Oracle データベースにおける次の権限が付与されている必要があります 権 限を付与するときは オブジェクトのシノニム (V_$OBJECT など アンダースコアなし) ではなく オブ ジェクトの実際の名前 (V$OBJECT など アンダースコアを含む) を使用してください GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT ) GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT GRANT SELECT ANY TRANSACTION to <dms_user> on V_$ARCHIVED_LOG to <dms_user> on V_$LOG to <dms_user> on V_$LOGFILE to <dms_user> on V_$DATABASE to <dms_user> on V_$THREAD to <dms_user> on V_$PARAMETER to <dms_user> on V_$NLS_PARAMETERS to <dms_user> on V_$TIMEZONE_NAMES to <dms_user> on V_$TRANSACTION to <dms_user> on ALL_INDEXES to <dms_user> on ALL_OBJECTS to <dms_user> on DBA_OBJECTS to <dms_user> (required if the Oracle version is earlier than on on on on on ALL_TABLES to <dms_user> ALL_USERS to <dms_user> ALL_CATALOG to <dms_user> ALL_CONSTRAINTS to <dms_user> ALL_CONS_COLUMNS to <dms_user> 88

95 ソースとして Oracle を使用する GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT SELECT SELECT SELECT SELECT SELECT SELECT SELECT SELECT SELECT SELECT on on on on on on on on on on ALL_TAB_COLS to <dms_user> ALL_IND_COLUMNS to <dms_user> ALL_LOG_GROUPS to <dms_user> SYS.DBA_REGISTRY to <dms_user> SYS.OBJ$ to <dms_user> DBA_TABLESPACES to <dms_user> ALL_TAB_PARTITIONS to <dms_user> ALL_ENCRYPTED_COLUMNS to <dms_user> V_$LOGMNR_LOGS to <dms_user> V_$LOGMNR_CONTENTS to <dms_user> 継続的なレプリケーション (CDC) を使用する場合は 以下の追加のアクセス権限が必要です AWS DMS で CDC を使用して 11g と 12c 両方の Oracle LogMiner REDO ログに追加する場合は 以下 のアクセス権限が必要です Grant EXECUTE ON dbms_logmnr TO <dms_user>; AWS DMS で CDC を使用して 12c のみの Oracle LogMiner REDO ログに追加する場合は 以下のアク セス権限が必要です Grant LOGMINING TO <dms_user>; 以下に示す追加機能のいずれかを使用している場合は 指定された追加のアクセス許可が必要です ビューが公開されている場合 ALL_VIEWS での SELECT を <dms_user> に付与します レプリケーションタスクでパターンを使用してテーブル名とマッチングする場合 SELECT ANY TABLE を付与します レプリケーションタスクでテーブルリストを指定した場合 リスト内の各テーブルでの SELECT を付与 します サプリメンタルロギングを追加する場合 ALTER ANY TABLE を付与します サプリメンタルロギングを追加し 特定のテーブルリストを使用する場合 リスト内のテーブルごとに ALTER を付与します Oracle RAC から移行する場合 gv_$ や v_$ といったプレフィックスを持つマテリアライズドビューに 対する SELECT アクセス権限を付与します AWS DMS の自己管理型 Oracle ソースを設定する 自己管理型 Oracle データベースを AWS DMS のソースとして使用する前に いくつかのタスクを実行す る必要があります Oracle アカウントアクセスを提供する AWS DMS の Oracle ユーザーアカウントを指定する必要があ ります ユーザーアカウントには 前のセクションで指定されているように Oracle データベースでの 読み取り/書き込み権限が必要です ARCHIVELOG モードがオンであることを確認する Oracle は ARCHIVELOG モードと NOARCHIVELOG モードの 2 つのモードで実行できます AWS DMS で Oracle を使用する場合は ソースデータベースが ARCHIVELOG モードになっている必要があります サプリメンタルロギングのセットアップ CDC タスクまたは全ロードと CDC タスクでソースを使用す る予定の場合 サプリメンタルロギングをセットアップしてレプリケーションの変更をキャプチャする 必要があります 89

96 ソースとして Oracle を使用する Oracle のサプリメンタルロギング作成を有効にするには 2 つのステップがあります まず データベー スレベルのサプリメンタルロギングを有効にする必要があります これにより クラスター化されたテー ブルやインデックスで整理されたテーブルなど さまざまなテーブル構造をサポートするのに必要な最小 限の情報が LogMiner に確保されます 次に 移行するテーブルごとにテーブルレベルのサプリメンタル ロギングを有効にする必要があります データベースレベルのサプリメンタルロギングを有効にするには 1. 次のクエリを実行し データベースレベルでのサプリメンタルロギングがすでに有効になっているか どうかを調べます 返される結果は GE to です SELECT name, value, description FROM v$parameter WHERE name = 'compatible'; 2. 次のクエリを実行します 返される結果は YES または IMPLICIT です SELECT supplemental_log_data_min FROM v$database; 3. 次のクエリを実行し データベースレベルのサプリメンタルロギングを有効にします ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; テーブルレベルのサプリメンタルロギング作成を有効にするには 2 つの方法があります 最初の方法で は データベースユーザーアカウントが移行するすべてのテーブルで ALTER TABLE 権限を持っている場 合 以下で説明するように追加の接続パラメータ addsupplementallogging を使用できます もう 1 つの方法では 移行時に各テーブルに以下のステップを使用できます テーブルレベルのサプリメンタルロギングを有効にするには 1. テーブルにプライマリキーがある場合 次のコマンドを実行してテーブルに PRIMARY KEY サプリメ ンタルロギングを追加します ALTER TABLE <table_name> ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; 2. プライマリキーが存在せず テーブルに一意のインデックスが複数存在する場合 AWS DMS はイン デックス名をアルファベット順に並べたときの最初の一意のインデックスを使用します 前述のように そのインデックスの列にサプリメンタルロググループを作成します 3. プライマリキーも一意のインデックスも存在しない場合 サプリメンタルロギングをすべての列に追 加する必要があります 次のクエリを実行し サプリメンタルロギングをすべての列に追加します ALTER TABLE <table_name> ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS; 場合によっては ターゲットテーブルのプライマリキーまたは一意のインデックスは ソーステーブルの プライマリキーまたは一意のインデックスと異なります その場合 ターゲットテーブルのプライマリ キーまたは一意のインデックスを構成するソーステーブル列でサプリメンタルロギングを追加します ターゲットテーブルのプライマリキーを変更する場合 元のプライマリキーまたは一意のインデックスで はなく 選択したインデックスの列にサプリメンタルロギングを追加する必要があります フィルタがテーブルに定義されている場合など 必要に応じて追加のロギングを追加します テーブルに 一意のインデックスやプライマリキーがある場合 フィルタに関係する列がプライマリキーまたは一意の インデックスの列とは異なるときは それらあの各列にサプリメンタルロギングを追加する必要がありま す ただし ALL COLUMNS サプリメンタルロギングがテーブルに追加されている場合 追加のロギング を追加する必要はありません 90

97 ソースとして Oracle を使用する ALTER TABLE <table_name> ADD SUPPLEMENTAL LOG GROUP <group_name> (<column_list>) ALWAYS; Amazon が管理する Oracle データベースを AWS DMS のソース として使用する Amazon が管理するデータベースは Amazon RDS Amazon Aurora Amazon S3 などの Amazon のサー ビス上にあるデータベースです AWS DMS で Amazon が管理する Oracle データベースを使用するとき にセットアップする必要がある権限と設定を以下に示します AWS DMS の Amazon が管理する Oracle ソースで必要なユーザーアカウント権 限 Amazon RDS で Oracle データベースにおける権限を付与するには ストアドプロシージャ rdsadmin.rdsadmin_util.grant_sys_object を使用します 詳細については SYS オブジェク トへの SELECT または EXECUTE 権限の付与 を参照してください AWS DMS ユーザーアカウントに Oracle ソースエンドポイントにアクセスするための以下の権限を付与 します GRANT SELECT ANY TABLE to <dms_user>; GRANT SELECT on ALL_VIEWS to <dms_user>; GRANT SELECT ANY TRANSACTION to <dms_user>; 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('v_ $ARCHIVED_LOG','<dms_user>','SELECT'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('v_ $LOG','<dms_user>','SELECT'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('v_ $LOGFILE','<dms_user>','SELECT'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('v_ $DATABASE','<dms_user>','SELECT'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('v_ $THREAD','<dms_user>','SELECT'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('v_ $PARAMETER','<dms_user>','SELECT'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('v_ $NLS_PARAMETERS','<dms_user>','SELECT'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('v_ $TIMEZONE_NAMES','<dms_user>','SELECT'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('v_ $TRANSACTION','<dms_user>','SELECT'); 次の作業を行います GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT GRANT SELECT SELECT SELECT SELECT SELECT SELECT SELECT SELECT SELECT on on on on on on on on on ALL_INDEXES to <dms_user>; ALL_OBJECTS to <dms_user>; ALL_TABLES to <dms_user>; ALL_USERS to <dms_user>; ALL_CATALOG to <dms_user>; ALL_CONSTRAINTS to <dms_user>; ALL_CONS_COLUMNS to <dms_user>; ALL_TAB_COLS to <dms_user>; ALL_IND_COLUMNS to <dms_user>; 91

98 ソースとして Oracle を使用する GRANT SELECT on ALL_LOG_GROUPS to <dms_user>; 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('dba_registry','<dms_user>','select'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('obj $','<dms_user>','select'); GRANT SELECT on DBA_TABLESPACES to <dms_user>; GRANT SELECT on ALL_TAB_PARTITIONS to <dms_user>; GRANT LOGMINING TO <dms_user>; 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('all_encrypted_columns','<dms_user>','select'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('v_ $LOGMNR_LOGS','<dms_user>','SELECT'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('v_ $LOGMNR_CONTENTS','<dms_user>','SELECT'); 次の作業を行います exec rdsadmin.rdsadmin_util.grant_sys_object('dbms_logmnr','<dms_user>','execute'); AWS DMS の Amazon が管理する Oracle ソースを設定する Amazon が管理する Oracle データベースを AWS DMS のソースとして使用する前に いくつかのタスク を実行する必要があります Oracle アカウントアクセスを提供する AWS DMS の Oracle ユーザーアカウントを指定する必要があ ります ユーザーアカウントには 前のセクションで指定されているように Oracle データベースでの 読み取り/書き込み権限が必要です Amazon RDS データベースのバックアップ保持期間を 1 日以上に設定します バックアップ保持期間を 設定すると データベースが ARCHIVELOG モードで実行されます バックアップ保持期間の設定の詳 細については Amazon RDS ユーザーガイド の バックアップの使用 を参照してください アーカイブ保持を設定します 以下を実行し Oracle データベースインスタンスのアーカイブされた REDO ログを保持します このコマンドを実行すると AWS DMS が LogMiner を使用してログ情報を 取得できるようになります 移行期間中 アーカイブされた REDO ログのための十分なストレージがあ ることを確認します 次の例では ログは 24 時間保持されます exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24); サプリメンタルロギングのセットアップ CDC タスクまたは全ロードと CDC タスクでソースを使用す る予定の場合 サプリメンタルロギングをセットアップしてレプリケーションの変更をキャプチャしま す Oracle のサプリメンタルロギング作成を有効にするには 2 つのステップがあります まず データ ベースレベルのサプリメンタルロギングを有効にする必要があります これにより クラスター化され たテーブルやインデックスで整理されたテーブルなど さまざまなテーブル構造をサポートするのに必 要な最小限の情報が LogMiner に確保されます 次に 移行するテーブルごとにテーブルレベルのサプ リメンタルロギングを有効にする必要があります データベースレベルのサプリメンタルロギングを有効にするには 次のクエリを実行し データベースレベルのサプリメンタルロギングを有効にします 92

99 ソースとして Oracle を使用する exec rdsadmin.rdsadmin_util.alter_supplemental_logging('add'); テーブルレベルのサプリメンタルロギングを有効にするには 次のコマンドを実行し プライマリキーを持つテーブルの PRIMARY KEY ロギングを有効にしま す exec rdsadmin.rdsadmin_util.alter_supplemental_logging('add','primary KEY'); プライマリキーを持たないテーブルの場合 次のコマンドを使用してサプリメンタルロギングを追加し ます alter table <table_name> add supplemental log data (ALL) columns; プライマリキーのないテーブルを作成する場合 create ステートメントにサプリメンタルロギング句を 含めるか テーブルを変更してサプリメンタルロギングを追加する必要があります 次のコマンドは テーブルを作成し サプリメンタルロギングを追加します create table <table_name> (<column_list>, supplemental log data (ALL) columns); テーブルを作成し 後でプライマリキーを追加した場合 テーブルにサプリメンタルロギングを追加す る必要があります 次のコマンドを使用してテーブルにサプリメンタルロギングを追加します alter table <table_name> add supplemental log data (PRIMARY KEY) columns; AWS DMS における Amazon RDS for Oracle ソースの変更データキャプチャ (CDC) を設定する AWS DMS を設定して CDC のソースとして Amazon RDS for Oracle インスタンスを使用することが できます Amazon RDS for Oracle ソースで Oracle Binary Reader を使用します (Oracle バージョン v11 以降 および v7 以降) Amazon RDS for Oracle ソースエンドポイントを作成する場合は 次の接続属性を接続情報に追加する必 要があります uselogminerreader=n;usebfile=y;accessalternatedirectly=false; usealternatefolderforonline=true; oraclepathprefix=/rdsdbdata/db/orcl_a/;usepathprefix=/rdsdbdata/log/; replacepathprefix=true Oracle を AWS DMS のソースとして使用する場合の制限 Oracle データベースを AWS DMS のソースとして使用する場合は 以下の制限が適用されます Oracle LogMiner と一緒に使用する場合 AWS DMS では Oracle の透過的なデータ暗号化 (TDE) テー ブルスペース暗号化と AWS Key Management Service (AWS KMS) 暗号化がサポートされます 他の暗 号化形式はどれもサポートされていません 93

100 ソースとして Oracle を使用する LOB のあるテーブルで CDC を使用するにはプライマリキーが必要です AWS DMS では Oracle バージョン 11 以降の rename table <table name> to <new table name> 構文がサポートされています 明示的な CHAR セマンティクスを使用して作成された Oracle ソースデータベース列は BYTE セマ ンティクスを使用してターゲット Oracle データベースに転送されます 移行前に ターゲット Oracle データベースでこのタイプの列を含むテーブルを作成する必要があります AWS DMS では ADD DROP EXCHANGE TRUNCATE のようなデータ定義言語 (DDL) オペレー ションなど パーティションまたはサブパーティションオペレーションの結果生じたデータの変更がレ プリケートされません このような変更をレプリケートするには レプリケートするテーブルを再ロー ドする必要があります AWS DMS は その後のデータ変更を新たに追加されたパーティションにレプ リケートします テーブルを再ロードする必要はありません ただし パーティション内の古いデータ レコードで UPDATE オペレーションを実行すると失敗し 0 rows affected 警告が生成されます DDL ステートメント ALTER TABLE ADD <column> <data_type> DEFAULT <> は デフォルト値 をターゲットにレプリケートしません ターゲットの新しい列は NULL に設定されます 新しい列で NULL が許容される場合 Oracle は DDL 自体を記録する前にすべてのテーブル行を更新します その結 果 AWS DMS ではカウンターへの変更がキャプチャされますが ターゲットは更新されません 新し い列は NULL に設定されるため ターゲットテーブルにプライマリキーまたは一意のインデックスがな い場合 その後の更新により 0 rows affected 警告が生成されます CREATE TABLE AS ステートメントの結果生じたデータ変更はサポートされていません ただし 新し いテーブルがターゲットで作成されます サイズ制限のある LOB モードが有効な場合 AWS DMS では Oracle ソース上の空の LOB をターゲッ トの NULL 値としてレプリケートします AWS DMS によって CDC が開始されると タイムスタンプが Oracle システム変更番号 (SCN) にマッピ ングされます Oracle ではデフォルトで タイムスタンプと SCN のマッピングは 5 日間 保持されま す 指定したタイムスタンプが古すぎる (保持期間が 5 日間より長い) 場合 Oracle ではエラーが生成さ れます 詳細については Oracle のドキュメントを参照してください AWS DMS では ASM プロキシを使用した Oracle ソースへの接続がサポートされていません AWS DMS では仮想列がサポートされていません AWS DMS のソースとして Oracle を使用する場合の追加の接続 属性 追加の接続属性を使用して Oracle ソースを設定できます これらの設定は ソースエンドポイントを作成 するときに指定します 複数の追加の接続属性の設定は 互いにセミコロンで区切る必要があります 次の表に AWS DMS のソースとして Oracle データベースを設定するために使用できる追加の接続属性を 示します 名前 説明 addsupplementallogging Oracle データベースにテーブルレベルのサプリメンタルロ ギングをセットアップするには この属性を設定します こ の属性により 移行タスクで選択されたすべてのテーブルで PRIMARY KEY サプリメンタルロギングが有効になります デフォルト値: N 有効な値: Y/N 例: addsupplementallogging=y 94

101 ソースとして Oracle を使用する 名前 説明 Note このオプションを使用する場合でも 前述のように データベースレベルサプリメンタルロギングを有効 にする必要があります additionalarchivedlogdestid この属性を プライマリ/スタンバイセットアップで archivedlogdestid と同時に設定します この属性はフェ イルオーバーの場合に役立ちます この場合 AWS DMS は アーカイブ REDO ログを取得して変更を読み取るための送信 先を知っている必要があります これは 前のプライマリイ ンスタンスがフェイルオーバー後にスタンバイインスタンス になるためです uselogminerreader LogMiner ユーティリティを使用して変更データをキャプチャ するには この属性を Y に設定します (デフォルト) AWS DMS をバイナリファイルとして REDO ログにアクセスで きるようにする場合は このオプションを N に設定しま す N に設定すると usebfile=y という設定も追加する必 要があります 詳細については 変更データキャプチャ (CDC) での Oracle LogMiner または Oracle Binary Reader の 使用 (p. 86) を参照してください デフォルト値: Y 有効な値: Y/N 例: uselogminerreader=n; usebfile=y Oracle ソースデータベースが Oracle 自動ストレージ管理 (ASM) を使用している場合 追加の接続パラメータに ASM ユーザー名と ASM サーバーアドレスを含める必要がありま す パスワードフィールドには両方のパスワード ソース ユーザーパスワード および ASM パスワードも必要です (互 いにカンマで区切ります) 例: uselogminerreader=n;asm_user=<asm_username>; asm_server=<first_rac_server_ip_address>:<port_number>/ +ASM retryinterval システムがクエリを再送するまで待機する時間の秒数を指定 します デフォルト値: 5 有効な値: 1 以降の数値 例: retryinterval=6 95

102 ソースとして Oracle を使用する 名前 説明 archivedlogdestid アーカイブされた REDO ログの宛先を指定します 値 は $archived_log テーブル内の DEST_ID 値と同じにする必 要があります ログの宛先を (DEST_ID) を複数使用する場 合 アーカイブされた REDO ログの場所の識別子を使用する ことをお勧めします これにより 最初から適切なログにア クセスされるため パフォーマンスが向上します デフォルト値: 0 有効な値: 数値 例: archivedlogdestid=1 このフィールドが Y に設定されている場合 AWS DMS は アーカイブされた REDO ログにのみアクセスします アーカ イブされた REDO ログが Oracle ASM のみに保存されている 場合 AWS DMS ユーザーアカウントに ASM 権限を付与す る必要があります archivedlogsonly デフォルト値: N 有効な値: Y/N 例: archivedlogsonly=y 数値のスケールを指定します 最大 38 のスケールを選択す るか FLOAT を選択できます デフォルトでは NUMBER データ型が精度 38 スケール 10 に変換されます numberdatatypescale デフォルト値: 10 有効な値: (FLOAT の場合は -1) 例: numberdatatypescale =12 AWS DMS がエンドポイントに接続した直後に実行するスク リプトを指定します afterconnectscript 有効な値: セミコロンで区切った任意の SQL ステートメン ト すべての SQL ステートメントがサポートされているわけ ではありません 例: afterconnectscript=alter SESSION SET CURRENT_SCHEMA = system; failtasksonlobtruncation true に設定されると LOB 列の実際のサイズが指定された LobMaxSize よりも大きい場合 この属性によりタスクは失 敗します タスクが制限付き LOB モードに設定され このオプションが true に設定されている場合 LOB データを切り捨てるので はなくタスクが失敗します デフォルト値: false 有効な値: ブール値 例: failtasksonlobtruncation=true 96

103 ソースとして Oracle を使用する 名前 説明 readtablespacename true に設定すると この属性はテーブルスペースのレプリ ケーションをサポートします デフォルト値: false 有効な値: ブール値 例: readtablespacename =true この属性を使用して スタンバイ同期の遅延時間を分単位で 指定します standbydelaytime AWS DMS バージョン 以降では Oracle Active Data Guard スタンバイインスタンスをサポートされているター ゲットへの継続的な変更をレプリケートするソースとして使 用する Oracle の継続的なレプリケーション (CDC) タスク を作成できます これにより 運用中のアクティブなデータ ベースに接続する必要がなくなります デフォルト値: 0 有効な値: 数値 例: standbydelaytime=1 Oracle のソースデータ型 AWS DMS の Oracle エンドポイントでは Oracle のほとんどのデータ型がサポートされています 次の 表に AWS DMS を使用する場合にサポートされる Oracle のソースデータ型と AWS DMS のデータ型へ のデフォルトマッピングを示します ターゲットにマッピングされるデータ型を表示する方法については 使用しているターゲットエンドポイ ントのセクションを参照してください AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください Oracle のデータ型 AWS DMS データ型 BINARY_FLOAT REAL4 BINARY_DOUBLE REAL8 BINARY BYTES FLOAT (P) 精度が 24 以下の場合 REAL4 を使用します 精度が 24 より高い場合 REAL8 を使用します NUMBER (P,S) スケールが 0 未満の場合 REAL8 を使用します Oracle のソースデータベー ス設定の Expose number as プロパティに従った NUMBER スケールが 0 の場合 精度が 0 の場合 REAL8 を使用します 精度が 2 以上の場合 INT1 を使用します 精度が 2 より大きく 4 以下の場合 INT2 を使用します 97

104 ソースとして Oracle を使用する Oracle のデータ型 AWS DMS データ型 精度が 4 より大きく 9 以下の場合 INT4 を使用します 精度が 9 より大きい場合 NUMERIC を使用します 精度がスケール以上の場合 NUMERIC を使用します 他のいずれの場合も REAL8 を使用します DATE DATETIME INTERVAL_YEAR TO MONTH STRING (間隔 year_to_month を指定) INTERVAL_DAY TO SECOND STRING (間隔 day_to_second を指定) TIME DATETIME TIMESTAMP DATETIME TIMESTAMP WITH TIME ZONE STRING (timestamp_with_timezone を指定) TIMESTAMP WITH LOCAL TIME ZONE STRING (timestamp_with_local_ timezone を指定) CHAR STRING VARCHAR2 STRING NCHAR WSTRING NVARCHAR2 WSTRING RAW BYTES REAL REAL8 BLOB BLOB AWS DMS でこのデータ型を使用する場合は 特定のタスク用に BLOB データ型の使用を有効にする必要があります AWS DMS では プライ マリキーを含むテーブルでのみ BLOB データ型がサポートされます CLOB CLOB AWS DMS でこのデータ型を使用する場合は 特定のタスク用に CLOB データ型の使用を有効にする必要があります 変更データキャプチャ (CDC) の実行中 AWS DMS ではプライマリキーを含むテーブルでのみ CLOB データ型がサポートされます NCLOB NCLOB AWS DMS でこのデータ型を使用する場合は 特定のタスク用に NCLOB データ型の使用を有効にする必要があります CDC の実行 中 AWS DMS ではプライマリキーを含むテーブルでのみ NCLOB デー タ型がサポートされます 98

105 SQL Server をソースとして使用する Oracle のデータ型 AWS DMS データ型 LONG CLOB LONG データ型は 最適化バッチ適用モード (TurboStream CDC モー ド) ではサポートされません AWS DMS でこのデータ型を使用す る場合は 特定のタスク用に LOB の使用を有効にする必要がありま す CDC の実行中 AWS DMS ではプライマリキーを持つテーブルで のみ LOB データ型がサポートされます LONG RAW BLOB LONG RAW データ型は 最適化バッチ適用モード (TurboStream CDC モード) ではサポートされません AWS DMS でこのデータ型を使用 する場合は 特定のタスク用に LOB の使用を有効にする必要がありま す CDC の実行中 AWS DMS ではプライマリキーを持つテーブルで のみ LOB データ型がサポートされます XMLTYPE CLOB XMLTYPE データ型のサポートには (Oracle Instant Client ではなく) フ ル Oracle クライアントが必要です ターゲット列が CLOB の場合 フ ル LOB モードと制限付き LOB モードの両方がサポートされます (ター ゲットによって異なります) 以下のデータ型の列とともにソースとして使用されている Oracle テーブルはサポートされておらず レプ リケートすることができません これらのデータ型の列をレプリケートすると NULL 列が発生します BFILE ROWID REF UROWID NESTED TABLE ユーザー定義のデータ型 ANYDATA Note 仮想列はサポートされていません Microsoft SQL Server データベースを AWS DMS の ソースとして使用する AWS DMS (AWS DMS) を使用して 1 つ以上の Microsoft SQL Server データベースからデータを移行で きます SQL Server データベースをソースとして使用すると 別の SQL Server データベースまたはサ ポートされている他のデータベースのいずれかにデータを移行できます AWS DMS では ソースとして Microsoft SQL Server バージョン R のオンプレミスおよび Amazon EC2 インスタンスデータベー スがサポートされます Enterprise Standard Workgroup および Developer エディションがサポート されます Web および Express エディションはサポートされていません AWS DMS では ソースとして SQL Server バージョン 2008R の Amazon RDS DB インスタンスデータベースがサポートされます Enterprise および Standard エディ 99

106 SQL Server をソースとして使用する ションがサポートされています CDC は Enterprise Edition のすべてのバージョンでサポートさ れています CDC は Standard Edition バージョン 2016 SP1 以降でのみサポートされていま す Web Workgroup Developer Express エディションはサポートされていません SQL Server データベースは ネットワーク内のどのコンピュータにもインストールできます また その データベースを AWS DMS で使用するには 選択したタスクのタイプに応じてソースデータベースに対す る適切なアクセス権限を持つ SQL Server アカウントが必要です AWS DMS は SQL Server の名前付きインスタンスからのデータ移行をサポートしています ソースエン ドポイントを作成するとき サーバー名では次の表記を使用できます IPAddress\InstanceName たとえば 正しいソースエンドポイントサーバー名を以下に示します ここでは 名前の最初の部分は サーバーの IP アドレス 2 番目の部分は SQL Server インスタンス名 (この例では SQLTest) です \SQLTest SSL を使用して SQL Server エンドポイントとレプリケーションインスタンスとの接続を暗号化できま す SQL Server エンドポイントで SSL を使用する方法の詳細については AWS Database Migration Service で SSL を使用する (p. 47) を参照してください ソースとして使用する SQL Server データベースから変更をキャプチャするには データベースは完全 バックアップ用に設定され Enterprise Developer Standard のいずれかのエディションであることが必 要です SQL Server ソースデータベースと AWS DMS を使用する方法の詳細については 以下を参照してくださ い トピック SQL Server を AWS DMS のソースとして使用する場合の制限 (p. 100) SQL Server ソースから継続的なレプリケーション (CDC) を使用する (p. 101) サポートされている圧縮方法 (p. 105) SQL Server AlwaysOn 可用性グループの使用 (p. 105) SQL Server データベースの AWS DMS のレプリケーションソースとしての設定 (p. 106) AWS DMS のソースとして SQL Server を使用する場合の追加の接続属性 (p. 106) SQL Server のソースデータ型 (p. 107) SQL Server を AWS DMS のソースとして使用する場合の制限 SQL Server データベースを AWS DMS のソースとして使用する場合は 以下の制限が適用されます 列の ID プロパティは ターゲットデータベース列に移行されません バージョン 2.4.x より前の AWS DMS エンジンでは 情報が 8000 バイトを超える (ヘッダーおよびマッ ピング情報を含む) 行への変更は SQL Server TLOG バッファサイズの制限のため適切に処理されませ ん この問題を回避するには 最新の AWS DMS バージョンを使用します SQL Server エンドポイントでは スパーステーブルの使用はサポートされていません Windows 認証はサポートされていません SQL Server の計算済みフィールドの変更はレプリケーションされていません 一時テーブルはサポートされていません 100

107 SQL Server をソースとして使用する SQL Server パーティション切り替えはサポートされていません ソースでクラスター化されたインデックスは ターゲットでクラスター化されていないインデックスと して作成されます WRITETEXT ユーティリティと UPDATETEXT ユーティリティを使用している場合 AWS DMS では ソースデータベースに適用されたイベントがキャプチャされません 次のデータ操作言語 (DML) パターンはサポートされていません SELECT <*> INTO <new_table> FROM <existing_table> SQL Server をソースとして使用している場合 列レベルの暗号化はサポートされていません SQL Server 2008 と 2008 R2 の既知の問題のため AWS DMS では ソースエンドポイントとして使用 している SQL Server 2008 と SQL Server 2008 R2 でのサーバーレベルの監査はサポートされていませ ん たとえば 次のコマンドを実行すると AWS DMS でエラーが発生します USE [master] GO ALTER SERVER AUDIT [my_audit_test ] WITH (STATE=on) GO SQL Server ソースから継続的なレプリケーション (CDC) を使用 する オンプレミスまたは Amazon EC2 上の自己管理型 SQL Server データベースや Amazon RDS 上の Amazon が管理するデータベースに継続的なレプリケーション (変更データキャプチャ つまり CDC) を使 用できます AWS DMS では これらの SQL Server 設定の継続的なレプリケーションがサポートされています オンプレミスまたは Amazon EC2 上のソース SQL Server インスタンスの場合 AWS DMS では SQL Server Enterprise Standard および Developer Edition の継続的なレプリケーションがサポートされま す Amazon RDS で実行されているソース SQL Server インスタンスの場合 AWS DMS は SQL Server Enterprise から SQL Server 2016 SP1 で継続的なレプリケーションをサポートしています このバー ジョン以降では AWS DMS は SQL Server Enterprise Edition と Standard Edition の両方で CDC をサ ポートしています AWS DMS が継続的なレプリケーションを自動的にセットアップするようにする場合 ソースデータベー スへの接続に使用する AWS DMS ユーザーアカウントに sysadmin 固定サーバーロールが必要です 使用 するユーザーアカウントに sysadmin ロールを割り当てない場合でも 以下で説明する一連の手動ステッ プに従うことで継続的なレプリケーションを使用できます AWS DMS のソースとして SQL Server データベースを使用して継続的なレプリケーションを使用する場 合は 次の要件が特別に適用されます SQL Server を完全バックアップ用に設定し データのレプリケートの開始前にバックアップを実行する 必要があります 復旧モデルを [Bulk logged] または [Full] に設定する必要があります 101

108 SQL Server をソースとして使用する 複数のディスクへの SQL Server のバックアップはサポートされていません データベースバックアッ プを異なるディスク上の複数のファイルに書き込むようにバックアップを定義している場合 AWS DMS ではそのデータを読み取ることができず AWS DMS タスクは失敗します 自己管理型 SQL Server ソースの場合 DMS CDC タスクで使用されたソースデータベースの SQL Server Replication Publisher 定義は そのタスクを削除しても削除されない点に注意してくださ い SQL Server システム管理者がそれらの定義を自己管理型ソースの SQL Server から削除する必要が あります CDC 中に AWS DMS は SQL Server トランザクションログのバックアップを検索して 変更を読み取 る必要があります AWS DMS では サードパーティーのバックアップソフトウェアを使用して作成さ れた SQL Server トランザクションログのバックアップの使用はサポートされていません 自己管理型 SQL Server ソースの場合 SQL Server は新しく作成されたテーブルの変更を 公開され るまでキャプチャしない点に注意してください テーブルが SQL Server ソースに追加されると AWS DMS は公開の作成を管理します ただし この処理には数分かかることがあります この遅延中に新た に作成されたテーブルに行われたオペレーションは ターゲットにキャプチャまたはレプリケーション されません AWS DMS 変更データキャプチャを行うには SQL Server で FULLOGGING を有効にする必要があり ます SQL Server で FULLLOGGING を有効にするには MS-REPLICATION または CHANGE DATA CAPTURE (CDC) を有効にします SQL Server の tlog は 変更が処理されるまで再利用できません CDC オペレーションはメモリ最適化テーブルに対してはサポートされていません この制限は この機 能が初めて導入された SQL Server 2014 とそれ以降のバージョンに適用されます SQL Server のデータ変更をキャプチャする 自己管理型 SQL Server ソースの場合 AWS DMS は以下を使用します MS-Replication: プライマリキーを持つテーブルの変更をキャプチャします これは ソース SQL Server インスタンスユーザーで AWS DMS エンドポイントユーザーに sysadmin 権限を付与すること で自動的に設定できます または このセクションで説明されているステップに従ってソースを準備 し AWS DMS エンドポイントに sysadmin 以外のユーザーを使用することもできます MS-CDC: プライマリキーを持たないテーブルの変更をキャプチャします MS-CDC は すべてのテー ブルのデータベースレベルで個別に有効になっている必要があります Amazon RDS で実行されている SQL Server ソースの場合 プライマリキーの有無にかかわらず AWS DMS は MS-CDC を使用してテーブルの変更をキャプチャします MS-CDC は このセクションで説明さ れている Amazon RDS 固有のストアドプロシージャを使用して すべてのテーブルのデータベースレベル で個別に有効になっている必要があります 継続的なレプリケーション (CDC) に SQL Server データベースを使用できる方法はいくつかあります sysadmin ロールを使用する継続的なレプリケーションをセットアップします(これは 自己管理型 SQL Server ソースにのみ適用されます) sysadmin ロールを使用しない継続的なレプリケーションをセットアップします (これは 自己管理型 SQL Server ソースにのみ適用されます) Amazon RDS for SQL Server DB インスタンスの継続的なレプリケーションをセットアップします sysadmin ロールを使用して継続的なレプリケーションをセットアップする プライマリキーがあるテーブルの場合 AWS DMS はソースで必要なアーティファクトを設定できます プライマリキーがないテーブルの場合 MS-CDC をセットアップする必要があります まず 次のコマンドを実行してデータベースで MS-CDC を有効にします sysadmin ロールが割り当てら れたアカウントを使用します 102

109 SQL Server をソースとして使用する use [DBname] EXEC sys.sp_cdc_enable_db 次に 以下のコマンドを実行して各ソーステーブルで MS-CDC を有効にします EXECUTE = = = NULL; 特定のテーブルの MS-CDC をセットアップする方法の詳細については SQL Server のドキュメントを参 照してください sysadmin ロールを割り当てずに継続的なレプリケーションをセットアップする ユーザーアカウントが sysadmin 権限を持っている必要がない SQL Server データベースソースに継続的な レプリケーションをセットアップできます sysadmin ロールを使用せずに継続的なレプリケーションの SQL Server データベースソースを セットアップするには 1. SQL Server Management Studio (SSMS) を使用してパスワード認証する新しい SQL Server アカウン トを作成します この例では dmstest というアカウントを使用します 2. SSMS の [User Mappings] セクションで MSDB および MASTER データベース (公開権限を付与しま す) を選択し 継続的なレプリケーションを使用するデータベースに DB_OWNER ロールを割り当て ます 3. 新しいアカウントのコンテキストメニュー (右クリック) を開き [Security] を選択して Connect SQL 権限を明示的に付与します 4. 以下の付与コマンドを実行します GRANT SELECT ON FN_DBLOG TO dmstest; GRANT SELECT ON FN_DUMP_DBLOG TO dmstest; GRANT VIEW SERVER STATE TO dmstest; use msdb; GRANT EXECUTE ON MSDB.DBO.SP_STOP_JOB TO dmstest; GRANT EXECUTE ON MSDB.DBO.SP_START_JOB TO dmstest; GRANT SELECT ON MSDB.DBO.BACKUPSET TO dmstest; GRANT SELECT ON MSDB.DBO.BACKUPMEDIAFAMILY TO dmstest; GRANT SELECT ON MSDB.DBO.BACKUPFILE TO dmstest; 5. SSMS で [Replication] フォルダのコンテキスト (右クリック) メニューを開き [Configure Distribution] を選択します すべてのデフォルトステップに従って ディストリビューションのこの SQL Server インスタンスを設定します ディストリビューションデータベースがデータベースの下に 作成されます 6. 以下の手順を使用してパブリケーションを作成します 7. 作成したユーザーアカウントを使用して ソースエンドポイントとして SQL Server を持つ新しい AWS DMS タスクを作成します Note この手順のステップは プライマリキーを持つテーブルにのみ適用されます プライマリキーが ないテーブルの場合 引き続き MS-CDC を有効にする必要があります 継続的なレプリケーション用の SQL Server パブリケーションの作成 SQL Server で CDC を使用するには 継続的なレプリケーションに参加しているテーブルごとにパブリ ケーションを作成する必要があります 103

110 SQL Server をソースとして使用する SQL Server の継続的なレプリケーション用にパブリケーションを作成するには 1. SYSADMIN ユーザーアカウントを使用して SSMS にログインします 2. [レプリケーション] を展開します 3. [Local Publications (ローカルパブリケーション)] を右クリックします 4. [New Publication Wizard (新規パブリケーションウィザード)] で [次へ] を選択します 5. パブリケーションを作成するデータベースを選択します 6. [トランザクションパブリケーション] を選択します [次へ] を選択します 7. [テーブル] を展開し PK (とパブリッシュするテーブル) を含むテーブルを選択します [Next (次へ)] を選択します 8. フィルタを作成する必要がないため [次へ] を選択します 9. Snapshot Agent を作成する必要がないため [次へ] を選択します 10. [セキュリティ設定] [Run under the SQL Server Agent service account (SQL Server エージェント サービスアカウントで実行)] の順に選択します 公開者接続用に [By impersonating the process account (プロセス用アカウントを偽装)] を選択します [OK] を選択します 11. [Next (次へ)] を選択します 12. [Create the publication (パブリケーションの作成)] を選択します 13. パブリケーションの名前を次の形式で指定します AR_PUBLICATION_000<DBID>.たとえば パブリケーションに AR_PUBLICATION_00018 という名 前を指定します また SQL Server で DB_ID 関数を使用することもできます DB_ID 関数の詳細に ついては SQL Server ドキュメント を参照してください Amazon RDS for SQL Server DB インスタンスで継続的なレプリケーションを セットアップする Amazon RDS for SQL Server では SQL Server 2016 SP1 までのすべてのバージョンの Amazon RDS for SQL Server Enterprise エディションの MS-CDC がサポートされます 標準エディションの SQL Server 2016 SP1 およびそれ以降のバージョンでは Amazon RDS for SQL Server の MS-CDC がサポートされま す 自己管理型の SQL Server ソースとは異なり Amazon RDS for SQL Server では MS-Replication はサポー トされません したがって AWS DMS はプライマリーキーの有無にかかわらずテーブルに MS-CDC を使 用する必要があります Amazon RDS は ソース SQL Server インスタンスの継続的な変更に AWS DMS が使用するレプリケー ションアーティファクトを設定するために sysadmin 権限を付与しません 以下の手順で マスターユー ザー権限を使用して Amazon RDS インスタンスで MS-CDC を有効にする必要があります RDS for SQL Server DB インスタンスで MS-CDC を有効にするには 1. データベースレベルで次のクエリを実行します exec msdb.dbo.rds_cdc_enable_db '<DB instance name>' 2. プライマリキーがあるテーブルごとに 次のクエリを実行して MS-CDC を有効にします exec = = = = 1 104

111 SQL Server をソースとして使用する GO 一意キーはあるがプライマリキーがないテーブルごとに 次のクエリを実行して MS-CDC を有効にし ます exec = = = = = 1 GO プライマリキーと一意キーの両方がないテーブルごとに 次のクエリを実行して MS-CDC を有効にし ます exec = = = NULL GO 3. 次のコマンドを使用して ソースで変更を使用できる保持期間を設定します EXEC = 'capture',@pollinginterval = は秒単位で測定されます 上記のコマンドは 変更を 1 日保持しま す AWS では AWS DMS で MS-CDC を使用する場合 1 日の保持期間を推奨しています サポートされている圧縮方法 次の表は SQL Server バージョンごとに AWS DMS によりサポートされている圧縮方法を示していま す SQL Server Version 行/ページの圧縮 (パーティション Vardecimal ストレージ形式 レベル) 2005 いいえ いいえ 2008 はい いいえ 2012 はい いいえ 2014 はい いいえ Note スパース列とカラム構造圧縮はサポートされていません SQL Server AlwaysOn 可用性グループの使用 SQL Server AlwaysOn 可用性グループ機能は データベースミラーリングにエンタープライズレベルの代 替方法を提供する高可用性および災害復旧ソリューションです AlwaysOn 可用性グループを AWS DMS でソースとして使用するには 以下の操作を実行します 105

112 SQL Server をソースとして使用する 可用性レプリカ内のすべての SQL Server インスタンスでディストリビューションオプションを有効に します AWS DMS コンソールで SQL Server ソースデータベース設定を開きます [Server Name] で 可用性 グループリスナーにせていされたドメインネームサービス (DNS) 名または IP アドレスを指定します AWS DMS タスクを初めて開始した場合 テーブル記事の作成が可用性グループサーバーにより複製され るため開始に通常より時間がかかることがあります SQL Server データベースの AWS DMS のレプリケーションソー スとしての設定 SQL Server データベースを AWS DMS (AWS DMS) のレプリケーションソースとして設定できます 変 更を完全にレプリケートするには SQL Server の Enterprise Standard Developer のいずれかのエディ ションの使用が推奨されます 以上のバージョンは MS-Replication (EE SE) と MS-CDC (EE DEV) を 含む唯一のバージョンであるために必要となります ソース SQL Server を完全バックアップ用に設定す る必要もあります さらに AWS DMS には 接続先の SQL Server データベースに対して sysadmin 固定 サーバーロールのあるユーザー (SQL Server インスタンスログイン) で接続する必要があります 以下に SQL Server を AWS DMS のレプリケーションソースとして設定する方法に関する情報を示しま す AWS DMS のソースとして SQL Server を使用する場合の追加の 接続属性 追加の接続属性を使用して SQL Server ソースを設定できます これらの設定は ソースエンドポイント を作成するときに指定します 複数の追加の接続属性の設定は セミコロンで区切る必要があります 次の表に SQL Server でソースとして使用できる追加の接続属性を示します 名前 説明 safeguardpolicy パフォーマンスを最大限に高めるため AWS DMS は未読 み取りのすべての変更をアクティブなトランザクションロ グ (TLOG) からキャプチャしようとします ただし 場合に よっては切り捨てが行われるため アクティブな TLOG に未 読みトロイの変更すべてが含まれていないことがあります この場合 AWS DMS はバックアップログにアクセスして 消失した変更をキャプチャします バックアップログにアク セスする必要性を最小限に抑えるため AWS DMS は次のい ずれかの方法を使用して切り捨てを防止します 1.Start transactions in the database: これがデフォルトの方 法です この方法を使用する場合 AWS DMS はデータベー スでトランザクションを模倣することで TLOG の切り捨て を防ぎます そのようなトランザクションが開かれている限 り そのトランザクションが開始されてから生じる変更は切 り捨てされません データベースで Microsoft レプリケーショ ンを有効にする場合 この方法を選択する必要があります 2. Exclusively use sp_repldone within a single task: こ の方法を使用すると AWS DMS が変更を読み取った 後 sp_repldone を使用して TLOG トランザクションを切り 捨て準備完了とマークします この方法にはトランザクショ ンアクティビティが伴いませんが Microsoft レプリケーショ ンが実行されていないときのみ使用できます さらに この 方法を使用すると 一度に 1 つの AWS DMS タスクのみデー 106

113 SQL Server をソースとして使用する 名前 説明 タベースにアクセスできます したがって 同じデータベー スに対して並行 AWS DMS タスクを実行する必要がある場合 は デフォルトの方法を使用してください デフォルト値: RELY_ON_SQL_SERVER_REPLICATION_AGENT 有効な値: EXCLUSIVE_AUTOMATIC_TRUNCATION, RELY_ON_SQL_SERVER_REPLICATION_AGENT 例: safeguardpolicy= RELY_ON_SQL_SERVER_REPLICATION_AGENT readbackuponly このパラメータが Y に設定されている場合 AWS DMS は トランザクションログのバックアップからの変更のみを読 み取ります 継続的なレプリケーションのアクティブトラ ンザクションログからは読み取られません このパラメータ が Y に設定されていると 継続的なレプリケーションに多少 のソースレイテンシー発生することがありますが これによ り 全ロード時および継続的なレプリケーションタスク時の アクティブトランザクションログファイルの増大を制御でき ます 有効な値: N または Y.デフォルト: N 例: readbackuponly=y SQL Server のソースデータ型 SQL Server を AWS DMS のソースとして使用するデータ移行では ほとんどの SQL Server データ型がサ ポートされます 次の表に AWS DMS を使用する場合にサポートされる SQL Server のソースデータ型 と AWS DMS のデータ型からのデフォルトマッピングを示します ターゲットにマッピングされるデータ型を表示する方法については 使用しているターゲットエンドポイ ントのセクションを参照してください AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください SQL Server のデータ型 AWS DMS データ型 BIGINT INT8 BIT BOOLEAN DECIMAL NUMERIC INT INT4 MONEY NUMERIC NUMERIC (p,s) NUMERIC SMALLINT INT2 SMALLMONEY NUMERIC 107

114 SQL Server をソースとして使用する SQL Server のデータ型 AWS DMS データ型 TINYINT UINT1 REAL REAL4 FLOAT REAL8 DATETIME DATETIME DATETIME2 (SQL Server 2008 以降) DATETIME SMALLDATETIME DATETIME DATE DATE TIME TIME DATETIMEOFFSET WSTRING CHAR STRING VARCHAR STRING VARCHAR(max) CLOB TEXT AWS DMS でこのデータ型を使用する場合は 特 定のタスク用に CLOB データ型の使用を有効にす る必要があります SQL Server テーブルの場合 SQL Server で LOB 列の値を変更しない UPDATE ステートメントで も AWS DMS はターゲットの LOB 列を更新しま す CDC 中 AWS DMS はプライマリキーを含むテー ブルでのみ CLOB データ型をサポートします NCHAR WSTRING NVARCHAR (長さ) WSTRING NVARCHAR (最大) NCLOB NTEXT AWS DMS でこのデータ型を使用する場合は 特 定のタスク用に NCLOB データ型の使用を有効に する必要があります SQL Server テーブルの場合 SQL Server で LOB 列の値を変更しない UPDATE ステートメントで も AWS DMS はターゲットの LOB 列を更新しま す CDC 中 AWS DMS はプライマリキーを含むテー ブルでのみ CLOB データ型をサポートします BINARY BYTES 108

115 SQL Server をソースとして使用する SQL Server のデータ型 AWS DMS データ型 VARBINARY BYTES VARBINARY (最大) BLOB IMAGE SQL Server テーブルの場合 SQL Server で LOB 列の値を変更しない UPDATE ステートメントで も AWS DMS はターゲットの LOB 列を更新しま す AWS DMS でこのデータ型を使用するには 特定 のタスク用に BLOB データ型の使用を有効にする 必要があります AWS DMS は プライマリキーを含むテーブルで のみ BLOB データ型をサポートします TIMESTAMP BYTES UNIQUEIDENTIFIER STRING HIERARCHYID SQL Server ターゲットエンドポイントにレプリ ケートする場合は HIERARCHYID を使用しま す 他のすべてのターゲットエンドポイントにレプリ ケートする場合は WSTRING (250) を使用しま す XML NCLOB SQL Server テーブルの場合 SQL Server で LOB 列の値を変更しない UPDATE ステートメントで も AWS DMS はターゲットの LOB 列を更新しま す AWS DMS でこのデータ型を使用する場合は 特 定のタスク用に NCLOB データ型の使用を有効に する必要があります CDC 中 AWS DMS は プライマリキーを含む テーブルでのみ NCLOB データ型をサポートしま す GEOMETRY このデータ型をサポートするターゲットエンドポ イントにレプリケートする場合は GEOMETRY を使用します このデータ型をサポートしないターゲットエンド ポイントにレプリケートする場合は CLOB を使 用します 109

116 Azure SQL データベースのソースとしての使用 SQL Server のデータ型 AWS DMS データ型 GEOGRAPHY このデータ型をサポートするターゲットエンドポ イントにレプリケートする場合は GEOGRAPHY を使用します このデータ型をサポートしないターゲットエンド ポイントにレプリケートする場合は CLOB を使 用します AWS DMS は 以下のデータ型のフィールドを含むテーブルをサポートしません CURSOR SQL_VARIANT TABLE Note ユーザー定義のデータ型は 基本型に従ってサポートされます たとえば DATETIME をベース とするユーザー定義のデータ型は DATETIME データ型として扱われます Microsoft Azure SQL データベースの AWS DMS の ソースとしての使用 AWS DMS では Microsoft Azure SQL データベースを SQL Server とほとんど同じ方法でソースとして使 用できます AWS DMS は ソースとして オンプレミスまたは Amazon EC2 インスタンスで実行されて いる SQL Server でサポートされるデータベースバージョンの同じリストをサポートします 詳細については Microsoft SQL Server データベースを AWS DMS のソースとして使用す る (p. 99) を参照してください Note AWS DMS は Azure SQL データベースを使用した変更データキャプチャ (CDC) オペレーション はサポートしていません PostgreSQL データベースの AWS DMS のソースとし ての使用 AWS DMS を使用して 1 つ以上の PostgreSQL データベースからデータを移行できます PostgreSQL データベースをソースとして使用すると 別の PostgreSQL データベースまたはサポートされている 他のデータベースのいずれかにデータを移行できます AWS DMS では オンプレミスデータベー ス EC2 インスタンス上のデータベース Amazon RDS DB インスタンス上のデータベースのソースとし て PostgreSQL バージョン 9.4 以降のデータベースがサポートされています Note PostgreSQL バージョン 10.x 以降では 以前のバージョンの関数名とフォルダ名に多くの変更が 加えられています PostgreSQL バージョン 10.x 以降を AWS DMS のソースとして使用している 場合は AWS DMS のソースとして PostgreSQL バージョン 10.x 以降を使用する (p. 118) トピックで AWS DMS のソースとしてのデータベースの準備に関する情報を参照してくださ い 110

117 PostgreSQL のソースとしての使用 SSL を使用して PostgreSQL エンドポイントとレプリケーションインスタンスとの接続を暗号化できま す PostgreSQL エンドポイントで SSL を使用する方法の詳細については AWS Database Migration Service で SSL を使用する (p. 47) を参照してください PostgreSQL データベースから AWS 上の PostgreSQL データベースへの同種移行の場合 以下が当てはま ります ソースの JSONB 列は ターゲットの JSONB 列に移行されます JSON 列は ターゲットで JSON 列として移行されます HSTORE 列は ターゲットで HSTORE 列として移行されます ソースが PostgreSQL ターゲットが別のデータベースエンジンである異種移行の場合 状況は異なりま す この場合 JSONB JSON および HSTORE 列は AWS DMS 中間タイプの NCLOB に変換され ターゲットで対応する NCLOB 列タイプに変換されます この場合 AWS DMS は JSONB データを LOB 列と同様に扱います 移行の全ロードフェーズ中 ターゲット列は NULL を許容する必要があります AWS DMS は プライマリキーを持つ PostgreSQL テーブルの変更データキャプチャ (CDC) をサポートし ています テーブルにプライマリキーがない場合 先書きログ (WAL) にはデータベース行の前イメージが 含まれていないため AWS DMS がテーブルを更新できません DB インスタンスが論理レプリケーションを使用するように設定されている場合 AWS DMS で は Amazon RDS PostgreSQL データベースでの CDC がサポートされています Amazon RDS は PostgreSQL DB インスタンスバージョン 以降および 以降の論理レプリケーションをサ ポートしています PostgreSQL データベースと AWS DMS の使用の詳細については 以下のセクションを参照してくださ い トピック AWS DMS を使用した PostgreSQL から PostgreSQL への移行 (p. 111) PostgreSQL データベースを AWS DMS のソースとして使用する場合の前提条件 (p. 113) PostgreSQL データベースを AWS DMS のソースとして使用する場合のセキュリティ要件 (p. 114) PostgreSQL データベースを AWS DMS のソースとして使用する場合の制限 (p. 114) ソースとしての Amazon RDS PostgreSQL DB インスタンスの設定 (p. 115) PostgreSQL ソースデータベースからの AWS DMS アーティファクトの削除 (p. 117) PostgreSQL データベースを AWS DMS のソースとして使用する場合の追加設定 (p. 118) AWS DMS のソースとして PostgreSQL バージョン 10.x 以降を使用する (p. 118) AWS DMS のソースとして PostgreSQL を使用する場合の追加の接続属性 (p. 119) PostgreSQL のソースデータ型 (p. 120) AWS DMS を使用した PostgreSQL から PostgreSQL への移行 PostgreSQL 以外のデータベースエンジンから PostgreSQL データベースに移行する異種移行では ほぼ 常に AWS DMS が最適な移行ツールです 一方 PostgreSQL データベースから PostgreSQL データベー スに移行する同種移行では ネイティブツールがより効果的な場合があります 以下の条件では pg_dump などのネイティブ PostgreSQL データベース移行ツールを使用することをお勧 めします ソース PostgreSQL データベースからターゲット PostgreSQL データベースに移行する同種移行であ る データベース全体を移行する ネイティブツールで最小のダウンタイムでデータを移行できる 111

118 PostgreSQL のソースとしての使用 pg_dump ユーティリティでは COPY コマンドを使用して PostgreSQL データベースのスキーマとデー タダンプを作成します pg_dump によって生成されるダンプスクリプトは 同じ名前のデータベースに データをロードし テーブル インデックス 外部キーを再作成します pg_restore コマンドと -d パ ラメータを使用して データを別の名前でデータベースに復元できます PostgreSQL データベースを Amazon RDS for PostgreSQL や Amazon Aurora (PostgreSQL) にイン ポートする詳しい方法については PostgreSQL.Procedural.Importing.html を参照してください DMS を使用した PostgreSQL から PostgreSQL へのデータの移行 AWS DMS では たとえば オンプレミスのソース PostgreSQL データベースからターゲットの Amazon RDS for PostgreSQL や Amazon Aurora(PostgreSQL) インスタンスにデータを移行できます 通 常 PostgreSQL のコアまたは基本のデータ型は正常に移行されます ソースデータベースではサポートされているが ターゲットではサポートされていないデータ型は 正常 に移行されない場合があります データ型が不明な場合 AWS DMS では一部のデータ型を文字列として ストリーミングします XML や JSON などの一部のデータ型は 小さなファイルの場合は正常に移行され ますが 大きなドキュメントの場合は失敗することがあります 次の表は ソース PostgreSQL のデータ型と これらのデータ型が正常に移行されるかどうかを示してい ます データ型 正常に移行 INTEGER X SMALLINT X BIGINT X 部分的に移行 移行されない コメント NUMERIC/DECIMAL(p,s) X 0<p<39 および 0<s NUMERIC/DECIMAL X p>38 または p=s=0 X 精度の指定なし X 精度の指定なし REAL X DOUBLE X SMALLSERIAL X SERIAL X BIGSERIAL X MONEY X CHAR CHAR(n) X VARCHAR VARCHAR(n) X TEXT X BYTEA X 112

119 PostgreSQL のソースとしての使用 データ型 TIMESTAMP 正常に移行 部分的に移行 X DATE X TIME X TIME (z) X INTERVAL X X ENUM X CIDR X INET X MACADDR X TSVECTOR X TSQUERY X XML X POINT X LINE X LSEG X BOX X PATH X POLYGON X CIRCLE X JSON コメント X TIMESTAMP(Z) BOOLEAN 移行されない X ARRAY X COMPOSITE X RANGE X PostgreSQL データベースを AWS DMS のソースとして使用する 場合の前提条件 PostgreSQL データベースを AWS DMS のソースにする場合 以下の操作を実行する必要があります バージョン 9.4.x 以降の PostgreSQL データベースを使用します PostgreSQL ソースデータベースに指定されたユーザーアカウントにスーパーユーザーアクセス許可を 付与します 113

120 PostgreSQL のソースとしての使用 AWS DMS レプリケーションサーバーの IP アドレスを pg_hba.conf 設定ファイルに追加します postgresql.conf 設定ファイルで次のパラメーターと値を設定します 設定 wal_level = logical max_replication_slots を 1 より大きい値に設定します max_replication_slots 値は 実行するタスクの数に従って設定してください たとえば 5 つ のタスクを実行するには 少なくとも 5 つのスロットを設定する必要があります スロットは タス クが開始するとすぐに自動的に開き タスクが実行されなくなった場合でも開いたままです 開いて いるスロットは手動で削除する必要があります max_wal_senders を 1 より大きい値に設定します max_wal_senders パラメーターは 実行可能な同時タスクの数を設定します 設定 wal_sender_timeout =0 wal_sender_timeout パラメーターは 指定されたミリ秒数が過ぎても非アクティブなレプリケー ション接続を終了します デフォルトは 60 秒ですが このパラメーターは 0 に設定することをお勧 めします (タイムアウトメカニズムが無効になります) PostgreSQL バージョン 9.6 以降で idle_in_transaction_session_timeout パラメータを使用す ると アイドル状態のトランザクションでタイムアウトやエラーが生じる場合があります 一部の AWS DMS トランザクションでは AWS DMS エンジンで再度そのパラメータが使用されるまでの間 しばら くアイドル状態になることがあります AWS DMS を使用する際 アイドル状態のトランザクションを 終了しないでください PostgreSQL データベースを AWS DMS のソースとして使用する 場合のセキュリティ要件 PostgreSQL をソースとして使用する場合の唯一のセキュリティ要件として 指定されるユーザーアカウ ントは PostgreSQL データベースの登録済みユーザーでなければなりません PostgreSQL データベースを AWS DMS のソースとして使用する 場合の制限 PostgreSQL を AWS DMS のソースとして使用する場合は 以下の制限が適用されます キャプチャされたテーブルにはプライマリキーが必要です テーブルにプライマリキーがない場 合 AWS DMS はそのテーブルの DELETE および UPDATE レコードオペレーションを無視します タイムゾーンの種類の列のタイムスタンプはサポートされていません AWS DMS は プライマリキーセグメントの更新の試みを無視します この場合 ターゲットは その 更新によってどの行も更新されないと識別します ただし PostgreSQL でのプライマリキーの更新結 果は予測できないため どのレコードも例外テーブルには書き込まれません AWS DMS では [Start Process Changes from Timestamp] 実行オプションがサポートされていませ ん AWS DMS では Amazon RDS for PostgreSQL での全ロードと変更処理がサポートされていま す PostgreSQL DB インスタンスを準備する方法と CDC を使用するようにそのインスタンスを設定 する方法については ソースとしての Amazon RDS PostgreSQL DB インスタンスの設定 (p. 115) を参照してください 大文字と小文字の組み合わせが異なる同じ名前 (table1 TABLE1 Table1) を持つ複数のテーブルをレ プリケートすると 予測できない動作が生じるため AWS DMS ではサポートされていません テーブルが内部関数またはプロシージャ本文ブロックに保持されているか ネストしている他の構造に 保持されている限り AWS DMS ではテーブルに対する CREATE ALTER DROP DDL ステートメン トの変更処理がサポートされています 114

121 PostgreSQL のソースとしての使用 たとえば 以下の変更はキャプチャされません CREATE OR REPLACE FUNCTION attu.create_distributors1() RETURNS void LANGUAGE plpgsql AS $$ BEGIN create table attu.distributors1(did serial PRIMARY KEY,name varchar(40) NOT NULL); END; $$; AWS DMS では TRUNCATE オペレーションの変更処理はサポートされていません OID LOB データ型は ターゲットに移行されません ソースがオンプレミスの PostgreSQL データベース または Amazon EC2 インスタンスの PostgreSQL データベースの場合は test_decoding 出力プラグイン (Postgres contrib パッケージに含む) がソー スエンドポイントにインストールされていることを確認します test-decoding プラグインの詳細につい ては PostgreSQL のドキュメント を参照してください AWS DMS では 列のデフォルト値を設定するための変更処理はサポートされていません (ALTER TABLE ステートメントでの ALTER COLUMN SET DEFAULT 句の使用) AWS DMS では 列の null 機能を設定するための変更処理はサポートされていません (ALTER TABLE ステートメントでの ALTER COLUMN [SET DROP] NOT NULL 句の使用) AWS DMS では パーティション分割されたテーブルのレプリケーションはサポートされていません パーティション分割されたテーブルが検出された場合 以下の状況が発生します エンドポイントは 親テーブルと子テーブルのリストを報告します AWS DMS は ターゲットのテーブルを 選択したテーブルと同じプロパティを持つ通常のテーブル として作成します ソースデータベースの親テーブルに子テーブルと同じプライマリキー値がある場合 重複する キー エラーが生成されます Note パーティション分割されたテーブルを PostgreSQL ソースから PostgreSQL ターゲットにレプリ ケートする場合 まずターゲットで親テーブルと子テーブルを手動で作成する必要があります 次に それらのテーブルにレプリケートする別個のタスクを定義します その場合 タスク設定 を [Truncate before loading] に設定します ソースとしての Amazon RDS PostgreSQL DB インスタンスの設 定 Amazon RDS for PostgreSQL DB インスタンスまたはリードレプリカを AWS DMS のソースとして使用で きます DB インスタンスは全ロードと CDC (継続的なレプリケーション) の両方で使用できます リード レプリカは全ロードタスクにのみ使用でき CDC に使用することはできません PostgreSQL DB インスタンス用の AWS マスターユーザーアカウントを AWS DMS の PostgreSQL ソー スエンドポイント用のユーザーアカウントとして使用します マスターユーザーアカウントには 変更 データキャプチャ (CDC) を設定するために必要なロールがあります マスターユーザーアカウント以外 のアカウントを使用する場合 アカウントには rds_superuser ロールと rds_replication ロールが必要で す rds_replication ロールは 論理スロットを管理し 論理スロットを使用してデータをストリーミング するアクセス権限を付与します DB インスタンスのマスターユーザーアカウントを使用しない場合は 使用するアカウントのマスター ユーザーアカウントから複数のオブジェクトを作成する必要があります 必要なオブジェクトの作成につ いては マスターユーザーアカウントの使用なしでの Amazon RDS for PostgreSQL データベースの移 行 (p. 116) を参照してください 115

122 PostgreSQL のソースとしての使用 RDS for PostgreSQL DB インスタンス での CDC の使用 PostgreSQL のネイティブ論理レプリケーション機能を使用して Amazon RDS PostgreSQL DB インスタ ンスのデータベースの移行中に CDC を有効にすることができます このアプローチにより ダウンタイ ムが短くなり 確実にターゲットデータベースがソース PostgreSQL データベースと同期されるようにな ります Amazon RDS は PostgreSQL DB インスタンスバージョン 以降および 以降の論理レ プリケーションをサポートしています Note Amazon RDS for PostgreSQL のリードレプリカを CDC (継続的なレプリケーション) に使用する ことはできません RDS PostgreSQL DB インスタンスに対して論理レプリケーションを有効にするには 以下の手順を実行 します 一般的に PostgreSQL DB インスタンス用の AWS マスターユーザーアカウントを PostgreSQL ソース エンドポイント用のユーザーアカウントとして使用します マスターユーザーアカウントには CDC を 設定するために必要なロールがあります マスターユーザーアカウント以外のアカウントを使用する場 合は 使用するアカウントのマスターユーザーアカウントから複数のオブジェクトを作成する必要があ ります 詳細については マスターユーザーアカウントの使用なしでの Amazon RDS for PostgreSQL データベースの移行 (p. 116) を参照してください DB パラメータグループの rds.logical_replication パラメーターを 1 に 設定します これは静的パラメータであり 有効にするには DB インスタンス の再起動が必要です このパラメータを適用する一環として AWS DMS は wal_level max_wal_senders max_replication_slots max_connections の各パラメータ を設定します これらのパラメータの変更により 生成される WAL が増えることがあるため 論理ス ロットを使用する場合にのみ rds.logical_replication パラメータを設定してください ベストプラクティスとして wal_sender_timeout パラメータを 0 に設定します このパラメーター を 0 に設定すると PostgreSQL が指定したタイムアウトを超えて非アクティブなレプリケーション接 続が終了することを防ぎます AWS DMS がデータを移行している間 レプリケーション接続は指定す るタイムアウトより長く実行できる必要があります マスターユーザーアカウントの使用なしでの Amazon RDS for PostgreSQL デー タベースの移行 Amazon RDS PostgreSQL DB インスタンス用のマスターユーザーアカウントをソースとして使用しない 場合は データ定義言語 (DDL) イベントをキャプチャするために複数のオブジェクトを作成する必要があ ります マスターアカウント以外のアカウントでこれらのオブジェクトを作成し マスターユーザーアカ ウントでトリガーを作成します Note ソースエンドポイントで captureddl パラメータを N に設定すると ソースデータベース上で 次のテーブルおよびトリガーを作成する必要はありません これらのオブジェクトを作成するには 以下の手順を実行します マスターアカウント以外のユーザーア カウントをこの手順では NoPriv アカウントと呼んでいます オブジェクトを作成するには 1. オブジェクトが作成されるスキーマを選択します デフォルトのスキーマは public です スキーマ が存在し NoPriv アカウントからアクセス可能であることを確認します NoPriv アカウントを使用して PostgreSQL DB インスタンスにログインします 以下のコマンドを実行して awsdms_ddl_audit テーブルを作成します コード内の <objects_schema> は 使用するスキーマの名前に置き換えてください 116

123 PostgreSQL のソースとしての使用 create table <objects_schema>.awsdms_ddl_audit ( c_key bigserial primary key, c_time timestamp, -- Informational c_user varchar(64), -- Informational: current_user c_txn varchar(16), -- Informational: current transaction c_tag varchar(24), -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE' c_oid integer, -- For future use - TG_OBJECTID c_name varchar(64), -- For future use - TG_OBJECTNAME c_schema varchar(64), -- For future use - TG_SCHEMANAME. For now - holds current_schema c_ddlqry text -- The DDL query associated with the current DDL event ) 4. 以下のコマンドを実行して awsdms_intercept_ddl 関数を作成します コード内の <objects_schema> は 使用するスキーマの名前に置き換えてください CREATE OR REPLACE FUNCTION <objects_schema>.awsdms_intercept_ddl() RETURNS event_trigger LANGUAGE plpgsql SECURITY DEFINER AS $$ declare _qry text; BEGIN if (tg_tag='create TABLE' or tg_tag='alter TABLE' or tg_tag='drop TABLE') then SELECT current_query() into _qry; insert into <objects_schema>.awsdms_ddl_audit values ( default,current_timestamp,current_user,cast(txid_current()as varchar(16)),tg_tag,0,'',current_schema,_qry ); delete from <objects_schema>.awsdms_ddl_audit; end if; END; $$; NoPriv アカウントからログアウトし rds_superuser ロールが割り当てられたアカウントを使用 してログインします 以下のコマンドを実行してイベントトリガー awsdms_intercept_ddl を作成します CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end EXECUTE PROCEDURE <objects_schema>.awsdms_intercept_ddl(); 前の手順を完了したら NoPriv アカウントを使用して AWS DMS ソースエンドポイントを作成できま す PostgreSQL ソースデータベースからの AWS DMS アーティファ クトの削除 DDL イベントをキャプチャするため 移行タスクの開始時に AWS DMS によりさまざまなアーティファ クトが PostgreSQL データベースに作成されます タスクが完了したら これらのアーティファクトを削 除できます アーティファクトを削除するには 以下のステートメントを発行します (示されている順序 で) AmazonRDSMigration は アーティファクトが作成されたスキーマです 117

124 PostgreSQL のソースとしての使用 drop event trigger awsdms_intercept_ddl; イベントトリガーは特定のスキーマに属していません drop function AmazonRDSMigration.awsdms_intercept_ddl() drop table AmazonRDSMigration.awsdms_ddl_audit drop schema AmazonRDSMigration Note スキーマを削除する場合でも 細心の注意を払ってください 運用中のスキーマ (特に公開スキー マ) は絶対に削除しないでください PostgreSQL データベースを AWS DMS のソースとして使用する 場合の追加設定 PostgreSQL データベースからデータを移行するときは 2 つの方法で詳細設定を追加できます 追加接続属性に値を追加して DDL イベントをキャプチャし 運用中の DDL データベースアー ティファクトが作成されたスキーマを指定します 詳細については AWS DMS のソースとして PostgreSQL を使用する場合の追加の接続属性 (p. 119) を参照してください 接続文字列パラメーターを上書きできます 以下のいずれかを行う必要がある場合は このオプション を選択します 内部 AWS DMS パラメータを指定します このようなパラメータが必要になることはめったにないた め ユーザーインターフェイスには表示されません 特定のデータベースクライアントのパススルー (passthru) 値を指定します AWS DMS では データ ベースクライアントに渡される接続文字列にパススルーパラメータが含まれています AWS DMS のソースとして PostgreSQL バージョン 10.x 以降を 使用する PostgreSQL バージョン 10.x 以降では 以前の PostgreSQL バージョンの関数名とフォルダ名に多くの変 更が加えられています そのため 一部の移行アクションには下位互換性がありません ほとんどの名前変更は表面上のものであるため AWS DMS では AWS DMS が PostgreSQL バージョン 10.x 以降を使用できるようにするラッパー関数を作成しました ラッパー関数は pg_catalog の関数 よりも優先されます さらに ユーザー定義関数などの他のシステムカタログ関数が上書きされないよう に 既存のスキーマのスキーマ可視性は変更されないようにしました 移行タスクを実行する前にこれらのラッパー関数を使用するには ソース PostgreSQL データベースで次 の SQL コードを実行します ターゲットデータベースに使用しているのと同じ AWS DMS ユーザーアカ ウントを使用します BEGIN; CREATE SCHEMA IF NOT EXISTS fnrenames; CREATE OR REPLACE FUNCTION fnrenames.pg_switch_xlog() RETURNS pg_lsn AS $$ SELECT pg_switch_wal(); $$ LANGUAGE SQL; CREATE OR REPLACE FUNCTION fnrenames.pg_xlog_replay_pause() RETURNS VOID AS $$ SELECT pg_wal_replay_pause(); $$ LANGUAGE SQL; CREATE OR REPLACE FUNCTION fnrenames.pg_xlog_replay_resume() RETURNS VOID AS $$ SELECT pg_wal_replay_resume(); $$ LANGUAGE SQL; CREATE OR REPLACE FUNCTION fnrenames.pg_current_xlog_location() RETURNS pg_lsn AS $$ SELECT pg_current_wal_lsn(); $$ LANGUAGE SQL; CREATE OR REPLACE FUNCTION fnrenames.pg_is_xlog_replay_paused() RETURNS boolean AS $$ SELECT pg_is_wal_replay_paused(); $$ LANGUAGE SQL; 118

125 PostgreSQL のソースとしての使用 CREATE OR REPLACE FUNCTION fnrenames.pg_xlogfile_name(lsn pg_lsn) RETURNS TEXT AS $$ SELECT pg_walfile_name(lsn); $$ LANGUAGE SQL; CREATE OR REPLACE FUNCTION fnrenames.pg_last_xlog_replay_location() RETURNS pg_lsn AS $$ SELECT pg_last_wal_replay_lsn(); $$ LANGUAGE SQL; CREATE OR REPLACE FUNCTION fnrenames.pg_last_xlog_receive_location() RETURNS pg_lsn AS $$ SELECT pg_last_wal_receive_lsn(); $$ LANGUAGE SQL; CREATE OR REPLACE FUNCTION fnrenames.pg_current_xlog_flush_location() RETURNS pg_lsn AS $$ SELECT pg_current_wal_flush_lsn(); $$ LANGUAGE SQL; CREATE OR REPLACE FUNCTION fnrenames.pg_current_xlog_insert_location() RETURNS pg_lsn AS $ $ SELECT pg_current_wal_insert_lsn(); $$ LANGUAGE SQL; CREATE OR REPLACE FUNCTION fnrenames.pg_xlog_location_diff(lsn1 pg_lsn, lsn2 pg_lsn) RETURNS NUMERIC AS $$ SELECT pg_wal_lsn_diff(lsn1, lsn2); $$ LANGUAGE SQL; CREATE OR REPLACE FUNCTION fnrenames.pg_xlogfile_name_offset(lsn pg_lsn, OUT TEXT, OUT INTEGER) AS $$ SELECT pg_walfile_name_offset(lsn); $$ LANGUAGE SQL; CREATE OR REPLACE FUNCTION fnrenames.pg_create_logical_replication_slot(slot_name name, plugin name, temporary BOOLEAN DEFAULT FALSE, OUT slot_name name, OUT xlog_position pg_lsn) RETURNS RECORD AS $$ SELECT slot_name::name, lsn::pg_lsn FROM pg_catalog.pg_create_logical_replication_slot(slot_name, plugin, temporary); $$ LANGUAGE SQL; ALTER <user name> USER SET search_path = fnrenames, pg_catalog, "$user", public; -- DROP SCHEMA fnrenames CASCADE; -- ALTER USER PG_User SET search_path TO DEFAULT; COMMIT; AWS DMS のソースとして PostgreSQL を使用する場合の追加の 接続属性 追加の接続属性を使用して PostgreSQL ソースを設定できます これらの設定は ソースエンドポイント を作成するときに指定します 複数の追加の接続属性の設定は セミコロンで区切る必要があります 次の表に PostgreSQL を AWS DMS のソースとして使用するときに使用できる追加の接続属性を示しま す 名前 説明 captureddl DDL イベントをキャプチャするために AWS DMS に よって タスクの開始時にさまざまなアーティファクトが PostgreSQL データベースに作成されます PostgreSQL ソースデータベースからの AWS DMS アーティファクトの削 除 (p. 117) に記載されているように これらのアーティ ファクトは後で削除できます この値が N に設定されている場合は ソースデータベース にテーブルまたはトリガーを作成する必要はありません 詳細については マスターユーザーアカウントの使用 なしでの Amazon RDS for PostgreSQL データベースの移 行 (p. 116) を参照してください ストリーミングされた DDL イベントがキャプチャされます デフォルト値: Y 有効な値: Y/N 119

126 PostgreSQL のソースとしての使用 名前 説明 例: captureddls=y 運用中の DDL データベースアーティファクトが作成されるス キーマ ddlartifactsschema デフォルト値: public 有効な値: 文字列 例: ddlartifactsschema=xyzddlschema failtasksonlobtruncation true に設定されている場合 LOB 列の実際のサイズが 指 定された LobMaxSize を上回ると この値によりタスクは失 敗します タスクが制限付き LOB モードに設定され このオプションが true に設定されている場合 LOB データを切り捨てるのでは なくタスクが失敗します デフォルト値: false 有効な値: ブール値 例: failtasksonlobtruncation=true executetimeout PostgreSQL インスタンスのクライアントステートメントタ イムアウト (秒単位) を設定します デフォルト値は 60 秒で す 例: executetimeout=100 PostgreSQL のソースデータ型 次の表に AWS DMS を使用する場合にサポートされる PostgreSQL のソースデータ型と AWS DMS の データ型とのデフォルトマッピングを示します ターゲットにマッピングされるデータ型を表示する方法については 使用しているターゲットエンドポイ ントのセクションを参照してください AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください PostgreSQL のデータ型 AWS DMS データ型 INTEGER INT4 SMALLINT INT2 BIGINT INT8 NUMERIC (p,s) 精度が 0 38 の場合 NUMERIC を使用します 精度が 39 以上の場合 STRING を使用します DECIMAL(P,S) 精度が 0 38 の場合 NUMERIC を使用します 精度が 39 以上の場合 STRING を使用します 120

127 PostgreSQL のソースとしての使用 PostgreSQL のデータ型 AWS DMS データ型 REAL REAL4 DOUBLE REAL8 SMALLSERIAL INT2 SERIAL INT4 BIGSERIAL INT8 MONEY NUMERIC(38,4) 注: MONEY データ型は SQL Server の FLOAT に マッピングされます CHAR WSTRING (1) CHAR(N) WSTRING (n) VARCHAR(N) WSTRING (n) TEXT NCLOB BYTEA BLOB TIMESTAMP TIMESTAMP TIMESTAMP (z) TIMESTAMP TIMESTAMP (タイムゾーン付き) サポート外 DATE DATE TIME TIME TIME (z) TIME INTERVAL STRING (128) 1 YEAR 2 MONTHS 3 DAYS 4 HOURS 5 MINUTES 6 SECONDS BOOLEAN CHAR (5) false または true ENUM STRING (64) CIDR STRING (50) INET STRING (50) MACADDR STRING (18) BIT (n) STRING (n) BIT VARYING (n) STRING (n) UUID STRING TSVECTOR CLOB TSQUERY CLOB XML CLOB 121

128 ソースとしての MySQL の使用 PostgreSQL のデータ型 AWS DMS データ型 POINT STRING (255) "(x,y)" LINE STRING (255) "(x,y,z)" LSEG STRING (255) "((x1,y1),(x2,y2))" BOX STRING (255) "((x1,y1),(x2,y2))" PATH CLOB "((x1,y1),(xn,yn))" POLYGON CLOB "((x1,y1),(xn,yn))" CIRCLE STRING (255) "(x,y),r" JSON NCLOB JSONB NCLOB ARRAY NCLOB COMPOSITE NCLOB HSTORE NCLOB INT4RANGE STRING (255) INT8RANGE STRING (255) NUMRANGE STRING (255) STRRANGE STRING (255) MySQL 互換データベースの AWS DMS のソースとし ての使用 AWS Database Migration Service を使用すると 任意の MySQL 互換データベース (MySQL MariaDB または Amazon Aurora MySQL) からデータを移行できます MySQL バージョン と MariaDB および Amazon Aurora MySQL は オンプレミスでサポートされています AWS が管理する すべての MySQL データベース (Amazon RDS for MySQL Amazon RDS for MariaDB Amazon Aurora MySQL) は AWS DMS でソースとしてサポートされています SSL を使用して MySQL 互換のエンドポイントとレプリケーションインスタンスとの接続を暗号化で きます MySQL 互換のエンドポイントで SSL を使用する方法の詳細については AWS Database Migration Service で SSL を使用する (p. 47) を参照してください 以降のセクションでは 自己管理型 という用語は オンプレミスまたは Amazon EC2 にインストー ルされているあらゆるデータベースに当てはまります Amazon が管理する という用語は Amazon RDS Amazon Aurora または Amazon S3 上のあらゆるデータベースに当てはまります MySQL 互換データベースと AWS DMS の使用方法の詳細については 以下のセクションを参照してくだ さい トピック AWS DMS を使用した MySQL から MySQL への移行 (p. 123) MySQL 互換データベースの AWS DMS のソースとしての使用 (p. 125) 自己管理型 MySQL 互換データベースの AWS DMS のソースとしての使用 (p. 125) 122

129 ソースとしての MySQL の使用 Amazon が管理する MySQL 互換データベースの AWS DMS のソースとしての使用 (p. 126) MySQL データベースを AWS DMS のソースとして使用する場合の制限 (p. 127) AWS DMS のソースとして MySQL を使用する場合の追加の接続属性 (p. 127) MySQL のソースデータ型 (p. 128) AWS DMS を使用した MySQL から MySQL への移行 MySQL 以外のデータベースエンジンから MySQL データベースに移行する異種移行では ほぼ常に AWS DMS が最適な移行ツールです 一方 MySQL データベースから MySQL データベースに移行する同種移 行では ネイティブツールがより効果的な場合があります 以下の条件では mysqldump などのネイティブ MySQL データベース移行ツールを使用することをお勧め します ソース MySQL データベースからターゲット MySQL データベースに移行する同種移行である データベース全体を移行する ネイティブツールで最小のダウンタイムでデータを移行できる 既存の MySQL や MariaDB データベースから Amazon RDS MySQL や MariaDB DB インスタンスにデー タをインポートできます これを行うには mysqldump を使用してデータベースをコピーし このコピー を Amazon RDS MySQL や MariaDB DB インスタンスに直接パイプします mysqldump コマンドライン ユーティリティは データのバックアップや 別の MySQL または MariaDB サーバーへの転送のためによ く使用されます このユーティリティは MySQL および MariaDB クライアントソフトウェアに含まれてい ます MySQL データベースを Amazon RDS for MySQL や Amazon Aurora (MySQL) にインポートする詳しい 方法については MySQL DB インスタンスへのデータのインポート と MySQL や MariaDB DB から Amazon RDS MySQL や MariaDB DB インスタンスへのデータのインポート を参照してください AWS DMS を使用した MySQL から MySQL へのデータの移行 AWS DMS では たとえば オンプレミスのソース MySQL データベースからターゲットの Amazon RDS for MySQL や Amazon Aurora(MySQL) インスタンスにデータを移行できます 通常 MySQL のコアまた は基本のデータ型は正常に移行されます ソースデータベースではサポートされているが ターゲットではサポートされていないデータ型は 正常 に移行されない場合があります データ型が不明な場合 AWS DMS では一部のデータ型を文字列として ストリーミングします XML や JSON などの一部のデータ型は 小さなファイルの場合は正常に移行され ますが 大きなドキュメントの場合は失敗することがあります 次の表は ソース MySQL のデータ型と これらのデータ型が正常に移行されるかどうかを示していま す データ型 正常に移行 INT X BIGINT X MEDIUMINT X TINYINT X DECIMAL(p,s) X BINARY X 部分的に移行 123 移行されない コメント

130 ソースとしての MySQL の使用 データ型 正常に移行 BIT (M) X BLOB X LONGBLOB X MEDIUMBLOB X TINYBLOB X DATE X DATETIME X TIME 部分的に移行 移行されない X TIMESTAMP X YEAR X DOUBLE X FLOAT X VARCHAR(N) X VARBINARY(N) X CHAR(N) X TEXT X LONGTEXT X MEDIUMTEXT X TINYTEXT X GEOMETRY X POINT X LINESTRING X POLYGON X MULTILINESTRING X MULTIPOLYGON X GEOMETRYCOLLECTION X ENUM X SET X 124 コメント

131 ソースとしての MySQL の使用 MySQL 互換データベースの AWS DMS のソースとしての使用 MySQL データベースを AWS DMS のソースとして使用し始める前に 次の前提条件を満たしていること を確認してください これらの前提条件は 自己管理型または Amazon が管理するソースのいずれかに適 用されます レプリケーション管理者ロールを持つ AWS DMS のアカウントを保有している必要があります ロールに は 次の権限が必要です REPLICATION CLIENT この権限は 変更データキャプチャ (CDC) タスクにのみ必要です つまり フルロードのみのタスクにはこの権限は必要ありません REPLICATION SLAVE この権限は 変更データキャプチャ (CDC) タスクにのみ必要です つまり フ ルロードのみのタスクにはこの権限は必要ありません SUPER この権限は バージョン より前の MySQL でのみ必要です AWS DMS ユーザーには レプリケーション対象に指定されたソーステーブルに対する SELECT 権限も必 要です 自己管理型 MySQL 互換データベースの AWS DMS のソースと しての使用 次の自己管理型 MySQL 互換データベースを AWS DMS のソースとして使用できます MySQL Community Edition MySQL Standard Edition MySQL Enterprise Edition MySQL Cluster Carrier Grade Edition MariaDB Community Edition MariaDB Enterprise Edition MariaDB Column Store 変更データキャプチャ (CDC) を使用する予定の場合 バイナリロギングを有効にする必要があります バ イナリロギングを有効にするには MySQL の my.ini (Windows) または my.cnf (UNIX) ファイルで以下 のパラメータを設定する必要があります パラメータ 値 server_id このパラメーターは 1 以上の値に設定します log-bin パスをバイナリログファイル (log-bin=e:\mysql_logs\binlog) に設定 します ファイル拡張子を含めないでください binlog_format このパラメーターは ROW に設定します expire_logs_days このパラメーターは 1 以上の値に設定します ディスク容量の使いすぎを 防ぐため デフォルト値の 0 は使用しないことをお勧めします binlog_checksum このパラメーターは NONE に設定します binlog_row_image このパラメーターは FULL に設定します log_slave_updates MySQL または MariaDB リードレプリカをソースとして使用している場合 は このパラメータを TRUE に設定します 125

132 ソースとしての MySQL の使用 ソースで NDB (クラスター化) データベースエンジンを使用している場合 そのストレージエンジンを使 用するテーブルで CDC を有効にするには以下のパラメータを設定する必要があります これらの変更を MySQL の my.ini (Windows) または my.cnf (UNIX) ファイルに追加します パラメータ 値 ndb_log_bin このパラメーターは ON に設定します この値により クラスター化された テーブルでの変更が確実にバイナリログに記録されます ndb_log_update_as_write このパラメーターは OFF に設定します この値に設定すると UPDATE ス テートメントが INSERT ステートメントとしてバイナリログに書き込まれな くなります ndb_log_updated_onlyこのパラメーターは OFF に設定します この値に設定すると バイナリログ に変更された列だけでなく行全体が含められます Amazon が管理する MySQL 互換データベースの AWS DMS の ソースとしての使用 次の Amazon が管理する MySQL 互換データベースを AWS DMS のソースとして使用できます MySQL Community Edition MariaDB Community Edition Amazon Aurora MySQL Amazon が管理する MySQL 互換データベースを AWS DMS のソースとして使用する場合は 次の前提条 件を満たしていることを確認してください 自動バックアップを有効にする必要があります 自動バックアップの設定の詳細については Amazon RDS ユーザーガイド の 自動バックアップの使用 を参照してください 変更データキャプチャ (CDC) を使用する予定の場合 バイナリロギングを有効にする必要がありま す Amazon RDS MySQL データベースのバイナリロギングの設定の詳細については Amazon RDS ユーザーガイド の 自動バックアップの使用 を参照してください バイナリログが AWS DMS で利用できることを確認する必要があります Amazon が管理する MySQL 互換データベースはできるだけ早くバイナリログを消去するため ログが利用可能な状態で保持される 時間を長くする必要があります たとえば ログ保持を 24 時間に伸ばすには 次のコマンドを実行し ます call mysql.rds_set_configuration('binlog retention hours', 24); binlog_formatパラメータを ROW に設定する必要があります binlog_checksum パラメータを NONE に設定する必要があります Amazon RDS MySQL でのパ ラメータの設定の詳細については Amazon RDS ユーザーガイド の 自動バックアップの使用 を 参照してください Amazon RDS MySQL または Amazon RDS MariaDB リードレプリカをソースとして使用している場 合 リードレプリカでバックアップを有効にする必要があります 126

133 ソースとしての MySQL の使用 MySQL データベースを AWS DMS のソースとして使用する場合 の制限 MySQL データベースをソースとして使用する場合 AWS DMS では以下のものがサポートされません 変更データキャプチャ (CDC) は Amazon RDS MySQL 5.5 以下ではサポートされていませ ん Amazon RDS MySQL の場合 CDC を有効にするにはバージョン 5.6 以降を使用する必要がありま す データ定義言語 (DDL) ステートメントの DROP TABLE および RENAME TABLE はサポートされませ ん さらに パーティション分割されたテーブルのすべての DDL ステートメントはサポートされませ ん ソースのパーティション分割されたテーブルで [ターゲットテーブル作成モード] を [ターゲット上の テーブルを削除] に設定すると AWS DMS は MySQL ターゲットにパーティションがないシンプルな テーブルを作成します パーティション分割されたテーブルをターゲットのパーティション分割された テーブルに移行するには ターゲット MySQL データベースでパーティション分割されたテーブルを事 前に作成します ALTER TABLE<table_name> ADD COLUMN <column_name> ステートメントを使用して テーブル (AFTER) の先頭 (FIRST) または中間に列を追加する操作はサポートされていません 列は常にテーブル の末尾に追加されます テーブル名に大文字と小文字が含まれていて 大文字と小文字が区別されるオペレーティングシステム にソースエンジンがホストされている場合 CDC はサポートされません たとえば Windows や HFS + を使用する OS X などです AR_H_USER ヘッダー列はサポートされていません 列の AUTO_INCREMENT 属性は ターゲットデータベース列に移行されません バイナリログが標準のブロックストレージに保存されている場合の変更のキャプチャはサポートされて いません たとえば バイナリログが Amazon S3 に保存されていると CDC は機能しません AWS DMS は デフォルトで InnoDB ストレージエンジンを使用してターゲットテーブルを作成しま す InnoDB 以外のストレージエンジンを使用する必要がある場合 テーブルを手動で作成し Do Nothing モードを使用してそのテーブルに移行する必要があります Aurora MySQL リードレプリカを AWS DMS のソースとして使用することはできません 全ロード時に MySQL 互換ソースが停止している場合 AWS DMS タスクはエラーで停止しません タ スクは正常に終了しますが ターゲットとソースが同期しない可能性があります この場合 タスクを 再開するか 影響を受けたテーブルを再ロードしてください 列の値の一部で作成されたインデックスは移行されません たとえば インデックス CREATE INDEX first_ten_chars ON customer (name(10)) はターゲットに作成されません 場合によっては タスクが LOB をレプリケートしないように設定されています ( SupportLobs がタ スク設定で false になっているか タスクコンソールで LOB 列を含めない がオンになっている) この場合 AWS DMS は MEDIUMBLOB LONGBLOB MEDIUMTEXT および LONGTEXT 列をター ゲットに移行しません BLOB TINYBLOB TEXT および TINYTEXT 列は影響を受けず ターゲットに移行されます AWS DMS のソースとして MySQL を使用する場合の追加の接続 属性 追加の接続属性を使用して MySQL ソースを設定できます これらの設定は ソースエンドポイントを作 成するときに指定します 複数の追加の接続属性の設定は 互いにセミコロンで区切る必要があります 次の表に Amazon RDS MySQL を AWS DMS のソースとして使用するときに使用できる追加の接続属性 を示します 127

134 ソースとしての MySQL の使用 名前 説明 eventspollinterval データベースがアイドル状態のとき バイナリログで新しい 変更/イベントをチェックする頻度を指定します デフォルト値: 5 有効な値: 1 60 例: eventspollinterval=5 この例では AWS DMS はバイナリログの変更を 5 秒ごと確 認します initstmt=set time_zone ソース MySQL データベースのタイムゾーンを指定します タイムスタンプは 指定されたタイムゾーンに変換されま す デフォルト値: UTC 有効な値: 使用するタイムゾーンの 3 文字の省略形 (UTC EST GMT など) 有効な値は ソース MySQL デー タベースをホストしているオペレーティングシステムにおけ るタイムゾーンの標準の省略形です 例: initstmt=set time_zone=utc AWS DMS がエンドポイントに接続した直後に実行するスク リプトを指定します 移行タスクは SQL ステートメント が成功するか失敗するかにかかわらず 引き続き実行されま す afterconnectscript 有効な値: セミコロンで区切られた 1 つ以上の有効な SQL ス テートメント 例: afterconnectscript=alter SESSION SET CURRENT_SCHEMA = system; CleanSrcMetadataOnMismatch 不一致が発生すると レプリケーションインスタンスのテー ブルメタデータ情報をクリーンアップして再作成します た とえば テーブルの DDL を変更すると レプリケーションイ ンスタンスにキャッシュされているテーブルに関する情報が 変更される場合があります Boolean. デフォルト値: false 例: CleanSrcMetadataOnMismatch=false MySQL のソースデータ型 次の表に AWS DMS を使用する場合にサポートされる MySQL データベースのソースデータ型と AWS DMS のデータ型からのデフォルトマッピングを示します Note UTF-8 の 4 バイト文字セット (utf8mb4) がサポートされていないため ソースデータベースでの 予期しない動作となることがあります 移行前に UTF-8 の 4 バイト文字セットを使用するデー タの変換を検討してください 128

135 ソースとしての MySQL の使用 ターゲットにマッピングされるデータ型を表示する方法については 使用しているターゲットエンドポイ ントのセクションを参照してください AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください MySQL のデータ型 AWS DMS データ型 INT INT4 MEDIUMINT INT4 BIGINT INT8 TINYINT INT1 DECIMAL(10) NUMERIC (10,0) BINARY BYTES(1) BIT BOOLEAN BIT(64) BYTES(8) BLOB BYTES(66535) LONGBLOB BLOB MEDIUMBLOB BLOB TINYBLOB BYTES(255) DATE DATE DATETIME DATETIME TIME STRING TIMESTAMP DATETIME YEAR INT2 DOUBLE REAL8 FLOAT REAL(DOUBLE) サポートされる FLOAT の範囲は -1.79E E および 2.23E E+308 で す FLOAT 値がこの範囲に収まらない場合 FLOAT データ型を STRING データが型にマッピングしま す VARCHAR(45) WSTRING (45) VARCHAR(2000) WSTRING (2000) VARCHAR(4000) WSTRING (4000) VARBINARY (4000) BYTES (4000) 129

136 SAP ASE のソースとしての使用 MySQL のデータ型 AWS DMS データ型 VARBINARY (2000) BYTES (2000) CHAR WSTRING TEXT WSTRING (65535) LONGTEXT NCLOB MEDIUMTEXT NCLOB TINYTEXT WSTRING (255) GEOMETRY BLOB POINT BLOB LINESTRING BLOB POLYGON BLOB MULTIPOINT BLOB MULTILINESTRING BLOB MULTIPOLYGON BLOB GEOMETRYCOLLECTION BLOB Note 値が ゼロ (つまり ) の DATETIME データ型と TIMESTAMP データ型が指定され ている場合 レプリケーションタスクのターゲットデータベースにより DATETIME データ型と TIMESTAMP データ型で ゼロ 値がサポートされていることを確認してください サポートさ れていない場合 これらの値はターゲットで NULL として記録されます 以下の MySQL データ型は全ロードでのみサポートされています MySQL のデータ型 AWS DMS データ型 ENUM STRING SET STRING SAP ASE データベースを AWS DMS のソースとして 使用する AWS DMS を使用すると SAP Adaptive Server Enterprise (ASE) データベース 旧 Sybase からデータ を移行できます SAP ASE データベースをソースとして使用すると サポートされている他のいずれかの AWS DMS ターゲットデータベースにデータを移行できます AWS DMS は SAP ASE バージョン 以上 および 以降をソースとしてサポートします SAP ASE データベースと AWS DMS の使用の詳細については 以下のセクションを参照してください トピック 130

137 SAP ASE のソースとしての使用 SAP ASE データベースを AWS DMS のソースとして使用する場合の前提条件 (p. 131) SAP ASE を AWS DMS のソースとして使用する場合の制限 (p. 131) SAP ASE を AWS DMS のソースとして使用する場合に必要なアクセス許可 (p. 132) 切り捨てポイントの削除 (p. 132) SAP ASE のソースデータ型 (p. 132) SAP ASE データベースを AWS DMS のソースとして使用する場 合の前提条件 SAP ASE データベースを AWS DMS のソースにする場合 以下の操作を実行します sp_setreptable コマンドを使用して テーブルで SAP ASE レプリケーションを有効にします SAP ASE データベースの RepAgent を無効にします 非ラテン文字 (例: 中国語) 用に設定された Microsoft Windows の Amazon EC2 インスタンスで SAP ASE バージョン 15.7 にレプリケートするには ターゲットコンピュータに SAP ASE 15.7 SP121 をイ ンストールします SAP ASE を AWS DMS のソースとして使用する場合の制限 SAP ASE データベースを AWS DMS のソースとして使用する場合は 以下の制限が適用されます SAP ASE データベースごとに AWS DMS タスクを 1 つのみ実行できます テーブルの名前を変更することはできません たとえば 以下のコマンドは失敗します sp_rename 'Sales.SalesRegion', 'SalesReg; 列の名前を変更することはできません たとえば 以下のコマンドは失敗します sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN'; バイナリデータ型文字列の末尾にあるゼロ値は ターゲットデータベースにレ プリケートされるときに切り捨てられます たとえば ソーステーブル内の 0x はターゲットテーブルでは 0x になります データベースのデフォルトで NULL 値が許容されない場合 NULL 値を許容しない列を持つターゲット テーブルが AWS DMS により作成されます そのため 全ロードまたは変更データキャプチャ (CDC) レプリケーションタスクに空の値が含まれる場合は AWS DMS はエラーをスローします 以下のコマ ンドを使用してソースデータベースで NULL 値を許容することにより これらのエラーを防ぐことがで きます sp_dboption <database name>, 'allow nulls by default', 'true' go use <database name> CHECKPOINT go reorg rebuild インデックスコマンドはサポートされていません クラスターはサポートされません 131

138 SAP ASE のソースとしての使用 SAP ASE を AWS DMS のソースとして使用する場合に必要なア クセス許可 SAP ASE データベースを AWS DMS タスクでソースとして使用するには AWS DMS データベース定義 で指定されたユーザーアカウントに SAP ASE データベースのアクセス許可する必要があります sa_role replication_role sybase_ts_role SAP ASE ソースエンドポイントを作成したときに [Automatically enable Sybase replication (Sybase レプリケーションを自動的に有効にする)] オプション ([アドバンスド] タブ内) を有効にした場合 は AWS DMS にストアドプロシージャ sp_setreptable を実行するアクセス許可も付与します 切り捨てポイントの削除 タスクが開始すると AWS DMS は レプリケーションプロセスが進行中であることを示す $replication_truncation_point エントリを syslogshold システムビューで確立します AWS DMS が動作している間 すでにターゲットにコピーされたデータの量に応じて レプリケーション切り捨 てポイントが定期的に進められます $replication_truncation_point エントリが確立されたら データベースログが大きくなりすぎる のを防ぐため AWS DMS タスクを実行したままにしておく必要があります AWS DMS タスクを永続的 に停止する場合 次のコマンドを発行してレプリケーション切り捨てポイントを削除します dbcc settrunc('ltm','ignore') 切り捨てポイントが削除されたら AWS DMS タスクを再開することはできません ログは 引き続き チェックポイントで自動的に切り捨てられます (自動切り捨てが設定されている場合) SAP ASE のソースデータ型 AWS DMS を使用する際にサポートされる SAP ASE ソースデータ型と AWS DMS のデータ型からの デフォルトマッピングについては 次のテーブルを参照してください AWS DMS は ユーザー定義型 (UDT) のデータ型の列を持つ SAP ASE ソーステーブルをサポートしていません このデータ型のレプリ ケートされた列は NULL として作成されます ターゲットにマッピングされるデータ型を表示する方法については ターゲットエンドポイントの デー タ移行のターゲット (p. 146) セクションを参照してください AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください SAP ASE のデータ型 AWS DMS データ型 BIGINT INT8 BINARY BYTES BIT BOOLEAN CHAR STRING DATE DATE 132

139 ソースとしての MongoDB の使用 SAP ASE のデータ型 AWS DMS データ型 DATETIME DATETIME DECIMAL NUMERIC DOUBLE REAL8 FLOAT REAL8 IMAGE BLOB INT INT4 MONEY NUMERIC NCHAR WSTRING NUMERIC NUMERIC NVARCHAR WSTRING REAL REAL4 SMALLDATETIME DATETIME SMALLINT INT2 SMALLMONEY NUMERIC TEXT CLOB TIME TIME TINYINT UINT1 UNICHAR UNICODE CHARACTER UNITEXT NCLOB UNIVARCHAR UNICODE VARBINARY BYTES VARCHAR STRING AWS DMS のソースとしての MongoDB の使用 AWS DMS は データベースソースとして MongoDB のバージョン 2.6.x 3.x をサポートします MongoDB を初めてお使いの方のために 以下の MongoDB データベースの概念について説明します MongoDB のレコードは フィールドと値のペアで構成されるデータ構造であるドキュメントです フィールドの値には 他のドキュメント 配列 ドキュメントの配列を含めることができます ドキュ メントは リレーショナルデータベーステーブルの行とほぼ同等です MongoDB のコレクションはドキュメントのグループであり リレーショナルデータベーステーブルと ほぼ同等です 内部的には MongoDB ドキュメントは ドキュメント内の各フィールドのタイプを含む 圧縮形式で バイナリ JSON (BSON) ファイルとして格納されます 各ドキュメントには一意の ID があります 133

140 ソースとしての MongoDB の使用 AWS DMS は MongoDB をソースとして使用する場合 次の 2 つの移行モードをサポートしていま す MongoDB エンドポイントを作成するときに AWS マネジメントコンソールまたは追加の接続属性 nestinglevel を使用して [メタデータモード] パラメータを使用して移行モードを指定します 移行 モードの選択は 以下に説明するように ターゲットデータの結果の形式に影響します ドキュメントモード ドキュメントモードでは MongoDB ドキュメントは 現状のまま 移行されます これは その中 のドキュメントデータが _doc という名前のターゲットテーブルの 1 つの列と見なされることを意 味します MongoDB をソースエンドポイントとして使用する場合のデフォルト設定はドキュメント モードです たとえば mycollection という MongoDB コレクションの次のドキュメントを考えてみましょう > db.mycollection.find() "_id" : ObjectId("5a94815f40bd44d1b02bdfe0"), "a" : 1, "b" : 2, "c" : 3 "_id" : ObjectId("5a94815f40bd44d1b02bdfe1"), "a" : 4, "b" : 5, "c" : 6 ドキュメントモードを使用してデータをリレーショナルデータベーステーブルに移行した後 データ は以下のように構成されます MongoDB ドキュメントのデータフィールドは _doc 列に統合されて います oid_id _doc 5a94815f40bd44d1b02bdfe0 "a" : 1, "b" : 2, "c" : 3 5a94815f40bd44d1b02bdfe1 "a" : 4, "b" : 5, "c" : 6 オプションで 追加の接続属性 extractdocid を true に設定して プライマリキーとして動作す る "_id" という名前の 2 つ目の列を作成できます 変更データキャプチャ (CDC) を使用する場 合 このパラメータを true に設定する必要があります ドキュメントモードでは AWS DMS は コレクションの作成と名前の変更を次のように管理しま す 新しいコレクションをソースデータベースに追加すると AWS DMS はコレクションの新しいター ゲットテーブルを作成し すべてのドキュメントをレプリケートします ソースデータベースで既存のコレクションの名前を変更すると AWS DMS はターゲットテーブル の名前を変更しません テーブルモード テーブルモードでは AWS DMS は MongoDB ドキュメントのそれぞれの最上位フィールドをター ゲットテーブルの列に変換します フィールドがネストされている場合 AWS DMS はネストされた 値を単一の列にフラット化します 次に AWS DMS は ターゲットテーブルのカラムセットにキー フィールドとデータ型を追加します 各 MongoDB ドキュメントについては AWS DMS はターゲットテーブルの列セットに各キーとタイ プを追加します たとえば テーブルモードを使用すると AWS DMS は前の例を次のテーブルに移 行します oid_id a b c 5a94815f40bd44d1b02bdfe a94815f40bd44d1b02bdfe

141 ソースとしての MongoDB の使用 入れ子の値は ドット区切りのキー名を含む列にフラット化されます 列は ピリオドで区切られ たフラット化されたフィールド名の連結と呼ばれます たとえば AWS DMS は "a" : "b" : "c": 1 のようなネストされた値のフィールドを持つ JSON ドキュメントを a.b.c. という名前 の列に移行します ターゲット列を作成するために テーブルモードでは AWS DMS は 指定数のMongoDB ドキュ メントをスキャンして すべてのフィールドおよびタイプのセットを作成します その後 AWS DMS はこのセットを使用して ターゲットテーブルの列を作成します コンソールを使用して MongoDB ソースエンドポイントを作成または変更する場合は スキャンするドキュメントの数を指 定できます デフォルト値は 1000 ドキュメントです AWS CLI を使用する場合は 追加の接続属性 docstoinvestigate を使用できます テーブルモードでは AWS DMS は ドキュメントとコレクションを次のように管理します 既存のコレクションにドキュメント (行) を追加する場合は ドキュメントがレプリケートされま す ターゲットに存在しないフィールドがある場合 それらのフィールドはレプリケーションされ ません ドキュメントを更新すると 更新されたドキュメントはレプリケートされます ターゲットに存在 しないフィールドがある場合 それらのフィールドはレプリケーションされません ドキュメントの削除は完全にサポートされています CDC タスクの実行中に新しいコレクションを追加しても ターゲット上に新しいテーブルは作成さ れません コレクションの名前を変更することはできません AWS DMS のソースとして MongoDB を使用する場合に必要なア クセス許可 MongoDB ソースを使用した AWS DMS の移行では ルート権限を持つユーザーアカウントを作成する か 移行するデータベースに対してのみアクセス許可を持つユーザーを作成することができます 次のコードは ルートアカウントとなるユーザーを作成します use admin db.createuser( user: "root", pwd: "<password>", roles: [ role: "root", db: "admin" ] ) 次のコードは 移行するデータベースに対して最小限の権限を持つユーザーを作成します use <database_to_migrate> db.createuser( user: "<dms-user>", pwd: "<password>", roles: [ role: "read", db: "local", "read"] ) 変更データキャプチャ (CDC) の MongoDB レプリカセットの設定 MongoDB で継続的なレプリケーションまたは変更データキャプチャ (CDC) を使用するには AWS DMS が MongoDB オペレーションログ (oplog) にアクセスする必要があります レプリカセットが存在しな 135

142 ソースとしての MongoDB の使用 い場合に oplog を作成するには レプリカセットをデプロイする必要があります 詳細については MongoDB のドキュメントを参照してください ソースエンドポイントとして設定された MongoDB レプリカのプライマリまたはセカンダリノードを持つ CDC を使用することができます スタンドアロンインスタンスをレプリカセットに変換するには 1. コマンドラインを使用して mongo に接続します mongo localhost 2. mongod サービスを停止します service mongod stop 3. 次のコマンドを使用して mongod を再起動します mongod --replset "rs0" --auth -port <port_number> 4. 次のコマンドを使用して レプリカセットへの接続をテストします mongo -u root -p <password> --host rs0/localhost:<port_number> --authenticationdatabase "admin" ドキュメントモードの移行を実行する予定がある場合は MongoDB エンドポイントを作成するときに _id as a separate column オプションを選択します このオプションを選択すると プライマリ キーとして機能する _id という名前の 2 番目の列が作成されます この 2 番目の列は AWS DMS が データ操作言語 (DML) オペレーションをサポートするために必要です AWS DMS のソースとして MongoDB を使用する場合のセキュリティ要件 AWS DMS は MongoDB で 2 つの認証方法をサポートしています この 2 つの認証方法はパスワードを 暗号化する際に使用するため authtype パラメータが PASSWORD に設定されているときにのみ使用さ れます MongoDB の認証方法は次のとおりです MONOGODB-CR MongoDB 2.x 認証を使用する場合のデフォルトです SCRAM-SHA-1 MongoDB バージョン 3.x 認証を使用する場合のデフォルトです 認証方法が指定されていない場合 AWS DMS は MongoDB ソースのバージョンのデフォルトの方法を 使用します MongoDB を AWS DMS のソースとして使用する場合の制限 MongoDB を AWS DMS のソースとして使用する場合の制限は次のとおりです _id オプションが別の列として設定されている場合 ID 文字列は 200 文字以下でなければなりません オブジェクト ID および配列タイプキーは テーブルモードで oid および array というプレフィックス が付けられた列に変換されます 内部的には これらの列はプレフィックスが付けられた名前で参照されます これらの列を参 照する変換ルールを AWS DMS で使用する場合は プレフィックス列を指定する必要があり ます たとえば $_id ではなく $oid id を指定するか $_addresses ではなく $array addresses を指定します 136

143 ソースとしての MongoDB の使用 コレクション名にドル記号 ($) を含めることはできません 前述のように テーブルモードとドキュメントモードには制限があります AWS DMS のソースとして MongoDB を使用する場合の追加の接続属性 ソースエンドポイントとして MongoDB を設定した場合 追加の接続属性を指定できます 追加の接続属 性はキーと値のペアを指定して セミコロンで区切ります 次のテーブルで AWS DMS のソースとして MongoDB データベースを使用する場合に利用可能な追加の 接続属性について説明します 属性名 有効な値 デフォルト値と説明 authtype NO PASSWORD NO が選択される場合 ユーザー名およびパ スワードのパラメータは使用されず 空白にできます PASSWORD authmechanism DEFAULT MONGODB_CR SCRAM_SHA_1 nestinglevel なし DEFAULT MongoDB バージョン 2.xで は MONGODB_CR を使用します MongoDB バージョ ン 3.x では SCRAM_SHA_1 を使用します この属性 は authtype=no の場合使用されません NONE ドキュメントモードを使用するには NONE を指定 します テーブルモードを使用するには ONE を指定しま す 1 extractdocid true false nestinglevel が NONE に設定されている場合 この属性を使用します false docstoinvestigate 0 より大きい正の整数 1000 nestinglevel が ONE に設定されている場合 こ の属性を使用します authsource 有効な MongoDB デー タベース名を指定して ください admin この属性は authtype=no の場合使用されませ ん MongoDB のソースデータ型 AWS DMS のソースとして MongoDB を使用するデータ移行では ほとんどの MongoDB データ型がサ ポートされます 次のテーブルに AWS DMS を使用する場合にサポートされる MongoDB のソースデー タ型と AWS DMS のデータ型からのデフォルトマッピングを示します MongoDB データ型の詳細につ いては MongoDB のドキュメント の BSON 型 を参照してください ターゲットにマッピングされるデータ型を表示する方法については 使用しているターゲットエンドポイ ントのセクションを参照してください AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください MongoDB データ型 AWS DMS データ型 Boolean Bool バイナリ BLOB 137

144 Amazon S3 のソースとしての使用 MongoDB データ型 AWS DMS データ型 改訂日 改訂日 タイムスタンプ 改訂日 Int INT4 Long INT8 Double REAL8 String (UTF-8) CLOB 配列 CLOB OID 文字列 REGEX CLOB CODE CLOB AWS DMS ソースとしての Amazon S3 の使用 Amazon S3 を使用して AWS DMS バケットからデータを移行できます これを行うには 1 つ以上のデー タファイルを含む S3 バケットへのアクセス権を提供します その S3 バケットに データおよびそれらの ファイルのデータのデータベーステーブル間のマッピングを記述する JSON ファイルを含めます 全ロードを開始する前に ソースデータファイルが S3 バケットに存在している必要があります バケッ ト名は bucketname パラメータを使用して指定します ソースデータファイルはカンマ区切り値 (CSV) 形式である必要があります 次に示す命名規則を使用し て名前を付けます この規則では schemaname がソーススキーマで tablename がそのスキーマ内の テーブルの名前です /schemaname/tablename/load001.csv /schemaname/tablename/load002.csv /schemaname/tablename/load003.csv... たとえば データファイルが次の S3 パスの mybucket にあるとします s3://mybucket/hr/employee ロード時に AWS DMS はソーススキーマ名が hr で ソーステーブル名が employee であると想定しま す bucketname (必須) に加えて オプションで bucketfolder パラメータを提供し AWS DMS が S3 バ ケットでデータファイルを探す場所を指定します 前の例を続けると bucketfolder を sourcedata に 設定した場合 AWS DMS は次のパスでデータファイルを読み取ります s3://mybucket/sourcedata/hr/employee 追加の接続属性を使用して 列の区切り文字 行の区切り文字 null 値のインジケータ およびその 他のパラメータを指定できます 詳細については AWS DMS のソースとしての S3 の追加の接続属 性 (p. 142) を参照してください 138

145 Amazon S3 のソースとしての使用 AWS DMS のソースとしての S3 用の外部テーブルの定義 データファイルに加えて 外部テーブル定義も指定する必要があります 外部テーブル定義は AWS DMS が S3 からのデータを解釈する方法について説明する JSON ドキュメントです このドキュメントの 最大サイズは 2 MB です AWS DMS マネジメントコンソールを使用してソースエンドポイントを作成す る場合 JSON を直接テーブルマッピングボックスに入力できます AWS Command Line Interface (AWS CLI) または AWS DMS API を使用して移行を実行する場合は JSON ファイルを作成して外部テーブル定 義を指定することができます 以下のものが含まれるデータファイルがあるとします 101,Smith,Bob,4-Jun-14,New York 102,Smith,Bob,8-Oct-15,Los Angeles 103,Smith,Bob,13-Mar-17,Dallas 104,Smith,Bob,13-Mar-17,Dallas このデータ用の外部テーブル定義の例を次に示します "TableCount": "1", "Tables": [ "TableName": "employee", "TablePath": "hr/employee/", "TableOwner": "hr", "TableColumns": [ "ColumnName": "Id", "ColumnType": "INT8", "ColumnNullable": "false", "ColumnIsPk": "true", "ColumnName": "LastName", "ColumnType": "STRING", "ColumnLength": "20", "ColumnName": "FirstName", "ColumnType": "STRING", "ColumnLength": "30", "ColumnName": "HireDate", "ColumnType": "DATETIME", "ColumnName": "OfficeLocation", "ColumnType": "STRING", "ColumnLength": "20" ], "TableColumnsTotal": "5" ] この JSON ドキュメントの要素は次のとおりです TableCount ソーステーブルの数 この例では テーブルは 1 つしかありません 139

146 Amazon S3 のソースとしての使用 Tables ソーステーブルあたり 1 つの JSON マップで構成される配列 この例では マップは 1 つし かありません 各マップは以下の要素で構成されています TableName ソーステーブルの名前 TablePath AWS DMS が全データロードファイルを見つけることができる S3 バケット内のパ ス bucketfolder の値を指定した場合 この値がパスの先頭に付加されます TableOwner このテーブルのスキーマ名 TableColumns 1 つ以上のマップの配列 それぞれがソーステーブルの列について説明します ColumnName ソーステーブルの列の名前 ColumnType 列のデータ型 有効なデータ型については Amazon S3 のソースデータ 型 (p. 142) を参照してください ColumnLength この列のバイト数 ColumnNullable (オプション) この列に NULL 値を含めることができる場合 true であるブール 値 ColumnIsPk (オプション) この列がプライマリキーの一部である場合 true であるブール値 TableColumnsTotal 列のリクエストの総数 この番号は TableColumns 配列内の要素数と一致 している必要があります 前述の例では 列の一部の型は STRING 型です この場合は ColumnLength 要素を使用して最大文字 数を指定します ColumnLength は 以下のデータ型に適用されます BYTE STRING 他に指定がない限り AWS DMS では ColumnLength がゼロであることが想定されます NUMERIC 型の列の場合は 精度とスケールを指定する必要があります 精度は数値の桁の合計数 であり スケールは小数点以下の桁数です 次に示すように これには ColumnPrecision および ColumnScale 要素を使用します "ColumnName": "HourlyRate", "ColumnType": "NUMERIC", "ColumnPrecision": "5" "ColumnScale": "2" S3 のソースとしての CDC と AWS DMS の使用 AWS DMS による全データロードの後で オプションでターゲットエンドポイントにデータの変更をレプ リケートできます これを行うには S3 バケットに変更データキャプチャファイル (CDC ファイル) を アップロードします AWS DMS は アップロード時にこれらの CDC ファイルを読み取り ターゲット エンドポイントで変更を適用します CDC ファイルは次のように名前が付けられます CDC00001.csv CDC00002.csv CDC00003.csv 140

147 Amazon S3 のソースとしての使用... AWS DMS がファイルを見つけることができる場所を示すには cdcpath パラメータを指定する必要が あります 前の例を続けると cdcpath を changedata に設定した場合 AWS DMS は次のパスで CDC ファイルを読み取ります s3://mybucket/changedata CDC ファイル内のレコードは次のような形式になります オペレーション 実行する変更オペレーション: INSERT UPDATE または DELETE これらのキー ワードでは大文字小文字を区別します テーブル名 ソーステーブルの名前 スキーマ名 ソーススキーマの名前 データ 変更するデータを表す 1 つまたは複数の列 employee という名前のテーブルの CDC ファイルの例を次に示します INSERT,employee,hr,101,Smith,Bob,4-Jun-14,New York UPDATE,employee,hr,101,Smith,Bob,8-Oct-15,Los Angeles UPDATE,employee,hr,101,Smith,Bob,13-Mar-17,Dallas DELETE,employee,hr,101,Smith,Bob,13-Mar-17,Dallas AWS DMS のソースとして S3 を使用する場合の前提条件 AWS DMS のソースとして S3 を使用する場合 使用するソース S3 バケットは データを移行するために 使用する AWS DMS レプリケーションインスタンスと同じ AWS リージョンに存在している必要がありま す また 移行に使用する AWS アカウントには ソースバケットへの読み取りアクセス権も必要です 移行タスクを作成するために使用されるユーザーアカウントに割り当てられる AWS Identity and Access Management (IAM) ロールは 次の一連のアクセス許可が必要です "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "s3:getobject" ], "Resource": [ "arn:aws:s3:::mybucket*" ], "Effect": "Allow", "Action": [ "s3:listbucket" ], "Resource": [ "arn:aws:s3:::mybucket*" ] ] 141

148 Amazon S3 のソースとしての使用 AWS DMS のソースとしての S3 の追加の接続属性 追加の接続属性として次のオプションを指定できます オプション 説明 bucketfolder (オプション) S3 バケットのフォルダ名 この属性を指定 すると ソースデータファイルおよび CDC ファイルがパス bucketfolder/ schemaname/tablename/ から読み取られます この属性が指定されない 場合 使用されるパスは schemaname/tablename/ となります 以下に例 を示します bucketfolder=testfolder; bucketname S3 バケットの名前 以下に例を示します bucketname=buckettest; cdcpath 変更データキャプチャ (CDC) ファイルの場所 タスクで変更データをキャ プチャする場合 この属性が必須です それ以外の場合はオプションで す cdcpath が存在する場合 AWS DMS はこのパスから CDC ファイ ルを読み取り データ変更をターゲットエンドポイントにレプリケートし ます 詳細については S3 のソースとしての CDC と AWS DMS の使 用 (p. 140) を参照してください 以下に例を示します cdcpath=datachanges; csvrowdelimiter ソースファイル内の行を分離するために使用される区切り文字 デフォルト は改行 (\n) です 以下に例を示します csvrowdelimiter=\n; csvdelimiter ソースファイル内の列を分離するために使用される区切り文字 デフォルト ではカンマを使用します 以下に例を示します csvdelimiter=,; externaltabledefinition AWS DMS が移行中に S3 バケットのデータを解釈する方法を説明する JSON オブジェクト 詳細については AWS DMS のソースとしての S3 用の外 部テーブルの定義 (p. 139) を参照してください 以下に例を示します externaltabledefinition=<json_object> ignoreheaderrows 1 に設定すると AWS DMS は CSV ファイルの最初の行ヘッダーを無視しま す 値が 1 の場合は機能が有効になり 値が 0 の場合は機能が無効になりま す デフォルトは 0 です ignoreheaderrows=1 Amazon S3 のソースデータ型 AWS DMS のソースとして Amazon S3 を使用するデータ移行では S3 から AWS DMS データ型にデータ をマッピングする必要があります 詳細については AWS DMS のソースとしての S3 用の外部テーブ ルの定義 (p. 139) を参照してください ターゲットにマッピングされるデータ型を表示する方法については 使用しているターゲットエンドポイ ントのセクションを参照してください 142

149 Amazon S3 のソースとしての使用 AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください AWS DMS データ型 ソースとしての Amazon S3 BYTE ColumnLength が必須です 詳細については AWS DMS のソースとしての S3 用の外部テーブルの 定義 (p. 139) を参照してください DATE TIME DATETIME TIMESTAMP INT1 INT2 INT4 INT8 NUMERIC ColumnPrecision および ColumnScale が必須です 詳細については AWS DMS のソースとして の S3 用の外部テーブルの定義 (p. 139) を参照してください REAL4 REAL8 STRING ColumnLength が必須です 詳細については AWS DMS のソースとしての S3 用の外部テーブルの 定義 (p. 139) を参照してください UINT1 UINT2 UINT4 UINT8 BLOB CLOB BOOLEAN 143

150 IBM Db2 をソースとして使用する AWS DMS のソースとして Linux Unix および Windows データベース用の IBM Db2 (Db2 LUW) を使 用する AWS DMS (AWS DMS) を使用して Linux Unix および Windows 用の IBM Db2 (Db2 LUW) データベー スから サポートされているすべてのターゲットデータを移行できます AWS DMS は 移行ソースとし て次の Db2 LUW バージョンをサポートしています バージョン 9.7 すべての Fix Pack がサポートされています バージョン 10.1 すべての Fix Pack がサポートされています Version 10.5 Fix Pack 5 を除くすべての Fix Pack がサポートされています SSL を使用して Db2 LUW エンドポイントとレプリケーションインスタンスとの接続を暗号化できま す AWS DMS エンジンバージョン 以上を使用して SSL を使用する必要があります Db2 LUW エ ンドポイントで SSL を使用する方法の詳細については AWS Database Migration Service で SSL を使 用する (p. 47) を参照してください AWS DMS のソースとして Db2 LUW を使用する場合の前提条件 Db2 LUW データベースをソースとして使用する前に 次の前提条件が必要です 変更データキャプチャ (CDC) とも呼ばれる継続的なレプリケーションを有効にするには 次を実行する必 要があります データベースを回復可能に設定する必要があります 変更をキャプチャするには AWS DMS は データベースが回復可能に構成されている必要があります データベース設定パラメータの LOGARCHMETH1 および LOGARCHMETH2 のいずれかまたは両方が ON に設定されている場合 デー タベースは回復可能です ユーザーアカウントには 次のアクセス権限が付与されている必要があります SYSADM または DBADM DATAACCESS Db2 LUW を AWS DMS のソースとして使用する場合の制限 クラスター化データベースはサポート外です ただし クラスタの各エンドポイントに個別の Db2 LUW を定義することができます 詳細については IBM Db2 LUW のドキュメントを参照してください 継続的なレプリケーション (CDC) を使用する場合は 次の制限が適用されます 複数のパーティションを持つテーブルを切り捨てると AWS DMS コンソールに表示される DDL イベン トの数は パーティションの数に等しくなります これは Db2 LUW がパーティションごとに個別の DDL を記録するためです 次の DDL アクションは 分割されたテーブルではサポート外です ALTER TABLE ADD PARTITION ALTER TABLE DETACH PARTITION ALTER TABLE ATTACH PARTITION DECFLOAT データ型はサポート外です したがって DECFLOAT 列への変更は 継続的なレプリケー ション中は無視されます RENAME COLUMN ステートメントはサポート外です 144

151 IBM Db2 をソースとして使用する MDC (多次元クラスタリング) テーブルの更新を実行すると それぞれの更新は AWS DMS コンソール に INSERT + DELETE として表示されます タスクの設定 [レプリケーションに LOB 列を含める] が無効になっていると LOB 列を持つテーブル は 継続的なレプリケーション中に中断されます 監査テーブルオプションが有効な場合 監査テーブルの最初のタイムスタンプレコードは NULL になり ます テーブルを変更するオプションを有効にすると テーブルの最初のタイムスタンプレコードはゼロにな ります (つまり :00: ) Db2 LUW バージョン 10.5 以上の場合: 行外に格納されたデータを含む可変長文字列列は無視されま す この制限は 行サイズを拡張して作成されたテーブルにのみ適用されます AWS DMS のソースとして Db2 LUW を使用する場合の追加の接 続属性 追加の接続属性を使用して Db2 LUW ソースを設定できます これらの設定は ソースエンドポイントを 作成するときに指定します 複数の追加の接続属性の設定は セミコロンで区切る必要があります 次の表に Db2 LUW でソースとして使用できる追加の接続属性を示します 名前 説明 MaxKBytesPerRead 読み取りあたりの最大バイト数 NUMBER 値です デフォル トは 64 KB です SetDataCaptureChanges 継続的なレプリケーション (変更データキャプチャ) をブール 値として有効にします デフォルトは true です IBM Db2 LUW のソースデータ型 Db2 LUW を AWS DMS のソースとして使用するデータ移行では ほとんどの Db2 LUW データ型がサ ポートされます 次の表に AWS DMS を使用する場合にサポートされる Db2 LUW のソースデータ型 と AWS DMS のデータ型からのデフォルトマッピングを示します Db2 LUW データ型の詳細について は Db2 LUW のドキュメント を参照してください ターゲットにマッピングされるデータ型を表示する方法については 使用しているターゲットエンドポイ ントのセクションを参照してください AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください Db2 LUW データ型 AWS DMS データ型 INTEGER INT4 SMALLINT INT2 BIGINT INT8 DECIMAL (p,s) NUMERIC (p,s) FLOAT REAL8 DOUBLE REAL8 REAL REAL4 145

152 データ移行のターゲット Db2 LUW データ型 AWS DMS データ型 DECFLOAT (p) If precision = 16, then: REAL8 If precision is = 34, then: STRING GRAPHIC WSTRING n<=127 VARGRAPHIC WSTRING n<=16k double byte chars LONG VARGRAPHIC CLOB CHAR(n) STRING n<=255 VARCHAR(n) STRING n<=32k LONG VARCHAR (n) CLOB n<=32k CHAR (n) FOR BIT DATA BYTES VARCHAR (n) FOR BIT DATA BYTES LONG VARCHAR FOR BIT DATA BYTES DATE DATE TIME TIME TIMESTAMP DATETIME BLOB BLOB CLOB CLOB Maximum size: 2 GB DBCLOB CLOB Maximum size: 1 G double byte chars XML CLOB データ移行のターゲット AWS Database Migration Service (AWS DMS) では 最もよく利用されているデータベースの多くをデー タレプリケーションのターゲットとして使用できます ターゲットには Amazon Elastic Compute Cloud 146

153 データ移行のターゲット (Amazon EC2) インスタンス Amazon Relational Database Service (Amazon RDS) インスタンス また はオンプレミスデータベースを使用できます Note ソースストレージエンジン (MyISAM MEMORY など) にかかわらず AWS DMS によってデ フォルトで InnoDB テーブルとして MySQL 互換のターゲットテーブルが作成されます InnoDB 以外のストレージエンジンを使用するテーブルが必要な場合は 手動でテーブルを MySQL 互換 のターゲットで作成し "Do Nothing" モードで移行できます "Do Nothing" モードの詳細につい ては 全ロードタスク設定 (p. 207) を参照してください データベースには次のものが含まれます オンプレミスおよび EC2 インスタンスデータベース Enterprise Standard Standard One および Standard Two エディションの Oracle バージョン 10g 11g 12c Enterprise Standard Workgroup および Developer エディションの Microsoft SQL Server バージョ ン R および 2016.Web および Express エディションはサポートさ れていません MySQL バージョン MariaDB (MySQL 互換データターゲットとしてサポートされています) PostgreSQL バージョン 9.4 以降 SAP Adaptive Server Enterprise (ASE) バージョン 以降 Amazon RDS インスタンスのデータベース Amazon Redshift Amazon S3 および Amazon DynamoDB Amazon RDS Oracle バージョン 11g (バージョン v1 以降) および 12c (Enterprise Standard Standard One Standard Two エディション) Amazon RDSEnterprise Standard Workgroup および Developer エディションの Microsoft SQL Server バージョン 2008R Web および Express エディションはサポートされていませ ん Amazon RDSMySQL バージョン Amazon RDS MariaDB (MySQL 互換データターゲットとしてサポートされています) Amazon RDSPostgreSQL バージョン 9.4 以降 MySQL と互換性がある Amazon Aurora PostgreSQL との互換性を持つ Amazon Aurora Amazon Redshift Amazon S3 Amazon DynamoDB トピック AWS Database Migration Service のターゲットとしての Oracle データベースの使用 (p. 148) AWS Database Migration Service のターゲットとしての Microsoft SQL Server データベースの使 用 (p. 152) AWS Database Migration Service のターゲットとしての PostgreSQL データベースの使用 (p. 156) AWS Database Migration Service のターゲットとしての MySQL 互換データベースの使用 (p. 159) AWS Database Migration Service のターゲットとしての Amazon Redshift データベースの使 用 (p. 163) AWS Database Migration Service のターゲットとしての SAP ASE データベースの使用 (p. 170) AWS Database Migration Service のターゲットとしての Amazon S3 の使用 (p. 171) 147

154 Oracle のターゲットとしての使用 AWS Database Migration Service のターゲットとしての Amazon DynamoDB データベースの使 用 (p. 175) AWS Database Migration Service のターゲットとして の Oracle データベースの使用 AWS DMS を使用して別の Oracle データベースまたはサポートされている他のいずれかのデータベース から Oracle データベースターゲットにデータを移行できます Secure Sockets Layer (SSL) を使用し て Oracle エンドポイントとレプリケーションインスタンスとの接続を暗号化できます Oracle エンド ポイントで SSL を使用する方法の詳細については AWS Database Migration Service で SSL を使用す る (p. 47) を参照してください AWS DMS では オンプレミスおよび EC2 インスタンスにおいて Enterprise Standard Standard One および Standard Two エディションの Oracle バージョン 10g 11g および12c がターゲッ トとしてサポートされています AWS DMS では Amazon RDS インスタンスデータベース用の Enterprise Standard Standard One および Standard Two エディションの Oracle バージョン 11g (バージョン v1 以降) および 12c がサポートされています Oracle をターゲットとして使用するときは ターゲット接続に使用されるスキーマまたはユーザーにデー タを移行することを前提とします 別のスキーマにデータを移行する場合は スキーマ変換を使用する 必要があります たとえば ターゲットエンドポイントがユーザー RDSMASTER に接続しており ユー ザー PERFDATA から PERFDATA に移行したいとします この場合 次のように変換を作成します "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "rule-action": "rename", "rule-target": "schema", "object-locator": "schema-name": "PERFDATA", "value": "PERFDATA" 変換の詳細については JSON を使用するテーブルマッピングによりテーブル選択および変換を指定す る (p. 229) を参照してください AWS DMS のターゲットとしての Oracle データベースの使用の詳細については 以下のセクションを参照 してください トピック AWS Database Migration Service のターゲットとして Oracle を使用する場合の制限 (p. 148) ターゲットとして Oracle を使用する場合に必要なユーザーアカウント権限 (p. 149) AWS Database Migration Service のターゲットとしての Oracle データベースの設定 (p. 150) AWS DMS のターゲットとして Oracle を使用する場合の追加の接続属性 (p. 150) Oracle のターゲットデータ型 (p. 151) AWS Database Migration Service のターゲットとして Oracle を 使用する場合の制限 データ移行のターゲットとして Oracle を使用する場合の制限は 以下のとおりです 148

155 Oracle のターゲットとしての使用 AWS DMS は ターゲット Oracle データベースにスキーマを作成しません 必要なすべてのスキーマ をターゲット Oracle データベースで作成する必要があります Oracle ターゲットのスキーマ名がすで に存在している必要があります ソーススキーマのテーブルは AWS DMS がターゲットインスタンス への接続に使用するユーザー/スキーマにインポートされます 複数のスキーマに移行する必要がある場 合 複数のレプリケーションタスクを作成する必要があります AWS DMS では テーブルに INDEXTYPE CONTEXT を使用する場合に Use direct path full load オプションがサポートされていません 回避策として 配列ロードを使用できます 最適化バッチ適用モードでは 差分変更テーブルへのロードに XMLType をサポートしない直接パスが 使用されます 回避策として トランザクション適用モードを使用できます ターゲットとして Oracle を使用する場合に必要なユーザーアカ ウント権限 AWS Database Migration Service タスクで Oracle ターゲットを使用するには AWS DMS Oracle データ ベース定義で指定されているユーザーアカウントに Oracle データベースにおける次の権限を付与する必 要があります SELECT ANY TRANSACTION V$NLS_PARAMETERS での SELECT V$TIMEZONE_NAMES での SELECT ALL_INDEXES での SELECT ALL_OBJECTS での SELECT DBA_OBJECTS での SELECT ALL_TABLES での SELECT ALL_USERS での SELECT ALL_CATALOG での SELECT ALL_CONSTRAINTS での SELECT ALL_CONS_COLUMNS での SELECT ALL_TAB_COLS での SELECT ALL_IND_COLUMNS での SELECT DROP ANY TABLE SELECT ANY TABLE INSERT ANY TABLE UPDATE ANY TABLE CREATE ANY VIEW DROP ANY VIEW CREATE ANY PROCEDURE ALTER ANY PROCEDURE DROP ANY PROCEDURE CREATE ANY SEQUENCE ALTER ANY SEQUENCE DROP ANY SEQUENCE 上記の権限は 以下に指定された要件のために付与します 特定のテーブルリストを使用するには レプリケートされたすべてのテーブルに SELECT を付与 し ALTER も付与します 149

156 Oracle のターゲットとしての使用 ユーザーがデフォルトテーブルスペースにテーブルを作成できるようにするには GRANT UNLIMITED TABLESPACE 権限を付与します ログオンのために CREATE SESSION 権限を付与します 直接パスを使用している場合 LOCK ANY TABLE 権限を付与します 全ロード設定で [DROP and CREATE table] オプションまたは [TRUNCATE before loading] オプション が選択されており ターゲットテーブルスキーマが AWS DMS ユーザーのものと異なる場合 DROP ANY TABLE 権限を付与します ターゲットテーブルスキーマが AWS DMS ユーザーのものと異なる場合に変更を変更テーブルまたは監 査テーブルに保存するには CREATE ANY TABLE 権限と CREATE ANY INDEX 権限を付与します ターゲットデータベース上の AWS Database Migration Service に必要な読み取り 権限 AWS DMS ユーザーアカウントには 以下の DBA テーブルの読み取り権限を付与する必要があります DBA_USERS での SELECT DBA_TAB_PRIVS での SELECT DBA_OBJECTS での SELECT DBA_SYNONYMS での SELECT DBA_SEQUENCES での SELECT DBA_TYPES での SELECT DBA_INDEXES での SELECT DBA_TABLES での SELECT DBA_TRIGGERS での SELECT 必要な権限のいずれかを V$xxx に付与できない場合は V_$xxx に付与します AWS Database Migration Service のターゲットとしての Oracle データベースの設定 データ移行ターゲットとして Oracle データベースを使用するには AWS DMS に Oracle ユーザーアカウ ントを提供する必要があります ユーザーアカウントには ターゲットとして Oracle を使用する場合に 必要なユーザーアカウント権限 (p. 149) で指定されているように Oracle データベースでの読み取り/ 書き込み権限が必要です AWS DMS のターゲットとして Oracle を使用する場合の追加の 接続属性 追加の接続属性を使用して Oracle ターゲットを設定できます これらの設定は ターゲットエンドポイン トを作成するときに指定します 複数の追加の接続属性の設定は セミコロンで区切る必要があります 次の表に Oracle をターゲットとして使用するときに利用できる追加の接続属性を示します 名前 説明 usedirectpathfullload 直接パスの全ロードを使用し これを指定して Oracle テーブ ルを一括ロードするための OCI 直接パスプロトコルを有効/無 効にします デフォルト値: Y 150

157 Oracle のターゲットとしての使用 名前 説明 有効な値: Y/N 例: usedirectpathfullload=n 列の長さのセマンティクスは 列の長さがバイト単位である か文字数単位であるかを指定します この値は CHAR に設定 します charlengthsemantics 例: charlengthsemantics=char Oracle のターゲットデータ型 AWS DMS で使用されるターゲット Oracle データベースでは Oracle のほとんどのデータ型がサポー トされます 以下の表に AWS DMS を使用する場合にサポートされる Oracle のターゲットデータ型 と AWS DMS のデータ型からのデフォルトマッピングを示します ソースからマッピングされるデータ 型を表示する方法の詳細については 使用しているソースのセクションを参照してください AWS DMS データ型 Oracle のデータ型 BOOLEAN NUMBER (1) BYTES RAW (長さ) DATE DATETIME TIME TIMESTAMP (0) DATETIME TIMESTAMP (スケール) INT1 NUMBER (3) INT2 NUMBER (5) INT4 NUMBER (10) INT8 NUMBER (19) NUMERIC NUMBER (p,s) REAL4 FLOAT REAL8 FLOAT STRING date を指定: DATE time を指定: TIMESTAMP timestamp を指定: TIMESTAMP timestamp_with_timezone を指定: TIMESTAMP WITH TIMEZONE timestamp_with_local_timezone を指定: TIMESTAMP WITH LOCAL TIMEZONE interval_year_to_month を指定: INTERVAL YEAR TO MONTH interval_day_to_second を指定: INTERVAL DAY TO SECOND 長さ > 4000 の場合: CLOB 151

158 ターゲットとしての SQL Server の使用 AWS DMS データ型 Oracle のデータ型 他のすべての場合: VARCHAR2 (長さ) UINT1 NUMBER (3) UINT2 NUMBER (5) UINT4 NUMBER (10) UINT8 NUMBER (19) WSTRING 長さ > 2000 の場合: NCLOB 他のすべての場合: NVARCHAR2 (長さ) BLOB BLOB AWS DMS でこのデータ型を使用する場合は 特定のタスク用に BLOB の使用を有効にする必要があります BLOB データ型は プライマリ キーを含むテーブルでのみサポートされます CLOB CLOB AWS DMS でこのデータ型を使用する場合は 特定のタスク用に CLOB の使用を有効にする必要があります CDC 中 CLOB データ型は プ ライマリキーを含むテーブルでのみサポートされます NCLOB NCLOB AWS DMS でこのデータ型を使用する場合は 特定のタスク用に NCLOB の使用を有効にする必要があります CDC 中 プライマリキー を含むテーブルでのみ NCLOB データ型がサポートされます XMLTYPE XMLTYPE ターゲットデータ型は Oracle 間レプリケーションタスクに のみ関連しています ソースデータベースが Oracle の場合 ソースデータ型は そのままの 状態で Oracle ターゲットにレプリケートされます たとえば ソー スにおける XMLTYPE データ型は ターゲットでは XMLTYPE データ 型として作成されます AWS Database Migration Service のターゲットとして の Microsoft SQL Server データベースの使用 AWS DMS を使用して Microsoft SQL Server データベースにデータを移行できます SQL Server デー タベースをターゲットとして使用すると 別の SQL Server データベースまたはサポートされている他の データベースのいずれかからデータを移行できます オンプレミスおよび Amazon EC2 インスタンスデータベースでは Enterprise Standard Workgroup および Developer エディションの SQL Server バージョン R および 2016 が AWS DMS によりターゲットとしてサポートされています Web および Express エディションは サポートされていません Amazon RDS インスタンスデータベースでは Enterprise Standard Workgroup Developer エディ ションの SQL Server バージョン 2008R および 2016 が AWS DMS によりターゲットと してサポートされています Web および Express エディションはサポートされていません 152

159 ターゲットとしての SQL Server の使用 AWS DMS および SQL Server ターゲットデータベースを使用する方法の詳細については 以下を参照し てください トピック AWS Database Migration Service のターゲットとして SQL Server を使用する場合の制限 (p. 153) AWS Database Migration Service のターゲットとして SQL Server を使用する場合のセキュリティ要 件 (p. 153) AWS DMS のターゲットとして SQLServer を使用する場合の追加の接続属性 (p. 153) Microsoft SQL Server のターゲットデータ型 (p. 154) AWS Database Migration Service のターゲットとして SQL Server を使用する場合の制限 AWS DMS のターゲットとして SQL Server データベースを使用する場合は 以下の制限が適用されま す 計算列を含む SQL Server ターゲットテーブルを手動で作成する場合 BCP 一括コピーユーティリティ を使用する全ロードレプリケーションがサポートされません 全ロードレプリケーションを使用するに は コンソールの [Advanced] タブで [Use BCP for loading tables] オプションを無効にします BCP の 詳細な操作方法については Microsoft SQL Server ドキュメント を参照してください SQL Server 空間データ型 (GEOMETRY と GEOGRAPHY) を含むテーブルをレプリケートすると 挿 入した空間参照識別子 (SRID) がすべて AWS DMS によりデフォルトの SRID に置き換えられます デ フォルトの SRID は GEOMETRY は 0 GEOGRAPHY は 4326 です 一時テーブルはサポートされていません ターゲット上に手動で作成されている場合に 一時テーブル を移行すると トランザクション適用モードのレプリケーションのみのタスクで動作することがありま す AWS Database Migration Service のターゲットとして SQL Server を使用する場合のセキュリティ要件 以下では Microsoft SQL Server ターゲットと共に AWS DMS を使用する場合のセキュリティ要件につい て説明します AWS DMS ユーザーアカウントには 接続先の Microsoft SQL Server データベースに対する db_owner ユーザーロールが最低限必要です Microsoft SQL Server システム管理者は すべての AWS DMS ユーザーアカウントにこのアクセス権限 を付与する必要があります AWS DMS のターゲットとして SQLServer を使用する場合の追 加の接続属性 追加の接続属性を使用して SQL Server ターゲットを設定できます これらの設定は ターゲットエンド ポイントを作成するときに指定します 複数の追加の接続属性の設定は セミコロンで区切る必要があり ます 次の表に SQL Server がターゲットである場合に使用できる追加の接続属性を示します 名前 説明 usebcpfullload BCP を使用して全ロードオペレーション用のデータを転送 するには この属性を使用します ターゲットテーブルに 153

160 ターゲットとしての SQL Server の使用 名前 説明 ソーステーブル内に存在しない IDENTITY 列が含まれている 場合 [use BCP for loading table (テーブルのロードに BCP を使用)] オプションを無効にする必要があります デフォルト値: Y 有効な値: Y/N 例: usebcpfullload=y BCP を使用したデータの転送に使用されるパケットの最大サ イズ (バイト単位) BCPPacketSize デフォルト値: 有効な値: 例: BCPPacketSize=16384 AWS DMS 内部テーブルのファイルグループを指定 します レプリケーションタスクが開始されると すべての内部 AWS DMS 制御テーブル (awsdms_ apply_exception awsdms_apply awsdms_changes) が 指 定したファイルグループで作成されます controltablesfilegroup デフォルト値: 該当なし 有効な値: 文字列 例: controltablesfilegroup=filegroup1 ファイルグループを作成するコマンドの例を次に示します ALTER DATABASE replicate ADD FILEGROUP Test1FG1; GO ALTER DATABASE replicate ADD FILE ( NAME = test1dat5, FILENAME = 'C:\temp\DATA\t1dat5.ndf', SIZE = 5MB, MAXSIZE = 100MB, FILEGROWTH = 5MB ) TO FILEGROUP Test1FG1; GO Microsoft SQL Server のターゲットデータ型 以下の表に AWS DMS を使用する場合にサポートされる Microsoft SQL Server のターゲットデータ型 と AWS DMS のデータ型からのデフォルトマッピングを示します AWS DMS のデータ型の詳細につい ては AWS Database Migration Service のデータ型 (p. 301) を参照してください AWS DMS データ型 SQL Server のデータ型 BOOLEAN TINYINT 154

161 ターゲットとしての SQL Server の使用 AWS DMS データ型 SQL Server のデータ型 BYTES VARBINARY(長さ) DATE SQL Server 2008 以降の場合 DATE を使用します それより前のバージョンでは スケールが 3 以下の場合は DATETIME を使用します 他のすべての場合は VARCHAR (37) を使用します TIME SQL Server 2008 以降の場合 DATETIME2 (%d) を使用します それより前のバージョンでは スケールが 3 以下の場合は DATETIME を使用します 他のすべての場合は VARCHAR (37) を使用します DATETIME SQL Server 2008 以降では DATETIME2 (scale) を使用します それより前のバージョンでは スケールが 3 以下の場合は DATETIME を使用します 他のすべての場合は VARCHAR (37) を使用します INT1 SMALLINT INT2 SMALLINT INT4 INT INT8 BIGINT NUMERIC NUMBER (p,s) REAL4 REAL REAL8 FLOAT STRING 列が日付または時刻列の場合 次の操作を行います SQL Server 2008 以降の場合 DATETIME2 を使用します それより前のバージョンでは スケールが 3 以下の場合は DATETIME を使用します 他のすべての場合は VARCHAR (37) を 使用します 列が日付または時刻列ではない場合 VARCHAR (長さ) を使用します UINT1 TINYINT UINT2 SMALLINT UINT4 INT UINT8 BIGINT WSTRING NVARCHAR (長さ) BLOB VARBINARY(最大) IMAGE AWS DMS でこのデータ型を使用する場合は 特定のタスク用に BLOB の使用を有効にする必要があります AWS DMS では プライマリキー を含むテーブルでのみ BLOB データ型がサポートされます 155

162 ターゲットとしての PostgreSQL の使用 AWS DMS データ型 SQL Server のデータ型 CLOB VARCHAR(max) AWS DMS でこのデータ型を使用する場合は 特定のタスク用に CLOB の使用を有効にする必要があります CDC 中 AWS DMS はプライマ リキーを含むテーブルでのみ CLOB データ型をサポートします NCLOB NVARCHAR(最大) AWS DMS でこのデータ型を使用する場合は 特定のタスク用に NCLOB の使用を有効にする必要があります CDC の実行中 AWS DMS ではプライマリキーを含むテーブルでのみ NCLOB データ型がサ ポートされます AWS Database Migration Service のターゲットとして の PostgreSQL データベースの使用 AWS DMS を使用して 別の PostgreSQL データベースまたはサポートされている他のいずれか のデータベースから PostgreSQL データベースにデータを移行できます オンプレミス Amazon RDS PostgreSQL との互換性のある Amazon Aurora および EC2 インスタンスデータベースで は PostgreSQL バージョン 9.4 以降がサポートされています AWS DMS は 全ロードフェーズでソースからターゲットにデータを移行するときに テーブル手法によ りテーブルを受け取ります 全ロードフェーズ中のテーブルの順序は保証されません テーブル全ロード フェーズ中 および個々のテーブルのキャッシュしたトランザクションが適用されている間は テーブル は同期されません その結果 アクティブな参照整合性制約により 全ロードフェーズ中にタスクが失敗 する可能性があります PostgreSQL では 外部キー (参照整合性制約) はトリガーを使用して実装されます 全ロードフェーズ中 に AWS DMS は各テーブルを一度に 1 つずつロードします 次のいずれかの方法を使用して 全ロード 中に外部キーの制約を無効にすることを強くお勧めします インスタンスからすべてのトリガーを一時的に無効にして 全ロードを終了します PostgreSQL では session_replication_role パラメータを使用します 特定の時間において トリガーは origin replica always または disabled のいずれかの状態に なります session_replication_role パラメータが replica に設定されている場合 replica 状 態のトリガーのみがアクティブになり 呼び出されると実行されます それ以外の場合 トリガーは非ア クティブなままです PostgreSQL には session_replication_role が設定されている場合でも テーブルの切り捨てを防 止するフェールセーフメカニズムが備わっています これをトリガーを無効にする代わりに使用して 全 ロードの完了を支援できます これを行うには ターゲットテーブルの準備モードを DO_NOTHING に設 定しますそれ以外の場合 外部キーの制約があると DROP および TRUNCATE オペレーションは失敗しま す Amazon RDS では パラメータグループを使用してこのパラメータの設定を管理できます Amazon EC2 で実行されている PostgreSQL インスタンスの場合 直接パラメータを設定できます AWS DMS のターゲットとしての PostgreSQL データベースの使用の詳細については 以下のセクション を参照してください トピック AWS Database Migration Service のターゲットとして PostgreSQL を使用する場合の制限 (p. 157) 156

163 ターゲットとしての PostgreSQL の使用 AWS Database Migration Service のターゲットとして PostgreSQL データベースを使用する場合のセ キュリティ要件 (p. 157) AWS DMS のターゲットとして PostgreSQL を使用する場合の追加の接続属性 (p. 157) PostgreSQL のターゲットデータ型 (p. 158) AWS Database Migration Service のターゲットとして PostgreSQL を使用する場合の制限 AWS DMS のターゲットとして PostgreSQL データベースを使用する場合 以下の制限が適用されます JSON データ型はネイティブ CLOB データ型に変換されます Oracle から PostgreSQL への移行で Oracle の列に NULL 文字 (16 進数値 U ) が含まれている場 合 AWS DMS は NULL 文字をスペース (16 進数値 U ) に変換します これは PostgreSQL の 制限によるものです AWS Database Migration Service のターゲットとして PostgreSQL データベースを使用する場合のセキュリティ要件 セキュリティ上の観点から データ移行に使用されるユーザーアカウントは ターゲットとして使用する PostgreSQL データベースにおける登録済みユーザーにする必要があります AWS DMS のターゲットとして PostgreSQL を使用する場合の追 加の接続属性 追加の接続属性を使用して PostgreSQL ターゲットを設定できます これらの設定は ターゲットエンド ポイントを作成するときに指定します 複数の追加の接続属性の設定は セミコロンで区切る必要があり ます 以下の表に AWS DMS のターゲットとして PostgreSQL を設定するときに使用できる追加の接続属性を 示します 名前 説明 maxfilesize PostgreSQL へのデータ転送に使用される CSV ファイルの最 大サイズ (KB 単位) を指定します デフォルト値: KB (32 MB) 有効な値: 例: maxfilesize=512 executetimeout PostgreSQL インスタンスのクライアントステートメントタ イムアウト (秒単位) を設定します デフォルト値は 60 秒で す 例: executetimeout=100 afterconnectscript=set この属性を追加して AWS DMS ですべての外部キーとユー session_replication_role='replica' ザートリガーをバイパスします このアクションにより 全 ロードモードを使用するときに データをバルクロードする ためにかかる時間が大幅に減ります 157

164 ターゲットとしての PostgreSQL の使用 名前 説明 例: afterconnectscript=set session_replication_role='replica' PostgreSQL のターゲットデータ型 AWS DMS の PostgreSQL データベースエンドポイントでは PostgreSQL データベースのほとん どのデータ型がサポートされています 以下の表に AWS DMS を使用する場合にサポートされる PostgreSQL データベースのターゲットデータ型と AWS DMS のデータ型からのデフォルトマッピング を示します サポートされていないデータ型は 表の後にリストされています AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください AWS DMS データ型 PostgreSQL のデータ型 BOOL BOOL BYTES BYTEA DATE DATE TIME TIME TIMESTAMP スケールが 0 6 の場合 TIMESTAMP を使用します スケールが 7 9 の場合 VARCHAR (37) を使用します INT1 SMALLINT INT2 SMALLINT INT4 INTEGER INT8 BIGINT NUMERIC DECIMAL (P,S) REAL4 FLOAT4 REAL8 FLOAT8 STRING 長さが 1 21,845 の場合 VARCHAR (バイト単位の長さ) を使用しま す 長さが 21,846 2,147,483,647 の場合 VARCHAR (65535) を使用し ます UINT1 SMALLINT UINT2 INTEGER UINT4 BIGINT UINT8 BIGINT WSTRING 長さが 1 21,845 の場合 VARCHAR (バイト単位の長さ) を使用しま す 158

165 ターゲットとしての MySQL の使用 AWS DMS データ型 PostgreSQL のデータ型 長さが 21,846 2,147,483,647 の場合 VARCHAR (65535) を使用し ます BCLOB BYTEA NCLOB TEXT CLOB TEXT Note PostgreSQL ソースからレプリケートする場合 AWS DMS はユーザー定義のデータ型を含む列 とは別に すべての列に対して同じデータ型のターゲットテーブルを作成します このような場 合 データ型はターゲットで character varying として作成されます AWS Database Migration Service のターゲットとして の MySQL 互換データベースの使用 AWS DMS を使用して AWS DMS がサポートするソースデータエンジンのいずれかから どの MySQL 互換データベースにもデータを移行できます オンプレミス MySQL 互換データベースに移行する場 合 AWS DMS では ソースエンジンが AWS エコシステム内に存在することが必要です エンジン は Amazon RDS Amazon Aurora Amazon S3 などの Amazon マネージド型サービス上に存在してい てかまいません または エンジンは Amazon EC2 の自己マネージド型データベース上に存在していても かまいません SSL を使用して MySQL 互換のエンドポイントとレプリケーションインスタンスとの接続を暗号化で きます MySQL 互換のエンドポイントで SSL を使用する方法の詳細については AWS Database Migration Service で SSL を使用する (p. 47) を参照してください MySQL バージョン と MariaDB および Aurora MySQL がサポートされています AWS DMS のターゲットとして以下の MySQL 互換データベースを使用できます MySQL Community Edition MySQL Standard Edition MySQL Enterprise Edition MySQL Cluster Carrier Grade Edition MariaDB Community Edition MariaDB Enterprise Edition MariaDB Column Store Amazon Aurora MySQL AWS DMS のターゲットとしての MySQL 互換データベースの使用の詳細については 以下のセクション を参照してください トピック AWS Database Migration Service のターゲットとしての任意の MySQL 互換データベースの使 用 (p. 160) AWS Database Migration Service のターゲットとして MySQL 互換データベースを使用する場合の制 限 (p. 160) 159

166 ターゲットとしての MySQL の使用 AWS DMS のターゲットとして MySQL 互換データベースを使用する場合の追加の接続属性 (p. 161) MySQL のターゲットデータ型 (p. 162) AWS Database Migration Service のターゲットとしての任意の MySQL 互換データベースの使用 AWS DMS のターゲットとして MySQL データベースを使用し始める前に 以下の前提条件を満たしてい ることを確認してください MySQL 互換データベースに対して読み取り/書き込み権限を持つユーザーアカウントを AWS DMS に指 定する必要があります 必要なアクセス権限を作成するには 以下のコマンドを実行します CREATE USER '<user IDENTIFIED BY '<user password>'; GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT ON <schema>.* TO '<user GRANT ALL PRIVILEGES ON awsdms_control.* TO '<user 全ロード移行フェーズ中 ターゲットテーブルで外部キーを無効にする必要があります 全ロード 中に MySQL 互換データベースで外部キーチェックを無効にするには ターゲットエンドポイントの [Advanced] セクションで [Extra Connection Attributes] に次のコマンドを追加します initstmt=set FOREIGN_KEY_CHECKS=0 AWS Database Migration Service のターゲットとして MySQL 互 換データベースを使用する場合の制限 ターゲットとして MySQL データベースを使用する場合 AWS DMS では以下のものがサポートされませ ん データ定義言語 (DDL) ステートメント: TRUNCATE PARTITION DROP TABLE RENAME TABLE ALTER TABLE <table_name> ADD COLUMN <column_name> ステートメントを使用して テーブ ルの先頭または中間に列を追加します ソーステーブルの LOB 列のみが更新されると AWS DMS は対応するターゲット列を更新しません ターゲット LOB は 少なくとも他の 1 つの列が同じトランザクションで更新された場合にのみ更新さ れます 全ロードタスク時に MySQL 互換ターゲットにデータをロードすると AWS DMS はタスクログで重複 するキーエラーを報告しません 列の値を既存の値に更新すると MySQL 互換データベースにより 0 rows affected 警告が返されま す この動作は技術的にはエラーではありませんが 他のデータベースエンジンによって状況が処理さ れる方法とは異なります たとえば Oracle は 1 行の更新を実行します MySQL 互換データベースの 場合 AWS DMS は awsdms_apply_exceptions 制御テーブルにエントリが生成され 以下の警告がログ 記録されます Some changes from the source database had no impact when applied to the target database. See awsdms_apply_exceptions table for details. 160

167 ターゲットとしての MySQL の使用 AWS DMS のターゲットとして MySQL 互換データベースを使用 する場合の追加の接続属性 追加の接続属性を使用して MySQL 互換ターゲットを設定できます これらの設定は ターゲットエンド ポイントを作成するときに指定します 複数の追加の接続属性の設定は 互いにセミコロンで区切る必要 があります 以下の表は AWS DMS の MySQL 互換ターゲットを作成するときに使用できる 追加の構成設定を示し ています 名前 説明 targetdbtype ソーステーブルを移行するターゲット上の場所 (1 つのデータ ベースか複数のデータベースか) を指定します デフォルト値: MULTIPLE_DATABASES 有効な値: SPECIFIC_DATABASE, MULTIPLE_DATABASES 例: targetdbtype=multiple_databases データを MySQL 互換ターゲットデータベースにロードする 際のパフォーマンスが向上します データを MySQL 互換 ターゲットデータベースにロードする際に使用するスレッ ドの数を指定します スレッドごとに別個の接続が必要に なるため スレッド数を大きく設定するとデータベースのパ フォーマンスに悪影響を生じる場合があります parallelloadthreads デフォルト値: 1 有効な値: 1 5 例: parallelloadthreads=1 initstmt=set FOREIGN_KEY_CHECKS=0 外部キーチェックを無効にします initstmt=set time-zone ターゲット MySQL 互換データベースのタイムゾーンを指定 します デフォルト値: UTC 有効な値: 使用するタイムゾーンの 3 4 文字の省略形 有 効な値は ターゲット MySQL 互換データベースをホストし ているオペレーティングシステムにおけるタイムゾーンの標 準の省略形です 例: initstmt=set time_zone=utc afterconnectscript=set MySQL 互換ターゲットが受け取ったステートメントを latin1 character_set_connection='latin1' 文字セット (データベースのデフォルトでコンパイルされる 文字セット) に変換する必要があることを指定します この パラメータでは通常 UTF8 クライアントからの変換時にパ フォーマンスが向上します maxfilesize MySQL 互換データベースへのデータ転送に使用される CSV ファイルの最大サイズ (KB 単位) を指定します デフォルト値: KB (32 MB) 161

168 ターゲットとしての MySQL の使用 名前 説明 有効な値: 例: maxfilesize=512 CleanSrcMetadataOnMismatch 不一致が発生すると レプリケーションインスタンスのテー ブルメタデータ情報をクリーンアップして再作成します た とえば テーブルの DDL を変更すると レプリケーションイ ンスタンスにキャッシュされているテーブルに関する情報が 変更される場合があります Boolean. デフォルト値: false 例: CleanSrcMetadataOnMismatch=false MySQL のターゲットデータ型 以下の表に AWS DMS を使用する場合にサポートされる MySQL データベースのターゲットデータ型 と AWS DMS のデータ型からのデフォルトマッピングを示します AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください AWS DMS データ型 MySQL のデータ型 BOOLEAN BOOLEAN BYTES 長さが 1 65,535 の場合 VARBINARY (長さ) を 使用します 長さが 65,536 2,147,483,647 の場 合 LONGLOB を使用します DATE DATE TIME TIME TIMESTAMP "スケールが 0 以上 6 以下の場合: DATETIME (Scale) スケールが 7 以上 9 以下の場合: VARCHAR (37)" INT1 TINYINT INT2 SMALLINT INT4 INTEGER INT8 BIGINT NUMERIC DECIMAL (p,s) REAL4 FLOAT REAL8 DOUBLE PRECISION STRING 長さが 1 21,845 の場合 VARCHAR (長さ) を使 用します 162

169 ターゲットとしての Amazon Redshift の使用 AWS DMS データ型 MySQL のデータ型 長さが 21,846 2,147,483,647 の場 合 LONGTEXT を使用します UINT1 UNSIGNED TINYINT UINT2 UNSIGNED SMALLINT UINT4 UNSIGNED INTEGER UINT8 UNSIGNED BIGINT WSTRING 長さが 1 32,767 の場合 VARCHAR (長さ) を使 用します 長さが 32,768 2,147,483,647 の場 合 LONGTEXT を使用します BLOB 長さが 1 65,535 の場合 BLOB を使用します 長さが 65,536 2,147,483,647 の場 合 LONGBLOB を使用します 長さが 0 の場合 LONGBLOB (LOB を完全にサ ポート) を使用します NCLOB 長さが 1 65,535 の場合 TEXT を使用します 長さが 65,536 2,147,483,647 の場 合 CHARACTER SET が ucs2 の LONGTEXT を 使用します 長さが 0 の場合 ucs2 が CHARACTER SET の LONGTEXT (LOB を完全にサポート) を使用しま す CLOB 長さが 1 65,535 の場合 TEXT を使用します 長さが 65, の場 合 LONGTEXT を使用します 長さが 0 の場合 LONGTEXT (LOB を完全にサ ポート) を使用します AWS Database Migration Service のターゲットとして の Amazon Redshift データベースの使用 AWS Database Migration Service を使用して Amazon Redshift データベースにデータを移行できま す Amazon Redshift は クラウド内での完全マネージド型 ペタバイトスケールのデータウェアハウス サービスです ターゲットとして Amazon Redshift データベースを使用すると サポートされている他の すべてのソースデータベースからデータを移行できます Amazon Redshift クラスターは レプリケーションインスタンスと同じ AWS アカウントと同じ AWS リー ジョンに存在している必要があります Amazon Redshift へのデータベース移行中 AWS DMS はまずデータを S3 バケットに移動します ファ イルが S3 バケットに移動されると AWS DMS はそれらのファイルを Amazon Redshift データウェアハ 163

170 ターゲットとしての Amazon Redshift の使用 ウス内の適切なテーブルに転送します AWS DMS は S3 バケットを Amazon Redshift データベースと 同じ AWS リージョンに作成します AWS DMS レプリケーションインスタンスはその同じリージョンに 存在している必要があります AWS Command Line Interface (AWS CLI) または AWS DMS API を使用してデータを Amazon Redshift に 移行する場合 S3 アクセスを許可するように AWS Identity and Access Management (IAM) ロールを設定 する必要があります この IAM ロールの作成に関する詳細については AWS CLI と AWS DMS API で 使用する IAM ロールを作成する (p. 34) を参照してください Amazon Redshift エンドポイントは 以下の完全なオートメーションを行います スキーマ生成およびデータ型マッピング ソースデータベーステーブルの全ロード ソーステーブルに加えられた変更の増分ロード ソーステーブルに加えられたスキーマ変更のデータ定義言語 (DDL) での適用 全ロードプロセスと変更データキャプチャ (CDC) プロセスの間の同期 AWS Database Migration Service では 全ロードオペレーションと変更処理オペレーションの両方がサ ポートされています AWS DMS は ソースデータベースからデータを読み取り 一連のカンマ区切り値 (CSV) ファイルを作成します 全ロードオペレーションの場合 AWS DMS はテーブルごとにファイルを 作成します 次に AWS DMS は各テーブルのテーブルファイルを Amazon S3 内の別個のフォルダにコ ピーします ファイルが Amazon S3 にアップロードされると AWS DMS がコピーコマンドを送信し ファイル内のデータが Amazon Redshift にコピーされます 変更処理オペレーションの場合 AWS DMS は差分変更を CSV ファイルにコピーします その後 AWS DMS は差分変更ファイルを Amazon S3 に アップロードし データを Amazon Redshift にコピーします AWS DMS のターゲットとしての Amazon Redshift の使用の詳細については 以下のセクションを参照し てください トピック AWS Database Migration Service のターゲットとして Amazon Redshift データベースを使用する場合 の前提条件 (p. 164) AWS Database Migration Service のターゲットとして Amazon Redshift を使用する場合の制 限 (p. 165) AWS Database Migration Service のターゲットとしての Amazon Redshift データベースの設 定 (p. 165) Amazon Redshift で拡張された VPC ルーティングを AWS Database Migration Service のターゲット として使用する (p. 166) AWS DMS のターゲットとして Amazon Redshift を使用する場合の追加の接続属性 (p. 166) Amazon Redshift のターゲットデータ型 (p. 168) AWS Database Migration Service のターゲットとして Amazon Redshift データベースを使用する場合の前提条件 以下のリストでは データ移行のターゲットとして Amazon Redshift を使用する場合に必要な前提条件に ついて説明します Amazon Redshift クラスターを起動するには AWS マネジメントコンソールを使用します AWS アカ ウントと Amazon Redshift クラスターに関する基本的な情報 (パスワード ユーザー名 データベース 名など) を記録してください これらの値は Amazon Redshift ターゲットエンドポイントを作成すると きに必要になります Amazon Redshift クラスターは レプリケーションインスタンスと同じ AWS アカウントと同じ AWS リージョンに存在している必要があります 164

171 ターゲットとしての Amazon Redshift の使用 AWS DMS レプリケーションインスタンスには クラスターで使用される Amazon Redshift エンドポイ ント (ホスト名とポート) へのネットワーク接続が必要です AWS DMS は Amazon S3 バケットを使用してデータを Amazon Redshift データベースに転送しま す AWS DMS がバケットを作成できるようにするため DMS コンソールは Amazon IAM ロール dmsaccess-for-endpoint を使用します AWS CLI または DMS API を使用して ターゲットデータ ベースとして Amazon Redshift を使用したデータベース移行を作成する場合 この IAM ロールを作成す る必要があります このロールの作成に関する詳細については AWS CLI と AWS DMS API で使用す る IAM ロールを作成する (p. 34) を参照してください AWS DMS は ターゲットの Amazon Redshift インスタンスで BLOB CLOB および NCLOB を VARCHAR に変換します Amazon Redshift では 64 KB を超える VARCHAR のデータ型がサポートさ れていないため 従来の LOB を Amazon Redshift に保存することはできません AWS Database Migration Service のターゲットとして Amazon Redshift を使用する場合の制限 ターゲットとして Amazon Redshift データベースを使用する場合 AWS DMS では以下のものがサポート されません 以下の DDL はサポートされていません ALTER TABLE <table name> MODIFY COLUMN <column name> <data type>; AWS DMS は 名前がアンダースコア (_) で始まるスキーマへの変更を移行またはレプリケートできま せん 名前がアンダースコアで始まるスキーマがある場合は マッピング変換を使用してターゲットで スキーマの名前を変更してください Amazon Redshift は 64 KB より大きい VARCHAR をサポートしていません 従来のデータベースからの LOB を Amazon Redshift に保存することはできません AWS Database Migration Service のターゲットとしての Amazon Redshift データベースの設定 Amazon Redshift インスタンスを使用できるように AWS Database Migration Service を設定する必要があ ります 以下の表では Amazon Redshift エンドポイントに使用できる設定プロパティについて説明しま す プロパティ 説明 server 使用する Amazon Redshift クラスターの名前 port Amazon Redshift のポート番号 デフォルト値は 5439 です username 登録済みユーザーの Amazon Redshift ユーザー名 パスワード username プロパティで指定されたユーザーのパスワード データベース 使用する Amazon Redshift データウェアハウス (サービス) Amazon Redshift エンドポイントに追加の接続文字列属性を追加する場合 maxfilesize 属性と filetransferuploadstreams 属性を指定できます これらの属性の詳細については AWS DMS の ターゲットとして Amazon Redshift を使用する場合の追加の接続属性 (p. 166) を参照してください 165

172 ターゲットとしての Amazon Redshift の使用 Amazon Redshift で拡張された VPC ルーティングを AWS Database Migration Service のターゲットとして使用する Amazon Redshift ターゲットで拡張された VPC ルーティング機能を使用する場合 Amazon Redshift クラ スターとデータリポジトリとの間のすべての COPY トラフィックが Amazon VPC を経由するようになり ます 拡張された VPC ルーティングは 他のリソースに Amazon Redshift がアクセスする方法に影響を 与えるため VPC を正しく設定していないと COPY コマンドが失敗することがあります AWS DMS がこの動作の影響を受けることがあるのは COPY コマンドを使用して S3 内のデータを Amazon Redshift クラスターに移動するためです 以下に示しているのは AWS DMS が Amazon Redshift ターゲットにデータをロードする手順です 1. AWS DMS がソースからレプリケーションサーバー上の CSV ファイルにデータをコピーします 2. AWS DMS が AWS SDK を使用してアカウントの S3 バケットに CSV ファイルをコピーします 3. AWS DMS がその後 Amazon Redshift で COPY コマンドを使用して S3 内の CSV ファイルから Amazon Redshift 内の該当するテーブルにデータをコピーします 拡張された VPC ルーティングが有効でない場合 Amazon Redshift は AWS ネットワークにおけるその他 のサービスへのトラフィックを含むトラフィックをインターネット経由でルーティングします この機能 が有効でない場合は ネットワークパスを設定する必要はありません この機能が有効な場合は クラス ターの VPC とデータリソースとの間のネットワークパスを別に作成する必要があります 必要な設定の詳 細については Amazon Redshift のドキュメントの 拡張された VPC ルーティング を参照してくださ い AWS DMS のターゲットとして Amazon Redshift を使用する場 合の追加の接続属性 追加の接続属性を使用して Amazon Redshift ターゲットを設定できます これらの設定は ソースエンド ポイントを作成するときに指定します 複数の追加の接続属性の設定は セミコロンで区切る必要があり ます 以下の表に Amazon Redshift がターゲットであるときに使用できる追加の接続属性を示します 名前 説明 maxfilesize Amazon Redshift へのデータ転送に使用される CSV ファイル の最大サイズ (KB 単位) を指定します デフォルト値: KB (32 MB) 有効な値: 例: maxfilesize=512 filetransferuploadstreams 1 つのファイルをアップロードするのに使用されるスレッド の数を指定します デフォルト値: 10 有効な値: 1 64 例: filetransferuploadstreams=20 acceptanydate などの無効な日付形式を含む あらゆる日付形式 を受け入れるかどうかを指定します ブール値 166

173 ターゲットとしての Amazon Redshift の使用 名前 説明 デフォルト値: false 有効な値: true false 例: acceptanydate=true dateformat 日付形式を指定します これは 文字列入力であり デ フォルトでは空です デフォルトの形式は YYYY-MM-DD ですが DD-MM-YYYY などに変更できます 日の値また は時間の値で異なる形式が使用される場合 dateformat パラメータとともに auto 引数を使用します auto 引数 は dateformat 文字列を使用する場合にサポートされない 形式を認識します auto キーワードでは大文字小文字を区 別します デフォルト値: 空 有効な値: 'dateformat_string' または auto 例: dateformat=auto timeformat 時間形式を指定します これは 文字列入力であり デ フォルトでは空です auto 引数は timeformat 文字列 を使用する場合にサポートされない形式を認識します 日 の値および時間の値でそれぞれ異なる形式が使用される場 合 timeformat パラメータとともに auto 引数を使用しま す デフォルト値: 10 有効な値: 'timeformat_string' 'auto' 'epochsecs' 'epochmillisecs' 例: timeformat=auto emptyasnull AWS DMS が空の CHAR および VARCHAR フィールドを null として移行するかどうかを指定します 値が true の場 合 空の CHAR および VARCHAR フィールドが null として 設定されます デフォルト値: false 有効な値: true false 例: emptyasnull=true truncatecolumns 列の仕様に合うよう 該当する文字数で列のデータを切り捨 てます データ型が VARCHAR または CHAR の列 および サイズが 4 MB 以下の行にのみ適用されます デフォルト値: false 有効な値: true false 例: truncatecolumns=true; 167

174 ターゲットとしての Amazon Redshift の使用 名前 説明 removequotes 入力データの文字列を囲む引用符を削除します 区切り記 号を含む引用符内のすべての文字は保持されます AWS Redshift ターゲットの引用符を削除する詳細については Redshift のドキュメント を参照してください デフォルト値: false 有効な値: true false 例: removequotes=true; trimblanks VARCHAR 文字列から末尾の空白文字を削除します このパ ラメータは VARCHAR データ型の列にのみ適用されます デフォルト値: false 有効な値: true false 例: trimblanks=false; Amazon Redshift のターゲットデータ型 Amazon Redshift の AWS DMS エンドポイントでは Amazon Redshift のほとんどのデータ型がサポート されています 以下の表に AWS DMSを使用する場合にサポートされる Amazon Redshift のターゲット データ型と AWS DMS のデータ型からのデフォルトマッピングを示します AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください AWS DMS データ型 Amazon Redshift データ型 BOOLEAN BOOL BYTES VARCHAR (長さ) DATE DATE TIME VARCHAR(20) DATETIME スケールが 0 以上 6 以下の場合 TIMESTAMP (s) スケールが 7 以上 9 以下の場合 VARCHAR(37) INT1 INT2 INT2 INT2 INT4 INT4 168

175 ターゲットとしての Amazon Redshift の使用 AWS DMS データ型 Amazon Redshift データ型 INT8 INT8 NUMERIC スケールが 0 以上 37 以下の場合 NUMERIC (p,s) スケールが 38 以上 127 以下の場合 VARCHAR (長さ) REAL4 FLOAT4 REAL8 FLOAT8 STRING 長さが 1 65,535 の場合 VARCHAR (バイト単 位の長さ) を使用します 長さが 65,536 2,147,483,647 の場 合 VARCHAR (65535) を使用します UINT1 INT2 UINT2 INT2 UINT4 INT4 UINT8 NUMERIC (20,0) WSTRING 長さが 1 65,535 の場合 NVARCHAR (バイト 単位の長さ) を使用します 長さが 65,536 2,147,483,647 の場 合 NVARCHAR (65535) を使用します BLOB VARCHAR (最大 LOB サイズ *2) 最大 LOB サイズが 31 KB を超えることはでき ません Amazon Redshift は 64 KB より大きい VARCHAR をサポートしていません NCLOB NVARCHAR (最大 LOB サイズ) 最大 LOB サイズが 63 KB を超えることはでき ません Amazon Redshift は 64 KB より大きい VARCHAR をサポートしていません CLOB VARCHAR (最大 LOB サイズ) 最大 LOB サイズが 63 KB を超えることはでき ません Amazon Redshift は 64 KB より大きい VARCHAR をサポートしていません 169

176 ターゲットとしての SAP ASE の使用 AWS Database Migration Service のターゲットとして の SAP ASE データベースの使用 AWS DMS を使用して サポートされているいずれかのデータベースソースから SAP Adaptive Server Enterprise (ASE) (旧 Sybase) データベースにデータを移行できます SAP ASE バージョン 以降がサポートされています AWS Database Migration Service のターゲットとして SAP ASE データベースを使用する場合の前提条件 AWS DMS のターゲットとして SAP ASE データベースを使用し始める前に 以下の前提条件を満たして いることを確認してください AWS DMS ユーザーに SAP ASE アカウントへのアクセスを許可する必要があります このユーザーに は SAP ASE データベースでの読み取り/書き込み権限が必要です AWS DMS では 非ラテン言語 (中国語など) に設定された Windows EC2 インスタンスにインストール されている SAP ASE バージョン 15.7 にレプリケートする場合 ターゲット SAP ASE マシンには SAP ASE 15.7 SP121 がインストールされている必要があります AWS DMS のターゲットとして SAP ASE を使用する場合の追加 の接続属性 追加の接続属性を使用して SAP ASE ターゲットを設定できます これらの設定は ターゲットエンドポ イントを作成するときに指定します 複数の追加の接続属性の設定は セミコロンで区切る必要がありま す 次の表に SAP ASE をターゲットとして使用するときに使用できる追加の接続属性を示します 名前 説明 enablereplication SAP ASE レプリケーションを自動的に有効にするには Y に 設定します これは SAP ASE レプリケーションがまだ有効 になっていない場合にのみ必要です additionalconnectionproperties 指定する追加の ODBC 接続パラメーター Note 接続文字列で指定されたユーザー名やパスワードに非ラテン文字 (中国語など) が含まれている場 合 次のプロパティが必要です charset=gb18030 SAP ASE のターゲットデータ型 以下の表に AWS DMS を使用する場合にサポートされる SAP ASE データベースのターゲットデータ型 と AWS DMS のデータ型からのデフォルトマッピングを示します AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください AWS DMS データ型 SAP ASE のデータ型 BOOLEAN BIT 170

177 ターゲットとしての Amazon S3 の使用 AWS DMS データ型 SAP ASE のデータ型 BYTES VARBINARY (長さ) DATE DATE TIME TIME TIMESTAMP スケールが 0 以上 6 以下の場合: BIGDATETIME スケールが 7 以上 9 以下の場合: VARCHAR (37) INT1 TINYINT INT2 SMALLINT INT4 INTEGER INT8 BIGINT NUMERIC NUMERIC (p,s) REAL4 REAL REAL8 DOUBLE PRECISION STRING VARCHAR (長さ) UINT1 TINYINT UINT2 UNSIGNED SMALLINT UINT4 UNSIGNED INTEGER UINT8 UNSIGNED BIGINT WSTRING VARCHAR (長さ) BLOB IMAGE CLOB UNITEXT NCLOB TEXT AWS DMS は 以下のデータ型のフィールドを含むテーブルをサポートしません これらのデータ型のレ プリケートされた列は NULL として表示されます ユーザー定義の型 (UDT) AWS Database Migration Service のターゲットとして の Amazon S3 の使用 サポートされるデータベースのソースから AWS DMS を使用することにより データを Amazon S3 に移行できます AWS DMS タスクのターゲットとして S3 を使用する場合 全ロードと 変更データキャプチャ (CDC) データの両方が カンマ区切り値 (CSV) 形式で書き込まれま す LOAD00001.csv LOAD00002 などの増分カウンタを使用して全ロード時に作成される AWS DMS 名ファイル csv などの タイムスタンプを使用した AWS DMS 名 CDC ファイ 171

178 ターゲットとしての Amazon S3 の使用 ル ソーステーブルごとに AWS DMS は 指定されたターゲットフォルダの下にフォルダを作成しま す AWS DMS は 指定された S3 バケットに すべての全ロードおよび CDC ファイルを書き込みます パラメータbucketFolder には.csvファイルがS3バケットにアップロードされる前に保存される場所が 含まれます テーブルデータは S3 バケットに以下の形式で格納されます: <schema_name>/<table_name>/load001.csv <schema_name>/<table_name>/load002.csv <schema_name>/<table_name>/<time-stamp>.csv 追加の接続属性を使用して 列の区切り文字 行の区切り文字 およびその他のパラメータを指定できま す 追加の接続属性の詳細については このセクションの最後にある AWS DMS のターゲットとして Amazon S3 を使用する場合の追加の接続属性 (p. 173) を参照してください AWS DMS を使用してデータ変更をレプリケートする場合 CSV 出力ファイルの最初の列に 次に示すよ うにデータがどのように変更されたかが示されます I,101,Smith,Bob,4-Jun-14,New York U,101,Smith,Bob,8-Oct-15,Los Angeles U,101,Smith,Bob,13-Mar-17,Dallas D,101,Smith,Bob,13-Mar-17,Dallas この例では ソースデータベースに EMPLOYEE テーブルがあるとします AWS DMS は以下のイベントに 応答して データを CSV ファイルに書き込みます 新しい従業員 (Bob Smith 従業員 ID 101) がニューヨークオフィスに 2014 年 6 月 4 日に採用されま した CSV ファイルで 最初の列の I は 新しい行がソースデータベースの EMPLOYEE テーブルに INSERT されたことを示しています 2015 年 10 月 8 日に Bob はロサンゼルスオフィスに転勤になりました CSV ファイルで U は Bob の新しい勤務地を反映するため EMPLOYEE テーブルの対応する行が UPDATE されたことを示してい ます その他の行は UPDATE の後に表示される EMPLOYEE テーブルの行を反映しています 2017 年 3 月 13 日に Bob はダラスオフィスに再度転勤になりました CSV ファイルで U はこの行 が再度 UPDATE されたことを示しています その他の行は UPDATE の後に表示される EMPLOYEE テーブルの行を反映しています Bob は しばらくダラスに勤務した後 退職しました CSV ファイルで D は 行がソーステーブルで DELETE されたことを示しています その他の行は 削除される前に行が EMPLOYEE テーブルにどの ように表示されたかを反映しています ターゲットとして Amazon S3 を使用する場合の前提条件 ターゲットとして使用している Amazon S3 バケットは データの移行に使用している DMS レプリケー ションインスタンスと同じリージョンにあることが必要です お客様が移行するために使用する AWS アカウントには ターゲットとして使用している Amazon S3 バ ケットに対する書き込みおよび削除アクセス権限が必要です 移行タスクを作成するために使用される ユーザーアカウントに割り当てられるロールは 次の一連のアクセス許可が必要です "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "s3:putobject", "s3:deleteobject" 172

179 ターゲットとしての Amazon S3 の使用, ] ], "Resource": [ "arn:aws:s3:::buckettest2*" ] "Effect": "Allow", "Action": [ "s3:listbucket" ], "Resource": [ "arn:aws:s3:::buckettest2*" ] ターゲットとして Amazon S3 を使用する場合の制限 以下の制限は ターゲットとして使用する Amazon S3 のファイルセットに適用されます 次のデータ定義言語 (DDL) コマンドのみサポートされます: TRUNCATE TABLE DROP TABLE およ び CREATE TABLE 完全 LOB モードはサポートされていません 全ロード時のソーステーブル構造に対する変更はサポートされていません 全ロード時のデータに対す る変更はサポートされています 同じソーステーブルから同じターゲット S3 エンドポイントバケットにデータをレプリケートする複数 のタスクを実行すると それらのタスクが同じファイルに書き込みます 同じテーブルのデータソース を使用する場合 異なるターゲットエンドポイント (バケット) を指定することをお勧めします セキュリティ ターゲットとして Amazon S3 を使用するには 移行のために使用されるアカウントに ターゲットとし て使用される Amazon S3 バケットに対する書き込みおよび削除アクセス権限が必要です Amazon S3 に アクセスするために必要なアクセス権限がある IAM ロールの Amazon リソースネーム (ARN) を指定する 必要があります AWS DMS は Amazon S3 に対する一連の事前定義済みの許可 (既定 ACL) をサポートしています 各既 定 ACL には Amazon S3 バケットに対するアクセス権限を設定するために使用できる一連の被付与者と アクセス権限があります S3 ターゲットエンドポイントの接続文字列属性で cannedaclforobjects で 使用して 既定 ACL を指定できます 追加の接続属性 cannedaclforobjects の使用の詳細について は AWS DMS のターゲットとして Amazon S3 を使用する場合の追加の接続属性 (p. 173) を参照し てください Amazon S3 の既定 ACL の詳細については 既定 ACL を参照してください 移行に使用する IAM ロールは s3:putobjectacl API アクションを実行できる必要があります AWS DMS のターゲットとして Amazon S3 を使用する場合の追 加の接続属性 追加の接続属性として次のオプションを指定できます 複数の追加の接続属性の設定は セミコロンで区 切る必要があります オプション 説明 addcolumnname.csv 出力ファイルに列名情報を追加できるようにするオプションのパラメー タ デフォルト: false 173

180 ターゲットとしての Amazon S3 の使用 オプション 説明 例: addcolumnname=true; bucketfolder S3バケット内のフォルダ名を設定するオプションのパラメータ このパラ メータを指定すると パス <bucketfolder>/<schema_name>/<table_name>/ にテーブルが作成されます このパラメータを指定しない場合 使用される パスは <schema_name>/<table_name>/ です 例: bucketfolder=testfolder; bucketname S3 バケットの名前 例: bucketname=buckettest; cannedaclforobjects S3 バケットに書き込まれたオブジェクトに対する事前定義済み (既定) のアク セスコントロールリストを AWS DMS で指定できるようにします Amazon S3 の既定 ACL の詳細については Amazon S3 開発者ガイドの 既定 ACL を参照してください 例: cannedaclforobjects=public_read; この属性の有効な値 は NONE PRIVATE PUBLIC_READ PUBLIC_READ_WRITE AUTHENTICATED_REA です この属性が指定されていない場合 デフォルトは NONE です cdcinsertsonly INSERT オペレーションのみを.CSV 出力ファイルに書き込むオプションの パラメータ デフォルトでは.CSV レコードの最初のフィールドに 文字 I (挿入) U (更新) または D (削除) が含まれ ソースデータベースで行が 挿入 更新 または削除されたかどうかを示します cdcinsertsonly が true に設定されている場合 INSERT のみが I 注釈なしで CSV ファイル に記録されます 例: cdcinsertsonly=true; compressiontype ターゲットファイルを圧縮するために GZIP を使用するオプションのパラ メータ NONE (デフォルト) に設定するか ファイルを解凍した状態にする ために使用しないでください 例: compressiontype=gzip; csvrowdelimiter ソースファイル内の行を分離するために使用される区切り文字 デフォルト は改行 (\n) です 例: csvrowdelimiter=\n; 174

181 ターゲットとしての Amazon DynamoDB の使用 オプション 説明 csvdelimiter ソースファイル内の列を分離するために使用される区切り文字 デフォルト ではカンマを使用します 例: csvdelimiter=,; maxfilesize 全ロードで S3 に移行中に作成される CSV ファイルの最大サイズ (KB 単位) を指定します デフォルト値: KB (1 GB) 有効な値: 例: maxfilesize=512 rfc4180 データが Amazon S3 に移行される RFC 準拠の動作を制御するために使用さ れるオプションパラメータ ターゲットとして Amazon S3 を使用すると データに引用符または改行文字がある場合 AWS DMS は列全体を追加の " で囲みます データ内のすべての引用符が 2 回が繰り返されます これは RFC 4180 に準拠しています デフォルト: true 例: rfc4180=false; AWS Database Migration Service のターゲットとして の Amazon DynamoDB データベースの使用 Amazon DynamoDB のテーブルにデータを移行するために AWS DMS を使用できます Amazon DynamoDB は 完全マネージド型の NoSQL データベースサービスであり 高速で予測可能なパフォーマ ンスとシームレスなスケーラビリティが特長です AWS DMS では ソースとしてリレーショナルデータ ベースや MongoDB を使用できます DynamoDB では テーブル 項目 および属性が 操作するコアコンポーネントです テーブルは項目の 集合であり 各項目は属性の集合です DynamoDB は テーブルの各項目を一意に識別するために パー ティションキーと呼ばれるプライマリキーを使用します より柔軟なクエリを提供するために キーおよ びセカンダリインデックスを使用することもできます ソースのデータベースから ターゲット DynamoDB テーブルにデータを移行するために オブジェクト のマッピングを使用します オブジェクトのマッピングを使用すると ソースデータがターゲットのどこ にあるか判定できます AWS DMS が Amazon DynamoDB ターゲットエンドポイントでテーブルを作成するときに ソースデー タベースのエンドポイントと同じ数のテーブルを作成します また AWS DMS はいくつかの Amazon DynamoDB パラメータ値も設定します テーブル作成のコストは データの量および移行するテーブルの 数によって異なります AWS DMS が移行タスクの Amazon DynamoDB パラメータ値を設定するときに デフォルトの読み込み キャパシティーユニット (RCU) パラメータ値が 200 に設定されます 175

182 ターゲットとしての Amazon DynamoDB の使用 書き込みキャパティティーユニット (WCU) のパラメータ値も設定されますが その値は他のいくつかの設 定によって異なります WCU パラメータのデフォルト値は 200 です parallelloadthreads パラメータが 1 より大きい値に設定された場合 (デフォルトは 0) WCU パラメー タは parallelloadthreads の値の 200 倍に設定されます 米国東部 (バージニア北部) リージョン (us-east-1) では 使用可能な最大 WCU パラメータ値は です AWS リージョンが us-east-1 で WCU パラメータが より大きい場合 WCU パラメータ 値は に設定されます us-east-1 以外の AWS リージョンでは 使用可能な最大 WCU パラメータは です us-east-1 以 外の AWS リージョンでは WCU パラメータが より大きい値に設定された場合 WCU パラメー タ値は に設定されます リレーショナルデータベースから DynamoDB テーブルへの移行 AWS DMS は DynamoDB のスカラーデータ型へのデータの移行をサポートしています Oracle や MySQL などのリレーショナルデータベースから DynamoDB に移行する場合は データを格納する方法を 再編成が必要となる場合があります 現在 AWS DMS は 単一テーブルから単一テーブルに移行する場合の DynamoDB のスカラー型属性へ の再構成をサポートしています リレーショナルデータベースのテーブルから DynamoDB にデータを移 行する場合 テーブルからデータを取得し DynamoDB のスカラーデータ型属性に形式を変更します こ れらの属性は複数の列からデータを受け入れることができるため 列を属性に直接マッピングすることが できます AWS DMS は以下の DynamoDB のスカラーデータ型をサポートしています 文字列 数値 Boolean Note ソースからの NULL データは ターゲットで無視されます AWS Database Migration Service のターゲットとして DynamoDB を使用する場合の前提条件 AWS DMS のターゲットとして DynamoDB データベースの操作を開始する前に 移行先の DynamoDB テーブルへのアクセスを AWS DMS が引き受けて許可できるようにする IAM ロールを必ず作成してくだ さい アクセス許可の最小設定は 次のサンプルロールのポリシーで示します ] "Version": " ", "Statement": [ "Effect": "Allow", "Principal": "Service": "dms.amazonaws.com", "Action": "sts:assumerole" 176

183 ターゲットとしての Amazon DynamoDB の使用 DynamoDB に移行する際に使用するロールには 次のアクセス許可が必要です "Version": " ", "Statement": [ "Effect": "Allow", "Action": [ "dynamodb:putitem", "dynamodb:createtable", "dynamodb:describetable", "dynamodb:deletetable", "dynamodb:deleteitem" ], "Resource": [ "arn:aws:dynamodb:us-west-2:account-id:table/name1", "arn:aws:dynamodb:us-west-2:account-id:table/othername*", ], ] "Effect": "Allow", "Action": [ "dynamodb:listtables" ], "Resource": "*" AWS Database Migration Service のターゲットとして DynamoDB を使用する場合の制限 ターゲットとして Amazon DynamoDB を使用する場合 以下の制限が適用されます DynamoDB は 数値データ型の最大精度を 38 に制限します 文字列として高い精度のすべてのデータ 型を保存します オブジェクトマッピング機能を使用して これを明示的に指定する必要があります Amazon DynamoDB に Date データ型はないため Date データ型を使用しているデータは 文字列に変 換されます Amazon DynamoDB はプライマリキー属性を更新しません この制限は ターゲットで不要なデータ が発生する可能性があるため 変更データキャプチャ (CDC) で継続的なレプリケーションを使用する 場合に重要です オブジェクトのマッピング方法に応じて プライマリキーを更新する CDC オペレー ションは失敗するか 更新されたプライマリキーと不完全なデータで新しい項目を挿入することができ ます AWS DMS は カスタムパーティションキーまたはソートキーまたはその両方を含むターゲットテー ブルにオブジェクトマッピングを指定しない限り 非複合プライマリキーを含むテーブルのレプリケー ションのみをサポートします AWS DMS は CLOB でない限り LOB データはサポートしません AWS DMS は データの移行時に CLOB データを DynamoDB 文字列に変換します DynamoDB にデータを移行するためのオブジェクトマッピング の使用 AWS DMS は ソースからターゲット DynamoDB テーブルにデータをマッピングするためのテーブ ルマッピングルールを使用します DynamoDB ターゲットにデータをマッピングするために object 177

184 ターゲットとしての Amazon DynamoDB の使用 mappingと呼ばれるテーブルマッピングルールのタイプを使用します オブジェクトマッピングにより 移行するデータの属性名とデータを定義できます オブジェクトマッピングを使用するときは選択ルール が必要です Amazon DynamoDB には パーティションのキーとオプションのソートキー以外に プリセット構造はあ りません 非複合プライマリキーが存在する場合は AWS DMS はそのキーを使用します 複合プライマ リキーがある場合 またはソートキーを使用する必要がある場合は ターゲット DynamoDB テーブルで それらのキーと他の属性を定義します オブジェクトマッピングルールを作成するには rule-typeobject-mappingとして指定します このルー ルが 使用したいるオブジェクトマッピングのタイプを指定します ルールの構造は次のとおりです "rules": [ "rule-type": "object-mapping", "rule-id": "<id>", "rule-name": "<name>", "rule-action": "<valid object-mapping rule action>", "object-locator": "schema-name": "<case-sensitive schema name>", "table-name": "", "target-table-name": "<table_name>", ] AWS DMS は現在 map-record-to-record および map-record-to-document を rule-action パラメー タの唯一の有効な値としてサポートしています map-record-to-record および map-record-to-document は exclude-columns 属性リストの一部として除外されていないレコードに AWS DMS がデフォルト で何をするかを指定します これらの値は どのような方法でも属性マッピングに影響を与えません map-record-to-record は リレーショナルデータベースから DynamoDB に移行する際に使用すること ができます Amazon DynamoDB のパーティションキーとしてリレーショナルデータベースからプラ イマリキーを使用し ソースデータベース内の各列の属性を作成します map-record-to-record を 使用する場合 exclude-columns 属性リストに示されていないソーステーブルのすべての列につい て AWS DMS は そのソース列が属性マッピングで使用されているかどうかにかかわらず ターゲッ ト DynamoDB インスタンス上に対応する属性を作成します map-record-to-document は 属性名 "_doc" を使用して ターゲット上の 1 つのフラット DynamoDB マップにソース列を配置します map-record-to-document を使用する場合 exclude-columns 属性リストに示されていないソーステーブル内のすべての列について AWS DMS は それらのデータ を "_doc" という名前のソース上の 1 つのフラットな DynamoDB マップ属性に設定します rule-action パラメータ map-record-to-record と map-record-to-document の間の相違を理解するための 1 つの方法は パラメータがどのように使用されているかを見ることです この例では 次の構造とデー タを含むリレーショナルデータベースのテーブルから始めると想定してください この情報を DynamoDB に移行するには データを DynamoDB テーブルにマッピングするルールを作成 します パラメータにリストされている exclude-columns 列を書き留めてください これらの列は ターゲットに直接マッピングされていません その代わりに データを組み合わせて新しい項目を作成 するために 属性マッピングが使用されています たとえば FirstName と LastName を組み合わせると DynamoDB ターゲット上の CustomerName になります NickName と income は除外されていません 178

185 ターゲットとしての Amazon DynamoDB の使用 "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "%", "rule-action": "include", "rule-type": "object-mapping", "rule-id": "1", "rule-name": "TransformToDDB", "rule-action": "map-record-to-record", "object-locator": "schema-name": "test", "table-name": "customer",, "target-table-name": "customer_t", "mapping-parameters": "partition-key-name": "CustomerName", "exclude-columns": [ "FirstName", "LastName", "HomeAddress", "HomePhone", "WorkAddress", "WorkPhone" ], "attribute-mappings": [ "target-attribute-name": "CustomerName", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "$FirstName,$LastName", "target-attribute-name": "ContactDetails", "attribute-type": "document", "attribute-sub-type": "dynamodb-map", "value": "M": "Home": "M": "Address": "S": "$HomeAddress", "Phone": "S": "$HomePhone", "Work": "M": "Address": "S": "$WorkAddress", "Phone": "S": "$WorkPhone" 179

186 ターゲットとしての Amazon DynamoDB の使用 ] ] rule-action パラメータ map-record-to-record を使用することで NickName および income のデータ は DynamoDB ターゲットで同じ名前の項目にマッピングされます ただし 同じルールを使用しますが rule-action パラメータを map-record-to-document に変更する とします この場合 exclude-columns パラメータ NickName および income にリストされない列 は _doc 項目にマッピングされます 180

187 ターゲットとしての Amazon DynamoDB の使用 オブジェクトマッピングでのカスタム条件式の使用 DynamoDB テーブルに書き込まれているデータを操作するための条件式と呼ばれる Amazon DynamoDB の機能を使用することができます DynamoDB の条件式の詳細については 条件式 を参照してくださ い 条件式のメンバーは次から構成されます 式 (必須) 式の属性値 (オプション)属性値の DynamoDB json 構造を指定します 式の属性名 (オプション) 条件式をいつ使用するかを選ぶオプション (オプション)デフォルトは apply-during-cdc = false および apply-during-full-load = true ルールの構造は次のとおりです "target-table-name": "customer_t", "mapping-parameters": "partition-key-name": "CustomerName", "condition-expression": "expression":"<conditional expression>", "expression-attribute-values": [ "name":"<attribute name>", "value":<attribute value> ], "apply-during-cdc":<optional Boolean value>, "apply-during-full-load": <optional Boolean value> 次のサンプルは 条件式に使用されるセクションを主に示しています 181

188 ターゲットとしての Amazon DynamoDB の使用 オブジェクトマッピングで属性マッピングを使用する 属性マッピングでは ターゲット上のデータを再編成するために ソース列名を使用してテンプレート文 字列を指定することができます ユーザーがテンプレートで指定する場合を除き 書式設定は行われませ ん 次の例は ソースデータベースの構造と DynamoDB ターゲットの必要とされる構造を示します 最初に 示すのは ソースの構造で この場合は Oracle データベースです 次に DynamoDB 内のデータの必要と される構造を示します この例では最後に 必要なターゲット構造を作成するのに使用される JSON を示 します Oracle データの構造は次のとおりです FirstName LastName StoreId HomeAddress HomePhone WorkAddressWorkPhone DateOfBirth プライ マリキー RandyMarsh5 該当なし 221B Baker Street Spooner Street, Quahog /29/

189 ターゲットとしての Amazon DynamoDB の使用 DynamoDB データの構造は次のとおりです CustomerName StoreId パー ティ ショ ン キー ContactDetails ソー トキー Randy,Marsh 5 DateOfBirth 該当なし "Name": "Randy", "Home": "Address": "221B Baker Street", "Phone": , "Work": "Address": "31 Spooner Street, Quahog", "Phone": /29/1988 次の JSON は DynamoDB 構造を達成するために使用されるオブジェクトマッピングと列マッピングを示 します "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "%", "rule-action": "include", "rule-type": "object-mapping", "rule-id": "2", "rule-name": "TransformToDDB", "rule-action": "map-record-to-record", "object-locator": "schema-name": "test", "table-name": "customer", "target-table-name": "customer_t", "mapping-parameters": "partition-key-name": "CustomerName", "sort-key-name": "StoreId", "exclude-columns": [ "FirstName", "LastName", "HomeAddress", "HomePhone", "WorkAddress", "WorkPhone" ], "attribute-mappings": [ 183

190 ターゲットとしての Amazon DynamoDB の使用 "target-attribute-name": "CustomerName", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "$FirstName,$LastName", "target-attribute-name": "StoreId", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "$StoreId", "target-attribute-name": "ContactDetails", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "\"Name\":\"$FirstName\",\"Home\":\"Address\":\"$HomeAddress\", \"Phone\":\"$HomePhone\", \"Work\":\"Address\":\"$WorkAddress\",\"Phone\": \"$WorkPhone\"" ] ] 列マッピングを使用するもう 1 つの方法は ドキュメントタイプとして DynamoDB 形式を使用すること です 次のコード例では 属性マッピングの attribute-sub-type としてdynamodb-map を使用しま す "rules": [ "rule-type": "object-mapping", "rule-id": "1", "rule-name": "TransformToDDB", "rule-action": "map-record-to-record", "object-locator": "schema-name": "test", "table-name": "customer",, "target-table-name": "customer_t", "mapping-parameters": "partition-key-name": "CustomerName", "sort-key-name": "StoreId", "exclude-columns": [ "FirstName", "LastName", "HomeAddress", "HomePhone", "WorkAddress", "WorkPhone" ], "attribute-mappings": [ "target-attribute-name": "CustomerName", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "$FirstName,$LastName", 184

191 ターゲットとしての Amazon DynamoDB の使用 "target-attribute-name": "StoreId", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "$StoreId", ] ] "target-attribute-name": "ContactDetails", "attribute-type": "document", "attribute-sub-type": "dynamodb-map", "value": "M": "Name": "S": "$FirstName" "Home": "M": "Address": "S": "$HomeAddress", "Phone": "S": "$HomePhone", "Work": "M": "Address": "S": "$WorkAddress", "Phone": "S": "$WorkPhone" 例1: オブジェクトマッピングで属性マッピングを使用する 次の例は 2 つの MySQL データベーステーブル nfl_data と sport_team のデータを NFLTeams と SportTeams という 2 つの DynamoDB テーブルへ移行します テーブルの構造 および MySQL データ ベーステーブルから DynamoDB テーブルへデータをマップするために使用される JSON は 次のとおり です MySQL データベース nfl_data の構造は次のとおりです mysql> desc nfl_data; Field Type Null Key Default Extra Position varchar(5) YES NULL player_number smallint(6) YES NULL Name varchar(40) YES NULL status varchar(10) YES NULL 185

192 ターゲットとしての Amazon DynamoDB の使用 stat1 varchar(10) YES NULL stat1_val varchar(10) YES NULL stat2 varchar(10) YES NULL stat2_val varchar(10) YES NULL stat3 varchar(10) YES NULL stat3_val varchar(10) YES NULL stat4 varchar(10) YES NULL stat4_val varchar(10) YES NULL team varchar(10) YES NULL MySQL データベーステーブルsport_team の構造は次のとおりです mysql> desc sport_team; Field Type Null Key Default Extra id mediumint(9) NO PRI NULL auto_increment name varchar(30) NO NULL abbreviated_name varchar(10) YES NULL home_field_id smallint(6) YES MUL NULL sport_type_name varchar(15) NO MUL NULL sport_league_short_name varchar(10) NO NULL sport_division_short_name varchar(10) YES NULL 2 つのテーブルを 2 つの DynamoDB テーブルにマッピングするために使用されるテーブルマッピングルー ルは次のとおりです "rules":[ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "dms_sample", "table-name": "nfl_data", "rule-action": "include", "rule-type": "selection", "rule-id": "2", "rule-name": "2", "object-locator": "schema-name": "dms_sample", "table-name": "sport_team", "rule-action": "include", "rule-type":"object-mapping", "rule-id":"3", "rule-name":"mapnfldata", "rule-action":"map-record-to-record", "object-locator": "schema-name":"dms_sample", "table-name":"nfl_data", 186

193 ターゲットとしての Amazon DynamoDB の使用 "target-table-name":"nflteams", "mapping-parameters": "partition-key-name":"team", "sort-key-name":"playername", "exclude-columns": [ "player_number", "team", "Name" ], "attribute-mappings":[ "target-attribute-name":"team", "attribute-type":"scalar", "attribute-sub-type":"string", "value":"$team", "target-attribute-name":"playername", "attribute-type":"scalar", "attribute-sub-type":"string", "value":"$name", "target-attribute-name":"playerinfo", "attribute-type":"scalar", "attribute-sub-type":"string", "value":"\"number\": \"$player_number\",\"position\": \"$Position\", \"Status\": \"$status\",\"stats\": \"Stat1\": \"$stat1:$stat1_val\",\"stat2\": \"$stat2:$stat2_val\",\"stat3\": \"$stat3:$ stat3_val\",\"stat4\": \"$stat4:$stat4_val\"" ], "rule-type":"object-mapping", "rule-id":"4", "rule-name":"mapsportteam", "rule-action":"map-record-to-record", "object-locator": "schema-name":"dms_sample", "table-name":"sport_team", "target-table-name":"sportteams", "mapping-parameters": "partition-key-name":"teamname", "exclude-columns": [ "name", "id" ], "attribute-mappings":[ "target-attribute-name":"teamname", "attribute-type":"scalar", "attribute-sub-type":"string", "value":"$name", "target-attribute-name":"teaminfo", "attribute-type":"scalar", "attribute-sub-type":"string", "value":"\"league\": \"$sport_league_short_name\",\"division\": \"$sport_division_short_name\"" ] ] 187

194 ターゲットとしての Amazon DynamoDB の使用 NFLTeams DynamoDB テーブルの出力例は次のとおりです "PlayerInfo": "\"Number\": \"6\",\"Position\": \"P\",\"Status\": \"ACT\",\"Stats\": \"Stat1\": \"PUNTS:73\",\"Stat2\": \"AVG:46\",\"Stat3\": \"LNG:67\",\"Stat4\": \"IN 20:31\"", "PlayerName": "Allen, Ryan", "Position": "P", "stat1": "PUNTS", "stat1_val": "73", "stat2": "AVG", "stat2_val": "46", "stat3": "LNG", "stat3_val": "67", "stat4": "IN 20", "stat4_val": "31", "status": "ACT", "Team": "NE" SportsTeams DynamoDB テーブルの出力例は次のとおりです "abbreviated_name": "IND", "home_field_id": 53, "sport_division_short_name": "AFC South", "sport_league_short_name": "NFL", "sport_type_name": "football", "TeamInfo": "\"League\": \"NFL\",\"Division\": \"AFC South\"", "TeamName": "Indianapolis Colts" Amazon DynamoDB のターゲットデータ型 Amazon AWS DMS の Amazon DynamoDB エンドポイントでは Amazon DynamoDB のほとんどのデー タ型がサポートされます 以下の表に AWS DMS を使用する場合にサポートされる Amazon AWS DMS のターゲットデータ型と AWS DMS のデータ型からのデフォルトマッピングを示します AWS DMS のデータ型の詳細については AWS Database Migration Service のデータ型 (p. 301) を 参照してください AWS DMS が異なるデータベースからデータを移行するときは ソースデータベースからのデータ型 を AWS DMS データ型という中間のデータ型にマッピングします その後 中間データ型をターゲッ トデータ型にマッピングします 以下の表は 各 AWS DMS データ型と DynamoDB でのマッピング先の データ型を示しています AWS DMS データ型 DynamoDB データ型 文字列 文字列 WString 文字列 Boolean Boolean 188

195 ソースおよびターゲットエンドポイントの作成 AWS DMS データ型 DynamoDB データ型 日付 文字列 DateTime 文字列 INT1 数値 INT2 数値 INT4 数値 INT8 数値 数値 数値 Real4 数値 Real8 数値 UINT1 数値 UINT2 数値 UINT4 数値 UINT8 数値 CLOB 文字列 ソースおよびターゲットエンドポイントの作成 レプリケーションインスタンスの作成時にソースエンドポイントとターゲットエンドポイントを作成する ことができます また レプリケーションインスタンスの作成後にエンドポイントを作成することもでき ます ソースおよびターゲットデータストアには Amazon Elastic Compute Cloud (Amazon EC2) インス タンス Amazon Relational Database Service (Amazon RDS) DB インスタンス またはオンプレミスデー タベースを使用できます 以下の手順では AWS DMS コンソールウィザードを選択したことを前提とします このステップは コ ンソールのナビゲーションペインで [Endpoints (エンドポイント)AWS DMS] [Create endpoint (エンドポ イントの作成)] の順に選択することでも実行できます コンソールウィザードを使用するときは ソース エンドポイントとターゲットエンドポイントの両方を同じページで作成します コンソールウィザードを 使用しないときは 各エンドポイントを個別に作成します AWS コンソールを使用して ソースまたはターゲットデータベースエンドポイントを指定するに は 1. [ソースおよびターゲットデータベースエンドポイントの接続] ページで ソースまたはターゲット データベースの接続情報を指定します 次の表で設定について説明します 189

196 ソースおよびターゲットエンドポイントの作成 使用するオプション 操作 エンドポイントタイプ このエンドポイントに対して ソースエンドポイントまた はターゲットエンドポイントを選択します RDS DB インスタンスの選択 エンドポイントが Amazon RDS DB インスタンスの場合 は このオプションを選択します エンドポイント識別子 エンドポイントを識別するのに使用する名前を入力し ます 名前に oracle-source または PostgreSQLtarget などのエンドポイントの種類を含めることができ ます 名前はすべてのレプリケーションインスタンスに対 して一意である必要があります ソースエンジンとターゲットエンジン エンドポイントであるデータベースエンジンのタイプを選 択します サーバー名 サーバー名を入力します オンプレミスデータベースの場 合 IP アドレスまたはパブリックホスト名にすることが できます Amazon RDS DB インスタンスの場合 DB イ ンスタンスのエンドポイント (DNS 名) とすることができ ます たとえば mysqlsrvinst.abcd uswest-2.rds.amazonaws.com とします ポート データベースが使用するポートを入力します 190

197 ソースおよびターゲットエンドポイントの作成 2. 使用するオプション 操作 SSL モード このエンドポイントの接続暗号化を有効にする場合 は SSL モードを選択します 選択したモードにより 証 明書 およびサーバー証明書情報の提供を求められること があります ユーザー名 データ移行を許可するために必要な権限を持つユーザー 名を入力します 必要な権限の詳細については このユー ザーガイドの ソースまたはターゲットデータベースエン ジンに対するセキュリティセクション を参照してくださ い パスワード 必要な権限のあるアカウントのパスワードを入力します パスワード内に特殊文字 ("+" や "&" など) を使用する場合 は パスワード全体を中かっこ "" で囲みます データベース名 エンドポイントとして使用するデータベースの名前 必要がある場合は 次に示す通り [Advanced] タブを選択して 接続文字列および暗号化キーの値を 設定します [テストの実行] を選択して エンドポイントの接続をテストできます 191

198 ソースおよびターゲットエンドポイントの作成 使用するオプション 操作 追加の接続属性 追加の接続パラメータをここに入力します 追加の接続属 性の詳細については データストアのドキュメントセク ションを参照してください KMS マスターキー 使用する暗号化キーを選択して レプリケーションのスト レージと接続情報を暗号化します (デフォルト) aws/dms を選択する場合 アカウントおよびリージョンに関連付け られたデフォルトの AWS Key Management Service (AWS KMS) キーが使用されます 暗号化キーの使用の詳細につ いては 暗号化キーの設定と KMS のアクセス許可の指 定 (p. 45) を参照してください エンドポイント接続のテスト (オプ ション) VPC およびレプリケーションインスタンス名を追加しま す 接続をテストするには [テストの実行] を選択しま す 192

199 AWS DMS タスクの使用 AWS Database Migration Service (AWS DMS) タスクは すべての処理が行われる場所です ログ記録要 件 制御テーブルデータ エラー処理など 移行と特別な処理に使用するテーブルとスキーマを指定しま す 移行タスクを作成するとき いくつかのことを知っておく必要があります 移行タスクを作成する前に ソースエンドポイント ターゲットエンドポイント およびレプリケー ションインスタンスを作成する必要があります 移行タスクを調整するために多くのタスク設定を指定できます それらは AWS マネジメントコンソー ル AWS Command Line Interface (AWS CLI) または AWS DMS API を使用して設定できます これ らの設定には 移行エラーの処理方法 エラーのログ記録 および制御テーブル情報を指定することが 含まれます タスクを作成した後 直ちに実行できます 必要なメタデータ定義を含むターゲットテーブルが自動的 に作成されてロードされるため 継続的なレプリケーションを指定できます デフォルトでは タスクを作成するとすぐに AWS DMS によりタスクが開始されます ただし 状況 によっては タスクの開始を延期できます たとえば AWS CLI を使用するとき タスクを作成するプ ロセスと トリガーイベントに基づいてタスクを開始する別のプロセスが存在する場合があります 必 要に応じて タスクの開始を延期できます AWS DMS コンソール AWS CLI または AWS DMS API を使用して タスクのモニタリング 停止 再開を行うことができます AWS DMS タスクを操作するときに実行できるアクションを以下に示します タスク 関連資料 タスク評価レポートの作成 タスク評価レポートの作成 (p. 194) 移行中に問題を発生させる可能性のあ る サポートされていないデータ型を示 すタスク評価レポートを作成できます タスクを実行する前にタスクでこのレ ポートを実行して 潜在的な問題を見つ けることができます タスクの作成 タスクの作成 (p. 197) タスクを作成するときに ソース ター ゲット およびレプリケーションインス タンスを 移行設定とともに作成しま す 継続的なレプリケーションのタスク作成 ソースとターゲット間で 継続的なレプ リケーションを提供するようにタスクを セットアップできます タスク設定の適用 各タスクには データベース移行の必要 に応じて設定できる設定があります こ AWS DMS を使用した継続的なレプリケーション用のタスク の作成 (p. 219) AWS Database Migration Service タスク設定の指 定 (p. 203) 193

200 タスク評価レポートの作成 タスク 関連資料 れらの設定は JSON ファイルで作成しま す その一部の設定は AWS DMS コン ソールで指定できます データ検証 AWS DMS タスクの検証 (p. 253). データ検証は AWS DMS でターゲット データストア上のデータを ソースデー タストアからのデータと比較するために 使用できるタスク設定です タスクの変更 タスクの変更 (p. 222) タスクが停止した際に そのタスクの設 定を変更できます タスク実行中のテーブル再ロード タスク実行中のテーブルの再ロード (p. 222) タスク実行中にエラーが発生した場合に は タスク実行中にテーブルを再ロード できます テーブルマッピングの使用 テーブルマッピングは データソース ソーススキーマ データ そしてタスク 実行中に必要なすべての変換を指定する ための複数のルールタイプを使用しま す フィルタの適用 ルールの選択 選択ルールと選択アクション (p. 229) 変換ルール 変換ルールおよび変換アクション (p. 231) ソースフィルタの使用 (p. 237) ソースフィルタを使用すると ソースか らターゲットに転送されるレコードの数 とタイプを制限できます たとえば 本 社を拠点とする従業員だけがターゲット データベースに移行されるように指定で きます データの列にフィルタを適用し ます タスクのモニタリング AWS DMS タスクのモニタリング (p. 241) タスクのパフォーマンスとそのタスクが 使用するテーブルに関する情報を取得す るためには 複数の方法があります タスクログの管理 AWS DMS タスクログの管理 (p. 248) AWS DMS API または AWS CLI を使用 してタスクログを表示および削除するこ とができます タスク評価レポートの作成 タスク評価機能によって 正しく移行されない可能性があるデータ型が識別されます タスクの評価中 に AWS DMS はソースデータベーススキーマを読み取り データ型のリストを作成します 次に こ 194

201 タスク評価レポートの作成 のリストが AWS DMS でサポートされているデータ型の事前に定義されたリストと比較されます ま た AWS DMS は移行タスクにサポートされていないデータ型があるかどうかを確認できるレポートが作 成されます タスクの評価レポートには サポートされていないデータ型と 各データ型の列数を一覧表示する概要が 含まれます サポートされていない各データ型について JSON のデータ構造のリストが含まれます こ のレポートを使用してソースデータ型を変更し 移行プロセスを向上させることができます サポートされていないデータ型のレベルは 2 つあります レポートに サポートされていない と表示 されたデータ型を移行することはできません レポートに 部分的にサポートされている と表示された データ型は別のデータ型に変換できる場合もありますが 予期どおり移行されない可能性があります タスクの評価レポートの例を次に示します "summary": "task-name":"test15", "not-supported": "data-type": [ "sql-variant" ], "column-count":3, "partially-supported": "data-type":[ "float8", "jsonb" ], "column-count":2, "types":[ "data-type":"float8", "support-level":"partially-supported", "schemas":[ "schema-name":"schema1", "tables":[ "table-name":"table1", "columns":[ "column1", "column2" ], "table-name":"table2", "columns":[ "column3", "column4" ] ], "schema-name":"schema2", "tables":[ "table-name":"table3", "columns":[ "column5", "column6" ] 195

202 タスク評価レポートの作成,, ] ] ] "table-name":"table4", "columns":[ "column7", "column8" ] "datatype":"int8", "support-level":"partially-supported", "schemas":[ "schema-name":"schema1", "tables":[ "table-name":"table1", "columns":[ "column9", "column10" ], "table-name":"table2", "columns":[ "column11", "column12" ] ] ] 最新のタスク評価レポートは AWS コンソールにある [タスクページ] の [評価] タブから表示できま す AWS DMS は Amazon S3 バケットに前のタスク評価レポートを保存します Amazon S3 バケット名 は次の形式になります dms-<customerid>-<customerdns> このレポートは タスク名で名前が付けられたフォルダ内のバケットに保存されます レポートのファイ ル名は yyyy-mm-dd-hh-mm 形式の評価日です Amazon S3 コンソールから 以前のタスク評価レポート を表示 比較できます また AWS DMS では S3 バケットへのアクセスを許可するために AWS Identity and Access Management (IAM) ロールが作成されます このロール名は dms-access-for-tasks です このロールでは AmazonDMSRedshiftS3Role ポリシーが使用されます AWS コンソール AWS CLI または DMS API を使用してタスク評価機能を有効にできます コンソールで タスクの作成時または変更時に [Task Assessment] を選択します コンソールを使 用してタスク評価レポートを表示するには [Tasks] ページでタスクを選択し 詳細セクションの [Assessment results] タブを選択します CLI コマンドは タスクの評価を開始する start-replication-task-assessment と タスク評価 レポートを JSON 形式で受け取る describe-replication-task-assessment-results です 196

203 タスクの作成 AWS DMS API は StartReplicationTaskAssessment アクションを使用してタスク評価を開始 し DescribeReplicationTaskAssessment アクションを使用して JSON 形式でタスク評価レポー トを受け取ります タスクの作成 AWS DMS 移行タスクを作成するためには いくつかの操作を行う必要があります 移行タスクを作成する前に ソースエンドポイント ターゲットエンドポイント およびレプリケー ションインスタンスを作成します 移行方法を選択します データをターゲットデータベースに移行する このプロセスでは ターゲットデータベースにファ イルまたはテーブルを作成し ターゲットで必要なメタデータを自動的に定義します また ソー スのデータをテーブルに入力します テーブルのデータは 効率を高めるために並列でロードされま す このプロセスは AWS コンソールでは [Migrate existing data] オプションとなっており API で は Full Load と呼ばれています 移行中に変更をキャプチャする このプロセスでは データがソースからターゲットに移行されてい るときに発生した変更をソースデータベースにキャプチャします 最初にリクエストされたデータの 移行が完了すると 変更データキャプチャ (CDC) プロセスがキャプチャした変更をターゲットデータ ベースに適用します 変更は 1 つのコミットされたトランザクションユニットとしてキャプチャお よび適用され 複数の異なるターゲットテーブルを 1 つのソースコミットとして更新できます この アプローチでは ターゲットデータベースにおけるトランザクションの完全性が保証されます この プロセスは AWS コンソールでは [Migrate existing data and replicate ongoing changes] オプション となっており API では full-load-and-cdc と呼ばれています データ変更のみソースデータベースにレプリケートする このプロセスでは ソースデータベース 管理システム (DBMS) の復旧ログファイルを読み取り 各トランザクションのエントリをまとめま す 場合によっては AWS DMS が妥当な時間内にターゲットに変更を適用できない場合があります (ターゲットにアクセスできない場合など) このような場合 AWS DMS は必要な限り変更をレプリ ケーションサーバーにバッファします DBMS ログを再読み取りしないため 長時間かかる可能性が あります このプロセスでは AWS DMS コンソールで [Replicate data changes only (データ変更の みをレプリケートする)] オプションが選択されています ソースでラージバイナリオブジェクト (LOB) を処理する方法を決定します 詳細については AWS DMS タスクのソースデータベースの LOB サポートの設定 (p. 218) を参照してください 移行タスクの設定を指定します これには ログ記録の設定 移行の制御テーブルに書き込まれるデー タ エラーの処理方法 およびその他の設定が含まれます タスク設定の詳細については AWS Database Migration Service タスク設定の指定 (p. 203) を参照してください テーブルマッピングを設定して 選択するルールを定義し 移行するデータをフィルタします テーブルマッピングの詳細については テーブルマッピングを使用して タスクの設定を指定す る (p. 224) を参照してください マッピングを指定する前に ソースデータベースとターゲットデー タベースのデータ型マッピングのドキュメントセクションを確認してください [タスクの作成] ページでタスクへの情報の指定が完了するとすぐにタスクを開始することができます ま たは タスク情報の指定が完了した後に [ダッシュボード] ページからタスクを開始することができます 以下の手順では AWS DMS コンソールウィザードを選択し コンソールウィザードを使用してレプリ ケーションインスタンスの情報とエンドポイントを指定したことを前提とします このステップは AWS DMS コンソールのナビゲーションペインで [タスク] [タスクの作成] を順に選択して実行することもでき ます 移行タスクを作成するには 1. [Create Task] ページで タスクオプションを指定します 次の表で設定について説明します 197

204 タスクの作成 2. 使用するオプション 操作 タスク名 タスクの名前を入力します タスクの説明 タスクの説明を入力します ソースエンドポイント 使用するソースエンドポイントを表示します ターゲットエンドポイント 使用するターゲットエンドポイントを表示します レプリケーションインスタンス 使用するレプリケーションインスタンスを表示します 移行タイプ 使用する移行方法を選択します 既存のデータのみをター ゲットデータベースへ移行するか 移行したデータに加え て継続的な変更もターゲットデータベースに送信するかを 選択できます 作成時にタスクを開始 このオプションが選択されていると タスクは作成直後に 始まります 次に示すように [Task Settings] タブを選択して ターゲットテーブルの値 LOB サポートを指定し て ログ作成を有効にします 表示されるタスク設定は 選択した移行タイプの値によって異なりま す たとえば [既存のデータの移行] を選択すると 次のオプションが表示されます 198

205 タスクの作成 199

206 タスクの作成 使用するオプション 操作 ターゲットテーブル作成モード [何もしない] [何もしない] モードの場合 AWS DMS で はターゲットテーブルがターゲットで事前に作成されてい ることを前提とします 移行が全ロードまたは全ロード + CDC である場合は 移行を開始する前にターゲットテー ブルが空であることを確認する必要があります 何もし ないモードは CDC のみのタスクに適切な選択肢です この場合 ターゲットテーブルはソースからバックフィル され ソースとターゲットの同期を維持するために継続的 なレプリケーションが適用されます ターゲットテーブル を事前に作成するには AWS スキーマ変換ツール (AWS SCT) を使用できます [ターゲット上のテーブルを削除] [ターゲット上のテーブ ルを削除] モードの場合 AWS DMS はターゲットテーブ ルを削除し これらを移行の開始前に再作成します これ により 移行の開始時にターゲットテーブルは確実に空に なります AWS DMS は データの効率的な移行に必要 なオブジェクト (テーブル プライマリキー および必要 に応じて一意のインデックス) のみを作成します テーブ ル プライマリキー 場合によっては一意のインデックス を作成します AWS DMS は セカンダリインデックス 非プライマリキーの制約 列データのデフォルトは作成し ません 全ロード + CDC のタスクまたは CDC のみのタ スクを実行する場合は 移行を一時停止し 更新および削 除のステートメントのフィルタ処理をサポートするセカン ダリインデックスを作成することをお勧めします [ターゲット上のテーブルを削除] モードを使用する場合 は 必要に応じてターゲットデータベースで一部の設定を 行います たとえば Oracle ターゲットの場合 セキュ リティ上の理由から AWS DMS はスキーマ (データベース ユーザー) を作成できません この場合 移行の開始時に AWS DMS でテーブルを作成できるように スキーマユー ザーを事前に作成する必要があります 他の大半のター ゲットタイプの場合 AWS DMS は適切な設定パラメータ を使用してスキーマおよびすべての関連するテーブルを作 成します [切り捨て] [切り捨て] モードの場合 AWS DMS は移 行の開始前にすべてのターゲットテーブルを切り捨てま す 切り捨てモードは全ロードまたは全ロード + CDC の 移行に適しています この場合 移行の開始前にターゲッ トスキーマは作成済みとします ターゲットテーブルを事 前に作成するには AWS スキーマ変換ツール (AWS SCT) を使用できます 200

207 タスクの作成 使用するオプション 操作 レプリケーションに LOB 列を含める [LOB 列を含めない] LOB 列は移行対象から除外されま す [完全 LOB モード] サイズに関係なく LOB 全体を移行し ます AWS DMS は [最大 LOB サイズ] パラメータで制 御されるチャンクの単位で LOB を移行します このモー ドは制限付き LOB モードを使用するよりも低速です [制限付き LOB モード] LOB を [最大 LOB サイズ] パラ メータの値まで切り詰めます このモードは完全 LOB モードを使用するよりも高速です 最大 LOB サイズ (KB) [制限付き LOB モード] では [最大 LOB サイズ] の設定を 超える LOB 列は指定した [最大 LOB サイズ] まで切り捨て られます 検証の有効化 データの検証を有効にして ソースからターゲットにデー タが正確に移行されることを確認します 詳細について は AWS DMS タスクの検証 (p. 253) を参照してく ださい ログ作成の有効化 Amazon CloudWatch でログ作成を有効にします [既存のデータの移行とレプリケート] を [移行タイプ] で選択した場合 次のオプションが表示されま す 201

208 タスクの作成 使用するオプション 操作 ターゲットテーブル作成モード [何もしない] ターゲットテーブルのデータとメタデータ は変更されません [ターゲット上のテーブルを削除] テーブルは削除され 代わりに新しいテーブルが作成されます [切り捨て] テーブルは テーブルのメタデータに影響を 与えないで切り捨てられます 全ロードの完了後にタスクを停止する [停止しない] タスクを停止せず キャッシュされた変更 をすぐに適用したら そのまま続行します [キャッシュされた変更を適用する前に停止する] - キャッ シュされた変更を適用する前に タスクを停止します こ の方法を使用して 変更の適用を高速化する可能性がある セカンダリインデックスを追加できます キャッシュされた変更を適用した後に停止する - キャッ シュされた変更を適用した後に タスクを停止します ト ランザクショナルな適用を使用する場合 この方法を使用 して 外部キーやトリガーなどを追加できます レプリケーションに LOB 列を含める [LOB 列を含めない] LOB 列は移行対象から除外されま す [完全 LOB モード] サイズに関係なく LOB 全体を移行し ます LOB は LOB チャンクサイズによって制御される チャンクの単位で移行されます この方法は制限付き LOB モードを使用するよりも低速です [制限付き LOB モード] LOB を 最大 LOB サイズ まで 切り詰めます この方法は完全 LOB モードを使用するよ りも高速です 3. 最大 LOB サイズ (KB) [制限付き LOB モード] では [最大 LOB サイズ] の設定を 超える LOB 列は指定した [最大 LOB サイズ] まで切り捨て られます 検証の有効化 データの検証を有効にして ソースからターゲットにデー タが正確に移行されることを確認します 詳細について は AWS DMS タスクの検証 (p. 253) を参照してく ださい ログ作成の有効化 Amazon CloudWatch でログ作成を有効にします 次に示す通り [テーブルマッピング] タブを選択して スキーママッピングの値およびマッピング方 法を設定します [カスタム] を選択した場合 ターゲットスキーマとテーブル値を指定できます テーブルマッピングの詳細については テーブルマッピングを使用して タスクの設定を指定す る (p. 224) を参照してください 202

209 タスク設定 4. タスクの設定を完了した後 [タスクの作成] を選択します AWS Database Migration Service タスク設定の指定 各タスクには データベース移行の必要に応じて設定できる設定があります これらの設定は JSON ファ イルで作成します その一部の設定は AWS DMS コンソールで指定できます 以下に示すように タスク設定には いくつかの主要なタイプがあります トピック ターゲットメタデータのタスク設定 (p. 206) 全ロードタスク設定 (p. 207) ログ記録タスク設定 (p. 207) テーブルの並列ロード (p. 209) 制御テーブルタスク設定 (p. 209) ストリームバッファタスク設定 (p. 212) 変更処理のチューニング設定 (p. 212) データ検証タスクの設定 (p. 213) 変更処理の DDL 処理のタスク設定 (p. 214) エラー処理タスクの設定 (p. 214) タスク設定の保存 (p. 216) タスク設定 関連資料 タスク評価レポートの作成 タスク評価レポートの作成 (p. 194) 移行中に問題を発生させる可能性のあ る サポートされていないデータ型を示 すタスク評価レポートを作成できます タスクを実行する前にタスクでこのレ ポートを実行して 潜在的な問題を見つ けることができます タスクの作成 タスクの作成 (p. 197) タスクを作成するときに ソース ター ゲット およびレプリケーションインス タンスを 移行設定とともに作成しま す 203

210 タスク設定 タスク設定 関連資料 継続的なレプリケーションのタスク作成 AWS DMS を使用した継続的なレプリケーション用のタスク の作成 (p. 219) ソースとターゲット間で 継続的なレプ リケーションを提供するようにタスクを セットアップできます タスク設定の適用 各タスクには データベース移行の必要 に応じて設定できる設定があります こ れらの設定は JSON ファイルで作成しま す その一部の設定は AWS DMS コン ソールで指定できます データ検証 AWS Database Migration Service タスク設定の指 定 (p. 203) AWS DMS タスクの検証 (p. 253). データ検証は AWS DMS でターゲット データストア上のデータを ソースデー タストアからのデータと比較するために 使用できるタスク設定です タスクの変更 タスクの変更 (p. 222) タスクが停止した際に そのタスクの設 定を変更できます タスク実行中のテーブル再ロード タスク実行中のテーブルの再ロード (p. 222) タスク実行中にエラーが発生した場合に は タスク実行中にテーブルを再ロード できます テーブルマッピングの使用 テーブルマッピングは データソース ソーススキーマ データ およびタスク 実行中に必要なすべての変換のタスク設 定を指定するための複数のルールタイプ を使用します フィルタの適用 ルールの選択 選択ルールと選択アクション (p. 229) 変換ルール 変換ルールおよび変換アクション (p. 231) ソースフィルタの使用 (p. 237) ソースフィルタを使用すると ソースか らターゲットに転送されるレコードの数 とタイプを制限できます たとえば 本 社を拠点とする従業員だけがターゲット データベースに移行されるように指定で きます データの列にフィルタを適用し ます タスクのモニタリング AWS DMS タスクのモニタリング (p. 241) タスクのパフォーマンスとそのタスクが 使用するテーブルに関する情報を取得す るためには 複数の方法があります 204

211 タスク設定 タスク設定 関連資料 タスクログの管理 AWS DMS タスクログの管理 (p. 248) AWS DMS API または AWS CLI を使用 してタスクログを表示および削除するこ とができます タスクの設定の JSON ファイルは次のようになります "TargetMetadata": "TargetSchema": "", "SupportLobs": true, "FullLobMode": false, "LobChunkSize": 64, "LimitedSizeLobMode": true, "LobMaxSize": 32, "BatchApplyEnabled": true, "FullLoadSettings": "TargetTablePrepMode": "DO_NOTHING", "CreatePkAfterFullLoad": false, "StopTaskCachedChangesApplied": false, "StopTaskCachedChangesNotApplied": false, "MaxFullLoadSubTasks": 8, "TransactionConsistencyTimeout": 600, "CommitRate": 10000, "Logging": "EnableLogging": false, "ControlTablesSettings": "ControlSchema":"", "HistoryTimeslotInMinutes":5, "HistoryTableEnabled": false, "SuspendedTablesTableEnabled": false, "StatusTableEnabled": false, "StreamBufferSettings": "StreamBufferCount": 3, "StreamBufferSizeInMB": 8, "ChangeProcessingTuning": "BatchApplyPreserveTransaction": true, "BatchApplyTimeoutMin": 1, "BatchApplyTimeoutMax": 30, "BatchApplyMemoryLimit": 500, "BatchSplitSize": 0, "MinTransactionSize": 1000, "CommitTimeout": 1, "MemoryLimitTotal": 1024, "MemoryKeepTime": 60, "StatementCacheSize": 50, "ChangeProcessingDdlHandlingPolicy": "HandleSourceTableDropped": true, "HandleSourceTableTruncated": true, "HandleSourceTableAltered": true, "ValidationSettings": "EnableValidation": false, 205

212 タスク設定 "ThreadCount": 5, "ErrorBehavior": "DataErrorPolicy": "LOG_ERROR", "DataTruncationErrorPolicy":"LOG_ERROR", "DataErrorEscalationPolicy":"SUSPEND_TABLE", "DataErrorEscalationCount": 50, "TableErrorPolicy":"SUSPEND_TABLE", "TableErrorEscalationPolicy":"STOP_TASK", "TableErrorEscalationCount": 50, "RecoverableErrorCount": 0, "RecoverableErrorInterval": 5, "RecoverableErrorThrottling": true, "RecoverableErrorThrottlingMax": 1800, "ApplyErrorDeletePolicy":"IGNORE_RECORD", "ApplyErrorInsertPolicy":"LOG_ERROR", "ApplyErrorUpdatePolicy":"LOG_ERROR", "ApplyErrorEscalationPolicy":"LOG_ERROR", "ApplyErrorEscalationCount": 0, "FullLoadIgnoreConflicts": true ターゲットメタデータのタスク設定 ターゲットメタデータ設定には 以下のものが含まれます TargetSchema ターゲットテーブルスキーマ名 このメタデータオプションが空の場合 ソーステー ブルのスキーマが使用されます AWS DMS は ソーススキーマが定義されていない場合 ターゲッ トデータベースの所有者プレフィックスをすべてのテーブルに自動的に追加します このオプション は MySQL 型のターゲットエンドポイントでは空のままにする必要があります LOB settings ラージオブジェクト (LOB) の管理方法を決定する設定 SupportLobs=true と設定 した場合 次のいずれかを true に設定する必要があります FullLobMode このオプションを true に設定した場合 LobChunkSize オプションの値を入力す る必要があります ターゲットにデータをレプリケートするときに使用する LOB チャンクサイズを キロバイト単位で入力します FullLobMode オプションは LOB のサイズが大きい場合に最適です が ロードが遅くなる傾向になります InlineLobMaxSize この値は 全ロード中にどの LOB AWS Database Migration Service が インライン転送するかを決定します 小さな LOB は ソーステーブルから探すよりも転送する 方が効率的です 全ロード中 AWS Database Migration Service はすべての LOB をチェック して InlineLobMaxSize より小さい LOB にインライン転送を実行します AWS Database Migration Service は InlineLobMaxSize を超えるすべての LOB を FullLobMode で 転送し ます InlineLobMaxSize のデフォルト値は 0 で 範囲は 1 キロバイト 2 ギガバイトです ほとんどの LOB が InlineLobMaxSize で設定した値よりも小さいことがわかっている場合の み InlineLobMaxSize に値を指定します LimitedSizeLobMode このオプションを true に設定した場合 LobMaxSize オプションの値を 入力する必要があります 個々の LOB の最大サイズをキロバイト単位で入力します LoadMaxFileSize ディスクに保存されるアンロードデータ (CSV ファイルなど) の最大サイズを定義 する PostgreSQL および MySQL ターゲットエンドポイントのオプション このオプションは 接続属 性を上書きします 0 (このオプションが接続属性を上書きしないことを示します) から 100,000 KB まで の値を指定できます BatchApplyEnabled 各トランザクションを個別に適用するか 変更をバッチでコミットするかを決 定します デフォルト値は false です BatchApplyEnabled パラメータは BatchApplyPreserveTransaction パラメータと併用されま す BatchApplyEnabled を true に設定すると BatchApplyPreserveTransaction パラメータ がトランザクションの整合性を確認します 206

213 タスク設定 BatchApplyPreserveTransaction を true に設定すると トランザクションの整合性が保持され バッチにはソースのトランザクション内のすべての変更が確実に含まれます BatchApplyPreserveTransaction を false に設定すると パフォーマンスを向上させるためにト ランザクションの整合性が一時的に失われることがあります BatchApplyPreserveTransaction パラメータは Oracle ターゲットエンドポイントにのみ適用さ れ BatchApplyEnabled パラメータが true に設定されている場合に限り 適切に機能します LOB 列がレプリケーションに含まれる場合 BatchApplyEnabled は [Limited-size LOB mode] でのみ 使用できます ParallelLoadThreads 各テーブルをターゲットデータベースにロードするために AWS DMS が使 用するスレッドの数を指定します MySQL ターゲットの最大値は 16 で DynamoDB ターゲットの最 大数は 32 です 最大制限は リクエストして増やすことができます ParallelLoadBufferSize 並列ロードスレッドからターゲットへのデータのロードに使用さ れるバッファの最大レコード保存数を指定します デフォルト値は 50 です 最大値は 1000 で す このフィールドは 現在 DynamoDB がターゲットの場合にのみ有効です このパラメータは ParallelLoadThreads と組み合わせて使用する必要があり ParallelLoadThreads >1 の場合のみ有効 です 全ロードタスク設定 全ロード設定には 以下のものが含まれます 全ロードセットアップ時にターゲットのロードを処理する方法を指定するに は TargetTablePrepMode オプションに次のいずれかの値を指定します DO_NOTHING 既存のターゲットテーブルのデータとメタデータには影響を与えません DROP_AND_CREATE 既存のテーブルが削除され 新しいテーブルがその場所に作成されます TRUNCATE_BEFORE_LOAD テーブルメタデータに影響を与えずにデータが切り捨てられます 全ロードが完了するまでプライマリキーや一意のインデックスの作成を遅らせるに は CreatePkAfterFullLoad オプションを設定します このオプションが選択されると 完了していない全ロードタスクを再開することはできません 全ロードタスクと CDC が有効なタスクの場合 次の Stop task after full load completes オ プションを設定できます StopTaskCachedChangesApplied 全ロードが完了してキャッシュされた変更が適用された後に タスクを停止するには このオプションを true に設定します StopTaskCachedChangesNotApplied キャッシュされた変更が適用される前にタスクを停止す るには このオプションを true に設定します MaxFullLoadSubTasks 並行してロードするテーブルの最大数を指定するには このオプションで設 定します デフォルトは 8 最大値は 50 です タスクの開始時にトランザクションが開いている場合 全ロードオペレーションを開 始する前にトランザクションが閉じるのを AWS DMS が待機する秒数を指定するに は TransactionConsistencyTimeout オプションで設定します デフォルト値は 600 (10 分) で す AWS DMS は 開いているトランザクションがある場合でも タイムアウト値に到達すると全ロー ドを開始します 全ロードのみのタスクは 10 分間待機せず 即座に開始されます まとめて転送可能なイベントの最大数を指定するには CommitRate オプションを設定します ログ記録タスク設定 ロギングタスク設定は JSON ファイルに書き込まれます それらの設定で ログに記録されるコンポーネ ントのアクティビティと ログに書き込まれる情報の量を指定できます ロギング機能は 移行プロセス 中に Amazon CloudWatch を使用して情報を記録します 207

214 タスク設定 Amazon CloudWatch ロギングを有効にする方法はいくつかあります 移行タスクを作成するときに AWS マネジメントコンソール マネジメントコンソールで EnableLogging オプションを選択するか AWS DMS API を使用してタスクを作成するときに EnableLogging オプションを true に設定できます さ らに タスク設定のロギングセクションの JSON で "EnableLogging": true を指定することもできま す タスクログを削除するには タスク設定のロギングセクションの JSON で "DeleteTaskLogs": true を指定することもできます 以下のコンポーネントアクティビティにロギングを指定できます SOURCE_UNLOAD データがソースデータベースからアンロードされます SOURCE_CAPTURE データがソースデータベースからキャプチャされます TARGET_LOAD データがターゲットデータベースにロードされます TARGET_APPLY データおよびデータ定義言語 (DDL) ステートメントがターゲットデータベースに適 用されます TASK_MANAGER タスクマネージャーによってイベントがトリガーされます コンポーネントアクティビティを指定した後で 記録される情報の量を指定できます 次のリストは 低 い情報レベルから高い情報レベルの順序になっています 高いレベルには 必ず低いレベルの情報が含ま れています 指定できる重要度の値は以下のとおりです LOGGER_SEVERITY_ERROR エラーメッセージがログに書き込まれます LOGGER_SEVERITY_WARNING 警告とエラーメッセージがログに書き込まれます LOGGER_SEVERITY_INFO 情報メッセージ 警告 エラーメッセージがログに書き込まれます LOGGER_SEVERITY_DEFAULT 情報メッセージ 警告 エラーメッセージがログに書き込まれま す LOGGER_SEVERITY_DEBUG デバッグメッセージ 情報メッセージ 警告 エラーメッセージがロ グに書き込まれます LOGGER_SEVERITY_DETAILED_DEBUG すべての情報がログに書き込まれます たとえば 次の JSON セクションにあるのは すべてのコンポーネントアクティビティをログに記録する ためのタスク設定です "Logging": "EnableLogging": true, "LogComponents": [ "Id": "SOURCE_UNLOAD", "Severity": "LOGGER_SEVERITY_DEFAULT", "Id": "SOURCE_CAPTURE", "Severity": "LOGGER_SEVERITY_DEFAULT", "Id": "TARGET_LOAD", "Severity": "LOGGER_SEVERITY_DEFAULT", "Id": "TARGET_APPLY", "Severity": "LOGGER_SEVERITY_INFO", "Id": "TASK_MANAGER", "Severity": "LOGGER_SEVERITY_DEBUG" ], 208

215 タスク設定 テーブルの並列ロード AWS DMS は全ロードタスクを論理的にサブタスクに分割し 複数のスレッドを並列で使用してテーブ ルをロードします この並列処理を使用して複数のスレッドロードテーブルとパーティション分割された テーブルを作成してから テーブルをターゲットエンドポイントに移行できます テーブルは プライマ リキー値で分割でき 一部のデータベースエンジンでは パーティションまたはサブパーティションで分 割できます 並列ロードを使用するには parallel-load オプションで型 table-settings のルールを作成しま す table-settings ルール内では 並列でロードする 1 つ以上のテーブルに選択条件を指定します 選択条件を指定するには parallel-load の type 要素を次のいずれかに設定します partitions-auto subpartitions-auto none 次の例では 並列でテーブルパーティションをロードする table-settings ルールを作成する方法を示 しています "rules": [ "rule-type": "table-settings", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "table1", "parallel-load": "type": "partitions-auto" ] 制御テーブルタスク設定 制御テーブルは AWS DMS タスクに関する情報に加えて 現在および今後の移行タスクの両方を計画お よび管理するのに使用できる有用な統計情報を提供します これらのタスク設定は JSON ファイルで適用 するか AWS DMS コンソールで [Create task (タスクの作成)] ページの [詳細設定] リンクを使用して適用 できます 常に作成される例外適用 (dmslogs.awsdms_apply_exceptions) テーブルに加えて 以下のよう な追加テーブルの作成を選択できます [レプリケーションステータス (dmslogs.awsdms_status)] このテーブルは 現在のタスクに関する詳 細を提供します これには タスクステータス タスクにより消費されるメモリの量 まだターゲット に適用されていない変更の数が含まれます また このテーブルは AWS DMS が現在読み取っている ソースデータベース内の位置を示し タスクが全ロードか変更データキャプチャ (CDC) かを示します 停止済みテーブル (dmslogs.awsdms_suspended_tables) このテーブルは 停止済みテーブルのリスト と 停止された理由を示します [レプリケーション履歴 (dmslogs.awsdms_history)] このテーブルは レプリケーション履歴に関する 情報を提供します この情報には タスク中に処理されたレコードの数とボリューム CDC タスク終了 時のレイテンシー およびその他の統計情報などが含まれています 例外適用 (dmslogs.awsdms_apply_exceptions) テーブルには 以下のパラメータが含まれます 209

216 タスク設定 列 タイプ 説明 TASK_NAME nvchar AWS DMS タスクの名前 TABLE_OWNER nvchar テーブル所有者 TABLE_NAME nvchar テーブルの名前 ERROR_TIME timestamp 時間例外 (エラー) が発生しました STATEMENT nvchar エラーが発生したときに実行された ステートメント ERROR nvchar エラーの名前と説明 レプリケーション履歴 (dmslogs.awsdms_history) テーブルには 以下のパラメータが含まれます 列 タイプ 説明 SERVER_NAME nvchar レプリケーションタスクを実行して いるマシンの名前 TASK_NAME nvchar AWS DMS タスクの名前 TIMESLOT_TYPE varchar 次のいずれかの値になります FULL LOAD CHANGE PROCESSING (CDC) タスクが全ロードと CDC の両方を実 行している場合 2 つの履歴レコー ドがタイムスロットに書き込まれま す TIMESLOT timestamp タイムスロットのタイムスタンプ終 了 TIMESLOT_DURATION int タイムスロットの期間 TIMESLOT_LATENCY int タイムスロットの終了時のでター ゲットレイテンシー この値は CDC タイムスロットにのみ適用されま す RECORDS int タイムスロット中に処理されるレ コード数 TIMESLOT_VOLUME int 処理されるデータ量を MB で 表示 レプリケーションステータス (dmslogs.awsdms_status) テーブルには タスクの現在のステータスとター ゲットのデータベースが含まれます これには 以下の設定があります 210

217 タスク設定 列 タイプ 説明 SERVER_NAME nvchar レプリケーションタスクを実行して いるマシンの名前 TASK_NAME nvchar AWS DMS タスクの名前 TASK_STATUS varchar 次のいずれかの値になります FULL LOAD CHANGE PROCESSING (CDC) 全ロードされているテーブルが少な くとも 1 つある限り タスクのス テータスを FULL LOAD と設定しま す CDC が有効化されている場合 すべてのテーブルがロードされた 後 タスクステータスは CHANGE PROCESSING に変更します STATUS_TIME timestamp タスクの状態のタイムスタンプ PENDING_CHANGES int ターゲットに適用されなかった変更 レコード数 DISK_SWAP_SIZE int 古い またはオフロードされたトラ ンザクションにより使用されるディ スク領域の量 TASK_MEMORY int 使用されている現在のメモリを MB で表示 SOURCE_CURRENT varchar AWS DMS が現在読み取っている ソースデータベースの位置 timestamp AWS DMS が現在読み取っている ソースデータベースのタイムスタン プ varchar 最も以前に起動された完了していな いトランザクションの位置 この値 は すべての変更を失わずに返すこ とができる最も新しい位置を示しま す timestamp 最も以前に起動された完了していな いトランザクションのタイムスタン プ この値は すべての変更を失わ ずに返すことができる最も新しいタ イムスタンプを示します timestamp 最新の完了したトランザクションの タイムスタンプ 一括適用のプロセ スでは この値はバッチ内の最新ト ランザクション完了のタイムスタン プの値を示します _POSITION SOURCE_CURRENT _TIMESTAMP SOURCE_TAIL _POSITION SOURCE_TAIL _TIMESTAMP SOURCE_TIMESTAMP _APPLIED 211

218 タスク設定 追加の制御テーブル設定には 以下のものが含まれます ControlSchema AWS DMS ターゲット制御テーブルのデータベーススキーマ名を指定するには こ のオプションを使用します このフィールドに情報を入力しない場合 テーブルはデータベースのデ フォルトの場所にコピーされます HistoryTimeslotInMinutes レプリケーション履歴テーブルにおける各タイムスロットの長さを指 定するには このオプションを使用します デフォルトは 5 分です ストリームバッファタスク設定 AWS CLI を使用して 以下のようなストリームバッファを設定できます StreamBufferCount 移行タスクのデータストリームバッファの数を指定するには このオプション を指定します デフォルトストリームバッファの数は 3 です この設定の値を大きくすると データ抽 出速度が上昇する可能性があります ただし このパフォーマンス向上は レプリケーションサーバー のソースシステムやインスタンスクラスなど 移行環境に大きく依存します ほとんどの場合はデフォ ルトで十分です StreamBufferSizeInMB 各データストリームバッファの最大サイズを指定するには このオプ ションを使用します デフォルトサイズは 8 MB です 非常に大きい LOB を使用する場合 このオプ ションの値を大きくする必要がある場合があります また ストリームバッファサイズが不十分であ ることを示すメッセージがログファイルに記録されている場合も この値を大きくする必要がある可 能性があります このオプションのサイズを計算するときは [Max LOB size (or LOB chunk size)]*[number of LOB columns]*[number of stream buffers]*[number of tables loading in parallel per task(maxfullloadsubtasks)]*3 式を使用できます CtrlStreamBufferSizeInMB 制御ストリームバッファのサイズを設定するには このオプションを 使用します 値はメガバイト単位で 1 8 が使用できます デフォルト値は 5 です かなり多くのテー ブル (数万のテーブルなど) を使用している場合 状況によってはこの値を大きくする必要があります 変更処理のチューニング設定 以下の設定により AWS DMS が変更データキャプチャ (CDC) 中にターゲットテーブルの変更 を処理する方法が決まります これらの設定のいくつかは ターゲットメタデータパラメーター BatchApplyEnabled の値によって異なります BatchApplyEnabled パラメーターの詳細について は ターゲットメタデータのタスク設定 (p. 206) を参照してください 変更処理のチューニング設定には 以下のものが含まれます 以下の設定は ターゲットメタデータパラメータ BatchApplyEnabled を true に設定している場合に のみ適用されます BatchApplyPreserveTransaction true に設定すると トランザクションの整合性が保持され バッチにはソースからのトランザクション内のすべての変更が含まれます デフォルト値は true で す この設定は Oracle ターゲットエンドポイントにのみ適用されます false に設定すると パフォーマンスを向上させるためにトランザクションの整合性が一時的に失われ ることがあります ソースからのトランザクション内のすべての変更が 1 バッチでターゲットに適用さ れるとは限りません BatchApplyTimeoutMin バッチ変更の各適用間で AWS DMS が待機する最短時間 (秒) を設定しま す デフォルト値は 1 です BatchApplyTimeoutMax バッチ変更の各適用間でタイムアウトになるまでに AWS DMS が待機する 最長時間 (秒) を設定します デフォルト値は 30 です BatchApplyMemoryLimit 最適化バッチ適用モードでの前処理に使用されるメモリの最大量 (MB) を 設定します デフォルト値は 500 です BatchSplitSize 1 つのバッチに適用される変更の最大数を設定します デフォルト値 0 は 適用さ れる制限がないことを意味します 212

219 タスク設定 以下の設定は ターゲットメタデータパラメータ BatchApplyEnabled を false に設定している場合に のみ適用されます MinTransactionSize 各トランザクションに含める変更の最小数を設定します デフォルト値は 1000 です CommitTimeout AWS DMS がタイムアウトを宣言するまでにトランザクションをバッチで収集する 最長時間 (秒) を設定します デフォルト値は 1 です HandleSourceTableAltered ソーステーブルが変更されたときにターゲットテーブルを変更するに は このオプションを true に設定します AWS DMS は トランザクションがソース/ターゲットに完全にコミットされるまで トランザクション データをメモリに保持しようとします ただし 割り当てたメモリより大きいトランザクションや 指定 した制限時間内にコミットされないトランザクションは ディスクに書き込まれます 以下の設定は 変更処理のモードに関係なく 変更処理のチューニングに適用されます MemoryLimitTotal すべてのトランザクションがディスクに書き込まれるまでにメモリ内で占有で きる最大サイズ (MB) を設定します デフォルト値は 1024 です MemoryKeepTime 各トランザクションがディスクに書き込まれるまでにメモリ内で保持できる最長時 間 (秒) を設定します この期間は AWS DMS がトランザクションのキャプチャを開始した時間から計 算されます デフォルト値は 60 です StatementCacheSize ターゲットに変更を適用するときに 後で実行するためにサーバーに保存す るプリペアドステートメントの最大数を設定します デフォルト値は 50 です 最大の値は 200 です データ検証タスクの設定 データがソースからターゲットに正確に移行されたことを確認できます タスクに対してこれを有効にす ると AWS DMS は テーブルに対して全ロードが実行された後で ソースデータとターゲットデータの 比較をすぐに開始します データ検証の詳細については AWS DMS タスクの検証 (p. 253) を参照し てください データの検証設定には 以下のものが含まれます データ検証を有効にするには EnableValidation 設定を true に設定します 検証中に AWS DMS が使用する実行スレッドの数を調整するには ThreadCount の値を設定しま す ThreadCount のデフォルト値は 5 です ThreadCount をより高い値に設定すると AWS DMS はより高速に検証を完了できます ただし この場合 AWS DMS はより多くの同時クエリを実行し ソースとターゲットでより多くのリソースを消費します たとえば 以下の JSON ではデータ検証が有効になります "ValidationSettings": "EnableValidation": true, "ThreadCount": 5 Oracle エンドポイントの場合 AWS DMS は DBMS_CRYPTO を使用して BLOB を検証します Oracle エンドポイントで BLOB を使用する場合は Oracle エンドポイントにアクセスするために使用されるユー ザーアカウントに dbms_crypto での実行権限を付与する必要があります これを行うには 以下のス テートメントを実行します grant execute on sys.dbms_crypto to <dms_endpoint_user>; 213

220 タスク設定 変更処理の DDL 処理のタスク設定 以下の設定により AWS DMS が変更データキャプチャ (CDC) 中にターゲットテーブルのデータ定義言語 (DDL) の変更を処理する方法が決まります 変更処理の DDL 処理のタスク設定には 以下のものが含まれ ています HandleSourceTableDropped ソーステーブルが削除されたときにターゲットテーブルを削除する には このオプションを true に設定します HandleSourceTableTruncated ソーステーブルが切り捨てられたときにターゲットテーブルを切 り捨てるには このオプションを true に設定します HandleSourceTableAltered ソーステーブルが変更されたときにターゲットテーブルを変更するに は このオプションを true に設定します エラー処理タスクの設定 以下の設定を使用して 変更データキャプチャ (CDC) 中にレプリケーションタスクのエラー処理動作を設 定できます DataErrorPolicy レコードレベルでデータ処理に関連するエラーが発生した場合に AWS DMS が 実行するアクションを決定します データ処理エラーの例には 変換エラー 変換時のエラー および 不良データが含まれます デフォルト: LOG_ERROR IGNORE_RECORD タスクは続行され 該当するデータのレコードは無視されま す DataErrorEscalationCount プロパティのエラーカウンターは増分されます したがって テーブルにエラー数の制限を設定している場合 このエラーはその制限に向かってカウントされま す LOG_ERROR タスクは続行され エラーはタスクログに書き込まれます SUSPEND_TABLE タスクは続行されますが エラーレコードのあるテーブルのデータはエラー状態 になり データはレプリケートされません STOP_TASK タスクは停止され 手動での介入が必要になります DataTruncationErrorPolicy データが切り捨てられたときに AWS DMS が実行するアクションを 決定します デフォルト: LOG_ERROR IGNORE_RECORD タスクは続行され 該当するデータのレコードは無視されま す DataErrorEscalationCount プロパティのエラーカウンターは増分されます したがって テーブルにエラー数の制限を設定している場合 このエラーはその制限に向かってカウントされま す LOG_ERROR タスクは続行され エラーはタスクログに書き込まれます SUSPEND_TABLE タスクは続行されますが エラーレコードのあるテーブルのデータはエラー状態 になり データはレプリケートされません STOP_TASK タスクは停止され 手動での介入が必要になります DataErrorEscalationPolicy エラーが最大数に達したときに AWS DMS が実行するアクションを 決定します エラーの最大数は DataErrorsEscalationCount パラメータで設定されます デフォル ト: SUSPEND_TABLE SUSPEND_TABLE タスクは続行されますが エラーレコードのあるテーブルのデータはエラー状態 になり データはレプリケートされません STOP_TASK タスクは停止され 手動での介入が必要になります DataErrorEscalationCount 特定のレコードで データに許可されるエラーの最大数を設定しま す この数に到達すると エラーレコードがあるテーブルのデータは DataErrorEscalationCount で設定されているポリシーに従って処理されます デフォルトは 0 です TableErrorPolicy 特定のテーブルのデータまたはメタデータの処理中にエラーが発生した場合 に AWS DMS が実行するアクションを決定します このエラーは一般のテーブルデータにのみ適用さ れ 特定のレコードに関連するエラーではありません デフォルト: SUSPEND_TABLE 214

221 タスク設定 SUSPEND_TABLE タスクは続行されますが エラーレコードのあるテーブルのデータはエラー状態 になり データはレプリケートされません STOP_TASK タスクは停止され 手動での介入が必要になります TableErrorEscalationPolicy エラーが最大数に達したときに AWS DMS が実行するアクション を決定します エラーの最大数は TableErrorEscalationCount パラメータで設定されます デフォ ルトで 唯一のユーザー設定は STOP_TASK です この設定では タスクが停止し手動での介入が必要 になります TableErrorEscalationCount 特定のテーブルで 一般データまたはメタデータに許可されるエ ラーの最大数 この数に到達すると このテーブルのデータは TableErrorEscalationPolicy で 設定されたポリシーに従って処理されます デフォルトは 0 です RecoverableErrorCount 環境エラーが発生したときに タスクの再開を試みる最大回数 システ ムが再起動を試みる回数が指定の回数に達すると タスクが停止し 手動での介入が必要になります デフォルト値は -1 で 無限にタスクの再起動を試みるよう AWS DMS に指示します タスクの再開を 試行しない場合には この値を 0 に設定します 致命的なエラーが発生した場合 AWS DMS はタスク の再起動を 6 回試みた後で試行を中止します RecoverableErrorInterval タスクの再開を試みてから次に再開を試みるまで AWS DMS が待機 する時間 (秒) デフォルトは 5 です RecoverableErrorThrottling 有効にすると 再開を試みるたびに 次の試行との間隔が長く なっていきます デフォルト: true RecoverableErrorThrottlingMax RecoverableErrorThrottling が有効になっている場合 に タスクの再開を試みてから次に再開を試みるまで AWS DMS が待機する最大時間数 (秒) デフォル トは 1800 です ApplyErrorDeletePolicy DELETE オペレーションとの競合がある場合に AWS DMS が実行する アクションを決定します デフォルト: IGNORE_RECORD IGNORE_RECORD タスクは続行され 該当するデータのレコードは無視されま す ApplyErrorEscalationCount プロパティのエラーカウンターは増分されます したがって テーブルにエラー数の制限を設定している場合 このエラーはその制限に向かってカウントされま す LOG_ERROR タスクは続行され エラーはタスクログに書き込まれます SUSPEND_TABLE タスクは続行されますが エラーレコードのあるテーブルのデータはエラー状態 になり データはレプリケートされません STOP_TASK タスクは停止され 手動での介入が必要になります ApplyErrorInsertPolicy INSERT オペレーションとの競合がある場合に AWS DMS が実行する アクションを決定します デフォルト: LOG_ERROR IGNORE_RECORD タスクは続行され 該当するデータのレコードは無視されま す ApplyErrorEscalationCount プロパティのエラーカウンターは増分されます したがって テーブルにエラー数の制限を設定している場合 このエラーはその制限に向かってカウントされま す LOG_ERROR タスクは続行され エラーはタスクログに書き込まれます SUSPEND_TABLE タスクは続行されますが エラーレコードのあるテーブルのデータはエラー状態 になり データはレプリケートされません STOP_TASK タスクは停止され 手動での介入が必要になります INSERT_RECORD 挿入されたソースレコードと同じプライマリキーを含む既存のターゲットレコー ドがある場合 ターゲットレコードは更新されます ApplyErrorUpdatePolicy UPDATE オペレーションとの競合がある場合に AWS DMS が実行する アクションを決定します デフォルト: LOG_ERROR IGNORE_RECORD タスクは続行され 該当するデータのレコードは無視されま す ApplyErrorEscalationCount プロパティのエラーカウンターは増分されます したがって テーブルにエラー数の制限を設定している場合 このエラーはその制限に向かってカウントされま す LOG_ERROR タスクは続行され エラーはタスクログに書き込まれます 215

222 タスク設定 SUSPEND_TABLE タスクは続行されますが エラーレコードのあるテーブルのデータはエラー状態 になり データはレプリケートされません STOP_TASK タスクは停止され 手動での介入が必要になります UPDATE_RECORD ターゲットレコードがない場合 欠落しているターゲットレコードがターゲット テーブルに挿入されます このオプションを選択するには Oracle がソースデータベースの場合 す べてのソーステーブルの列に対し 完全なサプリメンタルロギングが有効である必要があります ApplyErrorEscalationPolicy エラーが最大数に達したときに AWS DMS が実行するアクション を決定します エラーの最大数は ApplyErrorsEscalationCount パラメータで設定されます LOG_ERROR タスクは続行され エラーはタスクログに書き込まれます SUSPEND_TABLE タスクは続行されますが エラーレコードのあるテーブルのデータはエラー状態 になり データはレプリケートされません STOP_TASK タスクは停止され 手動での介入が必要になります ApplyErrorEscalationCount 変更プロセスオペレーションの実行中に特定のテーブルに 許可される APPLY 競合の最大数を設定します この数に到達すると このテーブルのデータ は ApplyErrorEscalationPolicy パラメーターで設定されたポリシーに従って処理されます デ フォルトは 0 です ApplyErrorFailOnTruncationDdl これを true に設定すると CDC 中に追跡されたいずれかの テーブルで切り捨てが実行された場合に タスクは失敗します エラーメッセージは 切り捨て DDL が検出されました のようになります デフォルト: false この方法は DDL テーブルの切り捨てをレプリケートしない PostgreSQL またはその他のソースエン ドポイントでは機能しません FailOnNoTablesCaptured これを true に設定すると タスクに対して定義された変換ルールによ りタスクの開始時にテーブルが見つからなかった場合 タスクは失敗します デフォルト: false FailOnTransactionConsistencyBreached このオプションは CDC でソースとして Oracle を使 用するタスクに適用されます これを true に設定すると トランザクションが指定されたタイムアウ トよりも長い時間開かれていて 削除できる場合 タスクは失敗します CDC タスクが Oracle で開始されると AWS DMS は最も古い 開いているトランザクションが終了す るのを制限された時間待ってから CDC を起動します タイムアウトに達するまで最も古い 開いて いるトランザクションが終了しない場合 通常 そのトランザクションを無視して CDC が開始されま す この設定が true に設定されている場合 タスクは失敗します FullLoadIgnoreConflicts これを false に設定すると AWS DMS では キャッシュされたイベ ントを適用するときに 影響を受ける行がゼロ および 重複 エラーは無視されます true に設 定した場合 AWS DMS はすべてのエラーを無視されずに報告します デフォルト: false タスク設定の保存 別のタスクで設定を再利用する場合 タスクの設定を JSON ファイルして保存することができます たとえば 以下の JSON ファイルにはタスクに保存された設定が含まれています "TargetMetadata": "TargetSchema": "", "SupportLobs": true, "FullLobMode": false, "LobChunkSize": 64, "LimitedSizeLobMode": true, "LobMaxSize": 32, "BatchApplyEnabled": true, "FullLoadSettings": "TargetTablePrepMode": "DO_NOTHING", 216

223 タスク設定 "CreatePkAfterFullLoad": false, "StopTaskCachedChangesApplied": false, "StopTaskCachedChangesNotApplied": false, "MaxFullLoadSubTasks": 8, "TransactionConsistencyTimeout": 600, "CommitRate": 10000, "Logging": "EnableLogging": false, "ControlTablesSettings": "ControlSchema":"", "HistoryTimeslotInMinutes":5, "HistoryTableEnabled": false, "SuspendedTablesTableEnabled": false, "StatusTableEnabled": false, "StreamBufferSettings": "StreamBufferCount": 3, "StreamBufferSizeInMB": 8, "ChangeProcessingTuning": "BatchApplyPreserveTransaction": true, "BatchApplyTimeoutMin": 1, "BatchApplyTimeoutMax": 30, "BatchApplyMemoryLimit": 500, "BatchSplitSize": 0, "MinTransactionSize": 1000, "CommitTimeout": 1, "MemoryLimitTotal": 1024, "MemoryKeepTime": 60, "StatementCacheSize": 50, "ChangeProcessingDdlHandlingPolicy": "HandleSourceTableDropped": true, "HandleSourceTableTruncated": true, "HandleSourceTableAltered": true, "ErrorBehavior": "DataErrorPolicy": "LOG_ERROR", "DataTruncationErrorPolicy":"LOG_ERROR", "DataErrorEscalationPolicy":"SUSPEND_TABLE", "DataErrorEscalationCount": 50, "TableErrorPolicy":"SUSPEND_TABLE", "TableErrorEscalationPolicy":"STOP_TASK", "TableErrorEscalationCount": 50, "RecoverableErrorCount": 0, "RecoverableErrorInterval": 5, "RecoverableErrorThrottling": true, "RecoverableErrorThrottlingMax": 1800, "ApplyErrorDeletePolicy":"IGNORE_RECORD", "ApplyErrorInsertPolicy":"LOG_ERROR", "ApplyErrorUpdatePolicy":"LOG_ERROR", "ApplyErrorEscalationPolicy":"LOG_ERROR", "ApplyErrorEscalationCount": 0, "FullLoadIgnoreConflicts": true 217

224 LOB サポートの設定 AWS DMS タスクのソースデータベースの LOB サ ポートの設定 ラージバイナリオブジェクト (LOB) をシステム間で移行することは難しい場合があります AWS DMS に は LOB の列のチューニングに役立つ多くのオプションが用意されています どのデータ型がいつ AWS DMS によって LOB と見なされるかについては AWS DMS のドキュメントを参照してください データベース間でデータを移行するとき 特に異機種間で移行するときは LOB の保存方法の見直しが必 要になる場合があります その場合 LOB データを移行する必要はありません LOB を含める場合は 他の LOB 設定を決定できます LOB モードにより LOB の処理方法が決定されます [完全 LOB モード] [完全 LOB モード] では サイズにかかわらず AWS DMS によってソースから ターゲットにすべての LOB が移行されます この設定では AWS DMS の最大許容 LOB サイズに関 する情報は不要です したがって LOB は一度に 1 つずつ移行されます Full LOB mode は非常に低 速になることがあります [制限付き LOB モード] [制限付き LOB モード] では AWS DMS の最大許容 LOB サイズを設定しま す これにより AWS DMS によってメモリが事前に割り当てられ LOB データを一括でロードでき るようになります 最大 LOB サイズを超える LOB は切り捨てられ 警告がログファイルに発行され ます [Limited LOB mode (制限付き LOB モード)] では [Full LOB mode (完全 LOB モード)] よりも大 幅にパフォーマンスが向上します 可能な限り Limited LOB mode を使用することをお勧めします Note Oracle では LOB は可能な限り VARCHAR データ型として扱われます この方法では AWS DMS によって LOB がデータベースから一括でフェッチされるため 他の方法よりも大幅に高 速になります Oracle での VARCHAR の最大サイズは 64 K です そのため Oracle がソース データベースである場合は 最大許容 LOB サイズを 64 K 未満に設定するのが最適です Limited LOB mode (制限付き LOB モード) で実行されるようにタスクを設定している場合 [Max LOB size (K) (最大 LOB サイズ (K))] オプションによって AWS DMS の最大許容 LOB サイズが決まります この値よりも大きい LOB はこの値まで切り捨てられます Full LOB mode (完全 LOB モード) を使用するようにタスクを設定している場合 AWS DMS によって LOB は 1 つずつ取得されます [LOB chunk size (K)] オプションにより 各ピースのサイズが決定され ます このオプションを設定するときは ネットワーク設定の最大許容パケットサイズに特に注意して ください LOB チャンクサイズが最大許容パケットサイズを超えた場合は 切断エラーが表示されるこ とがあります 複数のタスクの作成 移行シナリオによっては 複数の移行タスクを作成する必要があります タスクは個別に動作し 同時に 実行できます 各タスクには 独自の初期ロード CDC およびログ読み取りプロセスがあります デー タ操作言語 (DML) を通じて関連付けられたテーブルは 同じタスクの一部である必要があります 移行のために複数のタスクを作成する理由として 以下の理由が挙げられます タスクのターゲットテーブルが異なるデータベースに存在している (分散していたり システムを複数 のシステムに分割している場合など) フィルタリングを使用して 大きいテーブルの移行を複数のタスクに分割したい 218

225 継続的なレプリケーション用のタスク Note タスクごとに独自の変更キャプチャおよびログ読み取りプロセスがあるため タスク間で変更は 調整されません したがって 複数のタスクを使用して移行を実行する場合は ソーストランザ クションが 1 つのタスク内に完全に含まれていることを確認してください AWS DMS を使用した継続的なレプリケーション用 のタスクの作成 ソースデータストアへの継続的な変更をキャプチャする AWS DMS タスクを作成できます データの移行 中にこのキャプチャを実行できます サポートされているターゲットデータストアへの初回の移行が完了 した後で 継続的な変更をキャプチャするタスクを作成することもできます このプロセスは継続的なレ プリケーションまたは変更データキャプチャ (CDC) と呼ばれます AWS DMS では このプロセスを使用 してソースデータストアの継続的な変更をレプリケートします このプロセスでは データベースエンジ ンのネイティブ API を使用してデータベースログへの変更を収集します ソースエンジンごとに この変更ストリームを指定されたユーザーアカウントに開示するための固有の設 定要件があります ほとんどのエンジンでは キャプチャプロセスでデータ損失を発生させずに意味のあ る方法で変更データを使用するために 追加の設定が必要です たとえば Oracle ではサプリメンタルロ ギングの追加が必要であり MySQL では行レベルのバイナリログ (bin ログ) が必要です ソースデータベースから継続的な変更を読み取るために AWS DMS はエンジン固有の API アクションを 使用してソースエンジンのトランザクションログから変更を読み取ります これを AWS DMS で実行する 例を以下に示します Oracle AWS DMS は Oracle LogMiner API または Binary Reader API (bfile API) を使用して 継続的な 変更を読み取ります AWS DMS は システム変更番号 (SCN) に基づいてオンラインまたはアーカイブ REDO ログから継続的な変更を読み取ります Microsoft SQL Server の場合 AWS DMS は MS-Replication または MS-CDC を使用して SQL Server のトランザクションログに情報を書き込みます 次に SQL Server の fn_dblog() 関数または fn_dump_dblog() 関数を使用して ログシーケンス番号 (LSN) に基づいてトランザクションログの変 更を読み取ります MySQL の場合 AWS DMS は 行ベースのバイナリログ (binlogs) から変更を読み取り この変更を ターゲットに移行します PostgreSQL の場合 AWS DMS はレプリケーションスロットを設定し test_decoding プラグイン を使用して ソースから変更を読み取り この変更をターゲットに移行します ソースとしての Amazon RDS の場合は CDC をセットアップするためのバックアップが有効になって いることを確認してください また 変更ログを十分な時間だけ (通常は 24 時間) 保持するようにソー スデータベースが設定されていることを確認してください 継続的なレプリケーションタスクには 2 つのタイプがあります 全ロード + CDC タスクでは まず既存のデータを移行し 次にソースデータベースへの変更に応じて ターゲットデータベースを更新します CDC のみ タスクでは ターゲットデータベースにデータが取り込まれた後の継続的な変更を移行しま す CDC 開始ポイントからのレプリケーションの実行 AWS DMS の継続的なレプリケーションタスク (変更データのキャプチャのみ) は 複数のポイントから開 始できます これには次のものが含まれます 219

226 CDC 開始ポイントから開始するレプリケーション カスタム CDC 開始時刻から AWS マネジメントコンソール または AWS CLI を使用して レプリケー ションを開始するタイムスタンプを AWS DMS に提供できます AWS DMS は このカスタム CDC 開始時刻から継続的なレプリケーションタスクを開始します AWS DMS は 提供されたタイムスタ ンプ (UTC) をネイティブ開始ポイント (SQL Server の LSN または Oracle の SCN など) に変換しま す AWS DMS は エンジン固有の方法を使用し ソースエンジンの変更ストリームに基づいて移行タ スクの正確な開始位置を決定します Note PostgreSQL をソースとする場合 カスタム CDC の開始時刻はサポートされません これ は PostgreSQL データベースエンジンには Oracle や SQL Server とは異なり タイムスタ ンプを LSN や SCN にマップする方法がないためです 取引金額 CDC ネイティブの開始ポイントから ソースエンジンのトランザクションログのネイティブ ポイントから開始することもできます 場合によっては タイムスタンプはトランザクションログで 複数のネイティブポイントを示すことができるため このアプローチのほうが適している場合がありま す AWS DMS では この機能を以下のソースエンドポイントでサポートしています SQL Server Oracle MySQL CDC ネイティブの開始ポイントの決定 CDC ネイティブポイントは たとえば 特定の時点からあるバルクデータダンプがターゲットに適用され ているとします この場合 ダンプが取得されるより前のポイントから継続的なレプリケーションのみの タスクのネイティブ開始ポイント始点を参照できます 以下の例では サポートされているソースエンジンから CDC ネイティブの開始ポイントを見つける方法 を示します SQL Server SQL Server では ログシーケンス番号 (LSN) は以下の 3 つのパートで構成されています 仮想ログファイル (VLF) シーケンス番号 ログブロックの開始オフセット スロット番号 LSN の例: : :0001 トランザクションログのバックアップ設定に基づいて SQL Server の移行タスクの開始ポイントを取 得するには SQL Server の fn_dblog() 関数または fn_dump_dblog() 関数を使用します SQL Server で CDC ネイティブの開始ポイントを使用するには 継続的なレプリケーションに参加し ているいずれかのテーブルでパブリケーションを作成します パブリケーションの作成の詳細につい ては 継続的なレプリケーション用の SQL Server パブリケーションの作成 (p. 103) を参照して ください CDC ネイティブ開始ポイントを使用せずに CDC を使用すると AWS DMS が自動的にパ ブリケーションを作成します Oracle システム変更番号 (SCN) は Oracle データベースで使用される論理的な内部タイムスタンプで す SCN は データベース内で発生するイベントを順序付けします これは トランザクションの ACID プロパティを満たすために必要です Oracle データベースでは ディスクに書き込まれたすべ ての変更の位置を SCN でマークするため 書き込み済みの変更には復旧アクションが適用されませ ん また Oracle では データセットで REDO が存在しないポイントをマークして復旧を停止でき るようにするためにも SCN を使用します Oracle SCNs の詳細については Oracle のドキュメン トを参照してください 220

227 CDC 開始ポイントから開始するレプリケーション Oracle データベース内の現在の SCN を取得するには 次のコマンドを実行します SELECT current_scn FROM V$DATABASE MySQL MySQL バージョン がリリースされるまで MySQL のログシーケンス番号 (LSN) は 4 バイトの 符号なし整数でした MySQL バージョン で REDO ログファイルのサイズ上限が 4 GB から 512 GB に引き上げられ LSN は 8 バイトの符号なし整数になりました この引き上げは サイズ情 報の保存に追加のバイトが必要になったことが理由です MySQL 以降で構築された LSN 値を使 用するアプリケーションでは LSN 値を保存し比較するために 32 ビット変数ではなく 64 ビット変数 を使用する必要があります MySQL の LSN の詳細については MySQL のドキュメントを参照して ください MySQL データベース内の現在の LSN を取得するには 以下のコマンドを実行します mysql> show master status; このクエリから binlog ファイルの名前 位置 およびその他いくつかの値が返されます CDC ネイティブの開始ポイントは binlogs ファイルの名前と位置の組み合わせです (例: mysql-binchangelog :373) この例で mysql-bin-changelog は binlogs ファイルの名 前 373 は AWS DMS で変更のキャプチャを開始する位置です チェックポイントを CDC の開始ポイントとして使用する 継続的なレプリケーションタスクでは変更を移行し AWS DMS では AWS DMS 固有のチェックポイント 情報を時々キャッシュします AWS DMS が作成するチェックポイントに含まれている情報に従って レ プリケーションエンジンは変更ストリームの復旧ポイントを確認します チェックポイントを使用して変 更のタイムラインをさかのぼり 失敗した移行タスクを復旧できます チェックポイントを使用して 別 のターゲットに向けて別の継続的なレプリケーションタスクを任意の時点から開始することもできます チェックポイント情報は 以下の 2 つの方法で取得できます API コマンド DescribeReplicationTasks を実行して結果を確認します 情報をタスク別にフィル タ処理し チェックポイントを検索できます タスクが停止状態または失敗状態のときに最新のチェッ クポイントを取得できます ターゲットインスタンスで awsdms_txn_state というメタデータテーブルを表示します テーブルに クエリを実行してチェックポイント情報を取得できます メタデータテーブルを作成するには タスク の作成時に TaskRecoveryTableEnabled パラメータを Yes に設定します この設定により AWS DMS はチェックポイント情報を継続的にターゲットメタデータテーブルに書き込みます タスクを削除 すると この情報は失われます 次に メタデータテーブル checkpoint:v1#34# /0f000e48#0#0#*#0#121 でのチェック ポイントの例を示します コミット時間ポイントまたはサーバー時間ポイントでのタスクの 停止 CDC ネイティブの開始ポイントの導入により AWS DMS では以下のポイントでタスクを停止することも できます ソースのコミット時間 レプリケーションインスタンスのサーバー時間 221

228 タスクの変更 必要に応じてタスクを変更し 停止する時刻を UTC で設定できます タスクは 設定したコミット時間ま たはサーバー時間に基づいて自動的に停止します さらに タスクの作成時に移行タスクを停止する時間 があらかじめわかっている場合は タスクの作成時に停止時間を設定できます タスクの変更 タスクの設定 テーブルのマッピング その他の設定を変更する必要がある場合 タスクを変更できま す DMS コンソールでタスクを選択し [Modify] を選択して タスクを変更できます AWS CLI や AWS DMS API コマンド ModifyReplicationTask を使用することもできます タスクの変更には いくつかの制限があります 具体的には次のとおりです タスクのソースまたはターゲットエンドポイントは変更できません タスクの移行タイプを変更することはできません 実行されたタスクを変更する場合 タスクのステータスは [Stopped] または [Failed] である必要があり ます タスク実行中のテーブルの再ロード タスクを実行中に ソースのデータを使用して移行先データベースのテーブルを再ロードできます タス ク実行中にエラーが発生した際 またはパーティション操作によるデータの変更が生じた際に テーブル の再ロードが必要になる場合があります タスクから最大で 10 までのテーブルを再ロードできます テーブルを再ロードするには 以下の条件を適用する必要があります タスクが実行中であることが必要です タスクの移行メソッドは 全ロードまたは CDC による全ロードであることが必要です テーブルは複製できません AWS DMS では 以前に読み込んだテーブル定義が保持されます 再ロードオペレーション中に再作 成されることはありません テーブルが再ロードされる前に ALTER TABLE ADD COLUMN DROP COLUMN などの DDL ステートメントを実行すると 再ロードオペレーションが失敗する可能性があり ます AWS マネジメントコンソール AWS DMS コンソールを使用してテーブルを再ロードするには 1. AWS マネジメントコンソール にサインインして AWS DMS を選択します AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合 AWS DMS にアクセスするには適切な アクセス許可が必要です 必要なアクセス権限の詳細については AWS DMS を使用するのに必要 な IAM アクセス許可 (p. 31) を参照してください 2. ナビゲーションペインから [Tasks] を選択します 3. 再ロードするテーブルを含む実行中のタスクを選択します 4. [テーブル統計] タブを選択します 222

229 AWS マネジメントコンソール 5. 再ロードするテーブルを選択します タスクがすでに実行されていない場合は テーブルを再ロード できません 6. [Drop and reload table data] を選択します AWS DMS によりテーブルの再ロードが準備されている場合 コンソールはテーブルの状態を [The table is being reloaded (テーブルの再ロード中)] に変更します 223

230 テーブルマッピング テーブルマッピングを使用して タスクの設定を指 定する テーブルマッピングは データソース ソーススキーマ データ そしてタスク実行中に必要なすべての 変換を指定するための複数のルールタイプを使用します テーブルマッピングを使用して データベース で移行する個々のテーブルや 移行に使用するスキーマを指定できます また フィルタを使用して レ プリケートする特定のテーブルの列からデータを指定できます 変換を使用して ターゲットデータベー スに書き込むデータを変更できます コンソールからのテーブルマッピングによりテーブル 選択および変換を指定する AWS マネジメントコンソール コンソールを使用して テーブルの選択 変換の指定などのテーブルマッ ピングを実施できます コンソールで [Where (場所)] セクションを使用してスキーマ テーブル およ びアクションを含めるか除外するかを指定できます [フィルタ] セクションを使用して レプリケーショ ンタスクに適用する テーブルの列の名前と条件を指定します これら 2 つのアクションを合わせて 選 択ルールを作成します 選択ルールを 1 つ以上指定した後に 変換をテーブルマッピングに含めることができます 変換を使用し て スキーマまたはテーブルの名前を変更したり スキーマまたはテーブルにプレフィックスやサフィッ クスを追加したり テーブルの列を削除したりできます 224

231 コンソールからのテーブルマッピングに よりテーブル選択および変換を指定する 以下の例は EntertainmentAgencySample というスキーマの Customers テーブルの選択ルー ルを設定する方法を示しています 選択ルールと変換は [Guided (ガイド)] タブで作成します このタブ は スキーマとテーブル情報があるソースエンドポイントを選択した場合のみ表示されます テーブルの選択を指定するには AWS コンソールを使用して 条件と変換でフィルタリングしま す 1. AWS マネジメントコンソール にサインインして AWS DMS を選択します AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合 AWS DMS にアクセスするには適切な アクセス許可が必要です 必要なアクセス権限の詳細については AWS DMS を使用するのに必要 な IAM アクセス許可 (p. 31) を参照してください 2. [ダッシュボード] ページで [タスク] を選択します 3. [タスクの作成] を選択します 4. [タスク名] [レプリケーションインスタンス] [ソースエンドポイント] [ターゲットエンドポイン ト] [移行タイプ] などのタスク情報を入力します [テーブルマッピング] セクションから [Guided (ガ イド)] を選択します 5. [テーブルマッピング] セクションで スキーマ名とテーブル名を選択します テーブル名を指定する とき % をワイルドカード値として使用できます フィルタを使用して 定義されたデータを含 める 除外するかなど 実行するアクションを指定します 225

232 コンソールからのテーブルマッピングに よりテーブル選択および変換を指定する 6. [Add column filter (列フィルタの追加)] および [条件の追加] リンクを使用して フィルタ情報を指定し ます a. まず [Add column filter (列フィルタの追加)] を選択して列と条件を指定します b. [追加] を選択してその他の条件を追加します 以下の例は 01 から 85 の間に AgencyIDs を含む Customers テーブルのフィルタを示していま す 226

233 コンソールからのテーブルマッピングに よりテーブル選択および変換を指定する 7. 希望の選択を作成したら [Add selection rule (選択ルールの追加)] を選択します 8. 選択ルールを 1 つ以上作成したら タスクに変換を追加できます [add transformation rule (変換ルー ルの追加)] を選択します 9. 変換を希望するターゲットを選択し 必要な追加情報を入力します 以下の例は Customer テーブ ルから AgencyStatus 列を削除する変換を示しています 227

234 コンソールからのテーブルマッピングに よりテーブル選択および変換を指定する 10. [Add transformation rule] を選択します 11. (オプション) [add selection rule (選択ルールの追加)] または [add transformation rule (変換ルールの追 加)] を選択して 他の選択ルールや変換ルールを追加します 完了したら [Create task] を選択しま す 228

235 JSON を使用するテーブルマッピングに よりテーブル選択および変換を指定する JSON を使用するテーブルマッピングによりテーブル 選択および変換を指定する JSON 形式でテーブルマッピングを作成できます AWS DMS マネジメントコンソールを使用して移行タ スクを作成する場合 JSON を直接テーブルマッピングボックスに入力できます CLI または API を使用 して移行を実行する場合 JSON ファイルを作成して移行中に適用するテーブルマッピングを指定できま す 使用するテーブルやスキーマを指定し スキーマおよびテーブル変換を実行することができま す selection ルールタイプと transformation ルールタイプを使用してテーブルマッピングルールを 作成します 選択ルールと選択アクション テーブルマッピングを使用すると 選択ルールと選択アクションを使用することで 使用するテーブルや スキーマを指定できます 選択ルールタイプを使用するテーブルマッピングルールの場合 以下の値を適 用できます パラメータ 使用できる値 説明 rule-type selection テーブルマッピングを指定するときは 少なくとも 1 つの選択ルールが必要で す rule-id 数値 ルールを識別する一意の数値 rule-name 英数字値 ルールを特定する一意な名前 rule-action include exclude ルールにより選択されるオブジェクトを 含めるか除外します 229

236 JSON を使用するテーブルマッピングに よりテーブル選択および変換を指定する パラメータ 使用できる値 説明 load-order 正の整数 最大の値は で す テーブルを読み込むための優先度を示し ます 値が大きいテーブルが最初に読み 込まれます Example スキーマ内のすべてのテーブルの移行 以下の例では ソース内の Test という名前のスキーマからすべてのテーブルをターゲットエンドポイン トに移行します "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "Test", "table-name": "%", "rule-action": "include" ] Example スキーマの一部のテーブルの移行 以下の例では ソース内の Test という名前のスキーマから 先頭が DMS のテーブルを除くすべてのテー ブルをターゲットエンドポイントに移行します "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "Test", "table-name": "%", "rule-action": "include", "rule-type": "selection", "rule-id": "2", "rule-name": "2", "object-locator": "schema-name": "Test", "table-name": "DMS%", "rule-action": "exclude" ] Example スキーマ内のすべてのテーブルの移行 以下の例では ソース内の Test という名前のスキーマからすべてのテーブルをターゲットエンドポイン トに移行します 230

237 JSON を使用するテーブルマッピングに よりテーブル選択および変換を指定する "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "Test", "table-name": "%", "rule-action": "include" ] Example 設定順でテーブルを移行 以下の例は 2 つのテーブルを移行します テーブル loadfirst (優先度 2) はテーブル loadsecond よ り前に移行されます "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "Test", "table-name": "loadfirst", "rule-action": "include", "load-order": "2", "rule-type": "selection", "rule-id": "2", "rule-name": "2", "object-locator": "schema-name": "Test", "table-name": "loadsecond", "rule-action": "include", "load-order": "1" ] 変換ルールおよび変換アクション 選択したスキーマまたはテーブルに適用する変換を指定するには 変換アクションを使用します 変換 ルールはオプションです 変換ルールタイプを使用するテーブルマッピングルールの場合 以下の値を適用できます パラメータ 使用できる値 説明 rule-type transformation table-settings 選択ルールにより指定されたオブジェク トにルールを適用する値 rule-id 数値 ルールを識別する一意の数値 231

238 JSON を使用するテーブルマッピングに よりテーブル選択および変換を指定する パラメータ 使用できる値 説明 rule-name 英数字値 ルールを特定する一意な名前 object-locator schema-name スキーマの名前 ルールが適用されるスキーマとテーブ ル table-name テーブルの名前 ワイル ドカードとして "%" (パーセント記号) を 使用できます rule-action rename remove-column convert-lowercase convertuppercase add-prefix removeprefix replace-prefix add-suffix removesuffix replace-suffix オブジェクトに適用する変換 すべて変 換ルールアクションでは 大文字と小文 字が区別されます rule-target schema table column 変換するオブジェクトのタイプ value ターゲットタイプの名前付けルールに 従った英数字値 入力が必要なアクションの新しい値 (rename など) old-value ターゲットタイプの名前付けルールに 従った英数字値 置き換えが必要なアクションの古い値 (replace-prefix など) parallel-load partitions-auto 読み込み中にテーブルを分割する方法を 決定する値 パーティションまたはサブ パーティションによってテーブルをセグ メント化できます subpartitions-auto none Example スキーマの名前変更 以下の例では スキーマの名前をソースでの Test からターゲットエンドポイントでの Test1 に変更しま す "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "Test", "table-name": "%", "rule-action": "include", "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "rule-action": "rename", "rule-target": "schema", "object-locator": "schema-name": "Test", "value": "Test1" 232

239 JSON を使用するテーブルマッピングに よりテーブル選択および変換を指定する ] Example テーブル名の変更 以下の例では テーブルの名前をソースでの Actor からターゲットエンドポイントでの Actor1 に変更 します "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "Test", "table-name": "%", "rule-action": "include", "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "rule-action": "rename", "rule-target": "table", "object-locator": "schema-name": "Test", "table-name": "Actor", "value": "Actor1" ] Example 列名の変更 以下の例では テーブル Actor の列の名前をソースでの first_name からターゲットエンドポイントで の fname に変更します "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "%", "rule-action": "include", "rule-type": "transformation", "rule-id": "4", "rule-name": "4", "rule-action": "rename", "rule-target": "column", "object-locator": "schema-name": "test", "table-name": "Actor", 233

240 JSON を使用するテーブルマッピングに よりテーブル選択および変換を指定する ] "column-name" : "first_name", "value": "fname" Example 列の削除 以下の例では ソース内の Actor という名前のテーブルを変換し 先頭文字が col のすべての列をター ゲットエンドポイントから削除します "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "%", "rule-action": "include", "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "rule-action": "remove-column", "rule-target": "column", "object-locator": "schema-name": "test", "table-name": "Actor", "column-name": "col%" ] Example 小文字への変換 以下の例では テーブルの名前をソースでの ACTOR からターゲットエンドポイントでの actor に変換し ます "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "%", "rule-action": "include", "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "rule-action": "convert-lowercase", "rule-target": "table", "object-locator": "schema-name": "test", "table-name": "ACTOR" ] 234

241 JSON を使用するテーブルマッピングに よりテーブル選択および変換を指定する Example 大文字への変換 以下の例では すべてのテーブルおよびすべてのスキーマ内のすべての列を ソースでの小文字からター ゲットエンドポイントでの大文字に変換します "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "%", "rule-action": "include", "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "rule-action": "convert-uppercase", "rule-target": "column", "object-locator": "schema-name": "%", "table-name": "%", "column-name": "%" ] Example プレフィックスの追加 以下の例では ソース内のすべてのテーブルを変換し ターゲットエンドポイントではそれらのテーブル にプレフィックス DMS_ を追加します "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "%", "rule-action": "include", "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "rule-action": "add-prefix", "rule-target": "table", "object-locator": "schema-name": "test", "table-name": "%", "value": "DMS_" ] 235

242 JSON を使用するテーブルマッピングに よりテーブル選択および変換を指定する Example プレフィックスの置き換え 以下の例では ソースでプレフィックス Pre_ を含むすべての列を変換し ターゲットエンドポイントで はプレフィックスを NewPre_ に置き換えます "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "%", "rule-action": "include", "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "rule-action": "replace-prefix", "rule-target": "column", "object-locator": "schema-name": "%", "table-name": "%", "column-name": "%", "value": "NewPre_", "old-value": "Pre_" ] Example サフィックスの削除 以下の例では ソース内のすべてのテーブルを変換し ターゲットエンドポイントではそれらのテーブル からサフィックス _DMS を削除します "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "%", "rule-action": "include", "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "rule-action": "remove-suffix", "rule-target": "table", "object-locator": "schema-name": "test", "table-name": "%", "value": "_DMS" 236

243 ソースフィルタの使用 ] Example 読み込みのためのテーブルのセグメント化 次の例では テーブルをより効率的にロードまたはアンロードするためにソース内でテーブルをセグメン ト化します "rules": [ "rule-type": "table-settings", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "table1", "parallel-load": "type": "partitions-auto" ] ソースフィルタの使用 ソースフィルタを使用すると ソースからターゲットに転送されるレコードの数とタイプを制限できま す たとえば 本社を拠点とする従業員だけがターゲットデータベースに移行されるように指定できま す フィルタは 選択ルールの一部です データの列にフィルタを適用します ソースフィルタは 以下の制約に従う必要があります 選択ルールには フィルタを設定しないことも 1 つ以上のフィルタを選択することもできます すべてのフィルタには 1 つ以上のフィルタ条件を設定できます 複数のフィルタを使用する場合 フィルタのリストはフィルタ間で AND 演算子を使用しているものと して結合されます 1 つのフィルタ内で複数のフィルタ条件を使用する場合 フィルタ条件のリストはフィルタ条件間で OR 演算子を使用しているものとして結合されます フィルタは rule-action = 'include' の場合のみ適用されます フィルタには 列名とフィルタ条件のリストが必要です フィルタ条件には フィルタ演算子と値が必 要です 列名 テーブル名 およびスキーマ名では大文字と小文字が区別されます 時刻と日付でフィルタリング インポートするデータを選択すると フィルタ条件の一部として日付または期間を指定できます AWS DMS は フィルタリングに日付形式 YYYY-MM-DD と時刻形式 YYYY-MM-DD HH:MM:SS を使用しま す AWS DMS 比較関数は SQLite のルールに従います SQLite のデータ型と日付変換については SQLite バージョン 3 のデータ型 を参照してください 以下の例は 日付をフィルタリングする方法を示しています Example 1 つの日付フィルタ 次のフィルタは empstartdate >= January 1, 2002 のすべての従業員をターゲットデータベース にレプリケートします 237

244 ソースフィルタの使用 "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "employee", "rule-action": "include", "filters": [ "filter-type": "source", "column-name": "empstartdate", "filter-conditions": [ "filter-operator": "gte", "value": " " ] ] ] JSON 形式のソースフィルタルールの作成 ソースフィルタは 列名 フィルタ条件 フィルタ演算子 フィルタ値を指定することで作成できます 次の表は ソースフィルタリングに使用されるパラメーターを示しています パラメータ 値 filter-type source column-name フィルタを適用するソース列の名前 名前は 大文字と小文字が区別さ れます filter-conditions filter-operator このパラメータは以下のいずれかになります ste 以下 gte 以上 eq 等しい between 2 つの値に等しい またはその間 value filter-operator パラメータの値 filter-operator が between の場合 2 つ の値 (1 つは start-value の値 もう 1 つは end-value の値) を指定しま す 以下の例では ソースフィルタを使用する一般的な方法をいくつか示します Example 1 つのフィルタ 以下のフィルタは empid >= 100 のすべての従業員をターゲットデータベースにレプリケートします "rules": [ 238

245 ソースフィルタの使用 "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "employee", "rule-action": "include", "filters": [ "filter-type": "source", "column-name": "empid", "filter-conditions": [ "filter-operator": "gte", "value": "100" ] ] ] Example 複数のフィルタ演算子 以下のフィルタは 複数のフィルタ演算子を 1 つのデータ列に適用します このフィルタは (empid <=10) または (empid is between 50 and 75) または (empid >= 100) のすべての従業員をター ゲットデータベースにレプリケートします "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "employee", "rule-action": "include", "filters": [ "filter-type": "source", "column-name": "empid", "filter-conditions": [ "filter-operator": "ste", "value": "10", "filter-operator": "between", "start-value": "50", "end-value": "75", "filter-operator": "gte", "value": "100" ] ] ] Example 複数のフィルタ 以下のフィルタは テーブル内の 2 つの列に複数のフィルタを適用します このフィルタは (empid <= 100) および (dept= tech) のすべての従業員をターゲットデータベースにレプリケートします 239

246 ソースフィルタの使用 "rules": [ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "test", "table-name": "employee", "rule-action": "include", "filters": [ "filter-type": "source", "column-name": "empid", "filter-conditions": [ "filter-operator": "ste", "value": "100" ], "filter-type": "source", "column-name": "dept", "filter-conditions": [ "filter-operator": "eq", "value": "tech" ] ] ] 240

247 タスクのステータス AWS DMS タスクのモニタリング タスクのステータスを確認し タスクの統制テーブルをモニタリングすることで タスクの進行状況を 監視できます 統制テーブルの詳細については 制御テーブルタスク設定 (p. 209) を参照してくださ い Amazon CloudWatch を使用して タスクの進行状況をモニタリングすることもできます AWS マネジメ ントコンソール AWS コマンドラインインターフェイス (CLI) または AWS DMS API を使用して タス クの進行状況 使用されているリソースとネットワーク接続をモニタリングできます 最後に テーブルの状態を表示することにより タスクのソーステーブルの状態をモニタリングできま す DMS コンソールの 最終更新 列は テーブルに対して AWS DMS が最後にテーブル統計レコードを更 新した時刻を示すのみであることに注意してください これはテーブルの最終更新時間を示すものではあ りません 詳細については 以下のトピックを参照してください トピック タスクのステータス (p. 241) タスク実行中のテーブルの状態 (p. 242) Amazon CloudWatch を使用したレプリケーションモニタリングタスク (p. 243) データ移行サービスメトリクス (p. 245) AWS DMS タスクログの管理 (p. 248) AWS CloudTrail を使用した AWS DMS API コールのログ作成 (p. 249) タスクのステータス タスクのステータスはタスクの状態を表します 以下の表では タスクがなる得るステータスを示してい ます タスクのステータス 説明 作成 AWS DMS がタスクを作成中です 実行中 タスクが指定された移行処理を実行中です 停止 タスクが停止されました 停止中 タスクが停止中です これは通常 タスクでのユーザーによ る介入を示します 削除 タスクが (通常はユーザーによる介入のためリクエストから) 削除中です Failed タスクが失敗しました 詳細については タスクのログファ イルを参照してください Starting タスクがレプリケーションインスタンスに さらにソースお よびターゲットエンドポイントに接続中です フィルタと変 換を適用中です 241

248 タスク実行中のテーブルの状態 タスクのステータス 説明 準備完了 タスクの実行準備ができました このステータスになるのは 通常 "creating" 状態の後です 変更中 タスクが (通常はユーザーによるタスク設定の変更アクショ ンのため) 変更中です タスクのステータスバーで タスクの進捗状況を予測できます この予測の正確さはソースデータベース のテーブル統計の正確さによって異なります テーブル統計が正確であればあるほど 正確に予測できま す 予測された列の統計がないテーブルが 1 つだけのタスクでは どのような種類であっても完了率の予 測を提供できません この場合 タスクのステータスと ロードされた列の表示を使って タスクが実際 に実行されて進行していることを確認できます タスク実行中のテーブルの状態 AWS DMS コンソールは 移行中にテーブルの状態に関する情報を更新します 以下の表では 表示され る可能性のある状態値を示しています 州/地域 説明 テーブルが存在しません AWS DMS がソースエンドポイントでテーブルを見つけられ ません ロード前 フルロードプロセスが有効になっていますが まだ開始され ていません 242

249 Amazon CloudWatch を使用したレ プリケーションモニタリングタスク 州/地域 説明 Full load 全ロードプロセスが進行中です Table completed 全ロードが完了しました Table cancelled テーブルのロードがキャンセルされました Table error テーブルのロード時にエラーが発生しました Amazon CloudWatch を使用したレプリケーション モニタリングタスク Amazon CloudWatch のアラームやイベントを使用して 移行をより詳細に追跡できます Amazon CloudWatch の詳細については Amazon CloudWatch ユーザーガイド の Amazon CloudWatch Amazon CloudWatch Events Amazon CloudWatch Logs とは をご覧ください Amazon CloudWatch の使用には料金が発生することに注意してください AWS DMS コンソールには 次の図に示すように タスクのステータス 完了率 経過時間 テーブル の統計を含めて 各タスクの基本的な CloudWatch 統計が表示されます レプリケーションタスクを選択 し [Task monitoring] タブを選択します 243

250 Amazon CloudWatch を使用したレ プリケーションモニタリングタスク AWS DMS コンソールで [Table statistics (テーブル統計)] タブを選択すると 挿入 削除 更新の数な ど 各テーブルのパフォーマンス統計が表示されます 244

251 データ移行サービスメトリクス 加えて [Replication Instance] ページからレプリケーションインスタンスを選択した場合 [Monitoring] タ ブを選択することでインスタンスのパフォーマンスメトリクスを表示できます データ移行サービスメトリクス AWS DMS には 次の統計情報が表示されます ホストメトリクス Amazon CloudWatch により提供されるレプリケーションホストのパフォーマンス および使用状況の統計 使用可能なメトリクスの完全なリストについては レプリケーションインス タンスのメトリクス (p. 246) を参照してください レプリケーションタスクメトリクス 受信した変更とコミットされた変更 レプリケーションホストと ソースおよびターゲットデータベースの間のレイテンシーなど レプリケーションタスクの統計 使用 可能なメトリクスの完全なリストについては レプリケーションタスクのメトリクス (p. 247) を参 照してください テーブルメトリクス 挿入 更新 削除 完了した DDL ステートメントの数など 移行が進行中のテー ブルの統計 245

252 レプリケーションインスタンスのメトリクス タスクメトリクスは レプリケーションホストおよびソースエンドポイント間の統計と レプリケー ションホストおよびターゲットエンドポイント間の統計に分けられます 関連する 2 つの統計を一緒に 追加することで タスクの統計の合計を調べることもできます たとえば CDCLatencySource 値と CDCLatencyTarget 値を組み合わせることで タスクの合計レイテンシー (レプリカラグ) を調べることが できます タスクメトリック値は ソースデータベースにおける現在のアクティビティの影響を受ける可能性があり ます たとえば トランザクションが開始したが コミットされていない場合 CDCLatencySource メト リクスはトランザクションがコミットされるまで大きくなり続けます レプリケーションインスタンスの場合 FreeableMemory メトリクスには説明が必要です 解放可能なメ モリは 実際の使用可能な空きメモリを示しているわけではありません これは 解放して他の用途に使 用できる現在使用中のメモリであり レプリケーションインスタンスで使用されているバッファとキャッ シュの組み合わせです FreeableMemory メトリクスに実際の使用可能な空きメモリは反映されませんが FreeableMemory およ び SwapUsage メトリクスの組み合わせにより レプリケーションインスタンスが過負荷になっているか どうかがわかります 次の状態について これらの 2 つのメトリクスをモニタリングします FreeableMemory メトリクスが 0 に近づいている SwapUsage メトリクスが増加または変動する これらの 2 つの状態のいずれかが表示された場合は より大きなレプリケーションインスタンスへの移行 を検討する必要があります また レプリケーションインスタンスで実行中のタスクの数とタイプを減ら すことも検討してください 全ロードタスクは 変更をレプリケートするだけのタスクよりも多くのメモ リを必要とします レプリケーションインスタンスのメトリクス レプリケーションインスタンスのモニタリングには 次の統計に関する Amazon CloudWatch メトリクス が含まれています CPUUtilization 使用される CPU の量 単位: バイト FreeStorageSpace 使用可能なストレージ領域の容量 単位: バイト FreeableMemory 使用可能な RAM の容量 単位: バイト WriteIOPS 1 秒あたりのディスク I/O 操作の平均回数 単位: Count/Second ReadIOPS 1 秒あたりのディスク I/O 操作の平均回数 246

253 レプリケーションタスクのメトリクス 単位: Count/Second WriteThroughput 1 秒あたりのディスクへの平均書き込みバイト数 単位: バイト/Second ReadThroughput 1 秒あたりのディスクからの平均読み取りバイト数 単位: バイト/Second WriteLatency 1 回のディスク I/O 操作にかかる平均時間 単位: Seconds ReadLatency 1 回のディスク I/O 操作にかかる平均時間 単位: Seconds SwapUsage レプリケーションインスタンスで使用されるスワップ領域の量 単位: バイト NetworkTransmitThroughput モニタリングとレプリケーションに使用される顧客データベーストラフィックと AWS DMS トラ フィックの両方を含む レプリケーションインスタンスの送信ネットワークトラフィック 単位: バイト/秒 NetworkReceiveThroughput モニタリングとレプリケーションに使用される顧客データベーストラフィックと AWS DMS トラ フィックの両方を含む レプリケーションインスタンスの受信ネットワークトラフィック 単位: バイト/秒 レプリケーションタスクのメトリクス レプリケーションタスクのモニタリングには 次の統計のメトリクスが含まれています FullLoadThroughputBandwidthSource ソースから受信した全ロードによるネットワーク帯域幅 (1 秒あたりの KB 数) FullLoadThroughputBandwidthTarget ターゲットに送信される全ロードによるネットワーク帯域幅 (1 秒あたりの KB 数) FullLoadThroughputRowsSource ソースから受信した全ロードによる変更 (1 秒あたりの行数) FullLoadThroughputRowsTarget ターゲットに送信される全ロードによる変更 (1 秒あたりの行数) 247

254 AWS DMS ログを管理する CDCIncomingChanges ターゲットへの適用を待機している 特定の時点での変更イベントの合計数 これは ソースエンド ポイントのトランザクション変更レートの測定と同じではありません 通常 このメトリクスの多く は AWS DMS がキャプチャされた変更をタイムリーに適用できず ターゲットのレイテンシーが高 くなっていることを示します CDCChangesMemorySource メモリに累積され ソースからのコミットを待機している行の数 CDCChangesMemoryTarget メモリに累積され ターゲットへのコミットを待機している行の数 CDCChangesDiskSource ディスクに累積され ソースからのコミットを待機している行の数 CDCChangesDiskTarget ディスクに累積され ターゲットへのコミットを待機している行の数 CDCThroughputBandwidthSource ターゲットのネットワーク帯域幅 (KB/秒) CDCThroughputBandwidth は サンプリングポイントで 帯域幅を記録します ネットワークトラフィックが見つからない場合 値は 0 です CDC は長時間実 行トランザクションを発行しないため ネットワークトラフィックは記録されない場合があります CDCThroughputBandwidthTarget ターゲットのネットワーク帯域幅 (KB/秒) CDCThroughputBandwidth は サンプリングポイントで 帯域幅を記録します ネットワークトラフィックが見つからない場合 値は 0 です CDC は長時間実 行トランザクションを発行しないため ネットワークトラフィックは記録されない場合があります CDCThroughputRowsSource ソースから受信したタスクの変更 (1 秒あたりの行数) CDCThroughputRowsTarget ターゲットに送信されるタスクの変更 (1 秒あたりの行数) CDCLatencySource ソースエンドポイントからキャプチャされた最後のイベントと AWS DMS インスタンスの現在のシ ステムタイムスタンプの間の間隔 (秒) タスクの絞り込みによりソースから変更がキャプチャされな い場合 この値はゼロに設定されます CDCLatencyTarget ターゲットでコミットを待機中の最初のイベントタイムスタンプと AWS DMS インスタンスの現在 のタイムスタンプの間の間隔 (秒) この値は ターゲットによって処理されていないトランザクショ ンがある場合に発生します それ以外の場合 すべてのトランザクションが適用されると ターゲッ トレイテンシーはソースレイテンシーと同じになります ターゲットレイテンシーをソースレイテン シーより小さくすることはできません AWS DMS タスクログの管理 AWS DMS は 移行プロセス中に Amazon CloudWatch を使用してタスク情報を記録します AWS CLI または AWS DMS API を使用すると タスクログに関する情報を表示できます これを行うに は describe-replication-instance-task-logs AWS CLI コマンドまたは AWS DMS API アク ション DescribeReplicationInstanceTaskLogs を使用します たとえば 次の AWS CLI コマンドは JSON 形式のタスクログメタデータを表示します 248

255 AWS CloudTrail を使用した AWS DMS API コールのログ作成 $ aws dms describe-replication-instance-task-logs \ --replication-instance-arn arn:aws:dms:us-east-1: :rep:cdsfsfsfffssufcay コマンドからのレスポンス例を次に示します "ReplicationInstanceTaskLogs": [ "ReplicationTaskArn": "arn:aws:dms:useast-1: :task:my34u6z4msy52grtix3o4ay", "ReplicationTaskName": "mysql-to-ddb", "ReplicationInstanceTaskLogSize": ], "ReplicationInstanceArn": "arn:aws:dms:us-east-1: :rep:cdsfsfsfffssufcay" このレスポンスでは 1 つのタスクログ (mysql-to-ddb) がレプリケーションインスタンスに関連付けら れています このログのサイズは 3,726,124 バイトです describe-replication-instance-task-logs により返される情報を使用して タスクログの問題 を診断およびトラブルシューティングできます たとえば タスクの詳細なデバッグログを有効にした場 合 タスクログはすぐに大きくなるため レプリケーションインスタンスの使用可能なストレージをすべ て消費し インスタンスステータスが storage-full に変化する可能性があります タスクログを記述 することによって 必要ないタスクログを判断できます これにより それらのタスクログを削除してス トレージ領域を解放できます タスクのタスクログを削除するには タスク設定 DeleteTaskLogs を true に設定します たとえ ば AWS CLI modify-replication-task コマンドまたは AWS DMS API ModifyReplicationTask アクションを使用してタスクを変更するときに 次の JSON はタスクログを削除します "Logging": "DeleteTaskLogs":true AWS CloudTrail を使用した AWS DMS API コール のログ作成 AWS DMS は AWS CloudTrail と統合されています このサービスは AWS DMS 内でユーザーや ロール または AWS のサービスによって実行されたアクションを記録するサービスです CloudTrail は AWS DMS コンソールからのコールや AWS DMS API へのコード呼び出しを含む AWS DMS のす べての API コールをイベントとしてキャプチャします 証跡を作成する場合は AWS DMS のイベントな ど Amazon S3 バケットへの CloudTrail イベントの継続的な配信を有効にすることができます 証跡を設 定しない場合でも CloudTrail コンソールの [Event history (イベント履歴)] で最新のイベントを表示でき ます CloudTrail によって収集された情報を使用して リクエストの作成元の IP アドレス リクエストの 実行者 リクエストの実行日時などの詳細を調べて AWS DMS に対してどのようなリクエストが行われ たかを判断できます 249

256 CloudTrail 内の AWS DMS 情報 CloudTrail の詳細については AWS CloudTrail User Guide を参照してください CloudTrail 内の AWS DMS 情報 CloudTrail は アカウント作成時に AWS アカウントで有効になります AWS DMS でアクティビティが 発生すると そのアクティビティは [Event history (イベント履歴)] の AWS の他のサービスのイベントと ともに CloudTrail イベントに記録されます 最近のイベントは AWS アカウントで表示 検索 ダウン ロードできます 詳細については CloudTrail イベント履歴でのイベントの表示 を参照してくださ い AWS DMS のイベントなど AWS アカウントのイベントの継続的な記録については 証跡を作成します 証跡により CloudTrail はログファイルを Amazon S3 バケットに配信できます デフォルトでは コン ソールで証跡を作成するときに 証跡がすべてのリージョンに適用されます 証跡では AWS パーティ ションのすべてのリージョンからのイベントがログに記録され 指定した Amazon S3 バケットにログ ファイルが配信されます さらに より詳細な分析と CloudTrail ログで収集されたデータに基づいた行 動のためにその他の AWS サービスを設定できます 詳細については 以下のトピックを参照してくださ い 証跡を作成するための概要 CloudTrail でサポートされるサービスと統合 CloudTrail の Amazon SNS 通知の設定 複数のリージョンから CloudTrail ログファイルを受け取る と 複数のアカウントから CloudTrail ロ グファイルを受け取る AWS DMS アクションはすべて CloudTrail によって記録されます また これらのアク ションは AWS Database Migration Service API Referenceで説明されています たとえ ば CreateReplicationInstance TestConnection StartReplicationTask の各アクション を呼び出すと CloudTrail ログファイルにエントリが生成されます 各イベントまたはログエントリには リクエストの生成者に関する情報が含まれます この ID 情報は以下 のことを確認するのに役立ちます リクエストが ルートと IAM ユーザー認証情報のどちらを使用して送信されたか リクエストが ロールとフェデレーティッドユーザーのどちらの一時的なセキュリティ認証情報を使用 して送信されたか. リクエストが 別の AWS サービスによって送信されたかどうか 詳細については CloudTrail useridentity 要素 を参照してください AWS DMS ログファイルエントリの概要 証跡は 指定した Amazon S3 バケットにイベントをログファイルとして配信できる設定です CloudTrail ログファイルには 1 つ以上のログエントリが含まれます イベントは任意の送信元からの単一のリクエ ストを表し リクエストされたアクション アクションの日時 リクエストのパラメータなどに関する情 報が含まれます CloudTrail ログファイルは パブリック API 呼び出しの順序付けられたスタックトレー スではないため 特定の順序では表示されません 以下の例は RebootReplicationInstance アクションの CloudTrail ログエントリを示しています "eventversion": "1.05", "useridentity": "type": "AssumedRole", "principalid": "AKIAIOSFODNN7EXAMPLE:johndoe", 250

257 AWS DMS ログファイルエントリの概要 "arn": "arn:aws:sts:: :assumed-role/admin/johndoe", "accountid": " ", "accesskeyid": "ASIAYFI33SINADOJJEZW", "sessioncontext": "attributes": "mfaauthenticated": "false", "creationdate": " T16:42:09Z", "sessionissuer": "type": "Role", "principalid": "AKIAIOSFODNN7EXAMPLE", "arn": "arn:aws:iam:: :role/admin", "accountid": " ", "username": "admin", "eventtime": " T00:11:44Z", "eventsource": "dms.amazonaws.com", "eventname": "RebootReplicationInstance", "awsregion": "us-east-1", "sourceipaddress": " ", "useragent": "console.amazonaws.com", "requestparameters": "forcefailover": false, "replicationinstancearn": "arn:aws:dms:useast-1: :rep:ex4mbj2nmrdl3bmayjoxugypue", "responseelements": "replicationinstance": "replicationinstanceidentifier": "replication-instance-1", "replicationinstancestatus": "rebooting", "allocatedstorage": 50, "replicationinstanceprivateipaddresses": [ " " ], "instancecreatetime": "Aug 1, :56:21 PM", "autominorversionupgrade": true, "engineversion": "2.4.3", "publiclyaccessible": true, "replicationinstanceclass": "dms.t2.medium", "availabilityzone": "us-east-1b", "kmskeyid": "arn:aws:kms:us-east-1: :key/f7bc0f8e-1a3a-4ace-9faae8494fa3921a", "replicationsubnetgroup": "vpcid": "vpc-1f6a9c6a", "subnetgroupstatus": "Complete", "replicationsubnetgrouparn": "arn:aws:dms:useast-1: :subgrp:edhrvrbaaaponqaiywp4nuw22m", "subnets": [ "subnetidentifier": "subnet-cbfff283", "subnetavailabilityzone": "name": "us-east-1b", "subnetstatus": "Active", "subnetidentifier": "subnet-d7c825e8", "subnetavailabilityzone": "name": "us-east-1e", "subnetstatus": "Active", "subnetidentifier": "subnet b", 251

258 AWS DMS ログファイルエントリの概要,,, "subnetavailabilityzone": "name": "us-east-1f", "subnetstatus": "Active" "subnetidentifier": "subnet-bac383e0", "subnetavailabilityzone": "name": "us-east-1c", "subnetstatus": "Active" "subnetidentifier": "subnet ", "subnetavailabilityzone": "name": "us-east-1d", "subnetstatus": "Active" "subnetidentifier": "subnet-da327bf6", "subnetavailabilityzone": "name": "us-east-1a", "subnetstatus": "Active" ], "replicationsubnetgroupidentifier": "default-vpc-1f6a9c6a", "replicationsubnetgroupdescription": "default group created by console for vpc id vpc-1f6a9c6a", "replicationinstanceeniid": "eni-0d6db8c7137cb9844", "vpcsecuritygroups": [ "vpcsecuritygroupid": "sg-f839b688", "status": "active" ], "pendingmodifiedvalues":, "replicationinstancepublicipaddresses": [ " " ], "replicationinstancepublicipaddress": " ", "preferredmaintenancewindow": "fri:22:44-fri:23:14", "replicationinstancearn": "arn:aws:dms:useast-1: :rep:ex4mbj2nmrdl3bmayjoxugypue", "replicationinstanceeniids": [ "eni-0d6db8c7137cb9844" ], "multiaz": false, "replicationinstanceprivateipaddress": " ", "patchingprecedence": 0, "requestid": "a3c83c11-95e8-11e8-9d08-4b8f2b45bfd5", "eventid": "b3c4adb1-e34b-4744-bdeb a541", "eventtype": "AwsApiCall", "recipientaccountid": " " 252

259 レプリケーションタスクの統計 AWS DMS タスクの検証 AWS DMS は データがソースからターゲットに正確に移行されたことを確認するため データ検証のサ ポートを提供します タスクに対してこれを有効にすると AWS DMS は テーブルに対して全ロードが 実行された後で ソースデータとターゲットデータの比較をすぐに開始します データ検証はオプションです AWS DMS はソースレコードとターゲットレコードを比較し 不一致があ るとそれを報告します さらに AWS DMS は CDC が有効なタスクについては 増分変更を比較し 不 一致があるとそれを報告します データの検証中に AWS DMS はソースの各行をターゲットの対応する行と比較し それらの行に同じデー タが含まれていることを確認します AWS DMS は これを達成するため 適切なクエリを実行してデー タを取得します これらのクエリは ソースとターゲットでその他のリソースと その他のネットワーク リソースを消費します データ検証は以下のサービスと連携して動作します Oracle PostgreSQL MySQL MariaDB Microsoft SQL Server Amazon Aurora (MySQL) Amazon Aurora (PostgreSQL) データの検証には 移行自体に必要な時間以外にも さらに時間がかかります 必要な追加の時間は 移 行されたデータの量によって異なります データの検証設定には 以下のものが含まれます データ検証を有効にするには EnableValidation 設定を true に設定します 検証中に AWS DMS が使用する実行スレッドの数を調整するには ThreadCount の値を設定しま す ThreadCount のデフォルト値は 5 です ThreadCount をより高い値に設定すると AWS DMS は検証をより速く完了できます ただし より多くの同時クエリを実行し ソースとターゲットで消費 するリソースが増えます たとえば 以下の JSON では検証を有効にし スレッドの数をデフォルト設定の 5 から 8 に増やします ValidationSettings": "EnableValidation":true, "ThreadCount":8 レプリケーションタスクの統計 データ検証が有効になっている場合 AWS DMS はテーブルレベルで以下の統計情報を提供します ValidationState テーブルの検証状態 このパラメータには以下の値があります Not enabled 移行タスクでテーブルに対して検証が有効化されていません Pending records テーブル内の一部のレコードが 検証を待機しています 253

260 レプリケーションタスクの統計 Mismatched records テーブル内の一部のレコードが ソースとターゲット間で一致しません さま ざまな理由により 不一致が発生することがあります 詳細については ターゲットエンドポイント の awsdms_validation_failures を確認してください Suspended records テーブル内に検証できないレコードがあります No primary key テーブルにプライマリキーがないため 検証できません Table error テーブルがエラー状態で一部のデータが移行されなかったため テーブルは検証されま せんでした Validated テーブル内のすべての行が検証されます テーブルが更新された場合 ステータスは [Validated] から変わる可能性があります Error 予期しないエラーが発生したため テーブルを検証できません ValidationPending ターゲットに移行されたが まだ検証されていないレコードの数 ValidationSuspended AWS DMS が比較することができないレコードの数 たとえば ソースのレ コードが頻繁に更新されている場合 AWS DMS は ソースとターゲットを比較できません 詳細につ いては エラー処理タスクの設定 (p. 214) を参照してください ValidationFailed データの検証フェーズに合格しなかったレコードの数 詳細については エラー 処理タスクの設定 (p. 214) を参照してください ValidationSucceededRecordCount AWS DMS が検証した 1 分あたりの行数 ValidationAttemptedRecordCount 検証が試行された行の 1 分あたりの数 ValidationFailedOverallCount 検証が失敗した行の数 ValidationSuspendedOverallCount 検証が停止された行の数 ValidationPendingOverallCount 検証がまだ保留中の行の数 ValidationBulkQuerySourceLatency AWS DMS は 特に多くの変更がある場合に全ロード中または継 続的なレプリケーション中の特定のシナリオで データの検証を一括して実行できます このメトリッ クスは ソースエンドポイントから大量のデータを読み取るために必要なレイテンシーを示します ValidationBulkQueryTargetLatency AWS DMS は 特に多くの変更がある場合に全ロード中または継 続的なレプリケーション中の特定のシナリオで データの検証を一括して実行できます このメトリッ クスは ターゲットエンドポイントの大量のデータを読み取るために必要なレイテンシーを示します ValidationItemQuerySourceLatency 継続的なレプリケーションでは データ検証によって継続的な 変更を識別し それらの変更を検証できます このメトリックスは 変更をソースから読み取る際のレ イテンシーを示します 検証中にエラーが発生した場合 検証では必要な数以上のクエリを実行できま す ValidationItemQueryTargetLatency 継続的なレプリケーションでは データ検証によって継続的な変 更を識別し それらの変更を行ごとに検証できます このメトリックスは 変更をターゲットから読み 取る際のレイテンシーを示します 検証中にエラーが発生した場合 検証では必要な数以上のクエリが 実行される場合があります データ検証情報を表示するには コンソール AWS CLI または AWS DMS API を使用できます コンソールで タスクを作成または変更するときにタスクの検証を選択できます コンソールを使用 してデータ検証レポートを表示するには [Tasks] ページでタスクを選択し 詳細セクションの [Table statistics] タブを選択します CLI を使用して タスクを作成または変更してデータ検証を開始するときに EnableValidation パ ラメータを true に設定します 以下の例では タスクを作成し データ検証を有効にします create-replication-task --replication-task-settings '"ValidationSettings":"EnableValidation":true' --replication-instance-arn arn:aws:dms:us-east-1: : rep:36kwvmb7q --source-endpoint-arn arn:aws:dms:us-east-1: : endpoint:cszaefqurfymm --target-endpoint-arn arn:aws:dms:us-east-1: : endpoint:cgpp7mf6wt4jq 254

261 トラブルシューティング --migration-type full-load-and-cdc --table-mappings '"rules": ["rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": "schema-name": "data_types", "table-name": "%", "rule-action": "include"]' describe-table-statistics コマンドを使用して JSON 形式でデータ検証レポートを受け取りま す 以下のコマンドでは データ検証レポートを表示します aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1: : rep:36kwvmb7q このレポートは以下の例のようになります "ReplicationTaskArn": "arn:aws:dms:us-west-2: :task:vfpftykk2rysi", "TableStatistics": [ "ValidationPendingRecords": 2, "Inserts": 25, "ValidationState": "Pending records", "ValidationSuspendedRecords": 0, "LastUpdateTime": , "FullLoadErrorRows": 0, "FullLoadCondtnlChkFailedRows": 0, "Ddls": 0, "TableName": "t_binary", "ValidationFailedRecords": 0, "Updates": 0, "FullLoadRows": 10, "TableState": "Table completed", "SchemaName": "d_types_s_sqlserver", "Deletes": 0 AWS DMS API を使用し [CreateReplicationTask] アクションを使ってタスクを作成します 次 に EnableValidation パラメータを true に設定して タスクによって移行されたデータを検証し ます DescribeTableStatistics アクションを使用して JSON 形式でデータ検証レポートを受け取りま す トラブルシューティング 検証中に AWS DMS はターゲットエンドポイント awsdms_validation_failures_v1 に新しいテー ブルを作成します レコードが ValidationSuspended または ValidationFailed 状態になった場合 AWS DMS は診断情報を awsdms_validation_failures_v1 に書き込みます このテーブルをクエリするこ とで 検証エラーをトラブルシューティングすることができます 以下に awsdms_validation_failures_v1 テーブルの説明を示します 列名 データタイプ 説明 TASK_NAME VARCHAR(128) NOT NULL AWS DMS タスク識別子 TABLE_OWNER VARCHAR(128) NOT NULL テーブルのスキーマ (所有者) 255

262 制約事項 列名 データタイプ 説明 TABLE_NAMEVARCHAR(128) NOT NULL テーブル名 FAILURE_TIME DATETIME(3) NOT NULL イベントが失敗した時刻 KEY これは行レコードタイプのプライマリキーです TEXT NOT NULL FAILURE_TYPE VARCHAR(128) NOT NULL 検証エラーの重大度 Failed または Suspended とすることができ ます 以下のクエリでは awsdms_validation_failures_v1 テーブルに対してクエリを実行して タスク のすべての失敗を表示します タスク名は タスクの外部リソース ID である必要があります タスクの外 部リソース ID は タスク ARN の最後の値です たとえば ARN 値が arn:aws:dms:us-west-2:5599:task: VFPFKH4FJR3FTYKK2RYSI のタスクの場合 タスクの外部リソース ID は VFPFKH4FJR3FTYKK2RYSI となります select * from awsdms_validation_failures_v1 where TASK_NAME = VFPFKH4FJR3FTYKK2RYSI 失敗したレコードのプライマリキーを入手したら ソースエンドポイントとターゲットエンドポイントを クエリし レコードの一致しない部分を確認できます 制約事項 データ検証では テーブルにプライマリキーまたは一意のインデックスがなければなりません プライマリキー列の型を CLOB BLOB または BYTE に設定することはできません 型が VARCHAR または CHAR であるプライマリキー列の場合 長さは 1024 未満にする必要がありま す ターゲット PostgreSQL インスタンスのプライマリキー列の照合が C に設定されていない場合 プライマリキーと Oracle ではソート順が異なります PostgreSQL と Oracle でソート順序が異なる場 合 データ検証でレコードの検証に失敗します データ検証では ソースデータベースとターゲットデータベースに対して追加のクエリが生成されま す 両方のデータベースに この追加の負荷を処理するための十分なリソースがあることを確認する必 要があります 移行でカスタマイズされたフィルタリングを使用する場合や 複数のデータベースを 1 つに統合する 際 データ移行はサポートされません ソースまたはターゲット Oracle エンドポイントの場合 AWS DMS は DBMS_CRYPTO を使用して BLOB を検証します Oracle エンドポイントで BLOB を使用する場合は Oracle エンドポイントにアク セスするために使用されるユーザーアカウントに dbms_crypto での実行権限を付与する必要がありま す これを行うには 以下のステートメントを実行します grant execute on sys.dbms_crypto to <dms_endpoint_user>; 検証中にターゲットデータベースが AWS DMS 外部で変更された場合 不整合は正確に報告されない可 能性があります これは AWS DMS によってターゲットテーブルで検証が実行されている際に いず れかのアプリケーションがそのテーブルにデータを書き込む場合に発生する可能性があります 1 つまたは複数の行が検証中に継続的に変更される場合 AWS DMS はそれらの行を検証することがで きません ただし タスクの完了後に それらの行を手動で検証することができます 256

263 制約事項 AWS DMS が 10,000 以上の失敗または停止されたレコードを検出した場合 検証は中止されます 先 に進む前に データの根本的な問題を解決する必要があります 257

264 AWS Database Migration Service で のリソースへのタグ付け AWS Database Migration Service (AWS DMS) のタグを使用して リソースにメタデータを追加できま す また これらのタグを AWS Identity and Access Management (IAM) ポリシーで使用して AWS DMS リソースへのアクセスを管理したり AWS DMS リソースに適用できるアクションを制御したりできま す 最後に これらのタグを使用して 類似のリソースの費用をグループ化することで コストを追跡で きます 以下のすべての AWS DMS リソースにタグを付けることができます レプリケーションインスタンス エンドポイント レプリケーションタスク 証明書 AWS DMS タグは AWS DMS リソースを定義してそのリソースに関連付ける名前と値のペアです その 名前はキーと呼ばれます キーの値の指定は省略可能です タグを使用して AWS DMS リソースに任意 の情報を割り当てることができます たとえば タグキーを使用してカテゴリを定義し タグ値をそのカ テゴリのアイテムにすることができます 具体的には project というタグキーと Salix というタグ 値を定義して AWS DMS リソースが Salix プロジェクトに割り当てられていることを示すことができま す また タグキーとして environment=test や environment=production などを使用して AWS DMS リ ソースがテスト用なのか本稼働用なのかを示すこともできます AWS DMS リソースに関連付けられてい るメタデータの追跡が簡単になるように 一貫した一連のタグキーを使用することをお勧めします タグを使用して ユーザー独自のコスト構造を反映するように AWS 請求を整理します そのために は AWS アカウントにサインアップして タグキー値が含まれた AWS アカウントの請求書を取得する 必要があります 次に 結合したリソースのコストを見るには 同じタグキー値のリソースに従って請求 書情報を整理します たとえば 複数のリソースに特定のアプリケーション名のタグを付け 請求情報を 整理することで 複数のサービスを利用しているアプリケーションの合計コストを確認することができま す 詳細については AWS 請求情報とコスト管理情報についての コスト配分とタグ付け を参照してく ださい 各 AWS DMS リソースにはタグセットがあり それぞれの AWS DMS リソースに割り当てられているす べてのタグが含まれています タグセットには 最大 10 個のタグを格納でき 空にすることもできま す AWS DMS リソースに追加したタグのキーがそのリソースの既存のタグのキーと同じ場合 既存の値 は新しい値によって上書きされます AWS はタグに関連する意味を適用しません タグはキャラクタ文字列として厳密に解釈されます AWS DMS は リソース作成時の設定に応じて AWS DMS リソースにタグを設定する場合があります AWS DMS タグの特徴は以下のとおりです タグキーは 必須のタグ名です 文字列値は 文字の Unicode 文字です aws: または dms: をプレフィックスとして使用することはできません 文字列には 一連の Unicode 文字 数 字 空白 _. / = + - (Java 正規表現: "^([\\pl\\pz\\pn_.:/=+\\-]*)$) だけが含まれます タグ値は タグの省略可能な文字列値です 文字列値は 文字の Unicode 文字です aws: または dms: をプレフィックスとして使用することはできません 文字列には 一連の Unicode 文 258

265 API 字 数字 空白 _. / = + - (Java 正規表現: "^([\\pl\\pz\\pn_.:/=+\ \-]*)$) だけが含まれます 値はタグセット内で一意である必要はなく null を指定できます 例えば project/trinity と cost-center/ Trinity のタグセット内に 1 つのキーと値のペアを使用できます AWS CLI あるいは AWS DMS API を使用して AWS DMS リソースにタグの追加 一覧表示あるいは 削除ができます AWS CLI または AWS DMS API を使用するときは 操作する AWS DMS リソースの Amazon リソースネーム (ARN) を指定する必要があります ARN の作成の詳細については AWS DMS の Amazon リソースネーム (ARN) の構築 (p. 11) を参照してください タグはリソース承認用にキャッシュに格納されます そのため AWS DMS リソースに対するタグの追加 や更新には数分かかることがあります API AWS DMS API を使用して AWS DMS リソースのタグを追加 一覧表示 または削除できます AWS DMS リソースにタグを追加するには AddTagsToResource オペレーションを使用します AWS DMS リソースに割り当てられているタグを一覧表示するには ListTagsForResource オペ レーションを使用します AWS DMS リソースからタグを削除するには RemoveTagsFromResource オペレーションを使用しま す 必要な ARN を作成する方法の詳細については AWS DMS の Amazon リソースネーム (ARN) の構 築 (p. 11) を参照してください AWS DMS API を使用して XML を操作する場合 タグでは以下のスキーマを使用します <Tagging> <TagSet> <Tag> <Key>Project</Key> <Value>Trinity</Value> </Tag> <Tag> <Key>User</Key> <Value>Jones</Value> </Tag> </TagSet> </Tagging> 以下の表に示しているのは 使用可能な XML タグとその特性のリストです キーと値では大文字と小文 字が区別されます たとえば project=trinity と PROJECT=Trinity は 2 つの別個のタグです タグ付け要素 説明 タグセット タグセットは Amazon RDS リソースに割り当てられるすべてのタグのコ ンテナーです リソースごとに割り当て可能なのは 1 つのタグセットのみで す AWS DMS API によってのみタグセットを操作できます Tag タグはユーザー定義のキーと値のペアです 1 10 個のタグをタグセットに 含めることができます 259

266 API タグ付け要素 説明 キー キーはタグの必須の名前です 文字列値は 文字の Unicode 文字 です dms: または aws: をプレフィックスとして使用することはで きません 文字列には 一連の Unicode 文字 数字 空白 _. / = + - (Java 正規表現: "^([\\pl\\pz\\pn_.:/=+\\-]*)$) だけが含まれます キーはタグセットに対して一意である必要があります たとえば タグ セットでキーが同じで値が異なるキーと値のペアは使用できません たとえ ば project/trinity や project/xanadu は使用できません 値 値はタグの省略可能な値です 文字列値は 文字の Unicode 文字 です dms: または aws: をプレフィックスとして使用することはで きません 文字列には 一連の Unicode 文字 数字 空白 _. / = + - (Java 正規表現: "^([\\pl\\pz\\pn_.:/=+\\-]*)$) だけが含まれます 値はタグセット内で一意である必要はなく null を指定できます 例え ば project/trinity と cost-center/trinity のタグセット内に 1 つのキーと値の ペアを使用できます 260

267 AWS Database Migration Service の イベントと通知の使用 AWS Database Migration Service (AWS DMS) は Amazon Simple Notification Service (Amazon SNS) を 使用して AWS DMS イベントが発生したときに (レプリケーションインスタンスが作成されたときや 削除されたときなどに) 通知を送信します これらの通知は E メールメッセージ テキストメッセー ジ HTTP エンドポイントの呼び出しなど AWS リージョン用に Amazon SNS でサポートされているい ずれの形式でも使用できます AWS DMS は サブスクライブ可能なカテゴリにイベントをグループ分けします これにより そのカテ ゴリのイベントが発生すると 通知を受け取ることができます たとえば 特定のレプリケーションイン スタンスの作成カテゴリにサブスクライブした場合は レプリケーションインスタンスに影響を与える作 成関連のイベントが発生するたびに通知を受け取ります レプリケーションインスタンスの設定変更カテ ゴリにサブスクライブした場合は レプリケーションインスタンスの設定が変更されると 通知を受け取 ります また イベント通知サブスクリプションが変更されても 通知を受け取ります AWS DMS に用 意されているイベントカテゴリのリストについては 以下の AWS DMS イベントのカテゴリおよびイベ ントメッセージ (p. 262) を参照してください AWS DMS は イベントサブスクリプションを作成するときに指定したアドレスにイベント通知を送信し ます いくつかの異なるサブスクリプションを作成することもできます たとえば すべてのイベント通 知を受け取るサブスクリプションと 本稼働環境の DMS リソースに関する重要なイベントのみを含むサ ブスクリプションを作成できます AWS DMS コンソールで [Enabled (有効)] オプションを [No (いいえ)] に設定するか AWS DMS API を使用して Enabled パラメータを [false] に設定することで サブスクリ プションを削除せずに通知を簡単に無効にすることができます Note SMS テキストメッセージを使用した AWS DMS イベント通知は現在 AWS DMS がサポートさ れているすべてのリージョンで AWS DMS リソースで使用できます SNS によるテキストメッ セージの使用の詳細については Amazon SNS を使用した SMS 通知の送信と受信 を参照し てください AWS DMS では サブスクリプション識別子を使用して各サブスクリプションが識別されます 複数の AWS DMS イベントサブスクリプションを同じ Amazon SNS トピックに公開できます イベント通知を 使用する場合は Amazon SNS 料金が適用されます Amazon SNS の請求の詳細については Amazon SNS 料金表 を参照してください AWS DMS イベントにサブスクライブするには 以下のプロセスを使用します 1. Amazon SNS トピックを作成します トピックでは 受け取る通知のタイプと 通知先のアドレスまた は番号を指定します 2. AWS マネジメントコンソール AWS CLI または AWS DMS API を使用して AWS DMS イベント通 知サブスクリプションを作成します 3. サブスクリプションの作成で指定したアドレス宛てに AWS DMS から承認の E メールまたは SMS メッセージが送信されます サブスクリプションを確認するには 承認の E メールまたは SMS メッ セージのリンクをクリックします 4. サブスクリプションを確認すると AWS DMS コンソールの [Event Subscriptions (イベントサブスクリ プション)] セクションで サブスクリプションのステータスが更新されます 5. その後 イベント通知を受け取り始めます 通知できるカテゴリとイベントのリストについては 次のセクションを参照してください AWS DMS イ ベントサブスクリプションおよび使用方法の詳細については AWS DMS イベント通知へサブスクライ ブする (p. 263) を参照してください 261

268 AWS DMS イベントのカテゴリおよびイベントメッセージ AWS DMS イベントのカテゴリおよびイベントメッ セージ AWS DMS では AWS DMS コンソールまたは AWS DMS API を使用してサブスクライブできるカテゴリ 内で多数のイベントが生成されます 各カテゴリはソースタイプに適用されます AWS DMS では現在 レプリケーションインスタンスとレプリケーションタスクのソースタイプがサポートされています 以下の表では レプリケーションインスタンスソースタイプの可能なカテゴリとイベントを示していま す カテゴリ DMS イベント ID 説明 設定変更 DMS-EVENT-0012 REP_INSTANCE_CLASS_CHANGING このレプリ ケーションインスタンスのレプリケーションインスタ ンスクラスが変更中です 設定変更 DMS-EVENT-0014 REP_INSTANCE_CLASS_CHANGE_COMPLETE こ のレプリケーションインスタンスのレプリケーション インスタンスクラスが変更されました 設定変更 DMS-EVENT-0018 BEGIN_SCALE_STORAGE レプリケーションインス タンスのストレージが増加中です 設定変更 DMS-EVENT-0017 FINISH_SCALE_STORAGE レプリケーションインス タンスのストレージが増加しました 設定変更 DMS-EVENT-0024 BEGIN_CONVERSION_TO_HIGH_AVAILABILITY レ プリケーションインスタンスがマルチ AZ 設定に移行 中です 設定変更 DMS-EVENT-0025 FINISH_CONVERSION_TO_HIGH_AVAILABILITY レ プリケーションインスタンスがマルチ AZ 設定に移行 されました 設定変更 DMS-EVENT-0030 BEGIN_CONVERSION_TO_NON_HIGH_AVAILABILITY レプリケーションインスタンスがシングル AZ 設定 に移行中です 設定変更 DMS-EVENT-0029 FINISH_CONVERSION_TO_NON_HIGH_AVAILABILITY レプリケーションインスタンスがシングル AZ 設定 に移行されました 作成 DMS-EVENT-0067 CREATING_REPLICATION_INSTANCE レプリケー ションインスタンスが作成中です 作成 DMS-EVENT-0005 CREATED_REPLICATION_INSTANCE レプリケー ションインスタンスが作成されました 削除 DMS-EVENT-0066 DELETING_REPLICATION_INSTANCE レプリケー ションインスタンスが削除中です 削除 DMS-EVENT-0003 DELETED_REPLICATION_INSTANCE レプリケー ションインスタンスが削除されました メンテナンス DMS-EVENT-0047 FINISH_PATCH_INSTANCE レプリケーションイン スタンスの管理ソフトウェアが更新されました 262

269 AWS DMS イベント通知へサブスクライブする カテゴリ DMS イベント ID 説明 メンテナンス DMS-EVENT-0026 BEGIN_PATCH_OFFLINE レプリケーションインス タンスのオフラインメンテナンスが実行中です レプ リケーションインスタンスは現在使用できません メンテナンス DMS-EVENT-0027 FINISH_PATCH_OFFLINE レプリケーションインス タンスのオフラインメンテナンスが完了しました レ プリケーションインスタンスは現在使用できます LowStorage DMS-EVENT-0007 LOW_STORAGE レプリケーションインスタンスの 空きストレージが少なくなっています フェイルオーバー DMS-EVENT-0013 FAILOVER_STARTED マルチ AZ レプリケーション インスタンスのフェイルオーバーが開始されました フェイルオーバー DMS-EVENT-0049 FAILOVER_COMPLETED マルチ AZ レプリケーショ ンインスタンスのフェイルオーバーが完了しました フェイルオーバー DMS-EVENT-0050 MAZ_INSTANCE_ACTIVATION_STARTED マルチ AZ アクティベーションが開始されました フェイルオーバー DMS-EVENT-0051 MAZ_INSTANCE_ACTIVATION_COMPLETED マル チ AZ アクティベーションが完了しました 失敗 DMS-EVENT-0031 REPLICATION_INSTANCE_FAILURE レプリケー ションインスタンスでストレージの障害が発生しまし た 失敗 DMS-EVENT-0036 INCOMPATIBLE_NETWORK 互換性のないネット ワークのためレプリケーションインスタンスで障害が 発生しました 以下の表では レプリケーションタスクソースタイプの可能なカテゴリとイベントを示しています カテゴリ DMS イベント ID 説明 StateChange DMS-EVENT-0069 REPLICATION_TASK_STARTED レプリケーション タスクが開始されました StateChange DMS-EVENT-0077 REPLICATION_TASK_STOPPED レプリケーション タスクが停止されました 失敗 DMS-EVENT-0078 REPLICATION_TASK_FAILED レプリケーションタ スクが失敗しました 削除 DMS-EVENT-0073 REPLICATION_TASK_DELETED レプリケーション タスクが削除されました 作成 DMS-EVENT-0074 REPLICATION_TASK_CREATED レプリケーション タスクが作成されました AWS DMS イベント通知へサブスクライブする AWS DMS イベント通知サブスクリプションを作成して AWS DMS イベントが発生したときに通知を 受け取るようにできます サブスクリプションを作成する最も簡単な方法は AWS DMS コンソールを使 263

270 AWS マネジメントコンソール 用する方法です AWS DMS API を使用してイベント通知サブスクリプションを作成する場合 Amazon SNS トピックを作成し Amazon SNS コンソールまたは API を使用してそのトピックにサブスクライブ する必要があります この場合 トピックの Amazon リソースネーム (ARN) も記録しておく必要があり ます この ARN は CLI コマンドまたは API アクションを送信するときに使用するためです Amazon SNS トピックを作成してサブスクライブする方法については Amazon SNS の開始方法 を参照してく ださい 通知サブスクリプションでは 通知するソースのタイプと イベントをトリガーする AWS DMS ソースを 指定できます SourceType 値を使用して AWS DMS ソースタイプを定義します SourceIdentifier 値を 使用して イベントを生成するソースを定義します [SourceType] と [SourceIdentifier] を SourceType = db-instance と SourceIdentifier = mydbinstance1 などに指定すると 指定したソースに関 するすべての DB_Instance イベントの通知を受け取ります SourceType を指定しても SourceIdentifier を指定しない場合は すべての AWS DMS ソースについて 指定したソースタイプのイベントの通知を受 け取ります SourceType も SourceIdentifier も指定しない場合は お客様のアカウントに属するすべての AWS DMS ソースから生成されたイベントの通知を受け取ります AWS マネジメントコンソール コンソールを使用して AWS DMS イベント通知にサブスクライブするには 1. AWS マネジメントコンソールにサインインし [AWS DMS] を選択します AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合は AWS DMS にアクセスするための適 切なアクセス許可が必要です 2. 左のナビゲーションペインで [Event Subscriptions] を選択します 3. [Event Subscriptions] ページで [Create Event Subscription] を選択します 4. [Create Event Subscription] ページで 以下の操作を行います a. [Name] に イベント通知サブスクリプションの名前を入力します b. [Send notifications to (通知の送信先)] 用の既存の Amazon SNS トピックを選択するか [create topic (トピックを作成)] を選択します 通知の送信先として 既存の Amazon SNS トピックを使 用するか トピックを作成する必要があります [create topic] を選択した場合 通知の送信先の E メールアドレスを入力できます c. [Source Type] で ソースタイプを選択します 選択できるのは [replication instance] のみで す d. [Yes] を選択して サブスクリプションを有効にします サブスクリプションを作成しても 通知 はまだ送信しない場合は [No] を選択します e. 選択したソースタイプに応じて イベント通知を受け取る対象となるイベントカテゴリとソース を選択します 264

271 AWS DMS API f. [Create] を選択します AWS DMS コンソールでは サブスクリプションが作成されることが示されます AWS DMS API AWS DMS API を使用して AWS DMS イベント通知にサブスクライブするには CreateEventSubscription を呼び出します 265

272 プロセスの概要 AWS Database Migration Service と AWS Snowball を使用した大規模 データストアの移行 大規模なデータ移行には数テラバイトの情報が含まれることがあり ネットワークのパフォーマンスお よび移行するデータ量によっては 低速になる場合があります AWS DMS は AWS Snowball デバイス にデータをロードし そのデータを AWS に転送してから ターゲットの AWS データストアにデータを ロードします AWS DMS および AWS スキーマ変換ツール (AWS SCT) を使用して 2 段階でデータを移行します ま ず AWS SCT を使用してデータをローカルに処理し そのデータを AWS Snowball Edge アプライアンス に移動します 次に AWS Snowball は自動的にデータを Amazon S3 バケットにロードします 次に データが Amazon S3 で利用可能になると AWS DMS はファイルを受け取り データをターゲットデー タストアに移行します 変更データキャプチャ (CDC) を使用している場合 これらの更新は Amazon S3 バケットに書き込まれ ターゲットデータストアは継続的に更新されます AWS Snowball は AWS が所有するアプライアンスを使用して ネットワークよりも速い速度でクラウ ドにデータを転送するために使用できる AWS のサービスです AWS Snowball Edge デバイスは最大 100 TB のデータを保持できます Snowball では 256 ビットの暗号化 およびデータのセキュリティと完全 な保管継続性を確保するための業界標準であるトラステッドプラットフォームモジュール (TPM) を使用し ています Amazon S3 はストレージおよび取得サービスです Amazon S3 にオブジェクトを保管するには バケッ トに保管したいファイルをアップロードします ファイルをアップロードする際に オブジェクトだけで なく いずれのメタデータにも権限を設定することができます AWS DMS では 以下のシナリオのステージングがサポートされます オンプレミスデータウェアハウスから Amazon Redshift への移行 この方法では AWS スキーマ変換 ツールのクライアント側のソフトウェアをインストールします このツールはウェアハウス (エクスト ラクタ) から情報を読み取り S3 または Snowball にデータを移動します 次に AWS クラウドで 情 報が S3 または Snowball から読み取られ Amazon Redshift に挿入されます オンプレミスのリレーショナルデータベースから Amazon RDS データベースへの移行 この方法で も AWS スキーマ変換ツールのクライアント側のソフトウェアをインストールします このツール は AWS でサポートされているローカルデータベースから情報を読み取ります 次に S3 または Snowball にデータを移動します データが AWS クラウドに移動されると AWS DMS は Amazon EC2 または Amazon RDS のサポートされているデータベースにそのデータを書き込みます プロセスの概要 AWS DMS と AWS Snowball を使用するプロセスにはいくつかのステップがあり AWS DMS および AWS Snowball だけでなく AWS スキーマ変換ツール (AWS SCT) も使用されます この概要に続くセク ションでは これらの各タスクについて 詳しいガイドを示します Note AWS Snowball デバイスを使用する前に 移行をテストすることをお勧めします そのために は 単一のテーブルなどのデータを AWS Snowball デバイスではなく Amazon S3 バケットに送 信するタスクをセットアップできます 266

273 プロセスの概要 移行タスクには AWS SCT が AWS Snowball Edge デバイスにデータを移行するローカルタスクが関連し ます これは AWS Snowball Edge デバイスから S3 バケットにデータがコピーされる中間アクションで す 次に プロセスでは AWS DMS が Amazon S3 バケットから AWS のターゲットデータストアにデー タをロードするリモートタスクが実行されます AWS Snowball を使用してローカルデータストアから AWS データストアにデータを移行するには 次の ステップが発生する必要があります 1. AWS Snowball コンソールを使用して AWS Snowball ジョブを作成します 詳細については AWS Snowball のドキュメントの インポートジョブの作成 を参照してください 2. ローカルマシンで AWS SCT アプリケーションをダウンロードしてインストールします マシンは ネットワークアクセスが可能で 移行に使用する AWS アカウントにアクセスできる必要がありま す AWS SCT をインストールできるオペレーティングシステムの詳細については AWS スキーマ変 換ツールのインストールと更新 を参照してください 3. AWS SCT DMS エージェント (DMS エージェント) を ローカルの専用 Linux マシンにインストールし ます AWS SCT アプリケーションをインストールするのと同じマシンに DMS エージェントをインス トールしないことをお勧めします 4. DMS エージェントをインストールしたローカルの専用 Linux マシンを使用して AWS Snowball Edge デバイスをロック解除します 5. AWS SCT で新しいプロジェクトを作成します 6. DMS エージェントを使用するように AWS SCT を設定します 7. AWS SCT を使用して DMS エージェントを登録します 8. ソースデータベース用のデータベースドライバを DMS エージェントをインストールした専用マシン にインストールします 9. Amazon S3 バケットが使用するアクセス許可を作成および設定します 10.AWS SCT で [AWS Service Profile] を編集します 11.SCT で [Local & DMS Task] を作成します 12.SCT で [Local & DMS Task] を実行してモニタリングします 13.AWS SCT タスクを実行し SCT で進捗状況をモニタリングします 267

274 AWS DMS と AWS Snowball を 使用したデータ移行の詳しい手順 AWS DMS と AWS Snowball を使用したデータ移 行の詳しい手順 以下のセクションでは 移行ステップに関する詳細情報を提供します ステップ 1: AWS Snowball ジョブを作成する AWS Snowball のドキュメントの AWS Snowball Edge の使用開始: 最初のジョブ セクションに記載さ れているステップに従って AWS Snowball ジョブを作成します ステップ 2: AWS スキーマ変換ツール (AWS SCT) を ダウンロードしてインストールする AWS SCT ドキュメントの AWS スキーマ変換ツールのインストールと更新 の手順を使用して AWS ス キーマ変換ツールをダウンロードおよびインストールします AWS にアクセスできるローカルマシンに AWS SCT をインストールします このマシンは DMS エージェントをインストールする計画のものとは 別のマシンである必要があります ステップ 3: AWS SCT DMS エージェントをインス トールおよび設定する このステップでは AWS にアクセスできる専用のマシン および AWS SCT がインストールされたマシ ンに DMS エージェントをインストールします DMS エージェントは次の Linux プラットフォームにインストールできます Red Hat Enterprise Linux バージョン (64 ビット) SUSE Linux バージョン 11.1 (64 ビット) DMS エージェントをインストールするには 1. aws-schema-conversion-tool-dms-agent r2.x86_64.rpm という RPM ファイル を AWS SCT のインストールディレクトリから専用の Linux マシンにコピーします 2. 以下のコマンドをルートとして実行して DMS エージェントをインストールします DMS エージェ ントを SUSE Linux でインストールまたはアップグレードする場合は コマンドに --nodeps パラ メータを追加する必要があります sudo rpm -i aws-schema-conversion-tool-dms-agent r2.x86_64.rpm デフォルトのインストール場所は /opt/amazon/aws-schema-conversion-tool-dms-agent です デフォ ルト以外のディレクトリで DMS エージェントをインストールするには --prefix <path to new product dir> を使用します 3. Amazon RDS Migration Server が実行されていることを確認するには 以下のコマンドを実行しま す ps -ef grep repctl このコマンドの出力には 次の 2 つのプロセスが実行中であることが表示されます 268

275 ステップ 4: AWS Snowball Edge デバイスをロック解除する DMS エージェントを設定するには パスワードとポート番号を指定する必要があります AWS SCT でパ スワードを使用するため すぐに使用できるように準備しておいてください ポートは DMS エージェン トが AWS SCT 接続でリッスンするポートです 接続を許可するようにファイアウォールを設定しなけれ ばならない場合があります 次のスクリプトを実行して DMS エージェントを設定します sudo /opt/amazon/aws-schema-conversion-tool-dms-agent/bin/configure.sh ステップ 4: AWS Snowball Edge デバイスをロック解 除する DMS エージェントをインストールしたマシンから Snowball Edge デバイスをロック解除して認証情報を 提供するコマンドを実行します このようにして DMS エージェントの呼び出しが AWS Snowball Edge デバイスに接続できることを確認できます AWS Snowball Edge デバイスのロック解除の詳細について は Snowball Edge のロック解除 を参照してください たとえば 次のコマンドでは デバイスで使用されている Amazon S3 バケットが一覧表示されます aws s3 ls s3://<bucket-name> --profile <Snowball Edge profile> --endpoint IP>: recursive ステップ 5: 新しい AWS SCT プロジェクトを作成す る 次に 新しい AWS SCT プロジェクトを作成します AWS SCT で新しいプロジェクトを作成するには 1. AWS SCT を起動し [File] の [New Project] を選択します [New Project] ダイアログボックスが表示 されます 2. 以下のプロジェクト情報を追加します パラメーター 操作 プロジェクト名 コンピューターにローカルに保存されているプロジェクト の名前を入力します 場所 ローカルプロジェクトファイルの場所を入力します OLTP [Transactional Database (OLTP)] を選択します Source DB Engine ソースデータストアを選択します Target DB Engine ターゲットデータストアを選択します 3. [OK] を選択して AWS SCT プロジェクトを作成します 4. (オプション) 接続をテストします 269

276 ステップ 6: AWS SCT プロファイルを設定する ステップ 6: DMS エージェントと連携するように AWS SCT プロファイルを設定する DMS エージェントを使用するには AWS SCT プロファイルを更新する必要があります DMS エージェントと連携するように AWS SCT プロファイルを更新するには 1. AWS SCT を起動します 2. [Settings] を選択し [Global Settings] を選択します [AWS Service Profiles] を選択します 3. [Add New AWS Service Profile] を選択します 4. 以下のプロファイル情報を追加します パラメーター 操作 Profile Name プロファイルの名前を入力します AWS アクセスキー AWS アカウントの AWS アクセスキーと 移行に使用す る予定の AWS リージョンを入力します AWS シークレットキー AWS アカウントの AWS シークレットキーと 移行に使 用する予定の AWS リージョンを入力します リージョン 使用しているアカウントの AWS リージョンを選択しま す DMS レプリケーションインスタンス S3 バケット 270

277 ステップ 7: DMS エージェントを登録する パラメーター 操作 およびターゲットデータストアは この AWS リージョン にある必要があります S3 バケットフォルダ 5. AWS Snowball ジョブを作成したときに割り当てられた S3 バケットの名前を入力します 情報を入力したら [Test Connection] を選択して AWS SCT が Amazon S3 バケットに接続できる ことを確認します ポップアップウィンドウの [OLTP Local & DMS Data Migration] セクションには ステータスが [Pass] であるすべてのエントリが表示されます テストが失敗した場合 使用しているアカウントに Amazon S3 バケットにアクセスするための正しい権限がないことが原因である可能性があります 6. テストに合格した場合は [OK] を選択してから もう一度 [OK] を選択してウィンドウとダイアログ ボックスを閉じます ステップ 7: AWS SCT で DMS エージェントを登録す る 次に AWS SCT で DMS エージェントを登録します 次に SCT はエージェントに接続を試み ステー タスが表示されます エージェントが利用可能になると ステータスがアクティブになります DMS エージェントを登録するには 1. AWS SCT を起動し [View] [Database Migration View (DMS)] の順に選択します 2. [Agent] タブを選択し [Register] を選択します [New Agent Registration] ダイアログボックスが表示 されます 3. [New Agent Registration] ダイアログボックスに情報を入力します 271

278 ステップ 8: ソースデータベース ドライバーをインストールする 4. パラメーター 操作 説明 エージェントの名前 (DMS Agent) を入力します ホスト名 DMS エージェントをインストールしたマシンの IP アドレ スを入力します ポート DMS エージェントに設定したときに使用したポート番号 を入力します パスワード DMS エージェントに設定したときに使用したパスワード を入力します [Register] を選択して AWS SCT プロジェクトにエージェントを登録します ステップ 8: Linux コンピュータで DMS エージェント 用のソースデータベースドライバーをインストールす る 移行を成功させるために DMS エージェントはソースデータベースに接続できる必要があります これを 可能にするには ソースデータベース用のデータベースドライバーをインストールします 必要なドライ バーは データベースによって異なります データベースドライバーのインストール後に DMS エージェントを再起動するには 作業ディレクトリを <product_dir>/bin に変更し 以下に示すステップを各ソースデータベースに対して使用します cd <product_dir>/bin./arep.ctl stop./arep.ctl start Oracle にインストールするには Oracle Instant Client for Linux (x86-64) バージョン 以降をインストールします さらに まだシステムに含まれていない場合は $ORACLE_HOME\lib ディレクトリにシンボリック リンクを作成する必要があります このリンクは libclntsh.so という名前で このファイルの特定の バージョンを指す必要があります たとえば Oracle 12c クライアントの場合は次のようになりま す lrwxrwxrwx 1 oracle oracle 63 Oct 2 14:16 libclntsh.so -> /u01/app/oracle/home/lib/libclntsh.so.12.1 さらに LD_LIBRARY_PATH 環境変数には Oracle lib ディレクトリを付加し インストールの lib フォルダの site_arep_login.sh スクリプトに追加する必要があります このスクリプトが存在しない場 合は追加します vi cat <product dir>/bin/site_arep_login.sh export ORACLE_HOME=/usr/lib/oracle/12.2/client64; export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib 272

279 ステップ 8: ソースデータベース ドライバーをインストールする Microsoft SQL Server にインストールするには Microsoft ODBC ドライバーのインストール site_arep_login.sh を次のコードで更新します export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/microsoft/msodbcsql/lib64/ Simba ODBC ドライバー Microsoft ODBC ドライバーのインストール simba.sqlserverodbc.ini ファイルを次のように編集します DriverManagerEncoding=UTF-16 ODBCInstLib=libodbcinst.so SAP Sybase にインストールするには SAP Sybase ASE ODBC 64 ビットクライアントがインストールされている必要があります インストールディレクトリが /opt/sap の場合は site_arep_login.sh を更新します export SYBASE_HOME=/opt/sap export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SYBASE_HOME/ DataAccess64/ODBC/lib:$SYBASE_HOME/DataAccess/ODBC/ lib:$sybase_home/ocs-16_0/lib:$sybase_home/ocs-16_0/ lib3p64:$sybase_home/ocs-16_0/lib3p /etc/odbcinst.ini にはこれらのエントリが含まれている必要があります [Sybase] Driver=/opt/sap/DataAccess64/ODBC/lib/libsybdrvodb.so Description=Sybase ODBC driver MySQL にインストールするには MySQL Connector/ODBC for Linux バージョン 以降をインストールします 次の例のように /etc/odbcinst.ini ファイルに MySQL 用のエントリが含まれていることを確認しま す [MySQL ODBC Unicode Driver] Driver = /usr/lib64/libmyodbc5w.so UsageCount = 1 PostgreSQL にインストールするには postgresql pgdg.<os Version>.x86_64.rpm をインストールします これは psql 実行可能 ファイルを含むパッケージです 273

280 ステップ 9: Amazon S3 バケットにア クセスするように AWS SCT を設定する たとえば Red Hat 7 に必要なのは postgresql pgdg.rhel7.x86_64.rpm パッケージです Linux 用の ODBC ドライバー postgresql94-odbc pgdg.<os version>.x86_64 以降をイ ンストールします <OS version> は エージェントマシーンの OS です たとえば Red Hat 7 に必要なのは postgresql94-odbc pgdg.rhel7.x86_64 クライアン トです 次の例のように /etc/odbcinst.ini ファイルに PostgreSQL 用のエントリが含まれていることを確認し ます [PostgreSQL] Description = PostgreSQL ODBC driver Driver = /usr/pgsql-9.4/lib/psqlodbc.so Setup = /usr/pgsql-9.4/lib/psqlodbcw.so Debug = 0 CommLog = 1 UsageCount = 2 ステップ 9: Amazon S3 バケットにアクセスするよう に AWS SCT を設定する Amazon S3 バケットの設定の詳細については Amazon S3 のドキュメントの Working with Amazon S3 Buckets を参照してください Note 作成された Amazon S3 バケットを移行で使用するには S3 バケットと同じ AWS リージョン で作成された AWS DMS レプリケーションインスタンスが必要です まだ作成していない場合 は ステップ 2: レプリケーションのインスタンスを作成する (p. 18) で説明しているよう に AWS DMS マネジメントコンソールを使用して作成します ステップ 10: ローカルの DMS タスクを作成する 次に エンドツーエンドの移行タスクであるタスクを作成します このタスクには 2 つのサブタスクが 含まれます 1 つのサブタスクで ソースデータベースから AWS Snowball アプライアンスにデータを移 行します もう 1 つのサブタスクはアプライアンスが Amazon S3 バケットにロードするデータを受け取 り ターゲットデータベースに移行します エンドツーエンドの移行タスクを作成するには 1. AWS SCT を起動し [View] [Database Migration View (Local & DMS)] の順に選択します 274

281 ステップ 10: ローカルの DMS タスクを作成する 2. ソースデータベースのスキーマを表示する左のパネルで 移行するスキーマオブジェクトを選択しま す オブジェクトのコンテキスト (右クリック) メニューを開き [Create Local & DMS Task] を選択し ます 3. タスク情報を追加します パラメータ 操作 タスク名 タスクの名前を入力します エージェント [DMS Agent] を選択します レプリケーションインスタンス 使用する AWS DMS レプリケーションインスタンスを選 択します バージョン のレプリケーションのインス タンスのみ指定できます 移行タイプ 目的の移行のタイプを選択します [Migrate existing data] を選択して 選択したスキーマの内 容を移行します このプロセスは AWS DMS では全ロー ドと呼ばれます [Migrate existing data and replicate ongoing changes] を選 択し 選択されたスキーマのコンテンツを移行して デー タベースへの継続的な変更をすべてキャプチャします こ のプロセスは AWS DMS では全ロードおよび CDC と呼ば れます ターゲットテーブル作成モード 使用する準備モードを選択します 切り捨て - テーブルは テーブルのメタデータに影響を与 えないで切り捨てられます ターゲット上のテーブルを削除 - テーブルは削除され 代 わりに新しいテーブルが作成されます 何もしない - ターゲットテーブルのデータとメタデータは 変更されません IAM ロール Amazon S3 バケットおよびターゲットデータベースにア クセスする権限がある あらかじめ定義された IAM ロー ルを選択します Amazon S3 バケットにアクセスするた めに必要なアクセス権限の詳細については AWS DMS 275

282 ステップ 11: ローカルの DMS タ スクを実行およびモニタリングする パラメータ 操作 のソースとして S3 を使用する場合の前提条件 (p. 141) を参照してください 4. ログ記録 [Enable] を選択して AWS CloudWatch で移行のログ を作成します このサービスについては料金が発生し ます AWS CloudWatch の詳細については Amazon CloudWatch の仕組み を参照してください 説明 タスクの説明を入力します Snowball の使用 Snowball を使用するには このチェックボックスをオン にします ジョブ名 作成した AWS Snowball のジョブ名を選択します Snowball IP AWS Snowball アプライアンスの IP アドレスを入力しま す ポート AWS Snowball アプライアンスのポートの値を入力しま す Local AWS S3 Access key 移行用のアカウントの AWS アクセスキーを入力します ローカル AWS S3 シークレットキー 移行用のアカウントの AWS シークレットキーを入力しま す [Create] を選択して タスクを作成します ステップ 11: SCT でローカルの DMS タスクを実行お よびモニタリングする エンドポイントへのすべての接続に成功したら ローカルの DMS タスクを開始できます つまり DMS エージェントからソースデータベース ステージング Amazon S3 バケット AWS Snowball デバイスへ の接続を含む ローカルタスクへのすべての接続や ステージング Amazon S3 バケットから AWS のター ゲットデータベースへの接続を含む DMS タスクへの接続です [Show Log] を選択して DMS エージェントログをモニタリングできます ログ詳細には エージェント サーバー (Agent Log) ログおよびローカル実行タスク (Task Log) ログが含まれます エンドポイント接 続はサーバーによって行われる (ローカルタスクは実行されず タスクログがない) ため 接続の問題は [Agent Log] タブで一覧表示されます 276

283 ステップ 11: AWS Snowball アプライアンスを管理する ステップ 12: AWS Snowball アプライアンスを管理す る Snowball アプライアンスが完全にロードされると AWS SCT はタスクのステータスを更新し 50% 完了 したことを示します タスクのもう一方の部分では AWS DMS により Amazon S3 からターゲットデー タストアにデータが移動されます これを行うには AWS Snowball アプライアンスを切断し AWS に返送します AWS Snowball アプライ アンスの AWS への返送の詳細については AWS Snowball のドキュメントの AWS Snowball Edge の使 用開始: 最初のジョブ で説明されているステップに従ってください AWS Snowball コンソールまたは AWS SCT (DMS タスクの詳細を表示) を使用してアプライアンスのステータスを確認して AWS DMS が Amazon S3 バケットにいつデータのロードを開始するか調べることができます AWS Snowball アプライアンスが AWS に到着し S3 バケットにデータをアンロードした後で リモー ト (DMS) タスクの実行が開始されます タスク用に選択した移行タイプが [Migrate existing data] である 場合 Amazon S3 からターゲットデータストアにデータが転送されると DMS タスクのステータスは 100% 完了と表示されます 継続的なレプリケーションを含めるようにタスクモードを設定した場合 全 ロードが完了すると AWS DMS が継続的な変更を適用している間 タスクのステータスは タスクは引 き続き実行中であることを示します AWS Snowball と AWS Database Migration Service (AWS DMS) を使用する場合の制限事項 AWS Snowball を使用する場合に 注意が必要ないくつかの制限があります LOB モードでは LOB ファイルサイズが 32 K に制限されます ローカルデータベースから AWS Snowball Edge デバイスへのデータの移行中 または AWS DMS が Amazon S3 からターゲットデータベースにデータをロードするときにエラーが発生した場合 エラーが 復旧可能な場合はタスクが再起動されます AWS DMS がエラーから復旧できない場合 移行は中止さ れます すべての AWS SCT タスクでは AWS DMS で 2 つのエンドポイント接続が作成されます 複数のタス クを作成する場合 作成できるエンドポイントの数のリソース制限に達する可能性があります 277