aws database migration service - ステップバイス …aws database migration service ス...

AWS Database Migration Serviceステップバイステップ移行ガイド

API バージョン 2016-01-01

AWS Database Migration Service ステップバイステップ移行ガイド

AWS Database Migration Service: ステップバイステップ移行ガイドCopyright © 2020 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 discreditsAmazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may notbe affiliated with, connected to, or sponsored by Amazon.


Table of ContentsAWS Database Migration Service のステップバイステップチュートリアル .................................................. 1アマゾンウェブサービス (AWS) にデータベースを移行する .................................................................... 2

AWS 移行ツール ........................................................................................................................ 2このガイドのチュートリアル ........................................................................................................ 2

オンプレミス Oracle データベースの Amazon Aurora MySQL への移行 ...................................................... 4コスト ....................................................................................................................................... 4移行の概略 ................................................................................................................................ 5

ステップ 1: Oracle ソースデータベースの準備 ........................................................................ 5ステップ 2: Aurora MySQL ターゲットデータベースの起動と準備 ............................................. 6ステップ 3: レプリケーションインスタンスの起動 .................................................................. 6ステップ 4: ソースエンドポイントの作成 ............................................................................... 6ステップ 5: ターゲットエンドポイントの作成 ......................................................................... 7ステップ 6: 移行タスクの作成と実行 ..................................................................................... 7

移行のステップバイステップガイド ............................................................................................... 8ステップ 1: Oracle ソースデータベースの設定 ........................................................................ 8ステップ 2: Aurora ターゲットデータベースの設定 ................................................................ 11ステップ 3: レプリケーションインスタンスの作成 ................................................................. 11ステップ 4: Oracle ソースエンドポイントの作成 ................................................................... 13ステップ 5: Aurora MySQL ターゲットエンドポイントの作成 ................................................. 16ステップ 6: 移行タスクの作成 ............................................................................................ 18ステップ 7: 移行タスクのモニタリング ................................................................................ 23トラブルシューティング .................................................................................................... 23

移行のサンプルデータベースを使用する ....................................................................................... 24Amazon RDS Oracle データベースの Amazon Aurora MySQL への移行 .................................................... 25

コスト ..................................................................................................................................... 25前提条件 .................................................................................................................................. 27移行アーキテクチャ .................................................................................................................. 27ステップバイステップ移行 ......................................................................................................... 29

ステップ 1: CloudFormation テンプレートを使用して VPC で RDS インスタンスを起動する ........ 29ステップ 2: SQL ツールと AWS Schema Conversion Tool をローカルコンピュータにインストールする ............................................................................................................................. 34ステップ 3: Oracle DB インスタンスへの接続をテストしてサンプルスキーマを作成する ............. 37ステップ 4: Aurora MySQL DB インスタンスへの接続をテストする .......................................... 40ステップ 5: AWS スキーマ変換ツール (AWS SCT) を使用して、Oracle スキーマを AuroraMySQL に変換する ........................................................................................................... 42ステップ 6: スキーマ変換を検証する ................................................................................... 49ステップ 7: AWS DMS レプリケーションのインスタンスを作成する ....................................... 51ステップ 8: AWS DMS のソースとターゲットのエンドポイントを作成する ............................... 52ステップ 9: AWS DMS 移行タスクの作成と実行 ................................................................... 54ステップ 10: データ移行が正常に完了したことを検証する ...................................................... 57ステップ 11: チュートリアルのリソースを削除する ............................................................... 59

次のステップ ............................................................................................................................ 60SQL Server データベースの Amazon Aurora MySQL への移行 ................................................................ 61

前提条件 .................................................................................................................................. 61ステップバイステップ移行 ......................................................................................................... 62

ステップ 1: SQL ドライバーと AWS スキーマ変換ツールをローカルコンピュータにインストールする ............................................................................................................................. 63ステップ 2: Microsoft SQL Server ソースデータベースを設定する ............................................ 63ステップ 3: Aurora MySQL ターゲットデータベースの設定 ..................................................... 65ステップ 4: AWS SCT を使用して SQL Server スキーマを Aurora MySQL に変換する ................. 65ステップ 5: AWS DMS レプリケーションインスタンスを作成する .......................................... 73ステップ 6: AWS DMS のソースとターゲットのエンドポイントを作成する ............................... 75ステップ 7: AWS DMS 移行タスクの作成と実行 ................................................................... 79ステップ 8: Aurora MySQL へのカットオーバー .................................................................... 82

API バージョン 2016-01-01iii


トラブルシューティング ............................................................................................................ 83Oracle データベースの PostgreSQL への移行 ....................................................................................... 84

前提条件 .................................................................................................................................. 84ステップバイステップ移行 ......................................................................................................... 85

ステップ 1: SQL ドライバーと AWS スキーマ変換ツールをローカルコンピュータにインストールする ............................................................................................................................. 85ステップ 2: Oracle ソースデータベースの設定 ...................................................................... 86ステップ 3: PostgreSQL ターゲットデータベースを設定する .................................................. 89ステップ 4: AWS スキーマ変換ツール (AWS SCT) を使用して、Oracle スキーマを PostgreSQLに変換する ....................................................................................................................... 89ステップ 5: AWS DMS レプリケーションインスタンスを作成する .......................................... 97ステップ 6: AWS DMS のソースとターゲットのエンドポイントを作成する ............................... 99ステップ 7: AWS DMS 移行タスクの作成と実行 .................................................................. 102ステップ 8: PostgreSQL にカットオーバーする ................................................................... 105

移行のロールバック ................................................................................................................. 106トラブルシューティング ........................................................................................................... 106

Amazon RDS for Oracle Database の Amazon Redshift への移行 ........................................................... 108前提条件 ................................................................................................................................ 108移行アーキテクチャ ................................................................................................................. 109ステップバイステップ移行 ........................................................................................................ 110

ステップ 1: CloudFormation テンプレートを使用して VPC で RDS インスタンスを起動する ...... 111ステップ 2: SQL ツールと AWS Schema Conversion Tool をローカルコンピュータにインストールする ........................................................................................................................... 115ステップ 3: Oracle DB インスタンスへの接続をテストしてサンプルスキーマを作成する ............ 118ステップ 4: Amazon Redshift データベースへの接続をテストする .......................................... 122ステップ 5: AWS SCT を使用して Oracle スキーマを Amazon Redshift に変換する ................... 124ステップ 6: スキーマ変換を検証する .................................................................................. 131ステップ 7: AWS DMS レプリケーションインスタンスを作成します。 .................................... 132ステップ 8: AWS DMS のソースとターゲットのエンドポイントを作成する ............................. 133ステップ 9: AWS DMS 移行タスクの作成と実行 .................................................................. 136ステップ 10: データ移行が正常に完了したことを検証する .................................................... 140ステップ 11: チュートリアルのリソースを削除する .............................................................. 142

次のステップ .......................................................................................................................... 143MySQL との互換性があるデータベースを AWS に移行する ................................................................... 144との互換性があるデータベースのへの移行MySQLAmazon Aurora MySQL .............................................. 145

Amazon S3 MySQLを使用した外部Amazon Aurora MySQLデータベースからへのデータの移行 .......... 145Prerequisites .................................................................................................................. 145ステップ 1: DB クラスターとして復元するためのファイルのバックアップ ............................... 148ステップ 2: Amazon S3 バケットにファイルをコピーする .................................................... 149ステップ 3: Amazon S3 バケットからの Aurora MySQL DB クラスターの復元 ......................... 149

mysqldump を使用した MySQL への移行Amazon Aurora MySQL ................................................... 156Amazon RDS MySQL DB インスタンスから DB クラスターにデータを移行するAmazon AuroraMySQL .................................................................................................................................. 156

RDS MySQL スナップショットのへの移行Aurora MySQL .................................................... 157MariaDBまたは Amazon RDSでのへのMySQLデータベースの移行Amazon Aurora MySQL ........................ 165

ソースデータベースMariaDBとしての設定 .................................................................................. 166ターゲットデータベースAurora MySQLとしてのセットアップ ........................................................ 168AWS DMSレプリケーションインスタンスのセットアップ ............................................................. 170エンドポイントをテストする ..................................................................................................... 171移行タスクの作成 .................................................................................................................... 171移行の検証 ............................................................................................................................. 172カットオーバー ....................................................................................................................... 172

MongoDB から Amazon DocumentDB への移行 ................................................................................... 174Amazon EC2インスタンスを起動する ........................................................................................ 174MongoDBCommunity Edition のインストールと設定 ..................................................................... 175AWS DMSレプリケーションインスタンスを作成します。 ............................................................. 176ソースおよびターゲットエンドポイントの作成 ............................................................................ 177

API バージョン 2016-01-01iv


移行タスクを作成して実行する ................................................................................................. 179ドキュメント履歴 ............................................................................................................................ 181................................................................................................................................................. clxxxii

API バージョン 2016-01-01v


AWS Database Migration Service のステップバイステップチュートリアル

AWS Database Migration Service( AWS DMS ) を使用して、Oracle、 PostgreSQL 、Microsoft SQLServer、Amazon Redshift、Amazon Aurora、、 MariaDB など、幅広く使用されている商用およびオープンソースデータベースとの間でデータを移行MySQLできます。このサービスでは、Oracle から Oracle など、同種間の移行をサポートしているほか、Oracle MySQLやなど、異なるデータベースプラットフォーム間の異種の移行もサポートMySQLしています。MySQL と互換性がある Amazon Auroraソースまたはターゲットデータベースは、1 つの AWS サービス上に存在している必要があります。

このガイドでは、サンプルデータを AWS に移行するプロセスをステップごとに順を追って確認できます。

• アマゾンウェブサービス (AWS) にデータベースを移行する (p. 2)• オンプレミス Oracle データベースの Amazon Aurora MySQL への移行 (p. 4)• Amazon RDS Oracle データベースの Amazon Aurora MySQL への移行 (p. 25)• SQL Server データベースの Amazon Aurora MySQL への移行 (p. 61)• Oracle データベースの PostgreSQL への移行 (p. 84)• Amazon RDS for Oracle Database の Amazon Redshift への移行 (p. 108)• MySQL との互換性があるデータベースを AWS に移行する (p. 144)• との互換性があるデータベースのへの移行MySQLAmazon Aurora MySQL (p. 145)• MariaDBまたは Amazon RDSでのへのMySQLデータベースの移行Amazon Aurora MySQL (p. 165)• MongoDB から Amazon DocumentDB への移行 (p. 174)

DMS ユーザーガイドで追加のリソースを見つけることができます。

• AWS Database Migration Service と AWS Snowball Edge を使用した大規模データストアの移行

API バージョン 2016-01-011

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_LargeDBs.html


AWS 移行ツール

アマゾンウェブサービス (AWS) にデータベースを移行するAWS 移行ツール

AWS のいくつかのツールとサービスを使用して、外部データベースのデータを AWS に移行できます。データベースの移行タイプによっては、データベースエンジンのネイティブ移行ツールを使用できる場合もあります。

AWS Database Migration Service (AWS DMS) は、AWS にデータベースを効果的かつ安全に移行するのに役立ちます。移行中でもソースデータベースは完全に利用可能であり、このデータベースを利用するアプリケーションのダウンタイムは最小限に抑えられます。AWS DMS は、AWS の最も普及している商用のオープンソースデータベースに Oracle データを移行できます。

AWS DMS では、データ、テーブル、プライマリキーがターゲットデータベースに移行されます。他のすべてのデータベース要素は移行されません。たとえば、Oracle データベースを MySQL と互換性があるAmazon Aurora に移行する場合、AWS Schema Conversion Tool を AWS DMS で使用できます。

AWS スキーマ変換ツール (SCT) は、ソースデータベーススキーマと大部分のカスタムコード (ビュー、ストアドプロシージャ、関数など) をターゲットデータベースと互換性のある形式に自動的に変換し、異種データベースを簡単に移行できるようにします。自動的に変換できないコードは明確にマークされるため、手動で変換できます。このツールを使用して、Amazon RDS または EC2 のいずれかで、ソースOracle データベースを Amazon Aurora MySQL、MySQL、または PostgreSQL のターゲットデータベースに変換できます。

重要な点として、DMS と SCT は 2 つの異なるツールで、異なるニーズに対応するものであり、移行プロセスで両者が連携することはありません。このチュートリアルでは、DMS のベストプラクティスに基づく移行方法を説明します。

• AWS DMS では、必要最低限のアプローチに従って、データの効率的な移行に必要なオブジェクト (プライマリキーを持つテーブルなど) のみが作成されます。したがって、ここでは DMS を使用して、外部キーや制約が伴わないテーブルのデータをロードします(DMS 経由でロードを実行する前に、SCT を使用してテーブルスクリプトを生成してターゲットにテーブルを作成することもできます)。

• SCT は以下の目的で使用します。• スキーマ変換の問題、制限、アクションを確認する• 外部キーや制約を含むターゲットスキーマスクリプトを生成する• プロシージャやビューなどのコードをソースからターゲットに変換し、ターゲットに適用する

Oracle データベース移行のサイズとタイプに応じて、使用するツールは大きく異なります。たとえば、Oracle データベースから AWS の別のデータベースエンジンに移行する異種移行には AWS DMS が最適です。Oracle データベースから AWS の Oracle データベースに移行する同種移行には、ネイティブOracle ツールが最適です。

このガイドのチュートリアルオンプレミス Oracle データベースの Amazon Aurora MySQL への移行 (p. 4)

API バージョン 2016-01-012

AWS Database Migration Service ステップバイステップ移行ガイドこのガイドのチュートリアル

Amazon RDS Oracle データベースの Amazon Aurora MySQL への移行 (p. 25)

SQL Server データベースの Amazon Aurora MySQL への移行 (p. 61)

Oracle データベースの PostgreSQL への移行 (p. 84)

Amazon RDS for Oracle Database の Amazon Redshift への移行 (p. 108)

MySQL との互換性があるデータベースを AWS に移行する (p. 144)

との互換性があるデータベースのへの移行MySQLAmazon Aurora MySQL (p. 145)

API バージョン 2016-01-013


コスト

オンプレミス Oracle データベースのAmazon Aurora MySQL への移行

AWS Database Migration Service (AWS DMS) と AWS Schema Conversion Tool (AWS SCT) を使用して、オンプレミス Oracle データベース (ソースエンドポイント) を MySQL と互換性がある AmazonAurora (ターゲットエンドポイント) に移行するプロセスについて、概略と詳細なステップバイステップガイドの両方を以下に示します。

AWS DMS は、Oracle ソースから Aurora MySQL ターゲットにデータを移行します。また、AWS DMSは、ソースデータベースでのデータ操作言語 (DML) とサポートされるデータ定義言語 (DDL) の変更をキャプチャしてターゲットデータベースに適用します。このようにして、AWS DMS はソースデータベースとターゲットデータベース間の同期を常に維持します。データ移行を容易にするために、DMS では、必要に応じてターゲットデータベースでテーブルとプライマリキーインデックスを作成します。

ただし、AWS DMS は、セカンダリインデックス、シーケンス、デフォルト値、ストアドプロシージャ、トリガー、シノニム、ビューなど、データ移行に特に関係ないスキーマオブジェクトは移行しません。これらのオブジェクトを Aurora MySQL ターゲットに移行するには、AWS Schema Conversion Tool を使用します。

Amazon サンプルデータベースを使用して手順どおりに移行を進めることを強くお勧めします。サンプルデータベースの使用方法のチュートリアルとサンプルデータベースのコピーの取得方法については、「移行のサンプルデータベースを使用する (p. 24)」を参照してください。

AWS DMS を以前に使用した経験がある場合や、マウスをクリックして読みながら移行を進める場合は、概略を参照してください。詳細を確認しながら移行を進めたり、質問の回答を探したりする場合は、ステップバイステップガイドを参照してください。

トピック: オンプレミス Oracle から Aurora MySQL または Amazon RDS の MySQL への移行

時間:

料金:

ソースデータベース: Oracle

ターゲットデータベース: Amazon Aurora MySQL/MySQL

制限:

Oracle エディション: Enterprise、Standard、Express および Personal

Oracle バージョン: 10g (10.2 以降)、11g、12c、(Amazon Relational Database Service (AmazonRDS)、11g 以上が必要)

MySQL または関連データベースバージョン: 5.5、5.6、5.7、MariaDB、Amazon Aurora MySQL

コストAWS DMS はまだ見積りツールに組み込まれていないため、料金の見積りについては以下の表を参照してください。

API バージョン 2016-01-014


移行の概略

移行プロセスを完了するには、PC のセットアップに加えて AWS のいくつかのコンポーネントを作成する必要があります。AWS のコンポーネントは以下のとおりです。

AWS サービスタイプ説明

Amazon Aurora MySQL DB インスタンス db.r3.large シングル AZ、10GB のストレージ、100 万 I/O

AWS DMS レプリケーションインスタンス T2.large 50 GB のストレージ (レプリケーションログの保持用を含む)

AWS DMS データ転送無料 (サンプルデータベースのデータ転送量に基づく)

データ発信毎月 1 GB まで無料

移行の概略AWS DMS を使用して Oracle から Aurora MySQL にデータを移行するには、以下のステップを実行します。AWS DMS を以前に使用した経験がある場合や、マウスをクリックして読みながら移行を進める場合は、以下の概略を参照してください。移行の詳細を確認したり、質問の回答を探したりする場合は、ステップバイステップガイドを参照してください。

ステップ 1: Oracle ソースデータベースの準備AWS DMS を使用して Oracle ソースデータベースのデータを移行するには、ある程度の準備が必要です。また、ベストプラクティスとして、いくつかの追加のステップを実行することもお勧めします。

• AWS DMS アカウント - データ移行専用のアカウントを別個に作成することをお勧めします。このアカウントには、データ移行のための最低の権限セットが必要です。これらの権限別の詳細については、以下で説明します。プロダクションデータベース以外のデータベースで AWS DMS をテストするだけの場合は、任意の DBA アカウントを使用できます。

• サプリメンタルロギング – 変更をキャプチャするには、サプリメンタルロギングを有効にして DMS を使用する必要があります。データベースレベルでサプリメンタルロギングを有効にするには、次のコマンドを実行します。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA

さらに、AWS DMS では、移行するテーブルごとに少なくともキーレベルのサプリメンタルロギングを設定する必要があります。ソース接続に以下の追加の接続パラメータを含めると、このサプリメンタルロギングパラメータが AWS DMS で自動的に追加されます。

addSupplementalLogging=Y

• ソースデータベース - データを移行するには、AWS DMS レプリケーションサーバーからソースデータベースにアクセスする必要があります。ファイアウォールルールで AWS DMS レプリケーションサーバーからのアクセスが許可されていることを確認してください。

API バージョン 2016-01-015


ステップ 2: Aurora MySQL ターゲットデータベースの起動と準備

ステップ 2: Aurora MySQL ターゲットデータベースの起動と準備以下に示しているのは、Aurora MySQL インスタンスを起動するときの考慮事項です。

• 最良の結果を得るには、Aurora MySQL インスタンスとレプリケーションインスタンスを同じ VPC に配置すること、さらに可能であれば、同じアベイラビリティーゾーンに配置することをお勧めします。

• データ移行用のアカウントを別個に作成し、移行に必要な最低限の権限を付与することをお勧めします。この AWS DMS アカウントには、データ移行先のすべてのデータベースに対する以下の権限が必要です。

ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT

さらに、AWS DMS は awsdms_control データベースへのフルアクセスが許可されている必要があります。このデータベースには、AWS DMS で必要な移行専用の情報が保持されています。アクセス権を付与するには、次のコマンドを実行します。

ALL PRIVILEGES ON awsdms_control.* TO 'dms_user'

ステップ 3: レプリケーションインスタンスの起動AWS DMS サービスは、レプリケーションインスタンスを介してソースデータベースとターゲットデータベースに接続します。レプリケーションインスタンスを起動するときは、以下の点に留意してください。

• 最良の結果を得るには、レプリケーションインスタンスをターゲットデータベース (この例では AuroraMySQL) と同じ VPC および同じアベイラビリティーゾーンに配置することをお勧めします。

• ソースデータベースまたはターゲットデータベースのいずれかが、レプリケーションサーバーを起動する VPC の外部にある場合、レプリケーションサーバーはパブリックにアクセス可能であることが必要です。

• AWS DMS は大量のメモリと CPU を消費します。ただし、必要に応じて簡単にスケールアップできます。複数のタスクを 1 つのレプリケーションサーバーで実行することが予想される場合

• 通常、ほとんどの移行には、デフォルトのストレージで十分です。

ステップ 4: ソースエンドポイントの作成AWS DMS から Oracle ソースデータベースにアクセスするには、ソースエンドポイントを作成する必要があります。ソースエンドポイントは、AWS DMS がレプリケーションサーバーを介してソースデータベースに接続するために必要なすべての情報を定義します。ソースエンドポイントの要件は以下のとおりです。

• ソースエンドポイントは、レプリケーションサーバーからアクセスできる必要があります。これを許可するには、必要に応じてファイアウォールルールを変更してレプリケーションサーバーをホワイトリストに含めます。レプリケーションサーバーの IP アドレスは AWS DMS マネジメントコンソールで確認できます。

• AWS DMS で変更をキャプチャするには、Oracle でサプリメンタルロギングを有効にする必要があります。AWS DMS で自動的にサプリメンタルロギングを有効にする場合は、Oracle ソースエンドポイントの追加の接続属性に以下を追加します。


API バージョン 2016-01-016


ステップ 5: ターゲットエンドポイントの作成

ステップ 5: ターゲットエンドポイントの作成AWS DMS から Aurora MySQL ターゲットデータベースにアクセスするには、ターゲットエンドポイントを作成する必要があります。ターゲットエンドポイントは、DMS から Aurora MySQL データベースに接続するために必要なすべての情報を定義します。

• ターゲットエンドポイントは、レプリケーションサーバーからアクセスできる必要があります。ターゲットエンドポイントをアクセス可能にするために、必要に応じてセキュリティグループを変更します。

• ターゲットに作成済みのデータベースがある場合は、全ロード時に外部キーチェックを無効にすることをお勧めします。これを行うには、追加の接続属性に以下を追加します。

initstmt=SET FOREIGN_KEY_CHECKS=0

ステップ 6: 移行タスクの作成と実行移行タスクは、データの移行先と移行方法を AWS DMS に指示します。移行タスクを作成するときは、以下のように移行パラメータを設定することを検討してください。

エンドポイントとレプリケーションサーバー — 上で作成したエンドポイントとレプリケーションサーバーを選択します。

[Migration type (移行タイプ)] — ほとんどの場合は、[migrate existing data and replication ongoing changes(既存データの移行と進行中の変更のレプリケーション)] を選択します。このオプションを使用すると、AWS DMS はソースデータの変更をキャプチャしながらソースデータをロードします。データが完全にロードされると、AWS DMS はすべての未処理の変更を適用し、タスクが停止されるまで継続してソースデータベースとターゲットデータベースを同期させます。

[Target table preparation mode (ターゲットテーブル作成モード)] — AWS DMS でテーブルを作成している場合は、[drop tables on target (ターゲット上のテーブルを削除)] を選択します。他の方法 (AWS スキーマ変換ツールなど) を使用してターゲットテーブルを作成している場合は、[truncate] を選択します。

[LOB parameters (LOB パラメータ)] — AWS DMS のみを試している場合は、[include LOB columns inreplication (レプリケーションに LOB 列を含める)]、[Limited LOB mode (制限付き LOB モード)] の順に選択し、[max LOB size (最大 LOB サイズ)] を 16 (16k) に設定します。 LOB の詳細については、ステップバイステップガイドの説明をご覧ください。

[ログの有効化] — 移行問題のデバッグに役立てるために、常にログ記録を有効にしてください。

[Table mappings (テーブルのマッピング)] — Oracle から Aurora MySQL に移行するときは、スキーマ、テーブル、および列の名前を小文字に変換することをお勧めします。これを行うには、カスタムテーブルマッピングを作成します。次の例では、スキーマ DMS_SAMPLE を移行するときに、スキーマ、テーブル、および列の名前を小文字に変換しています。

{ "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "DMS_SAMPLE", "table-name": "%" }, "rule-action": "include" }, {

API バージョン 2016-01-017


移行のステップバイステップガイド

"rule-type": "transformation", "rule-id": "6", "rule-name": "6", "rule-action": "convert-lowercase", "rule-target": "schema", "object-locator": { "schema-name": "%" } }, { "rule-type": "transformation", "rule-id": "7", "rule-name": "7", "rule-action": "convert-lowercase", "rule-target": "table", "object-locator": { "schema-name": "%", "table-name": "%" } }, { "rule-type": "transformation", "rule-id": "8", "rule-name": "8", "rule-action": "convert-lowercase", "rule-target": "column", "object-locator": { "schema-name": "%", "table-name": "%", "column-name": "%" } } ]}

移行のステップバイステップガイド以下に示しているのは、オンプレミス環境の Oracle データベースを Amazon Aurora MySQL に移行するための詳細な手順です。以下の手順では、「AWS Database Migration Service を使用するためのセットアップ」で説明している、AWS DMS を使用するためのセットアップ手順を完了していることを前提とします。

トピック• ステップ 1: Oracle ソースデータベースの設定 (p. 8)• ステップ 2: Aurora ターゲットデータベースの設定 (p. 11)• ステップ 3: レプリケーションインスタンスの作成 (p. 11)• ステップ 4: Oracle ソースエンドポイントの作成 (p. 13)• ステップ 5: Aurora MySQL ターゲットエンドポイントの作成 (p. 16)• ステップ 6: 移行タスクの作成 (p. 18)• ステップ 7: 移行タスクのモニタリング (p. 23)• トラブルシューティング (p. 23)

ステップ 1: Oracle ソースデータベースの設定AWS Database Migration Service (AWS DMS) のソースとして Oracle を使用するには、まずARCHIVELOG MODE がオンになっていて、LogMiner に情報が提供されることを確認する必要があり

API バージョン 2016-01-018

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_SettingUp.html

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_SettingUp.html


ステップ 1: Oracle ソースデータベースの設定

ます。AWS DMS では、LogMiner を使用してアーカイブログから情報を読み取り、その情報に基づいてAWS DMS が変更をキャプチャできるようにします。

この情報を AWS DMS で読み取るには、AWS DMS がアーカイブログを必要とする期間にわたって、アーカイブログが常にデータベースサーバーに保持されていることを確認します。変更のキャプチャをすぐ開始するようにタスクを設定する場合は、実行期間が最も長いトランザクションより少しだけ長くアーカイブログを保持するだけで済みます。アーカイブログの保持期間は、通常、24 時間で十分です。過去のある時点から開始するようにタスクを設定する場合は、その時点からアーカイブログが利用できることが必要です。ARCHIVELOG MODE を有効にする方法とオンプレミス Oracle データベースのログを保持する方法の詳細については、Oracle のドキュメントを参照してください。

変更データをキャプチャするには、AWS DMS では、ソースデータベースで AWS DMS に対してサプリメンタルロギングが有効になっている必要があります。データベースレベルで最小限のサプリメンタルロギングを有効にする必要があります。AWS DMS では、識別キーのログ記録も有効になっている必要があります。このオプションでは、データベースでプライマリキーを含む行が更新されるたびに (プライマリキーの値に変更がない場合でも)、行のプライマリキーのすべての列が REDO ログファイル内に配置されます。このオプションは、データベースレベルまたはテーブルレベルで設定できます。

Oracle ソースが Amazon RDS 内にある場合は、バックアップを有効にしているときに限り、データベースが ARCHIVELOG MODE に配置されます。次のコマンドを実行すると、アーカイブログは RDS ソースに 24 時間、確実に保持されます。

exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

Oracle ソースデータベースを設定するには

1. 以下のコマンドを実行して、AWS DMS で必要なサプリメンタルロギングをデータベースレベルで有効にします。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

For RDS:exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');

2. 以下のコマンドを使用して、識別キーのサプリメンタルロギングをデータベースレベルで有効にします。サプリメンタルロギングを必要に応じて自動的に追加することを AWS DMS に許可したり、キーレベルのサプリメンタルロギングをテーブルレベルで有効にしたりする場合を除き、AWS DMS ではデータベースレベルでのサプリメンタルキーロギングが必要です。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

For RDS:exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');

3. キーレベルのサプリメンタルロギングを有効にすると、ソースデータベースで多少のオーバーヘッドが生じます。したがって、テーブルのサブセットのみを移行する場合は、テーブルレベルでのサプリメンタルロギングを有効にすることをお勧めします。キーレベルのサプリメンタルロギングをテーブルレベルで有効にするには、次のコマンドを使用します。

alter table table_name add supplemental log data (PRIMARY KEY) columns;

テーブルにプライマリキーがない場合は、2 つのオプションを使用できます。

• テーブル (インデックス名でソート済み) の最初の固有なインデックスに関連するすべての列にサプリメンタルロギングを追加できます。

• テーブルのすべての列にサプリメンタルロギングを追加できます。

API バージョン 2016-01-019

https://community.oracle.com/thread/3717174



テーブル内の列のサブセット (固有なインデックスに関連する列) にサプリメンタルロギングを追加するには、次のコマンドを実行します。

ALTER TABLE table_name ADD SUPPLEMENTAL LOG GROUP example_log_group (ID,NAME) ALWAYS;

テーブルのすべての列にサプリメンタルロギングを追加するには、次のコマンドを実行します。

alter table table_name add supplemental log data (ALL) columns;

4. AWS DMS で使用するデータベースアカウントを作成または設定します。AWS DMS で AWS DMS 接続に必要な最低限の権限を備えたアカウントを使用することをお勧めします。AWS DMS に必要な権限は以下のとおりです。

CREATE SESSIONSELECT ANY TRANSACTIONSELECT on V_$ARCHIVED_LOGSELECT on V_$LOGSELECT on V_$LOGFILESELECT on V_$DATABASESELECT on V_$THREADSELECT on V_$PARAMETERSELECT on V_$NLS_PARAMETERSSELECT on V_$TIMEZONE_NAMESSELECT on V_$TRANSACTIONSELECT on ALL_INDEXESSELECT on ALL_OBJECTSSELECT on ALL_TABLESSELECT on ALL_USERSSELECT on ALL_CATALOGSELECT on ALL_CONSTRAINTSSELECT on ALL_CONS_COLUMNSSELECT on ALL_TAB_COLSSELECT on ALL_IND_COLUMNSSELECT on ALL_LOG_GROUPSSELECT on SYS.DBA_REGISTRYSELECT on SYS.OBJ$SELECT on DBA_TABLESPACESSELECT on ALL_TAB_PARTITIONSSELECT on ALL_ENCRYPTED_COLUMNS* SELECT on all tables migrated

変更のキャプチャと適用 (CDC) を行うには、以下の権限も必要です。

EXECUTE on DBMS_LOGMNR SELECT on V_$LOGMNR_LOGSSELECT on V_$LOGMNR_CONTENTSLOGMINING /* For Oracle 12c and higher. */* ALTER for any table being replicated (if you want DMS to add supplemental logging)

API バージョン 2016-01-0110


ステップ 2: Aurora ターゲットデータベースの設定

バージョン 11.2.0.3 より前の Oracle には、以下の権限が必要です。ビューが公開される場合は、以下の権限が必要です。

SELECT on DBA_OBJECTS /* versions before 11.2.0.3 */SELECT on ALL_VIEWS (required if views are exposed)

ステップ 2: Aurora ターゲットデータベースの設定ソースデータベースと同様に、接続するユーザーのアクセスを制限することをお勧めします。一時的なユーザーを作成して移行後に削除することもできます。

CREATE USER 'dms_user'@'%' IDENTIFIED BY 'dms_user';GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT ON <target database(s)>.* TO 'dms_user'@'%';

AWS DMS では、awsdms_control データベースでターゲットのコントロールテーブルをいくつか使用します。次のコマンドを実行すると、awsdms_control データベースのアクセスに必要な権限が dms_user に付与されます。

GRANT ALL PRIVILEGES ON awsdms_control.* TO 'dms_user'@'%';flush privileges;

ステップ 3: レプリケーションインスタンスの作成AWS DMS レプリケーションインスタンスは、ソースとターゲットの間で実際のデータ移行を行います。レプリケーションインスタンスは、移行中の変更もキャッシュします。レプリケーションインスタンスで使用できる CPU およびメモリ容量に応じて、移行全体の所要時間が変わります。レプリケーションインスタンスのパラメータを設定するには、次の手順を使用します。

AWS DMS レプリケーションインスタンスを作成するには

1. AWS マネジメントコンソールにサインインし、AWS DMS コンソール (https://console.aws.amazon.com/dms/) を開き、[Replication instances (レプリケーションインスタンス)]を選択します。AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合、AWS DMS にアクセスするには適切なアクセス権限が必要です。必要なアクセス許可の詳細については、「AWS DMS を使用するのに必要な IAM アクセス許可」を参照してください。

2. [Create replication instance] を選択します。3. [Create replication instance] ページで、次に示すようにレプリケーションのインスタンス情報を指定

します。

パラメータ操作

名前複数のレプリケーションインスタンスを起動したり、アカウントを共有したりする予定がある場合は、レプリケーションインスタンスを簡単に見分けられる名前を付けます。

API バージョン 2016-01-0111

https://console.aws.amazon.com/dms/


https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Security.IAMPermissions.html


ステップ 3: レプリケーションインスタンスの作成


説明レプリケーションインスタンスの用途が簡単にわかるような名前を付けると、事故防止にも役立ちます。

インスタンスクラス AWS DMS は大量のメモリと CPU を消費する場合があります。大規模なデータベース (多数のテーブル) や複数のLOB データ型を使用する場合は、より大きなインスタンスを設定します。以下で説明するように、複数のタスクを実行することで、スループットを向上させることができます。複数のタスクはより多くのリソースを消費し、より大きなインスタンスを必要とします。テストを実行しながら CPU とメモリの消費量に注目してください。CPU やスワップ領域の容量を使い果たすような場合は、簡単にスケールアップできます。

VPC ここで、レプリケーションインスタンスを起動する VPCを選択できます。可能であれば、ソースデータベースまたはターゲットデータベース (あるいはその両方) がある同じ VPC を選択することをお勧めします。AWS DMS は、この VPC 内からソースデータベースとターゲットデータベースにアクセスする必要があります。データポイントエンドポイントの両方またはいずれかが、この VPC の外部にある場合は、AWS DMS からアクセスできるようにファイアウォールルールを変更します。

マルチ AZ マルチ AZ を選択すると、AWS DMS はプライマリとセカンダリのレプリケーションインスタンスを別個のアベイラビリティーゾーンで起動します。壊滅的なディスク障害が発生した場合、プライマリレプリケーションインスタンスは自動的にセカンダリレプリケーションインスタンスにフェイルオーバーして、サービスの中断を回避します。通常の移行では、マルチ AZ は必要ありません。初回のデータロードに時間がかかり、ソースデータベースとターゲットデータベースの同期に大量の時間が必要な場合は、マルチ AZ 設定で移行サーバーを実行することを検討します。

パブリックアクセス可能ソースデータベースまたはターゲットデータベースのいずれかが、レプリケーションインスタンスがある VPC の外部にある場合は、レプリケーションインスタンスをパブリックにアクセス可能にする必要があります。

4. [Advanced] セクションで、以下のパラメータを設定して、[Next] を選択します。

使用するオプション操作

Allocated storage (GB) ストレージは主に、ログファイルと、キャッシュされたトランザクションで消費されます。キャッシュされたトランザクションでは、ストレージは、キャッシュされたトランザクションをディスクに書き込む必要がある場合にのみ使用されます。そのため、AWS DMS では大量のストレージは使用されませんが、次のような場合は例外です。

• 膨大なトランザクションをロードする、サイズの大きなテーブル。サイズの大きなテーブルをロードするには時間がかかります。そのため、サイズの大きなテーブルをロードする間、キャッシュされたトランザクションが書き込まれる可能性が高くなります。

API バージョン 2016-01-0112


ステップ 4: Oracle ソースエンドポイントの作成

使用するオプション操作• キャッシュされたトランザクションをロードする前に停

止するよう設定されているタスク。この場合、すべてのテーブルのロードが完了するまで、すべてのトランザクションがキャッシュされます。この設定では、キャッシュされたトランザクションにより、かなりの量のストレージが消費されることがあります。

• Amazon Redshift にロードされるテーブルを使用する設定になっているタスク。ただし、Aurora MySQL がターゲットのときは、この設定は問題にはなりません。

ほとんどの場合、ストレージのデフォルトの割り当てで十分です。ただし、ストレージ関連のメトリクスに注意を払い、デフォルトの割り当てよりも消費量が多い場合はストレージを拡張することをおすすめします。

レプリケーションサブネットグループマルチ AZ 設定で実行する場合は、少なくとも 2 つのサブネットグループが必要です。

アベイラビリティーゾーン可能な場合は、プライマリレプリケーションサーバーをターゲットデータベースと同じアベイラビリティーゾーンに配置します。

VPC セキュリティグループセキュリティグループを使用すると、VPC への出入りを制御できます。AWS DMS では、レプリケーションサーバーを起動する VPC に 1 つ以上のセキュリティグループを関連付けることができます。

KMS マスターキー AWS DMS では、すべてのデータが保管中に KMS 暗号化キーで暗号化されます。デフォルトでは、AWS DMS で、レプリケーションサーバー用に新しい暗号化キーが作成されます。ただし、必要に応じて既存のキーを使用することもできます。

ステップ 4: Oracle ソースエンドポイントの作成レプリケーションインスタンスの作成時に、AWS マネジメントコンソールを使用して Oracle ソースエンドポイントを指定できます。ただし、接続をテストできるのはレプリケーションインスタンスの作成後に限ります (接続のテストにレプリケーションインスタンスが使用されるため)。

AWS コンソールを使用して、ソースまたはターゲットデータベースエンドポイントを指定するには

1. AWS DMS コンソールのナビゲーションペインで [Endpoints (エンドポイント)] を選択します。2. [Create endpoint] を選択します。次のような [Create database endpoint page] が表示されます。

API バージョン 2016-01-0113



3. ソース Oracle データベースの接続情報を指定します。次の表はソース設定の説明です。


エンドポイントタイプ [Source] を選択します。

エンドポイント識別子 Oracle エンドポイントの ID を入力します。エンドポイントの ID は、AWS リージョン内で一意であることが必要です。

ソースエンジン [oracle] を選択します。

サーバー名データベースがオンプレミスにある場合は、AWS DMSからレプリケーションサーバを介してデータベースに接続するための IP アドレスを入力します。データベースが Amazon Elastic Compute Cloud (Amazon EC2) または Amazon RDS で実行している場合は、ドメインネームサービス (DNS) のパブリックアドレスを入力します。

ポートデータベースで接続をリッスンするポート (Oracle のデフォルトは 1521) を入力します。

SSL モードこのエンドポイントの接続暗号化を有効にする場合は、Secure Sockets Layer (SSL) モードを選択します。選

API バージョン 2016-01-0114



パラメータ操作択したモードにより、必要に応じて証明書およびサーバー証明書情報を提供します。

[Username] AWS アカウントのユーザー名を入力します。移行専用のAWS アカウントを作成することをお勧めします。

パスワード上のユーザー名のパスワードを入力します。

4. [Advanced] タブを選択し、追加の接続文字列と暗号化キーの値を設定します。


追加の接続属性ここで、エンドポイントの動作を制御する追加の属性の値を指定できます。いくつかの関連性が高い属性を以下に示します。完全なリストについては、ドキュメントを参照してください。複数を追加する場合はセミコロン (;) で区切ります。

• addSupplementalLogging: このオプションを有効(addSupplementalLogging=Y) にすると、AWS DMS でサプリメンタルロギングが自動的に追加されます。

• useLogminerReader: デフォルトでは、AWS DMS でログから変更データをキャプチャするために OracleLogMiner が使用されます。AWS DMS では、独自のテクノロジーを使用してログを解析することもできます。Oracle 12c を使用していて、LOBS を含むテーブルへの変更をキャプチャする場合は、これを No(useLogminerReader=N) に設定します。

• numberDataTypeScale: Oracle は、精度またはスケールが含まれない NUMBER データ型をサポートしています。デフォルトでは、NUMBER は精度 38、スケール10の number(38,10) として数値が変換されます。有効な値は、0 〜 38 または -1 (FLOAT) です。

• archivedLogDestId: このオプションでは、アーカイブされた REDO ログの宛先を指定します。値は、$archived_log テーブル内の DEST_ID 値と同じにする必要があります。ログの宛先 (DEST_ID) を複数使用する場合は、アーカイブされた REDO ログの場所の識別子を指定することをお勧めします。これにより、最初から適切なログにアクセスされるため、パフォーマンスが向上します。このオプションのデフォルト値は 0 です。

KMS マスターキー使用する暗号化キーを選択して、レプリケーションのストレージと接続情報を暗号化します。(デフォルト) aws/dmsを選択する場合、アカウントおよびリージョンに関連付けられたデフォルトの AWS KMS キーが使用されます。

エンドポイントは保存前にテストできます。テストするには、テストを行う VPC とレプリケーションインスタンスを選択します。テストの一環として、AWS DMS はエンドポイントに関連付けられたスキーマのリストを更新します。(スキーマは、このソースエンドポイントを使用してタスクを作成する際にソースオプションとして提示されます)。

API バージョン 2016-01-0115


ステップ 5: Aurora MySQL ターゲットエンドポイントの作成

ステップ 5: Aurora MySQL ターゲットエンドポイントの作成次に、Amazon Aurora MySQL ターゲットデータベースの情報を提供するために、ターゲットエンドポイントの設定を指定します。次の表はターゲット設定の説明です。

AWS マネジメントコンソールを使用してターゲットデータベースのエンドポイントを指定するには

1. AWS DMS コンソールのナビゲーションペインで [Endpoints (エンドポイント)] を選択します。2. [Create endpoint] を選択します。次のような [Create database endpoint page] が表示されます。

3. Aurora MySQL ターゲットデータベースの接続情報を指定します。次の表はターゲット設定の説明です。


エンドポイントタイプ [Target] を選択します。

エンドポイント識別子 Aurora MySQL エンドポイントの ID を入力します。エンドポイントの ID は、AWS リージョン内で一意であることが必要です。

Target Engine [aurora] を選択します。

API バージョン 2016-01-0116


ステップ 5: Aurora MySQL ターゲットエンドポイントの作成


Servername Aurora MySQL インスタンスのライターエンドポイントを入力します。ライターエンドポイントはプライマリインスタンスです。

ポートインスタンスに割り当てられたポートを入力します。

SSL モードこのエンドポイントの接続暗号化を有効にする場合は、SSL モードを選択します。選択したモードにより、必要に応じて証明書およびサーバー証明書情報を提供します。

[Username] 移行用のアカウントのユーザー名を入力します。移行専用のアカウントを作成することをお勧めします。

パスワード上のユーザー名のパスワードを入力します。

4. [Advanced] タブを選択し、必要に応じて追加の接続文字列と暗号化キーの値を設定します。


追加の接続属性ここでエンドポイントの動作を制御する追加の属性の値を入力できます。いくつかの関連性の高い属性を以下に示します。完全なリストについては、ドキュメントを参照してください。複数を追加する場合はセミコロン (;) で区切ります。

• targetDbType: デフォルトでは、AWS DMSで移行するスキーマごとに MySQL データベースが作成されます。いくつかのスキーマのオブジェクトを結合して 1 つのデータベースを構成することもできます。これを行うには、このオプションを特定のデータベース(targetDbType=SPECIFIC_DATABASE) に設定します。

• initstmt: このオプションを使用して、MySQLinitstmt 接続パラメータを呼び出し、mysqlinitstmt で受け入れるすべてのものを受け入れます。Aurora MySQL ターゲットを使用する場合は、通常、外部キーチェックを無効にすると便利です。これを行うには、次のようにinitstmt パラメータを使用します。

initstmt=SET FOREIGN_KEY_CHECKS=0

KMS マスターキー使用する暗号化キーを選択して、レプリケーションのストレージと接続情報を暗号化します。(デフォルト) aws/dms を選択する場合、アカウントおよびリージョンに関連付けられたデフォルトの AWS KMS キーが使用されます。

API バージョン 2016-01-0117

AWS Database Migration Service ステップバイステップ移行ガイドステップ 6: 移行タスクの作成

エンドポイントは保存前にテストできます。テストするには、テストを行う VPC とレプリケーションインスタンスを選択する必要があります。

ステップ 6: 移行タスクの作成移行タスクを作成するときは、データの移行方法を AWS DMS に正確に指示します。タスク内に、移行するテーブル、移行先、移行方法を定義します。AWS DMS の機能を使用して変更のキャプチャと適用を行う場合は、トランザクションが単一のタスク内に保持されていることを確認することが重要です。つまり、1 つのトランザクションに関与するすべてのテーブルを同じタスクで移行する必要があります。

AWS DMS タスクを使用して、移行するスキーマと、移行のタイプを指定できます。既存のデータを移行するか、既存のデータを移行して継続的な変更をレプリケートするか、またはデータ変更のみをレプリケートするかを選択できます。このチュートリアルでは、既存のデータのみを移行します。

移行タスクを作成するには

1. ナビゲーションペインで、[Tasks] を選択します。2. [タスクの作成] を選択します。3. [Create Task] ページで、タスクオプションを指定します。次の表で設定について説明します。


タスク名タスクにはわかりやすい名前を付けて整理しやすいようにします。

タスクの説明タスクの説明を入力します。

ソースエンドポイントソースエンドポイントを選択します。

ターゲットエンドポイントターゲットエンドポイントを選択します。

レプリケーションインスタンスタスクを実行するレプリケーションインスタンスを選択します。ソースエンドポイントとターゲットエンドポイントは、このインスタンスからアクセス可能であることが必要です。

移行タイプ AWS DMS では、3 つの異なる移行タイプを使用できます。

• 既存のデータを移行する:

このオプションを選択すると、AWS DMS では既存のデータのみが移行されます。ソースデータへの変更はキャプチャされず、ターゲットに適用されません。全ロード中に停止が発生しても支障ない場合は、このオプションで移行するのがシンプルで効率的です。この方法は、データベースのテストコピーを作成するときにも有効です。

• 既存のデータを移行し、継続的な変更をレプリケートする:

このオプションを選択すると、AWS DMS は既存のデータの移行中に変更をキャプチャします。AWS DMS では、バルクデータのロード後でも変更のキャプチャと適用が行われます。最終的にソースデータベースとターゲットデータベースは同期され、移行に伴うダウンタイムは最小限に抑えられます。これを行うには、以下のステップに従います。

API バージョン 2016-01-0118


使用するオプション操作• アプリケーションをシャットダウンします。• 最終的な変更をターゲットに送信します。• 外部キーやトリガーを有効にするなどの管理タスクを

実行します。• 新しいターゲットデータベースを参照するアプリケー

ションを起動します。

Note

AWS DMS は、バルクデータをテーブルごとにロードし、一度に <n> テーブルをロードします。全ロードの進行中に、AWS DMS はできるだけ早い段階で、キャッシュされた変更をターゲットテーブルに適用する処理を開始します。バルクロード中は、参照整合性が保持されないため、全ロードに対して既存の外部キーを無効にする必要があります。全ロードが完了すると、ターゲットデータベースで整合性が確保され、変更がトランザクションとして適用されます。

• データ変更のみをレプリケートする:

必要に応じて、別の方法を使用してバルクデータをロードする場合もあります。このアプローチは、通常、同種間の移行にのみ適用されます。

作成時にタスクを開始通常は、タスクをすぐ開始しても問題ありません。ただし、ロギングのレベルを変更する目的などで、タスクの開始を遅らせる場合もあります。

4. 次に、以下のような詳細設定を行います。


ターゲットテーブル作成モード AWS DMS では、ターゲットテーブルをロード前に準備する方法を指定できます。

[Do nothing (何もしない)] - このオプションを選択すると、AWS DMS ではテーブルの準備として何も実行されません。テーブルの構造はそのまま変更されず、既存のデータはテーブル内に残ります。この方法を使用して複数のシステムのデータを統合できます。

[Drop tables on target (ターゲット上のテーブルを削除)] -通常、AWS DMS でターゲットテーブルを自動的に作成するときに、このオプションを使用します。このオプションを選択すると、AWS DMS で移行対象のテーブルが移行前に削除され、再作成されます。

[Truncate] - AWS スキーマ変換ツールなどを使用して、ターゲットシステムでテーブルのすべてまたは一部を事前に作成する場合は、このオプションを選択します。このオプションを選択すると、AWS DMS でターゲットテーブルがロード前に切り詰められます。ターゲットテーブルが存

API バージョン 2016-01-0119


使用するオプション操作在しない場合は、AWS DMS で自動的にテーブルが作成されます。

レプリケーションに LOB 列を含めるラージオブジェクト (LOB) をシステム間で移行することは難しい場合があります。AWS DMS には、LOB の列のチューニングに役立つ多くのオプションが用意されています。どのデータ型がいつ AWS DMS によって LOB と見なされるかについては、AWS DMS のドキュメントを参照してください。

Don't include LOB columns - データベース間でデータを移行するとき、特に異機種間で移行するときは、LOB の保存方法の見直しが必要になる場合があります。その場合、LOB データを移行する必要はありません。

Full LOB mode (完全 LOB モード) - Full LOB mode (完全LOB モード) では、AWS DMS によってソースからターゲットに、サイズにかかわらずすべての LOB が移行されます。この設定では、AWS DMS の最大許容 LOB サイズに関する情報は不要です。したがって、LOB は一度に 1つずつ移行されます。Full LOB mode は非常に低速になることがあります。

Limited LOB mode (制限付き LOB モード) - Limited LOBmode (制限付き LOB モード) では、AWS DMS の最大許容 LOB サイズを設定します。これにより、AWS DMS によってメモリが事前に割り当てられ、LOB データを一括でロードできるようになります。最大 LOB サイズを超えるLOB は切り捨てられ、警告がログファイルに発行されます。Limited LOB mode では、Full LOB mode よりも大幅にパフォーマンスが向上します。可能な限り Limited LOBmode を使用することをお勧めします。

Note

Oracle では、LOB は可能な限り VARCHAR データ型として扱われます。この方法では、AWSDMS によって LOB がデータベースから一括でフェッチされるため、他の方法よりも大幅に高速になります。Oracle では VARCHAR の最大サイズが 64K であるため、Oracle がソースデータベースである場合は、最大許容 LOB サイズを64K 未満に設定するのが最適です。

Max LOB size (K) Limited LOB mode (制限付き LOB モード) で実行されるようにタスクを設定している場合、このオプションによってAWS DMS の最大許容 LOB サイズが決まります。この値よりも大きい LOB はこの値まで切り捨てられます。

API バージョン 2016-01-0120



LOB チャンクサイズ (K) Full LOB mode (完全 LOB モード) を使用するようにタスクを設定している場合、AWS DMS によって LOB は 1 つずつ取得されます。このオプションによって各 LOB のサイズが決まります。このオプションを設定するときは、ネットワーク設定の最大許容パケットサイズに特に注意してください。LOB チャンクサイズが最大許容パケットサイズを超えた場合は、切断エラーが表示されることがあります。

カスタム CDC 開始時刻このパラメータは、データ変更のレプリケーション専用に設定されたタスクに関係します。これにより、変更ストリームのどこから変更を探し始めるかを AWS DMS に指示します。

ログ作成の有効化常にロギングを有効にします。

5. 追加のパラメータを設定します。


ターゲットスキーマで制御テーブルを作成

AWS DMS では、ターゲットデータベース内にいくつかのコントロールテーブルが必要です。デフォルトでは、これらのテーブルは、データと同じデータベースに作成されます。このパラメータでは、これらのアーティファクトの作成先として別の場所を AWS DMS に指示できます。

並列にロードするテーブルの最大数 AWS DMS では、データがテーブル単位でロードされます。このパラメータでは、AWS DMS で同時に並行してロードするテーブルの数を制御できます。デフォルトは 8であり、ほとんどの状況に最適です。

6. テーブルマッピング設定を指定します。

テーブルマッピングでは、タスクでどのテーブルをソースからターゲットに移行するかを AWS DMSに指示します。テーブルマッピングは JSON 形式で表されます。ただし、一部の設定は AWS マネジメントコンソールで作成できます。テーブルマッピングには、テーブル名を大文字から小文字に変更するなどの変換を含めることもできます。

AWS DMS では、ソースデータベースの (システム以外の) スキーマごとにデフォルトのテーブルマッピングが生成されます。通常、テーブルマッピングはカスタマイズします。テーブルマッピングをカスタマイズするには、カスタムラジオボタンを選択します。テーブルマッピングの作成の詳細については、AWS DMS のドキュメントを参照してください。次のテーブルマッピングでは、以下の操作を行ないます。

• DMS_SAMPLE スキーマを移行に含めます。• NFL_DATA、MLB_DATA、NAME_DATE、および STADIUM_DATA の各テーブルを除外します。• スキーマ、テーブル、および列の名前を小文字に変換します。

{ "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1",

API バージョン 2016-01-0121


"object-locator": { "schema-name": "DMS_SAMPLE", "table-name": "%" }, "rule-action": "include" }, { "rule-type": "selection", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "DMS_SAMPLE", "table-name": "MLB_DATA" }, "rule-action": "exclude" },{ "rule-type": "selection", "rule-id": "3", "rule-name": "3", "object-locator": { "schema-name": "DMS_SAMPLE", "table-name": "NAME_DATA" }, "rule-action": "exclude" }, { "rule-type": "selection", "rule-id": "4", "rule-name": "4", "object-locator": { "schema-name": "DMS_SAMPLE", "table-name": "NFL_DATA" }, "rule-action": "exclude" },

{ "rule-type": "selection", "rule-id": "5", "rule-name": "5", "object-locator": { "schema-name": "DMS_SAMPLE", "table-name": "NFL_STADIUM_DATA" }, "rule-action": "exclude" },{ "rule-type": "transformation", "rule-id": "6", "rule-name": "6", "rule-action": "convert-lowercase", "rule-target": "schema", "object-locator": { "schema-name": "%" } }, { "rule-type": "transformation", "rule-id": "7", "rule-name": "7", "rule-action": "convert-lowercase", "rule-target": "table", "object-locator": { "schema-name": "%",

API バージョン 2016-01-0122


ステップ 7: 移行タスクのモニタリング

"table-name": "%" } }, { "rule-type": "transformation", "rule-id": "8", "rule-name": "8", "rule-action": "convert-lowercase", "rule-target": "column", "object-locator": { "schema-name": "%", "table-name": "%", "column-name": "%" } } ]}

ステップ 7: 移行タスクのモニタリングコンソールの 3 つのセクションでは、移行タスクの実行状況を確認できます。

• タスクのモニタリング – [Task Monitoring] タブでは、全ロードのスループット、変更のキャプチャと適用のレイテンシーを確認できます。

• テーブル統計 – [Table Statistics] タブでは、処理された行数、処理されたトランザクションのタイプと数に関する詳細な情報を確認できます。DDL オペレーションに関する情報も確認できます。

• ログ – [Logs] タブでは、タスクのログファイルを確認できます (ロギングをオンにしている場合)。何らかの理由でタスクが失敗した場合は、このファイルでエラーを調べます。さらに、このファイルで警告も確認できます。タスクでデータが切り捨てられた場合は、ログファイルに警告として表示されます。必要に応じて、AWS コマンドラインインターフェイス (CLI) でログレベルを引き上げることができます。

トラブルシューティングOracle をソースとし、Aurora MySQL をターゲットとして使用するときに最も問題が発生しやすい 2 つの領域として、サプリメンタルロギングと大文字/小文字の区別があります。

• サプリメンタルロギング – Oracle で変更データをレプリケートするにはサプリメンタルロギングを有効にする必要があります。ただし、サプリメンタルロギングをデータベースレベルで有効にした場合は、新しいテーブルの作成時に再度有効にする必要があります。この最良の対策としては、追加の接続属性を使用してサプリメンタルロギングを自動的に有効にすることを DMS を許可します。


• 大文字/小文字の区別: Oracle では大文字と小文字が区別されます (オブジェクト名を引用符で囲んだ場合を除きます)。ただし、テキストは大文字で表示されます。したがって、AWS DMS ではデフォルトでターゲットオブジェクト名が大文字になります。通常は、変換を使用してスキーマ、テーブル、および列の名前を小文字に変更します。

詳細なヒントについては、『AWS DMS ユーザーガイド』の AWS DMS トラブルシューティングのセクションを参照してください。

API バージョン 2016-01-0123

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html


移行のサンプルデータベースを使用する

Oracle 固有の問題のトラブルシューティングを行うには、以下の Oracle のトラブルシューティングセクションを参照してください。

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.Oracle

Aurora MySQL のトラブルシューティングを行うには、MySQL のトラブルシューティングのセクションを参照してください。

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.MySQL

移行のサンプルデータベースを使用するこれまでに紹介した概略とガイドに従って Amazon が提供するサンプルの Oracle データベースを使用することをお勧めします。このデータベースは、スポーツイベントの簡単なチケット発行システムに似せて作られています。サンプルデータベースを生成するためのスクリプトは、https://github.com/awslabs/aws-database-migration-samples にあります。

サンプルデータベースを構築するには、oracle/sampledb/v1 フォルダにアクセスし、そこにあるREADME.md ファイルの手順に従ってください。

サンプルでは、約 8 〜 10 GB のデータが作成されます。サンプルデータベースには ticketManagmentパッケージも含まれており、これを使用していくつかのトランザクションを生成できます。トランザクションを生成するには、SQL*Plus または SQL Developer にログインし、dms_sample として以下を実行します。

SQL>exec ticketManagement.generateTicketActivity(0.01,1000);

最初のパラメータはトランザクションの遅延時間 (秒単位) であり、2 番目のパラメータは生成するトランザクション数です。上のプロシージャでは単に人々に「チケットを販売」します。テーブルsporting_event_ticket と ticket_purchase_history の更新が表示されます。

いくつかのチケットを [販売] したら、次のコマンドを使用して転送できます。

SQL>exec ticketManagement.generateTransferActivity(1,100);

最初のパラメータはトランザクションの遅延時間 (秒単位) であり、2 番目のパラメータは生成するトランザクション数です。このプロシージャでは sporting_event_ticket と ticket_purchase_history も更新されます。

API バージョン 2016-01-0124





https://github.com/awslabs/aws-database-migration-samples

https://github.com/awslabs/aws-database-migration-samples


コスト

Amazon RDS Oracle データベースのAmazon Aurora MySQL への移行

このチュートリアルでは、AWS Database Migration Service と AWS Schema Conversion Tool を使用した、Amazon RDS Oracle から MySQL と互換性がある Amazon Aurora への異種データベースの移行について説明します。これは入門演習であり、すべてのシナリオを網羅していませんが、このような移行の実行に関連するステップについてよく理解することができます。

重要な点として、AWS DMS と AWS SCT は 2 つの異なるツールであり、異なるニーズに対応します。両者が移行プロセスで連携することはありません。大まかに述べると、この移行に関連するステップは次のとおりです。

1. AWS SCT を使用して、次のことを行います。• Oracle から Aurora MySQL への変換レポートを実行して、スキーマ変換の問題、制約、および必要な

アクションを確認します。• スキーマスクリプトを生成し、ターゲットに適用してから、AWS DMS を介してデータのロードを実

行します。AWS SCT は、手順やビューなどのオブジェクトに必要なコード変換を実行します。2. AWS SCT によって報告された問題のソリューションを識別して実装します。たとえば、Oracle

Sequence など、Amazon Aurora MySQL でサポートされていないオブジェクトタイプは、auto_increment オプションを使用して代理キーを入力するか、アプリケーションレイヤーでシーケンスのロジックを開発して処理できます。

3. 外部キー、または AWS DMS データのロードに影響する可能性があるその他の制約事項を無効にします。

4. AWS DMS では、全ロードアプローチを使用してソースからターゲットにデータをロードします。AWSDMS は、ロードの一部としてターゲット内でオブジェクトを作成できますが、最小主義の手法に従って効率的にデータを移行するため、ソースからターゲットにスキーマ構造全体をコピーしません。

5. 追加のインデックスの作成、外部キーの有効化、アプリケーションでの必要な変更による新しいデータベースの指定など、移行後のアクティビティを実行します。

このチュートリアルでは、カスタム AWS CloudFormation テンプレートを使用して、Oracle およびAmazon Aurora MySQL 用の Amazon RDS DB インスタンスを作成します。次に SQL コマンドスクリプトを使用し、Amazon Aurora MySQL に移行するサンプルスキーマとデータを最初に Amazon RDS OracleDB インスタンスにインストールします。

このチュートリアルの所要時間は約 2 時間です。AWS リソースを使用してこのチュートリアルを完了するための推定コストは、約 5.00 USD です。追加料金が発生しないように、チュートリアルが終了したら、手順に従って必ずリソースを削除してください。

トピック• コスト (p. 25)• 前提条件 (p. 27)• 移行アーキテクチャ (p. 27)• ステップバイステップ移行 (p. 29)• 次のステップ (p. 60)

コストこのチュートリアルでは、AWS CloudFormation および AWS Database Migration Service (AWS DMS) のリソースを使用して Amazon Relational Database Service (Amazon RDS) リソースをプロビジョニング

API バージョン 2016-01-0125


コスト

します。これらのリソースのプロビジョニングでは、AWS アカウントに時間単位で課金されます。AWSSchema Conversion Tool は AWS DMS の一部として提供されるため、このツールで料金は発生しません。

このウォークスルーでは最小限のリソースのみが必要ですが、これらのリソースの一部は AWS 無料利用枠の対象ではありません。このウォークスルーの最後に、追加料金が発生しないようにするためにリソースを削除するセクションがあります。ウォークスルーを完了したらすぐにリソースを削除してください。

このウォークスルーを AWS で実行するためのコストを予測するために、AWS 簡易見積りツールを使用できます。ただし、AWS DMS サービスはまだツールに組み込まれていません。次の表は、AWS DMS および Amazon RDS Oracle Standard Edition Two の両方の料金を示しています。

AWS サービスインスタンスタイプ

ストレージおよびI/O

Amazon RDS Oracle DB インスタンス、ライセンス込み(Standard Edition Two)、シングル AZ

db.m3.medium シングル AZ、10GB のストレージ、GP2

Amazon Aurora MySQL DB インスタンス db.r3.large シングル AZ、10GB のストレージ、100 万 I/O

AWS DMS レプリケーションインスタンス t2.small 50 GB のストレージ (レプリケーションログの保持用を含む)

AWS DMS データ転送同一アベイラビリティーゾーン内のAWS DMS と RDSインスタンスのデータベース間のデータ転送は無料

データ発信毎月 1 GB まで無料

このウォークスルーを 2 時間実行すると想定した場合の、AWS リソースの料金の見積りは次のとおりです。

• 料金表サイトからアクセスできる簡易見積りツールへのリンクを使用して見積もられた Amazon AuroraMySQL + 10 GB のストレージ料金は、1.78 USD です。

• Amazon RDS Oracle SE2 (ライセンス込み) + 10 GB の GP2 ストレージのコスト、見積り料金はaws.amazon.comaws.amazon.com に従い、(0.226 USD) * 2 時間 + (0.115 USD) * 10 GB = 1.602 USDです。

• t2.small インスタンスと 50 GB の GP2 ストレージのの AWS DMS サービスのコスト、見積り料金は料金表サイトに従い、(0.036 USD) * 2 時間 = 0.072 USD です。

このプロジェクトを実行するための合計推定コスト = 1.78 USD + 1.602 USD + 0.072 USD = 3.454 — 約5.00 USD。

この料金は次の前提事項に基づいています。

• インターネットへのデータ転送量の合計は 1 ギガバイト未満と想定しています。前述の見積りでは、RDS および DMS サービスに関連するデータ転送およびバックアップ料金が無料利用枠内であると想定しています。

API バージョン 2016-01-0126

https://aws.amazon.com/dms/pricing/




前提条件

• Aurora MySQL データベースによって消費されるストレージは、毎月 GB 単位で課金され、消費されるI/O は 100 万リクエスト単位で課金されています。

• 同じアベイラビリティーゾーン内の DMS と RDS インスタンスのデータベース間のデータ転送は無料です。

前提条件このチュートリアルを実施する前提条件として以下も必要です。

• Amazon RDS、該当するデータベーステクノロジー、および SQL に関する知識。• 移行するテーブルと移行を確認する SQL クエリの作成に必要な以下のカスタムスクリプト。

• Oracle-HR-Schema-Build.sql—HR スキーマを構築するための SQL ステートメント。• Oracle_Aurora_For_DMSDemo.template—AWS CloudFormation テンプレート。

スクリプトは、次のリンクで入手できますdms-sbs-RDSOracle2Aurora.zip。

チュートリアルの各ステップには、関連ファイルをダウンロードするためのリンクや、該当するクエリが含まれています。

• AWS リージョンで Amazon Relational Database Service (Amazon RDS) および AWS DatabaseMigration Service (AWS DMS) インスタンスの起動を許可する AWS Identity and Access Management(IAM) の認証情報を含む AWS アカウント。IAM 認証情報の詳細については、「IAM ユーザーの作成」を参照してください。

• Amazon Virtual Private Cloud (Amazon VPC) サービスとセキュリティグループに関する基本的な知識。Amazon RDS での Amazon VPC の使用方法については、「Virtual Private Cloud (VPC) および Amazon RDS」を参照してください。Amazon RDS セキュリティグループの詳細については、「Amazon RDS セキュリティグループ」を参照してください。

• AWS DMS でサポートされている機能と制限についての理解。AWS DMS に関する詳細については、「AWS Database Migration サービスとは」を参照してください。

• Oracle と Amazon Aurora MySQL でサポートされているデータ型変換オプションの知識。ソースとしての Oracle データ型の詳細については、「AWS Database Migration Service のソースとして Oracle データベースを使用する」を参照してください。ターゲットとしての Amazon Aurora MySQL データ型の詳細については、「AWS Database Migration Service のターゲットとして MySQL 互換データベースを使用する」を参照してください。

AWS DMS の詳細については、「AWS DMS に関するドキュメント」を参照してください。

移行アーキテクチャこのチュートリアルでは、AWS CloudFormation を使用してデータベース移行用の単純なネットワークトポロジーを作成します。このトポロジーでは、ソースデータベース、レプリケーションインスタンス、ターゲットデータベースを同じ VPC 内に配置します。AWS CloudFormation の詳細については、CloudFormation のドキュメントを参照してください。

この AWS Database Migration Service (AWS DMS) のチュートリアルで使用する AWS リソースは AWSCloudFormation でプロビジョニングされます。これらのリソースには、Oracle、および Amazon AuroraMySQL 用の VPC および Amazon Relational Database Service (Amazon RDS) インスタンスが含まれます。AWS CloudFormation を介してプロビジョニングするのは、これによりプロセスが簡素化され、データ移行に関連するタスクに専念できるためです。AWS CloudFormation テンプレートからスタックを作成するときに、次のリソースがプロビジョニングされます。

API バージョン 2016-01-0127

http://docs.aws.amazon.com/dms/latest/sbs/samples/dms-sbs-RDSOracle2Aurora.zip

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_SettingUp.html#CHAP_SettingUp.IAM

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.html


https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html

https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.Oracle.html


https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html


https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html


移行アーキテクチャ

• VPC は CIDR (10.0.0.0/24) で、リージョン内にパブリックサブネットが 2 つあります。DBSubnet1は、アドレスが 10.0.0.0/26 で、アベイラビリティーゾーン 1 (AZ 1) にあります。DBSubnet2 は、アドレスが 10.0.0.64/26 で、AZ 2にあります。

• DB サブネットグループ。これには DBSubnet1 と DBSubnet2 が含まれます。• Oracle RDS Standard Edition Two。これには、以下のデプロイメントオプションがあります。

• ライセンス込み• シングル AZ のセットアップ• db.m3.medium または同等のインスタンスクラス• ポート 1521• デフォルトのオプションとパラメータグループ

• これらのデプロイオプションを備えた Amazon Aurora MySQL DB インスタンス:• レプリカなし• db.r3.large または同等のインスタンスクラス• ポート 3306• デフォルトのオプションとパラメータグループ

• セキュリティグループ。入力パラメータに基づいてコンピュータからの着信アクセスを制御するか、0.0.0.0/0 ですべての場所からのアクセスを許可します。

今回設計した CloudFormation テンプレートでは、ユーザーの入力はほとんど必要ありません。最小限の推奨設定で、必要な AWS リソースがプロビジョニングされます。ただし、テンプレートの更新は自由です。必要に応じて設定やパラメータ (VPC CIDR ブロックや Amazon RDS インスタンスタイプなど) の一部を変更できます。

AWS マネジメントコンソールを使用して、レプリケーションインスタンス、エンドポイント、タスクなどの AWS DMS リソースをプロビジョニングします。SQL Workbench/J、AWS スキーマ変換ツール (AWSSCT) などのクライアントツールをローカルコンピュータにインストールし、Amazon RDS インスタンスに接続します。

次の図は、このチュートリアルでの移行アーキテクチャです。

API バージョン 2016-01-0128


ステップバイステップ移行

ステップバイステップ移行以下のセクションでは、Amazon Relational Database Service (Amazon RDS) の Oracle データベースからAmazon Aurora MySQL への移行手順を示します。各ステップでは、これまでのセクションの説明に従ってソースデータベースが準備済みであることを前提とします。

トピック• ステップ 1: CloudFormation テンプレートを使用して VPC で RDS インスタンスを起動する (p. 29)• ステップ 2: SQL ツールと AWS Schema Conversion Tool をローカルコンピュータにインストールす

る (p. 34)• ステップ 3: Oracle DB インスタンスへの接続をテストしてサンプルスキーマを作成する (p. 37)• ステップ 4: Aurora MySQL DB インスタンスへの接続をテストする (p. 40)• ステップ 5: AWS スキーマ変換ツール (AWS SCT) を使用して、Oracle スキーマを Aurora MySQL に

変換する (p. 42)• ステップ 6: スキーマ変換を検証する (p. 49)• ステップ 7: AWS DMS レプリケーションのインスタンスを作成する (p. 51)• ステップ 8: AWS DMS のソースとターゲットのエンドポイントを作成する (p. 52)• ステップ 9: AWS DMS 移行タスクの作成と実行 (p. 54)• ステップ 10: データ移行が正常に完了したことを検証する (p. 57)• ステップ 11: チュートリアルのリソースを削除する (p. 59)

ステップ 1: CloudFormation テンプレートを使用してVPC で RDS インスタンスを起動する開始する前に、AWS CloudFormation テンプレートをダウンロードする必要があります。以下の手順に従います。

1. 以下のアーカイブをコンピュータにダウンロードします http://docs.aws.amazon.com/dms/latest/sbs/samples/dms-sbs-RDSOracle2Aurora.zip。

2. アーカイブから CloudFormation テンプレート (Oracle_Aurora_For_DMSDemo.template) を抽出します。

3. Oracle_Aurora_For_DMSDemo.template ファイルを現在のディレクトリにコピーアンドペーストします。

まず、このウォークスルーで使う AWS リソースをプロビジョニングする必要があります。

AWS CloudFormation を使用して、このチュートリアルの Amazon RDS リソースを作成するには

1. AWS マネジメントコンソールにサインインして、https://console.aws.amazon.com/cloudformation でAWS CloudFormation コンソールを開きます。

2. [Create stack] を選択します。3. [Select Template (テンプレートを選択)] ページで、[Upload a template to Amazon S3 (Amazon S3 に

テンプレートをアップロード)] を選択します。4. [Choose File (ファイルを選択)] をクリックして dms-sbs-RDSOracle2Aurora.zip アーカイブから

抽出した Oracle_Aurora_For_DMSDemo.template ファイルを選択します。5. [Next (次へ)] を選択します。[Specify Details] ページで、以下のようにパラメータ値を指定します。

API バージョン 2016-01-0129



https://console.aws.amazon.com/cloudformation/


ステップ 1: CloudFormation テンプレートを使用して VPC で RDS インスタンスを起動する


スタックの名前 DMSdemo と入力します。

OracleDBName データベースの一意の名前を指定します。名前は文字で始める必要があります。デフォルト: ORCL。

OracleDBUsername Oracle インスタンスを管理する管理者 (DBA) ユーザーを指定します。デフォルト: oraadmin。

OracleDBPassword 管理者ユーザーのパスワードを入力します。デフォルト:oraadmin123。

AuroraDBUsername Aurora MySQL インスタンスを管理する管理者 (DBA) ユーザーを指定します。デフォルト: auradmin。

AuroraDBPassword 管理者ユーザーのパスワードを入力します。デフォルト:auradmin123。

ClientIP ローカルコンピュータの IP アドレスを CIDR (x.x.x.x/32)形式で指定します。IP アドレスは whatsmyip.org から取得できます。RDS インスタンスのセキュリティグループは、この IP アドレスへのアクセスを許可します。デフォルトは、すべての場所 (0.0.0.0/0) からのアクセスを許可するため、お勧めできません。このチュートリアル用の IPアドレスを使用してください。

API バージョン 2016-01-0130



6. [Next (次へ)] を選択します。次に示す [Options] ページで、[Next] を選択します。

API バージョン 2016-01-0131



7. [Review] ページで詳細を確認し、正しい場合は [Create Stack] を選択します。[Cost] を選択すると、この CloudFormation テンプレートを実行するための推定コストを取得できます。

8. AWS では、Amazon RDS Oracle と Amazon Aurora MySQL インスタンスでスタックを作成するのに、20 分以上かかる場合があります。

API バージョン 2016-01-0132



9. スタックが作成されたら、[Stack] を選択してから DMSdemo スタックを選択し、[Outputs] を選択します。後でこのチュートリアルで Oracle と Aurora MySQL DB インスタンスに接続するために使用するため、JDBC 接続文字列 OracleJDBCConnectionString および AuroraJDBCConnectionString を記録しておきます。

API バージョン 2016-01-0133


ステップ 2: SQL ツールと AWS Schema ConversionTool をローカルコンピュータにインストールする

Note

Oracle 12c SE Two License バージョン 12.1.0.2.v4 は、すべてのリージョンで利用可能です。ただし、Amazon Aurora MySQL は、すべてのリージョンで利用可能なわけではありません。Amazon Aurora MySQL は、現在、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (東京)、アジアパシフィック (ムンバイ)、アジアパシフィック (シドニー)、およびアジアパシフィック (ソウル) にてご利用いただけます。AuroraMySQL が利用できないリージョンでスタックの作成を試みると、Invalid DB Engine forAuroraCluster というエラーで作成に失敗します。

ステップ 2: SQL ツールと AWS Schema ConversionTool をローカルコンピュータにインストールする次に、SQL クライアントおよび AWS スキーマ変換ツール (AWS SCT) をローカルコンピュータにインストールする必要があります。

このウォークスルーでは、SQL Workbench/J クライアントを使用して、移行の検証のために RDS インスタンスに接続することを前提としています。次に示す、他のいくつかのソフトウェアツールも検討することをお勧めします。

• JACK DB: JDBC 経由で RDS データベース (Oracle と Aurora MySQL) を操作するオンラインウェブインターフェイス

• DBVisualizer• Oracle SQL Developer

API バージョン 2016-01-0134

http://www.jackdb.com

https://www.dbvis.com/download/

https://www.oracle.com/technetwork/developer-tools/sql-developer/overview/index-097090.html



SQL クライアントソフトウェアをインストールするには

1. SQL Workbench/J のウェブサイトから SQL Workbench/J をダウンロードし、ローカルコンピュータにインストールします。この SQL クライアントは無料のオープンソースであり、DBMS に依存しません。

2. Oracle データベースリリース用の JDBC ドライバーをダウンロードします。詳細については、https://www.oracle.com/jdbc を参照してください。

3. MySQL; 用の JDBC ドライバー (.jar ファイル) をダウンロードします。詳細については、https://dev.mysql.com/downloads/connector/j/ を参照してください。

4. SQL Workbench/J を使用して、次に示すように Oracle および Aurora MySQL 用の JDBC ドライバーの接続を設定します。

a. SQL Workbench/J で、[File] を選択し、[Manage Drivers] を選択します。b. ドライバーのリストから、[Oracle] を選択します。c. [Open] アイコンをクリックし、前のステップでダウンロードした Oracle JDBC driver ドライバー

の .jar ファイルを選択します。[OK] を選択します。

d. ドライバーのリストから、[MySQL] を選択します。e. [Open] アイコンをクリックし、前のステップでダウンロードした MySQL JDBC ドライバーを選

択します。[OK] を選択します。

API バージョン 2016-01-0135

http://www.sql-workbench.net/downloads.html

https://www.oracle.com/jdbc


https://dev.mysql.com/downloads/connector/j/




次に、AWS スキーマ移行ツールおよび必要な JDBC ドライバーをインストールします。

AWS スキーマ移行ツールおよび JDBC ドライバーをインストールするには

1. 『AWS Schema Conversion Tool ユーザーガイド』の「AWS Schema Conversion Tool のインストールと更新」から AWS Schema Conversion Tool をダウンロードデフォルトでは、このツールは C:\Program Files\AWS Schema Conversion Tool\AWS ディレクトリにインストールされます。

2. AWS スキーマ変換ツールを起動します。3. AWS スキーマ変換ツールで、[Settings] の [Global Settings] を選択します。4. [Global Settings] で、[Driver] を選択し、[Oracle Driver Path] の [Browse] を選択します。JDBC

Oracle ドライバーを見つけ、[OK] を選択します。次に、[MySql Driver Path] の [Browse] を選択します。MySQL JDBC ドライバーを見つけ、[OK] を選択します。[OK] を選択してダイアログボックスを閉じます。

API バージョン 2016-01-0136

https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.Installing.html



ステップ 3: Oracle DB インスタンスへの接続をテストしてサンプルスキーマを作成する

ステップ 3: Oracle DB インスタンスへの接続をテストしてサンプルスキーマを作成するCloudFormation スタックを作成したら、SQL Workbench/J を使用して Oracle DB インスタンスへの接続をテストし、HR サンプルスキーマを作成します。

SQL Workbench/J を使用して Oracle DB インスタンスへの接続をテストし、サンプルスキーマを作成するには

1. SQL Workbench/J で、[File] を選択し、[Connect window] を選択します。次に示すように、以下の情報を使用して新しい接続プロファイルを作成します


[New profile] の名前 RDSOracleConnection と入力します。

ドライバー Oracle (oracle.jdbc.OracleDriver) を選択します。

URL 前のステップで DMSdemo スタックの出力詳細を調べたときに記録した OracleJDBCConnectionString の値を使用します。

[Username] oraadmin と入力します。

パスワード AWS CloudFormation テンプレートを使用して Oracle DBインスタンスを作成したときに割り当てた、管理者ユーザーのパスワードを入力します。

API バージョン 2016-01-0137



2. [Test] を選択して接続をテストします。[OK] を選択してダイアログボックスを閉じ、[OK] を選択して接続プロファイルを作成します。

Note

接続が失敗した場合は、CloudFormation テンプレートの作成時に割り当てた IP アドレスが、接続元の IP アドレスになっていることを確認します。これは、インスタンスへの接続を試みるときの最も一般的な問題です。

3. カスタム SQL スクリプト (Oracle-HR-Schema-Build.sql) を使用して、移行に使用する HR スキーマを作成します。このスクリプトを取得するには、以下を実行します。

1. 以下のアーカイブをコンピュータにダウンロードします http://docs.aws.amazon.com/dms/latest/sbs/samples/dms-sbs-RDSOracle2Aurora.zip。

2. アーカイブから SQL スクリプト Oracle-HR-Schema-Build.sql を抽出します。3. Oracle-HR-Schema-Build.sql ファイルを現在のディレクトリにコピーアンドペーストしま

す。4. 用意された SQL スクリプトをテキストエディタで開きます。スクリプト全体をコピーします。5. SQL Workbench/J で、Statement 1 が表示されている Default.wksp ウィンドウに SQL スクリプトを

貼り付けます。6. [SQL] を選択し、[Execute All] を選択します。

スクリプトを実行すると、ユーザー HR が存在しないことを示すエラーメッセージが表示されます。このエラーは無視してスクリプトを実行できます。このスクリプトは、ユーザーの作成前にユーザーを削除するため、それによりエラーが生成されます。

7. 次の SQL クエリを実行し、HR スキーマのオブジェクトタイプと数が正常に作成されたことを確認します。

Select OBJECT_TYPE, COUNT(*) from dba_OBJECTS where owner='HR' GROUP BY OBJECT_TYPE;

API バージョン 2016-01-0138





このクエリの結果は以下のようになります。

OBJECT_TYPE COUNT(*) INDEX 8PROCEDURE 2 SEQUENCE 3 TABLE 7 VIEW 1

8. 次の SQL クエリを実行して、HR スキーマの制約の数を確認します。

Select CONSTRAINT_TYPE,COUNT(*) from dba_constraints where owner='HR' AND (CONSTRAINT_TYPE IN ('P','R')OR SEARCH_CONDITION_VC NOT LIKE '%NOT NULL%') GROUP BY CONSTRAINT_TYPE;


CONSTRAINT_TYPE COUNT(*) R 10 P 7 C 1

9. 以下を実行して、HR スキーマを分析します。

BEGIN dbms_stats.gather_schema_stats('HR');END;/

10. 次の SQL クエリを実行して、テーブルの合計数と各テーブルの行数を確認します。

SELECT table_name, num_rows from dba_tables where owner='HR' order by 1;


TABLE_NAME NUM_ROWS COUNTRIES 25 DEPARTMENTS 27 EMPLOYEES 107 JOBS 19 JOB_HISTORY 10 LOCATIONS 23 REGIONS 4

11. テーブルの関係を確認します。次の SQL クエリを実行して、従業員が 10 人より多い部門を確認します。

API バージョン 2016-01-0139


ステップ 4: Aurora MySQL DB インスタンスへの接続をテストする

Select b.department_name,count(*) from HR.Employees a,HR.departments b where a.department_id=b.department_id group by b.department_name having count(*) > 10order by 1;


DEPARTMENT_NAME COUNT(*)Sales 34Shipping 45

ステップ 4: Aurora MySQL DB インスタンスへの接続をテストする次に、Aurora MySQL DB インスタンスへの接続をテストします。

SQL Workbench/J を使用して Aurora MySQL DB インスタンスへの接続をテストするには

1. SQL Workbench/J で、[File] を選択し、[Connect window] を選択します。以下の情報を使用して、[Create a new connection profile (新しい接続プロファイル)] アイコンを選択します。次に示すように、SQL Workbench/J で Aurora MySQL DB インスタンスに接続します


[New profile] の名前 RDSAuroraConnection と入力します。

ドライバー MySQL (com.mysql.jdbc.Driver) を選択します。

URL 前のステップで DMSdemo スタックの出力詳細を調べたときに記録した AuroraJDBCConnectionString の値を使用します。

[Username] auradmin と入力します。

パスワード AWS CloudFormation テンプレートを使用して AuroraMySQL DB インスタンスを作成したときに割り当てた、管理者ユーザーのパスワードを入力します。


API バージョン 2016-01-0140


ステップ 4: Aurora MySQL DB インスタンスへの接続をテストする

Note

接続が失敗した場合は、CloudFormation テンプレートの作成時に割り当てた IP アドレスが、接続元の IP アドレスになっていることを確認します。これは、インスタンスへの接続を試みるときの最も一般的な問題です。

3. マスター管理者認証情報を使用して Aurora MySQL インスタンスにログオンします。4. SHOW DATABASES; などのサンプル SQL コマンドを実行して、Aurora MySQL DB インスタンスへの

接続を検証します。

API バージョン 2016-01-0141


ステップ 5: AWS スキーマ変換ツール (AWS SCT) を使用して、Oracle スキーマを Aurora MySQL に変換する

ステップ 5: AWS スキーマ変換ツール (AWS SCT) を使用して、Oracle スキーマを Aurora MySQL に変換するデータを Aurora MySQL に移行する前に、次に示すように Oracle スキーマを Aurora MySQL スキーマに変換します。

AWS スキーマ変換ツール (AWS SCT) を使用して Oracle スキーマを Aurora MySQL スキーマに変換するには

1. AWS スキーマ変換ツール (AWS SCT) を起動します。AWS SCT で [File] を選択し、[New Project] を選択します。DMSDemoProject という新しいプロジェクトを作成します。[New Project] ウィンドウに次の情報を入力し、[OK] を選択します。


プロジェクト名 DMSDemoProject と入力します。

場所デフォルトの [Projects] フォルダとデフォルトの[Transactional Database (OLTP)] オプションを使用します。

Source Database Engine [Oracle] を選択します。

Target Database Engine [Amazon Aurora (MySQL Compatible)] を選択します。

2. [Connect to Oracle] を選択します。[Connect to Oracle] ダイアログボックスに次の情報を入力して、[Test Connection] を選択します。


タイプ [SID] を選択します。

API バージョン 2016-01-0142




サーバー名 Oracle DB インスタンスへの接続に使用した[OracleJDBCConnectionString] の値を使用しますが、JDBC プレフィックス情報は削除します。たとえば、SQL Workbench/J で使用する接続文字列が、「jdbc:oracle:thin:@do1xa4grferti8y.cqiw4tcs0mg7.us-west-2.rds.amazonaws.com:1521:ORCL」であるとします。AWS SCT の [Server name (サーバー名)]の場合、「jdbc:oracle:thin:@//」と「:1521」を削除し、サーバー名「do1xa4grferti8y.cqiw4tcs0mg7.us-west-2.rds.amazonaws.com」のみを使用します。

Server port 1521 と入力します。

Oracle SID ORCL と入力します。

ユーザー名 oraadmin と入力します。


3. [OK] を選択してアラートボックスを閉じ、[OK] を選択してダイアログボックスを閉じて、OracleDB インスタンスへの接続を開始します。Oracle DB インスタンスのデータベース構造が表示されます。HR スキーマのみを選択します。

API バージョン 2016-01-0143



4. [Connect to Amazon Aurora] を選択します。[Connect to Amazon Aurora] ダイアログボックスに次の情報を入力して、[Test Connection] を選択します。



サーバー名 Aurora MySQL DB インスタンスへの接続に使用したAuroraJDBCConnectionString の値を使用します。ただし、JDBC プレフィックス情報、ポートサフィックスは削除します。たとえば、SQL Workbench/J で使用する接続文字列が、「jdbc:mysql://dmsdemo-auroracluster-1u1ogdfg35v.cluster-cqiw4tcs0mg7.us-west-2.rds.amazonaws.com:3306」であるとします。AWS SCT の [Server name (サーバー名)] の場合、「jdbc:mysql://」と「:3306」を削除し、サーバー名「dmsdemo-auroracluster-1u1ogdfg35v.cluster-cqiw4tcs0mg7.us-west-2.rds.amazonaws.com」のみを使用します。

API バージョン 2016-01-0144





ユーザー名 auradmin と入力します。


AWS SCT は HR スキーマを分析し、Amazon Aurora MySQL への変換に関するデータベース移行評価レポートを作成します。

5. [OK] を選択してアラートボックスを閉じ、[OK] を選択してダイアログボックスを閉じて、AmazonAurora MySQL DB インスタンスへの接続を開始します。

6. HR スキーマを右クリックし、[Create Report] を選択します。

API バージョン 2016-01-0145



7. レポートと提案されたアクション項目を確認します。レポートには、AWS SCT を使用して変換できるオブジェクトのタイプ、移行に伴って発生する可能性がある問題、これらの問題の解決策についての説明があります。このチュートリアルでは、次のように表示されます。

API バージョン 2016-01-0146



後で分析するためにオプションで、レポートを .csv または .pdf 形式で保存できます。8. 「Action Items (アクション項目)」タブを選択し、表示されている推奨事項を確認します。9. HR スキーマを右クリックし、[スキーマの変換] を選択します。

10. 確認メッセージで、[Yes] を選択します。AWS SCT でスキーマがターゲットデータベース形式に変換されます。

API バージョン 2016-01-0147



11. 次に示すように、HR スキーマを選択し、[Apply to database (データベースに適用)] を選択してスキーマスクリプトをターゲットの Aurora MySQL インスタンスに適用します。

12. 次に示すように HR スキーマを選択し、[Refresh from Database] を選択してターゲットデータベースから更新します。

API バージョン 2016-01-0148


ステップ 6: スキーマ変換を検証する

データベーススキーマが変換されてソースからターゲットへインポートされます。

ステップ 6: スキーマ変換を検証するスキーマ変換を検証するには、Oracle データベースと Aurora MySQL データベースで見つかったオブジェクトを SQL Workbench/J で比較します。

SQL Workbench/J を使用してスキーマ変換を検証するには

1. SQL Workbench/J で、[File] を選択し、[Connect window] を選択します。前のステップで作成したRDSAuroraConnection を選択します。[OK] をクリックします。

2. 次のスクリプトを実行して、ターゲットの Aurora MySQL データベースの HR スキーマのオブジェクトタイプと数を確認します。これらの値は、ソースの Oracle データベースのオブジェクト数と一致する必要があります。

SELECT a.OBJECT_TYPE, COUNT(*)FROM(SELECT OBJECT_TYPE,OBJECT_SCHEMA,OBJECT_NAMEFROM (SELECT 'TABLE' AS OBJECT_TYPE,TABLE_NAME AS OBJECT_NAME

API バージョン 2016-01-0149



,TABLE_SCHEMA AS OBJECT_SCHEMAFROM information_schema.TABLESwhere TABLE_TYPE='BASE TABLE'UNIONSELECT 'VIEW' AS OBJECT_TYPE,TABLE_NAME AS OBJECT_NAME,TABLE_SCHEMA AS OBJECT_SCHEMAFROM information_schema.VIEWSUNION

SELECT 'INDEX' AS OBJECT_TYPE,CONCAT (CONSTRAINT_TYPE,' : ',CONSTRAINT_NAME,' : ',TABLE_NAME) AS OBJECT_NAME,TABLE_SCHEMA AS OBJECT_SCHEMAFROM information_schema.TABLE_CONSTRAINTSwhere constraint_type='PRIMARY KEY'UNIONSELECT ROUTINE_TYPE AS OBJECT_TYPE,ROUTINE_NAME AS OBJECT_NAME,ROUTINE_SCHEMA AS OBJECT_SCHEMAFROM information_schema.ROUTINESUNIONSELECT 'TRIGGER' AS OBJECT_TYPE,CONCAT (TRIGGER_NAME,' : ',EVENT_OBJECT_SCHEMA,' : ',EVENT_OBJECT_TABLE) AS OBJECT_NAME,TRIGGER_SCHEMA AS OBJECT_SCHEMAFROM information_schema.triggers) RWHERE R.OBJECT_SCHEMA ='HR'order by 1) a GROUP BY a.OBJECT_TYPE;

このクエリの出力は以下のようになります。

OBJECT_TYPE COUNT(*) INDEX 7 PROCEDURE 2 TABLE 7 TRIGGER 10 VIEW 1

次に、以下のクエリを実行してテーブル制約情報を取得します。

SELECT CONSTRAINT_TYPE,COUNT(*) FROM information_schema.TABLE_CONSTRAINTS where constraint_schema='HR' GROUP BY CONSTRAINT_TYPE;

API バージョン 2016-01-0150


ステップ 7: AWS DMS レプリケーションのインスタンスを作成する

このクエリの出力は以下のようになります。

CONSTRAINT_TYPE COUNT(*) FOREIGN KEY 10PRIMARY KEY 7UNIQUE 7

ステップ 7: AWS DMS レプリケーションのインスタンスを作成するこれまでに説明したように、ソースとターゲットのデータベース間のスキーマ構造を検証したら、次のステップとして、このチュートリアルの核心であるデータ移行に進みます。次の図は、移行プロセスの概要を示しています。

DMS レプリケーションインスタンスは、ソースとターゲットの間で実際のデータ移行を行います。また、レプリケーションインスタンスは移行中にトランザクションログもキャッシュします。レプリケーションインスタンスで使用できる CPU およびメモリ容量に応じて、移行全体の所要時間が変わります。


1. AWS マネジメントコンソールにサインインし、https://console.aws.amazon.com/ dms/ で AWS DMSを選択して、[Create Migration (移行の作成)] を選択します。AWS Identity and Access Management(IAM) ユーザーとしてサインインしている場合、AWS DMS にアクセスするための適切なアクセス許可が必要です。必要なアクセス許可の詳細については、「AWS DMS を使用するのに必要な IAM アクセス許可」を参照してください。

2. [Next] を選択して、コンソールの [Welcome] ページからデータベースの移行を開始します。3. [Create replication instance] ページで、次に示すようにレプリケーションのインスタンス情報を指定

します。


名前 DMSdemo-repserver と入力します。

説明 DMS demo replication server などの簡単な説明を入力します。

インスタンスクラス [dms.t2.medium] を選択します。このインスタンスクラスでは小さいテーブルのセットを十分に移行できます。

VPC DMSDemoVPC を選択します。これは、CloudFormation スタックによって作成された VPC です。

API バージョン 2016-01-0151





ステップ 8: AWS DMS のソースとターゲットのエンドポイントを作成する


マルチ AZ No を選択します。

パブリックアクセス可能この項目は選択したままにします。

4. [Advanced] セクションで、デフォルト設定のままにして、[Next] を選択します。

ステップ 8: AWS DMS のソースとターゲットのエンドポイントを作成するレプリケーションインスタンスの作成時に、AWS マネジメントコンソールを使用してソースとターゲットのエンドポイントを指定できます。ただし、接続をテストできるのはレプリケーションインスタンスの作成後に限ります (接続にレプリケーションインスタンスが使用されるため)。


1. ソース Oracle データベースとターゲット Amazon Aurora MySQL データベースの接続情報を指定します。次の表はソース設定の説明です。


エンドポイント識別子 Orasource (Amazon RDS Oracle エンドポイント) と入力します。


サーバー名 Oracle DB インスタンス名を入力します。これは、「do1xa4grferti8y.cqiw4tcs0mg7.us-west-2.rds.amazonaws.com」など、AWS SCT に使用した[Server name] です。

ポート 1521 と入力します。

SSL モード [None] を選択します。


パスワード Oracle DB インスタンスのパスワードを入力します。

SID Oracle データベースの名前を入力します。

次の表はターゲット設定の説明です。


エンドポイント識別子 Aurtarget (Amazon Aurora MySQL エンドポイント) と入力します。


Servername Aurora MySQL DB インスタンス名を指定します。これは、「dmsdemo-auroracluster-1u1oyqny35jwv.cluster-

API バージョン 2016-01-0152



パラメータ操作cqiw4tcs0mg7.us-west-2.rds.amazonaws.com」など、AWS SCT に使用した [Server name] です。



[Username] auradmin と入力します。

パスワード Aurora MySQL DB インスタンスのパスワードを入力します。

完了したページは次のようになります。

2. 初期データロード中に外部キーチェックを無効にするには、次のコマンドをターゲットの AuroraMySQL DB インスタンスに追加する必要があります。次に示す [Advanced (詳細)] セクションで、

API バージョン 2016-01-0153


ステップ 9: AWS DMS 移行タスクの作成と実行

[Extra connection attributes (追加の接続属性)] に次のコマンドを入力します。initstmt=SETFOREIGN_KEY_CHECKS=0;autocommit=1

最初のコマンドはロード中に外部キーチェックを無効にし、2 番目のコマンドは DMS が実行するトランザクションをコミットします。

3. [Next (次へ)] を選択します。

ステップ 9: AWS DMS 移行タスクの作成と実行AWS DMS タスクを使用して、移行するスキーマと、移行のタイプを指定できます。既存のデータを移行するか、既存のデータを移行して継続的な変更をレプリケートするか、またはデータ変更のみをレプリケートするかを選択できます。このチュートリアルでは、既存のデータのみを移行します。


1. [Create Task] ページで、タスクオプションを指定します。次の表で設定について説明します。


タスク名 migratehrschema と入力します。


API バージョン 2016-01-0154




ソースエンドポイント orasource (Amazon RDS Oracle エンドポイント) を表示します。

ターゲットエンドポイント aurtarget (Amazon Aurora MySQL エンドポイント) を表示します。

レプリケーションインスタンス DMSdemo-repserver (以前のステップで作成した AWSDMS レプリケーションインスタンス) を表示します。

移行タイプ [Migrate existing data] オプションを選択します。

作成時にタスクを開始このオプションを選択します。

このページは次のようになります。

2. [Task Settings] で、[ターゲットテーブル作成モード] の [何もしない] を選択します。これは、既にスキーマ変換ツールを介してテーブルを作成したためです。この移行には LOB が含まれていないため、LOB 設定はデフォルトのままにしておくことができます。

API バージョン 2016-01-0155



オプションとして [ログの有効化] を選択できます。ログ記録を有効にした場合、CloudWatch ログの作成に、Amazon CloudWatch の追加料金が発生します。このウォークスルーでは、ログは必要ありません。

3. 詳細設定はデフォルト値のままにしておきます。4. [Table mappings (テーブルマッピング)]、[Mapping method (マッピング方法)] の [Default (デフォル

ト)]、[Schema to migrate (移行対象のスキーマ)] の [HR] の順に選択します。

完了したセクションは次のようになります。

API バージョン 2016-01-0156


ステップ 10: データ移行が正常に完了したことを検証する

5. [タスクの作成] を選択します。タスクは直ちに開始されます。

[Tasks] セクションでは、移行タスクのステータスが表示されます。

タスクの設定時に [Enable logging] を選択すると、タスクをモニタリングできます。次に、以下の操作を行って CloudWatch メトリクスを表示できます。

進行中のデータ移行タスクをモニタリングするには

1. ナビゲーションペインで、[Tasks] を選択します。2. 移行タスク (migratehrschema) を選択します。3. [Task monitoring] タブを選択し、そのタブで進行中のタスクをモニタリングします。

ステップ 10: データ移行が正常に完了したことを検証する移行タスクの完了後に、タスクの結果と予測結果を比較できます。

移行タスクの結果と予測結果を比較するには

1. ナビゲーションペインで、[Tasks] を選択します。2. 移行タスク (migratehrschema) を選択します。

API バージョン 2016-01-0157



3. 次に示すように、[Table statistics] タブを選択します。

4. SQL Workbench/J を使用して Amazon Aurora MySQL インスタンスに接続し、次に示すように SQLスクリプトを実行して、データベーステーブルが Oracle から Aurora MySQL に正常に移行されたかどうかを確認します。

SELECT TABLE_NAME,TABLE_ROWS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'HR' and TABLE_TYPE='BASE TABLE' order by 1;

API バージョン 2016-01-0158


ステップ 11: チュートリアルのリソースを削除する

5. 次のクエリを実行してテーブルの関係を確認します。このクエリでは従業員数が 10 人より多い部門を確認します。

SELECT B.DEPARTMENT_NAME,COUNT(*) FROM HR.EMPLOYEES A,HR.DEPARTMENTS B WHERE A.DEPARTMENT_ID=B.DEPARTMENT_ID GROUP BY B.DEPARTMENT_NAME HAVING COUNT(*) > 10 ORDER BY 1;

このクエリの出力は次のようになります。

department_name count(*)Sales 34Shipping 45

これで、Amazon RDS Oracle DB インスタンスから Amazon Aurora MySQL へのデータベース移行が正常に完了しました。

ステップ 11: チュートリアルのリソースを削除するこのチュートリアルを完了したら、チュートリアルで使用した AWS リソースに対する課金を避けるために、以下の手順を実行します。必ず手順どおりに実行してください。そうしないと、リソース間に依存関係がある場合に、一部のリソースが削除されません。

AWS DMS リソースを削除するには

1. ナビゲーションペインで、[Tasks (タスク)]、移行タスク (migratehrschema)、[Delete (削除)] の順に選択します。

2. ナビゲーションペインで、[Endpoints (エンドポイント)]、Oracle のソースエンドポイント(orasource)、[Delete (削除)] の順に選択します。

API バージョン 2016-01-0159


次のステップ

3. Amazon Aurora MySQL ターゲットエンドポイント (aurtarget) を選択してから、[Delete (削除)] を選択します。

4. ナビゲーションペインで、[Replication instances (レプリケーションインスタンス)]、レプリケーションインスタンス (DMSdemo-repserver)、[Delete (削除)] の順に選択します。

次に、AWS CloudFormation スタック DMSdemo を削除する必要があります。

AWS CloudFormation スタックを削除するには


AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合、AWSCloudFormation にアクセスするための適切なアクセス許可が必要であることに注意してください。

2. CloudFormation スタック、DMSdemo を選択します。3. [Actions] の [Delete stack] を選択します。

DMSdemo スタックに関連付けられたリソースが AWS CloudFormation によってクリーンアップされている間は、スタックのステータスが [DELETE_IN_PROGRESS] に変わります。AWS CloudFormation でリソースのクリーンアップが終了すると、スタックがリストから削除されます。

次のステップこのチュートリアルでは取り上げていませんが、AWS DMS の以下のような機能も試すことができます。

• AWS DMS の変更データのキャプチャ (CDC) 機能。データの継続的なレプリケーションに役立ちます。• 変換アクション。移行プロセスの一環として、選択されたスキーマやテーブルに変換を指定して適用で

きます。

詳細については、AWS DMS のドキュメントを参照してください。

API バージョン 2016-01-0160




前提条件

SQL Server データベースの AmazonAurora MySQL への移行

このウォークスルーでは、Microsoft SQL Server データベースを AWS Schema Conversion Tool (AWSSCT) および AWS Database Migration Service (AWS DMS) を使用して MySQL と互換性がある AmazonAurora に移行する方法について説明します。AWS DMS は、データを SQL Server ソースから AuroraMySQL ターゲットに移行します。

AWS DMS は、セカンダリインデックス、シーケンス、デフォルト値、ストアドプロシージャ、トリガー、シノニム、ビューなど、データ移行に特に関係ないスキーマオブジェクトは移行しません。これらのオブジェクトを Aurora MySQL のターゲットに移行するには、AWS SCT を使用します。

トピック• 前提条件 (p. 61)• ステップバイステップ移行 (p. 62)• トラブルシューティング (p. 83)

前提条件このチュートリアルを実施する前提条件として以下が必要です。

• Amazon Relational Database Service (Amazon RDS)、該当するデータベーステクノロジー、およびSQL について理解します。

• AWS Identity and Access Management (IAM) 認証情報を使用して AWS アカウントを作成します。この認証情報で、AWS リージョンでの Amazon RDS および AWS Database Migration Service (AWS DMS)インスタンスの起動が許可されます。IAM 認証情報の詳細については、「IAM ユーザーの作成」を参照してください。

• Amazon Virtual Private Cloud (Amazon VPC) サービスとセキュリティグループについて理解します。Amazon VPC と Amazon RDS の使用に関する詳細は、「Amazon Virtual Private Cloud (VPC) および Amazon RDS」を参照してください。Amazon RDS セキュリティグループの詳細については、「Amazon RDS セキュリティグループ」を参照してください。

• AWS DMS でサポートされている機能と制限について理解する。AWS DMS に関する詳細については、「AWS Database Migration Service とは」を参照してください。

• Microsoft SQL Server をソースとし、Amazon Aurora MySQL をターゲットとして使用する方法について理解します。ソースとしての SQL Server の使用の詳細については、「AWS Database MigrationService のソースとして SQL Server データベースを使用する」を参照してください。Aurora MySQL はMySQL と互換性があるデータベースです。ターゲットとしての Aurora MySQL の使用の詳細については、「AWS Database Migration Service のターゲットとして MySQL 互換データベースを使用する」を参照してください。

• SQL Server と Aurora MySQL でサポートされているデータ型変換オプションについて理解します。ソースとしての SQL Server のデータ型の詳細については、「Microsoft SQL Server のソースデータ型」を参照してください。ターゲットとしての Aurora MySQL のデータ型の詳細については、「MySQL のターゲットデータ型」を参照してください。

• ターゲットの Aurora MySQL データベースホストのサイズを指定します。DBA は、現在のソースのSQL Server データベースホストのロードプロファイルに注意する必要があります。CPU、メモリ、およ

API バージョン 2016-01-0161






https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.SQLServer.html

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.SQLServer.html


https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Reference.Source.SQLServer.DataTypes.html

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Reference.Target.MySQL.DataTypes.html

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Reference.Target.MySQL.DataTypes.html



び IOPS を考慮します。Amazon RDS では、移行後にターゲットデータベースホストのサイズを拡大または縮小できます。Aurora MySQL に移行するのが初めての場合は、パフォーマンスの問題とチューニングの機会のため、余分な処理能力を残しておくことをお勧めします。

• ソース SQL Server データベースを監査します。各スキーマと各スキーマのすべてのオブジェクトについて、使用されなくなったオブジェクトがないかどうか判断します。使用されていない場合は移行する必要はないため、ソース SQL Server データベースでそれらのオブジェクトを廃止します。

• 既存のデータを移行するのみか、既存のデータを移行して継続的な変更をレプリケートするか決定します。• 既存のデータのみを移行する場合、移行は SQL Server ソースデータベースから Aurora MySQL ター

ゲットデータベースへの 1 回のみのデータ移行です。移行中にソースデータベースが変更に対して開かれたままになる場合、これらの変更は移行の完了後にターゲットデータベースに適用される必要があります。

Note

SQL Server データベースが Amazon RDS データベースの場合、レプリケーションはサポートされず、既存のデータのみを移行するオプションを使用する必要があります。

• 既存のデータを移行し、継続的な変更をレプリケートする場合、1 つのオプションとしてソースデータベースの変更をレプリケートします。レプリケーションにより、移行プロセス中にソースデータベースとターゲットデータベースの同期を保ち、データベースのダウンタイムを減らすことができます。このオプションでは、初期の同期オペレーションを完了してから、MS-REPLICATION を設定します。このオプションでは、Standard、Enterprise、または Developer SQL Server エディションが必要です。データベースソースとして使用する各 SQL Server インスタンスで MS-REPLICATION を有効にします。

• 既存のデータを移行し、継続的な変更をレプリケートする場合は、別のオプションとして、レプリケーションの代わりに変更データキャプチャ (CDC) があります。このオプションにより、AWS DMSはデータの継続的な移行を実行できます。CDC の場合、AWS DMS は CDC テーブルを使用して継続的なデータベースの移行を可能にします。このオプションでは、SQL Server の Enterprise またはDeveloper エディションが必要です。

AWS DMS の詳細については、『AWS DMS ユーザーガイド』を参照してください。

ステップバイステップ移行次のステップでは、Microsoft SQL Server データベースを Amazon Aurora MySQL データベースに移行するための手順を示します。各ステップでは、「前提条件 (p. 61)」の説明に従ってソースデータベースが準備済みであることを前提とします。

トピック• ステップ 1: SQL ドライバーと AWS スキーマ変換ツールをローカルコンピュータにインストールす

る (p. 63)• ステップ 2: Microsoft SQL Server ソースデータベースを設定する (p. 63)• ステップ 3: Aurora MySQL ターゲットデータベースの設定 (p. 65)• ステップ 4: AWS SCT を使用して SQL Server スキーマを Aurora MySQL に変換する (p. 65)• ステップ 5: AWS DMS レプリケーションインスタンスを作成する (p. 73)• ステップ 6: AWS DMS のソースとターゲットのエンドポイントを作成する (p. 75)• ステップ 7: AWS DMS 移行タスクの作成と実行 (p. 79)• ステップ 8: Aurora MySQL へのカットオーバー (p. 82)

API バージョン 2016-01-0162



ステップ 1: SQL ドライバーと AWS スキーマ変換ツールをローカルコンピュータにインストールする

ステップ 1: SQL ドライバーと AWS スキーマ変換ツールをローカルコンピュータにインストールする最初に、SQL ドライバーおよび AWS Schema Conversion Tool (AWS SCT) をローカルコンピュータにインストールします。


1. Microsoft SQL Server 用の JDBC ドライバーをダウンロードします。2. Aurora MySQL 用の JDBC ドライバーをダウンロードします。Amazon Aurora MySQL では MySQL

ドライバーが使用されます。3. AWS SCT と必要な JDBC ドライバーをインストールします。

a. 『AWS スキーマ変換ツールユーザーガイド』の「AWS スキーマ変換ツールのインストールと更新」を参照し、適切なリンクを選択して、AWS SCT をダウンロードします。

b. AWS SCT を起動し、[Settings (設定)]、[Global Settings (グローバル設定)] の順に選択します。c. [Global Settings] で、[Drivers] を選択し、[Microsoft Sql Server Driver Path] の [Browse] を選択し

ます。SQL Server の JDBC ドライバーを見つけ、[OK] を選択します。d. [MySql Driver Path] の [Browse] を選択します。Aurora MySQL 用にダウンロードした JDBC ドラ

イバーを見つけ、[OK] を選択します。

e. [OK] を選択し、[Global Settings] ダイアログボックスを閉じます。

ステップ 2: Microsoft SQL Server ソースデータベースを設定するSQL ドライバーと AWS Schema Conversion Tool をインストールした後、データを移行する計画に基づいて、複数のオプションのいずれかを使用して Microsoft SQL Server ソースデータベースを設定できます。

API バージョン 2016-01-0163

https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11774





ステップ 2: Microsoft SQL Serverソースデータベースを設定する

SQL Server ソースデータベースを設定するには

• ソースデータベースを設定するときは、既存のデータを移行するのみ、既存のデータを移行して継続的な変更をレプリケートする、または既存のデータを移行し変更データキャプチャ (CDC) を使用して継続的な変更をレプリケートする選択ができます。前提条件の詳細については、「前提条件」を参照してください。

• 既存のデータの移行のみ

SQL Server データベースに対して必要な設定ステップはありません。「ステップ 3: Aurora MySQLターゲットデータベースの設定 (p. 65)」に進むことができます。

Note

SQL Server データベースが Amazon RDS データベースの場合、レプリケーションはサポートされず、既存のデータのみを移行するオプションを使用する必要があります。

• 既存データの移行と進行中の変更のレプリケート

Note

レプリケーションでは、レプリケート中のすべてのテーブルにプライマリキーが必要です。テーブルにプライマリキーが定義されていない場合は、代わりに CDC の使用を検討してください。

MS-REPLICATION を設定するには、以下のステップを完了します。

1. Microsoft SQL Server Management Studio で、[Replication] フォルダーのコンテキスト (右クリック) メニューを開き、[Configure Distribution] を選択します。

2. [Distributor] ステップで、[db_name will act as its own distributor] を選択します。SQL Server により、ディストリビューションデータベースとログが作成されます。

詳細については、Microsoft のドキュメントを参照してください。

設定が完了すると、サーバーでレプリケーションが有効になります。ディストリビューションデータベースが配置されたか、リモートディストリビューションデータベースを使用するようにサーバーを設定しました。

• 既存のデータの移行と、変更データキャプチャ (CDC) を使用した継続的な変更のレプリケート

MS-CDC を設定するには、以下のステップを完了します。

1. SYSADMIN ロールメンバーシップを持つログインを使用して SQL Server に接続します。2. 移行中のデータを含む各データベースで、データベースコンテキスト内で次のコマンドを実行

します。

use [DBname]EXEC sys.sp_cdc_enable_db

3. 継続的な移行を設定する各テーブルで、次のコマンドを実行します。

EXEC sys.sp_cdc_enable_table @source_schema = N'schema_name', @source_name = N'table_name', @role_name = NULL;

詳細については、Microsoft のドキュメントを参照してください。API バージョン 2016-01-01

64

CHAP_SQLServer2Aurora.Prerequisites.html

https://docs.microsoft.com/en-us/sql/relational-databases/replication/enable-a-database-for-replication-sql-server-management-studio

https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/enable-and-disable-change-data-capture-sql-server


ステップ 3: Aurora MySQL ターゲットデータベースの設定

Note

• AlwaysOn 可用性グループに参加するデータベースを移行する場合、移行にレプリケーションを使用するのがベストプラクティスです。このオプションを使用するには、公開を有効にし、ディストリビューションデータベースを AlwaysOn 可用性グループの各ノードに設定する必要があります。さらに、ターゲットサーバー名には、現在可用性グループデータベースをホストしているサーバーの名前ではなく、データベースの可用性グループリスナーの名前を使用します。これらの要件は、クラスター内の SQL Server の各インスタンスに適用され、可用性グループリスナーを使用して設定することはできません。

• データベースが MS-REPLICATION または MS-CDC に対してサポートされていない場合 (たとえば、SQL Server の Workgroup Edition を実行しているなど)、いくつかの変更 (INSERT および DELETE ステートメントなど) をキャプチャできますが、UPDATE や TRUNCATE TABLE などのその他の DML ステートメントはキャプチャされません。したがって、この設定では継続的なデータレプリケーションを使用した移行は推奨されず、静的な 1 回の移行 (または 1 回の完全移行の繰り返し) を検討する必要があります。

MS-REPLICATION および MS-CDC の使用の詳細については、「Microsoft SQL Server データベースのAWS Database Migration Service のレプリケーションソースとしての設定」を参照してください。

ステップ 3: Aurora MySQL ターゲットデータベースの設定AWS DMS は SQL Server ソースから Amazon Aurora MySQL ターゲットにデータを移行します。このステップでは、Aurora MySQL ターゲットデータベースを設定します。

1. AWS DMS ユーザーを作成してターゲットデータベースに接続し、Superuser または必要な個別の権限を付与します (あるいは、Amazon RDS では、マスターユーザー名を使用します)。

または、既存のユーザーに権限を付与できます。

CREATE USER 'aurora_dms_user' IDENTIFIED BY 'password';

GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT ON target_database.* TO 'aurora_dms_user';

2. AWS DMS では、データベース awsdms_control でターゲットのコントロールテーブルを使用します。次のコマンドを使用して、awsdms_control データベースのアクセスに必要な権限をユーザーに付与します。

GRANT ALL PRIVILEGES ON awsdms_control.* TO 'aurora_dms_user';FLUSH PRIVILEGES;

ステップ 4: AWS SCT を使用して SQL Server スキーマを Aurora MySQL に変換するデータを Amazon Aurora MySQL に移行する前に、AWS Schema Conversion Tool (AWS SCT) を使用して Microsoft SQL Server スキーマを Aurora MySQL スキーマに変換します。

API バージョン 2016-01-0165

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.SQLServer.html#CHAP_Source.SQLServer.Configuration

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.SQLServer.html#CHAP_Source.SQLServer.Configuration


ステップ 4: AWS SCT を使用して SQLServer スキーマを Aurora MySQL に変換する

SQL Server スキーマを Aurora MySQL スキーマに変換するには

1. AWS SCT で、[File (ファイル)]、[New Project (新規プロジェクト)] の順に選択します。AWS SchemaConversion Tool SQL Server to Aurora MySQL という新しいプロジェクトを作成します。

2. [New Project] ウィンドウに以下の情報を入力し、[OK] を選択します。

パラメータ説明

プロジェクト名 AWS Schema Conversion Tool SQL Server toAurora MySQL と入力します。


Source Database Engine [Microsoft SQL Server] を選択します。

Target Database Engine [Amazon Aurora (MySQL compatible)] を選択します。

3. [Connect to Microsoft SQL Server] を選択します。[Connect to Microsoft SQL Server] ダイアログボックスに次の情報を入力して、[Test Connection] を選択します。


サーバー名サーバー名を入力します。

Server port SQL Server のポート番号を入力します。デフォルト:1433。

Instance name SQL Server データベースのインスタンス名を入力します。

API バージョン 2016-01-0166




ユーザー名 SQL Server の管理者ユーザーの名前を入力します。

パスワード管理者ユーザーのパスワードを入力します。

4. [OK] を選択してアラートボックスを閉じます。次に、[OK] を選択してダイアログボックスを閉じ、SQL Server DB インスタンスへの接続を開始します。SQL Server DB インスタンス上のデータベース構造が表示されます。

5. [Connect to Amazon Aurora (MySQL compatible)] を選択します。[Connect to Amazon Aurora (MySQLcompatible)] ダイアログボックスに次の情報を入力して、[Test Connection] を選択します。



Server port SQL Server のポート番号を入力します。デフォルト:3306。

ユーザー名 Aurora MySQL の管理者ユーザーの名前を入力します。


API バージョン 2016-01-0167



6. [OK] を選択してアラートボックスを閉じます。次に、[OK] を選択してダイアログボックスを閉じ、Aurora MySQL DB インスタンスへの接続を開始します。

7. 移行するスキーマのコンテキスト (右クリック) メニューを開き、[Convert schema] を選択します。

API バージョン 2016-01-0168



8. 確認メッセージで、[Yes] を選択します。AWS SCT により、スキーマがターゲットデータベース形式に変換されます。

API バージョン 2016-01-0169



AWS SCT はスキーマを分析して、Aurora MySQL への変換に関するデータベース移行評価レポートを作成します。

9. [View] から [Assessment Report View] を選択し、レポートを確認します。

このレポートは、各オブジェクトタイプ別の情報と、正しい変換に必要な手動の変更の量を示しています。

API バージョン 2016-01-0170



一般的に、パッケージ、手順、および関数で、解決が必要な問題が多く発生します。これは、最もカスタムな PL/SQL コードが含まれているためです。AWS SCT は、これらのオブジェクトの修正方法に関するヒントも提供します。

10. [Action Items] タブを選択します。

[Action Items] タブには、オブジェクトごとに注意が必要な問題が表示されます。

変換の問題ごとに、次のいずれかのアクションを完了できます。• ソースの SQL Server データベースのオブジェクトを変更して、AWS SCT がそれらのオブジェク

トをターゲットの Aurora MySQL データベースに変換できるようにします。

1. ソース SQL Server データベースでオブジェクトを変更します。2. 前のステップを繰り返してスキーマを変換し、評価レポートを確認します。3. 必要に応じて、変換の問題がなくなるまでこのプロセスを繰り返します。

API バージョン 2016-01-0171



4. [View] の [Main View] を選択します。ターゲット Aurora MySQL スキーマのコンテキスト (右クリック) メニューを開き、[Apply to database (データベースに適用)] を選択してスキーマの変更を Aurora MySQL データベースに適用し、スキーマの変更を適用することを確認します。

• ソーススキーマを変更する代わりに、AWS SCT によって生成されたスクリプトを変更してから、そのスクリプトをターゲットの Aurora MySQL データベースに適用します。

1. [View] の [Main View] を選択します。ターゲットの Aurora MySQL スキーマ名のコンテキストメニューを開き (右クリック)、[Save as SQL (SQL として保存)] を選択します。次に、スクリプトの名前と保存先を選択します。

2. スクリプトで、変換の問題を修正するオブジェクトを変更します。

外部キーの制約、トリガー、およびセカンダリインデックスをスクリプトから除外することもできます。これらによって、移行中に問題が発生する可能性があるためです。移行が完了したら、Aurora MySQL データベースでこれらのオブジェクトを作成できます。

3. ターゲットの Aurora MySQL データベースでスクリプトを実行します。

詳細については、『AWS Schema Conversion Tool ユーザーガイド』の「AWS Schema ConversionTool を使用した Amazon RDS へのデータベーススキーマの変換」を参照してください。

11. (オプション) AWS SCT を使用してマッピングルールを作成します。

API バージョン 2016-01-0172

https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.Converting.html



ステップ 5: AWS DMS レプリケーションインスタンスを作成する

a. [Settings] の [Mapping Rules] を選択します。b. アクション項目に基づいて、必要な追加のマッピングルールを作成します。c. マッピングルールを保存します。d. [Export script for DMS (DMS にスクリプトをエクスポート)] を選択して、AWS DMS タスクが使

用するすべての変換の JSON 形式をエクスポートします。[Save] を選択します。

ステップ 5: AWS DMS レプリケーションインスタンスを作成するソースおよびターゲットデータベース間のスキーマ構造を検証したら、このチュートリアルの核心であるデータ移行に進みます。次の図は、移行プロセスの概要を示しています。

AWS DMS レプリケーションインスタンスは、ソースとターゲットの間で実際のデータ移行を行います。また、レプリケーションインスタンスは移行中にトランザクションログもキャッシュします。レプリケーションインスタンスで使用できる CPU およびメモリ容量に応じて、移行全体の所要時間が変わります。

AWS DMS を使用するためのベストプラクティスについては、「AWS Database Migration Service のベストプラクティス」を参照してください。


1. AWS マネジメントコンソールにサインインし、https://console.aws.amazon.com/dms/ で AWS DMSコンソールを開きます。

2. コンソールで、[Create migration] を選択します。AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合は、AWS DMS にアクセスするための適切なアクセス許可が必要です。必要なアクセス許可の詳細については、「AWS DMS を使用するのに必要な IAM アクセス許可」を参照してください。

3. Welcome ページで、[Next] を選択してデータベースの移行を開始します。4. [Create replication instance] ページで、レプリケーションのインスタンス情報を指定します。


名前レプリケーションインスタンスの名前を選択します。複数のレプリケーションサーバーを使用するか、アカウントを共有する場合、異なるサーバーをすばやく区別できるような名前を選択します。

説明短い説明を入力します。

インスタンスクラス作成するレプリケーションサーバーのタイプを選択します。インスタンスクラスの各サイズとタイプでは、CPU、メモリ、I/O キャパシティーが増えます。一般的に、低負

API バージョン 2016-01-0173

https://d0.awsstatic.com/whitepapers/RDS/AWS_Database_Migration_Service_Best_Practices.pdf

https://d0.awsstatic.com/whitepapers/RDS/AWS_Database_Migration_Service_Best_Practices.pdf






パラメータ説明荷のタスクには t2 インスタンスを使用し、高負荷で数が多いタスクには c4 インスタンスが適しています。

VPC レプリケーションインスタンスを起動する Virtual PrivateCloud (VPC) を選択します。可能であれば、ソースデータベースまたはターゲットデータベース (あるいはその両方)が存在しているのと同じ VPC を選択します。

マルチ AZ [Yes] を選択すると、プライマリレプリケーションサーバーに問題がある場合に、AWS DMS では、フェイルオーバーのため、別のアベイラビリティーゾーンで 2 番目のレプリケーションサーバーが作成されます。

パブリックアクセス可能ソースデータベースまたはターゲットデータベースのいずれかが、レプリケーションサーバーが存在している VPCの外部にある場合は、レプリケーションサーバーポリシーをパブリックアクセス可能にする必要があります。

5. [Advanced] セクションで、以下の情報を指定します。


Allocated storage (GB) 履歴のタスクログを含む、AWS DMS タスクログ用のレプリケーションサーバー上のストレージの量。また、AWSDMS は、ディスクストレージを使用して、ソースデータベースからターゲットにレプリケートする間に特定のデータをキャッシュします。さらに、通常はストレージが増えれば、サーバー上の IOPS も向上します。

レプリケーションサブネットグループマルチ AZ 設定で実行している場合は、少なくとも 2 つのサブネットグループが必要です。

アベイラビリティーゾーン通常、プライマリレプリケーションサーバーをターゲットデータベースと同じアベイラビリティーゾーンに配置した場合にパフォーマンスが向上します。

VPC セキュリティグループセキュリティグループを使用すると、VPC への出入りを制御できます。AWS DMS は、レプリケーションサーバーが起動される VPC に 1 つ以上のセキュリティグループを関連付けることができます。

KMS マスターキー AWS DMS では、すべてのデータが保管中に KMS 暗号化キーで暗号化されます。デフォルトでは、AWS DMS で、レプリケーションサーバー用に新しい暗号化キーが作成されます。ただし、既存のキーを使用することもできます。

KMS マスターキーの詳細については、「暗号化キーの設定と KMS のアクセス許可の指定」を参照してください。

6. [Next] をクリックします。

API バージョン 2016-01-0174

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Security.EncryptionKey.html



ステップ 6: AWS DMS のソースとターゲットのエンドポイントを作成するレプリケーションインスタンスの作成時に、AWS マネジメントコンソールを使用してソースとターゲットデータベースのエンドポイントを指定できます。ただし、接続をテストできるのはレプリケーションインスタンスの作成後に限ります (接続にレプリケーションインスタンスが使用されるため)。

コンソールを使用して、ソースまたはターゲットデータベースエンドポイントを指定するには

1. AWS DMS コンソールで、ソース SQL Server データベースとターゲット Aurora MySQL データベースの接続情報を指定します。次の表はソース設定の説明です。


エンドポイント識別子 SQLServerSource などの名前を入力します。

ソースエンジン [sqlserver] を選択します。

サーバー名 SQL Server DB インスタンスのサーバー名を入力します。

ポートデータベースのポート番号を入力します。SQL Server のデフォルト値は 1433 です。

SSL モード接続のトラフィック暗号化を有効にする場合は、SSL モードを選択します。

ユーザー名ソースデータソースに接続するために使用するユーザーの名前を入力します。

パスワードユーザーのパスワードを入力します。

データベース名 SQL Server データベースの名前を入力します。

次の表は詳細なソース設定の説明です。


追加の接続属性エンドポイントで設定して機能を追加したり、AWS DMSの動作を変更したりする追加のパラメータ。いくつかの関連性が高い属性を以下に示します。複数のエントリを区切るには、セミコロン (;) を使用します。

• safeguardpolicy - AWS DMS がログを読み取り中にトランザクションログが切り捨てられないようにするため、トランザクションを開いて SQL Server の動作を変更します。有効な値は、EXCLUSIVE_AUTOMATIC_TRUNCATION またはRELY_ON_SQL_SERVER_REPLICATION_AGENT (デフォルト) です。

• useBCPFullLoad - データの読み込みに BCP (一括コピー) を使用するように AWS DMS に指示します。有効な値は Y または N です。ターゲットテーブルに、ソーステーブル内に存在しない IDENTITY 列が含まれている場合、パラメータを N に設定してテーブルの読み込みでBCP の使用を無効にする必要があります。

API バージョン 2016-01-0175



パラメータ説明• BCPPacketSize - データの読み込みで BCP が有効に

なっている場合は、BCP によって使用される最大パケットサイズを入力します。有効な値は 1～100000 (デフォルトは 16384) です。

• controlTablesFileGroup - AWS DMS プロセスがデータベースで作成する統制テーブルに使用するファイルグループを指定します。

KMS マスターキーレプリケーションインスタンスのストレージを暗号化することを選択した場合は、KMS のマスターキーを入力します。



エンドポイント識別子 Auroratarget などの名前を入力します。


サーバー名プライマリインスタンスの Aurora MySQL DB サーバー名を入力します。

ポートデータベースのポート番号を入力します。Aurora MySQLのデフォルトは 3306 です。


ユーザー名ターゲットデータソースに接続するために使用するユーザーの名前を入力します。


次の表は詳細なターゲット設定の説明です。

API バージョン 2016-01-0176




追加の接続属性エンドポイントで設定して機能を追加したり、AWS DMSの動作を変更したりする追加のパラメータ。いくつかの関連性が高い属性を以下に示します。複数のエントリを区切るには、セミコロンを使用します。

• targetDbType - デフォルトでは、AWS DMS で移行するスキーマごとにデータベースが作成されます。いくつかのスキーマを結合して 1 つのデータベースを構成する場合は、このオプションをtargetDbType=SPECIFIC_DATABASE に設定します。

• initstmt - このオプションを使用して、MySQLinitstmt 接続パラメータを呼び出し、MySQLinitstmt で受け入れるすべてのものを受け入れます。Aurora MySQL ターゲットの場合、このオプションを initstmt=SET FOREIGN_KEY_CHECKS=0 に設定して外部キーのチェックを無効にすると便利です。


以下は完了したページの例です。

API バージョン 2016-01-0177



追加の接続属性の詳細については、「AWS Database Migration Service での追加の接続属性の使用」を参照してください。

2. エンドポイントおよびレプリケーションインスタンスが作成された後、ソースおよびターゲットエンドポイントに対して [Run test] を選択して、エンドポイント接続をテストします。

3. 外部キーの制約とトリガーをターゲットデータベースにドロップします。

全ロードプロセス中に、AWS DMS は特定の順序でデータをロードしないため、親テーブルデータより前に子テーブルデータをロードする場合があります。その結果、外部キーの制約が有効になっている場合、それらの制約に違反する可能性があります。また、ターゲットデータベースにトリガーが存在する場合は、AWS DMS によって予期しない方法でデータが変更される可能性があります。

ALTER TABLE 'table_name' DROP FOREIGN KEY 'fk_name'; DROP TRIGGER 'trigger_name';

4. 外部キーの制約とトリガーをターゲットデータベースで削除した場合は、外部キーの制約およびトリガーを有効にするスクリプトを生成します。

その後、移行されたデータベースに追加する場合、このスクリプトを実行できます。5. (オプション) ターゲットデータベースのセカンダリインデックスを削除します。

API バージョン 2016-01-0178

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introduction.ConnectionAttributes.html



(すべてのインデックスと同様に) セカンダリインデックスは、ロードプロセス中に保持および更新する必要があるため、テーブルへのデータの全ロード速度が低下する原因となる場合があります。セカンダリインデックスを削除することで、全ロードプロセスのパフォーマンスを向上させることができます。インデックスを削除する場合、全ロードの完了後に、再度追加する必要があります。

ALTER TABLE 'table_name' DROP INDEX 'index_name';


ステップ 7: AWS DMS 移行タスクの作成と実行AWS DMS タスクを使用して、移行するスキーマと、移行のタイプを指定できます。既存のデータを移行するか、既存のデータを移行して継続的な変更をレプリケートするか、またはデータ変更のみをレプリケートするかを選択できます。


1. AWS DMS コンソールの [Create task (タスクの作成)] ページで、タスクオプションを指定します。次の表で設定について説明します。


タスク名移行タスクの名前を入力します。


ソースエンドポイント SQL Server ソースエンドポイントを表示します。

アカウント内に複数のエンドポイントがある場合は、リストから正しいエンドポイントを選択します。

ターゲットエンドポイント Aurora MySQL のターゲットエンドポイントを表示します。

レプリケーションインスタンス AWS DMS レプリケーションインスタンスを表示します。

移行タイプオプションを選択します。

• [Migrate existing data (既存のデータを移行する)] - AWSDMS は既存のデータのみを移行します。ソースデータへの変更はキャプチャされず、ターゲットに適用されません。全ロード中に停止が発生しても支障ない場合は、これが最もシンプルなオプションです。このオプションを使用して、データベースのテストコピーを作成することもできます。ソース SQL Server データベースが Amazon RDS データベースである場合は、このオプションを選択する必要があります。

• [Migrate existing data and replicate ongoing changes (既存のデータを移行し、継続的な変更をレプリケートする)] - AWS DMS は、既存のデータの移行中に変更をキャプチャします。AWS DMS では、バルクデータのロード後でも変更のキャプチャと適用が行われます。最終的にソースデータベースとターゲットデータベースは同期され、ダウンタイムは最小限に抑えられます。

API バージョン 2016-01-0179



パラメータ説明• Replicate data changes only - 別の方法を使用してデー

タを一括ロードします。このアプローチは、通常、同種間の移行にのみ適用されます。

作成時にタスクを開始通常は、このオプションを選択します。ただし、ロギングのレベルを変更する目的などで、タスクの開始を遅らせる場合もあります。

このページは次の図のように表示されます。

2. [Task settings] で、設定を指定します。次の表で設定について説明します。


ターゲットテーブル作成モードオプションを選択します。

• [Do nothing (何もしない)] - AWS DMS ではテーブルの準備として何も実行されません。テーブルの構造は同じままで、既存のデータはテーブル内に残ります。この方法を使用して複数のシステムのデータを統合できます。

• [Drop tables on target (ターゲット上のテーブルを削除)]- AWS DMS により、ターゲットテーブルが作成されます。AWS DMS で移行対象のテーブルが移行前に削除され、再作成されます。AWS DMS で、異機種間の移行の場合のみ、テーブルとプライマリキーが作成されます。

• Truncate - AWS DMS でロード前にターゲットテーブルが切り捨てられます。ターゲットテーブルが存在しない場合は、AWS DMS で作成されます。

API バージョン 2016-01-0180




Important

既に AWS Schema Conversion Tool でターゲットにテーブルが作成された場合は、[Do nothing (何もしない)] または [Truncate (切り捨て)] を選択します。

レプリケーションに LOB 列を含めるオプションを選択します。

• Don't include LOB columns - LOB データを移行しません。

• 完全 LOB モード - サイズにかかわらず、AWS DMS によってすべての LOB (大きなオブジェクト) がソースからターゲットに移行されます。この設定では、AWSDMS の最大許容 LOB サイズに関する情報は不要です。したがって、LOB は一度に 1 つずつ移行されます。FullLOB mode は比較的低速になることがあります。

• 制限付き LOB モード - AWS DMS で許容される最大LOB サイズを設定します。このオプションでは、AWSDMS によってメモリが事前に割り当てられ、LOB データを一括でロードできるようになります。最大許容 LOBサイズを超える LOB は切り捨てられ、警告がログファイルに発行されます。limited LOB mode では、Full LOBmode よりも大幅にパフォーマンスが向上します。可能な限り Limited LOB mode を使用することをお勧めします。

最大 LOB サイズ (KB) [Limited LOB mode (制限付き LOB モード)] を選択すると、このオプションによって AWS DMS の最大許容 LOBサイズが決まります。この値よりも大きい LOB はこの値まで切り捨てられます。

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

3. 詳細設定はデフォルト値のままにしておきます。4. 「ステップ 4: AWS SCT を使用して SQL Server スキーマを Aurora MySQL に変換する (p. 65)」

の最後のステップで、AWS SCTを使用してマッピングルールを作成およびエクスポートした場合は、[Table mappings (テーブルマッピング)] を選択し、[JSON] タブを選択します。次に、[Enable JSONediting] を選択し、保存したテーブルマッピングを入力します。

マッピングルールを作成していない場合は、次のステップに進みます。5. [タスクの作成] を選択します。タスクがすぐに開始されます。


API バージョン 2016-01-0181


ステップ 8: Aurora MySQL へのカットオーバー

セットアップ中に [Enable logging] を選択すると、タスクをモニタリングできます。次に、AmazonCloudWatch メトリクスを表示できます。


1. ナビゲーションペインで、[Tasks] を選択します。2. 移行タスクを選択します。3. [Task monitoring] タブを選択し、そのタブで進行中のタスクをモニタリングします。

全ロードが完了しキャッシュされた変更が適用されると、タスクは自動的に停止します。4. ターゲット Aurora MySQL データベースで、外部キー制約とトリガーを無効にした場合は、前に保存

したスクリプトを使用してそれらを有効にします。5. ターゲット Aurora MySQL データベースで、以前に削除した場合はセカンダリインデックスを再作成

します。6. AWS DMS を使用して変更のレプリケートを選択した場合は、AWS DMS コンソールで、タスクの

[Start/Resume (開始/再開)] を選択して AWS DMS タスクを開始します。

モニタリングする重要なレプリケーションインスタンスメトリクスには、次のものがあります。

• CPU• FreeableMemory• DiskQueueDepth• CDCLatencySource• CDCLatencyTarget

AWS DMS タスクは、ソースデータベースの変更を使用して、ターゲット Aurora MySQL データベースを最新の状態に保ちます。AWS DMS は、アプリケーションの移行を実行する時までタスクのすべてのテーブルを最新の状態に保ちます。ターゲットがソースに追いつくと、レイテンシーはゼロまたはゼロに近くなります。

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

ステップ 8: Aurora MySQL へのカットオーバー次のステップを実行して、Microsoft SQL Server データベースから Amazon Aurora MySQL データベースに接続を移動します。

Aurora MySQL にカットオーバーするには

1. 実行中のスクリプトやクライアント接続など、すべての SQL Server データベースの依存関係とアクティビティを終了します。SQL Server エージェントサービスが停止されていることを確認します。

次のクエリは、接続以外の結果を返しません。

SELECT session_id, login_name from sys.dm_exec_sessions where session_id > 50;

API バージョン 2016-01-0182

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html


トラブルシューティング

2. 残りのセッション (自分のセッション以外) を強制終了します。

KILL session_id;

3. SQL Server サービスをシャットダウンします。4. AWS DMS タスクで、Amazon Aurora MySQL データベースの SQL Server データベースから最終的

な変更を適用します。5. AWS DMS コンソールで、AWS DMS タスクの [Stop (停止)] を選択し、タスクを停止することを確認

して、タスクを停止します。

トラブルシューティングMicrosoft SQL Server をソースデータベースとして、Amazon Aurora MySQL をターゲットデータベースとして使用する場合、2 つの最も一般的な問題領域は SQL Server の変更データキャプチャ (CDC) と外部キーです。

• MS-CDC: MS-CDC と SQL Server を移行に使用している場合、一般的にアクセス権限に関連するエラー、または変更データキャプチャ中のエラーが発生します。通常、いずれかの前提条件が満たされていない場合に、このようなタイプのエラーが発生します。たとえば、最も一般的に見過ごされる前提条件は、完全データベースバックアップです。

• 外部キー: 全ロードプロセス中に、AWS DMS は特定の順序でデータをロードしないため、親テーブルデータより前に子テーブルデータをロードする場合があります。その結果、外部キーの制約が有効になっている場合、それらの制約に違反する可能性があります。Aurora MySQL ターゲットデータベースで外部キーを無効にする必要があります。移行が完了した後、ターゲットで外部キーを有効にすることができます。

詳細なヒントについては、『AWS DMS ユーザーガイド』のAWS DMSトラブルシューティングのセクションを参照してください。

SQL Server 固有の問題のトラブルシューティングを行うには、以下の SQL Server のトラブルシューティングのセクションを参照してください。

• Microsoft SQL Server 固有の問題のトラブルシューティング

Aurora MySQL の問題をトラブルシューティングするには、Aurora MySQL のトラブルシューティングのセクションおよび MySQL のトラブルシューティングのセクションを参照してください。

• Amazon Aurora MySQL 特有の問題のトラブルシューティング• MySQL 固有の問題のトラブルシューティング

API バージョン 2016-01-0183


https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.SQLServer

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.Aurora



前提条件

Oracle データベースの PostgreSQLへの移行

このウォークスルーでは、AWS Database Migration Service (AWS DMS) と AWS スキーマ変換ツール(AWS SCT) を使用して、Oracle データベースを PostgreSQL データベースに移行する方法について説明します。

AWS DMS は、Oracle ソースから PostgreSQL ターゲットにデータを移行します。また、AWS DMS は、ソースデータベースでのデータ操作言語 (DML) とサポートされるデータ定義言語 (DDL) の変更をキャプチャしてターゲットデータベースに適用します。このようにして、AWS DMS はソースデータベースとターゲットデータベース間の同期を常に維持します。AWS SCT は、データ移行を容易にするために、ターゲットデータベースで移行されたスキーマを作成します (必要に応じて、ターゲットのテーブルとプライマリキーインデックスが含まれます)。

AWS DMS は、セカンダリインデックス、シーケンス、デフォルト値、ストアドプロシージャ、トリガー、シノニム、ビューなど、データ移行に特に関係ないスキーマオブジェクトは移行しません。これらのオブジェクトを PostgreSQL のターゲットに移行するには、AWS SCT を使用します。

トピック• 前提条件 (p. 84)• ステップバイステップ移行 (p. 85)• 移行のロールバック (p. 106)• トラブルシューティング (p. 106)

前提条件このチュートリアルを実施する前提条件として以下が必要です。

• Amazon Relational Database Service (Amazon RDS)、該当するデータベーステクノロジー、およびSQL について理解する。

• AWS リージョンで Amazon RDS および AWS Database Migration Service (AWS DMS) インスタンスの起動を許可する AWS Identity and Access Management (IAM) の認証情報を含む AWS アカウントを作成する。IAM 認証情報の詳細については、「IAM ユーザーの作成」を参照してください。

• Amazon Virtual Private Cloud (Amazon VPC) サービスとセキュリティグループについて理解する。Amazon RDS での Amazon VPC の使用方法については、「Amazon Virtual Private Cloud (VPC)および Amazon RDS」を参照してください。Amazon RDS セキュリティグループの詳細については、「Amazon RDS セキュリティグループ」を参照してください。

• AWS DMS でサポートされている機能と制限について理解する。AWS DMS に関する詳細については、「AWS Database Migration Service とは」を参照してください。

• Oracle と PostgreSQL でサポートされているデータ型変換オプションについて理解する。ソースとしての Oracle データ型の詳細については、「AWS Database Migration Service のソースとして Oracle データベースを使用する」を参照してください。ターゲットとしての PostgreSQL データ型の詳細については、「AWS Database Migration Service のターゲットとして PostgreSQL を使用する」を参照してください。

API バージョン 2016-01-0184

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introduction.SupportedDDL.html








https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.PostgreSQL.html



• ターゲットの PostgreSQL データベースホストのサイズを指定する。DBA は、現在のソースの Oracleデータベースホストのロードプロファイルに注意する必要があります。CPU、メモリ、および IOPSを考慮します。RDS では、移行後にターゲットデータベースホストのサイズを拡大または縮小できます。PostgreSQL に移行するのが初めての場合は、パフォーマンスの問題とチューニングの機会のため、余分な処理能力を残しておくことをお勧めします。

• ソース Oracle データベースを監査する。各スキーマと各スキーマのすべてのオブジェクトについて、使用されなくなったオブジェクトがないかどうか確認します。使用されていない場合は移行する必要はないため、ソース Oracle データベースでそれらのオブジェクトを廃止します。

• ロード容量がある場合は、ソースデータベースで各 LOB タイプの最大サイズ (kb) を取得し、後で使用するためにこの情報を保管しておきます。

• 可能であれば、BLOB、CLOB、NCLOB、LONG、LONG RAW、XMLTYPE の列を AmazonS3、Dynamo DB、または別のデータストアに移動する。これにより、ソースの Oracle データベースが、容易に移行できるように簡素化されます。また、ターゲット PostgreSQL データベースの容量要件が低くなります。

AWS DMS の詳細については、「AWS DMS に関するドキュメント」を参照してください。

ステップバイステップ移行次のステップでは、Oracle データベースを PostgreSQL データベースに移行するための手順を示します。各ステップでは、「前提条件 (p. 84)」の説明に従ってソースデータベースが準備済みであることを前提とします。

トピック• ステップ 1: SQL ドライバーと AWS スキーマ変換ツールをローカルコンピュータにインストールす

る (p. 85)• ステップ 2: Oracle ソースデータベースの設定 (p. 86)• ステップ 3: PostgreSQL ターゲットデータベースを設定する (p. 89)• ステップ 4: AWS スキーマ変換ツール (AWS SCT) を使用して、Oracle スキーマを PostgreSQL に変

換する (p. 89)• ステップ 5: AWS DMS レプリケーションインスタンスを作成する (p. 97)• ステップ 6: AWS DMS のソースとターゲットのエンドポイントを作成する (p. 99)• ステップ 7: AWS DMS 移行タスクの作成と実行 (p. 102)• ステップ 8: PostgreSQL にカットオーバーする (p. 105)

ステップ 1: SQL ドライバーと AWS スキーマ変換ツールをローカルコンピュータにインストールするSQL ドライバーと AWS スキーマ変換ツール (AWS SCT) をローカルコンピュータにインストールします。



2. PostgreSQL ドライバー (postgresql-42.1.4.jar) をダウンロードします。3. AWS SCT と必要な JDBC ドライバーをインストールします。

API バージョン 2016-01-0185




https://jdbc.postgresql.org/download/postgresql-42.1.4.jar



a. 『AWS Schema Conversion Tool ユーザーガイド』の「AWS Schema Conversion Tool のインストールと更新」から AWS SCT をダウンロードします。

b. AWS SCT を起動します。c. AWS SCT で、[Settings] の [Global Settings] を選択します。d. [Global Settings] で、[Driver] を選択し、[Oracle Driver Path] の [Browse] を選択します。JDBC

Oracle ドライバーを見つけ、[OK] を選択します。e. [PostgreSQL Driver Path] の [Browse] を選択します。JDBC PostgreSQL ドライバーを見つけ、

[OK] を選択します。

f. [OK] を選択してダイアログボックスを閉じます。

ステップ 2: Oracle ソースデータベースの設定AWS Database Migration Service (AWS DMS) のソースとして Oracle を使用するには、まずARCHIVELOG MODE がオンになっていて、LogMiner に情報が提供されることを確認する必要があります。AWS DMS では、LogMiner を使用してアーカイブログから情報を読み取り、その情報に基づいてAWS DMS が変更をキャプチャできるようにします。

この情報を AWS DMS で読み取るには、AWS DMS がアーカイブログを必要とする期間にわたって、アーカイブログが常にデータベースサーバーに保持されていることを確認します。変更のキャプチャをすぐ開始するようにタスクを設定する場合は、実行期間が最も長いトランザクションより少しだけ長くアーカイブログを保持するだけで済みます。アーカイブログの保持期間は、通常、24 時間で十分です。過去のある時点から開始するようにタスクを設定する場合は、その時点からアーカイブログが利用できることが必要です。ARCHIVELOG MODE を有効にする方法と Oracle データベースのログを保持する方法の詳細については、Oracle のドキュメントを参照してください。

変更データをキャプチャするには、AWS DMS では、ソースデータベースでサプリメンタルロギングが有効になっている必要があります。データベースレベルで最小限のサプリメンタルロギングを有効にする必要があります。AWS DMS では、識別キーのロギングも有効になっている必要があります。このオプションでは、データベースでプライマリキーを含む行が更新されるたびに、行のプライマリキーのすべての列

API バージョン 2016-01-0186



http://docs.oracle.com/database/121/ADMIN/archredo.htm#ADMIN11335



が REDO ログファイル内に配置されます。プライマリキーの値が変更されない場合でも、この結果になります。このオプションは、データベースレベルまたはテーブルレベルで設定できます。

Oracle ソースデータベースを設定するには

1. AWS DMS で使用するデータベースアカウントを作成または設定します。AWS DMS で AWS DMS 接続に必要な最低限の権限を備えたアカウントを使用することをお勧めします。AWS DMS に必要な権限は以下のとおりです。

CREATE SESSIONSELECT ANY TRANSACTIONSELECT on V_$ARCHIVED_LOGSELECT on V_$LOGSELECT on V_$LOGFILESELECT on V_$DATABASESELECT on V_$THREADSELECT on V_$PARAMETERSELECT on V_$NLS_PARAMETERSSELECT on V_$TIMEZONE_NAMESSELECT on V_$TRANSACTIONSELECT on ALL_INDEXESSELECT on ALL_OBJECTSSELECT on ALL_TABLESSELECT on ALL_USERSSELECT on ALL_CATALOGSELECT on ALL_CONSTRAINTSSELECT on ALL_CONS_COLUMNSSELECT on ALL_TAB_COLSSELECT on ALL_IND_COLUMNSSELECT on ALL_LOG_GROUPSSELECT on SYS.DBA_REGISTRYSELECT on SYS.OBJ$SELECT on DBA_TABLESPACESSELECT on ALL_TAB_PARTITIONSSELECT on ALL_ENCRYPTED_COLUMNS* SELECT on all tables migrated

変更のキャプチャと適用 (CDC) を行う場合は、以下の権限も必要です。

EXECUTE on DBMS_LOGMNR SELECT on V_$LOGMNR_LOGSSELECT on V_$LOGMNR_CONTENTSLOGMINING /* For Oracle 12c and higher. */* ALTER for any table being replicated (if you want AWS DMS to add supplemental logging)

バージョン 11.2.0.3 より前の Oracle には、以下の権限が必要です。

SELECT on DBA_OBJECTS /* versions before 11.2.0.3 */SELECT on ALL_VIEWS (required if views are exposed)

2. Oracle データベースが AWS RDS データベースである場合は、管理ユーザーとしてそのデータベースに接続し、次のコマンドを実行して、アーカイブログが RDS ソースに 24 時間保持されるようにします。

API バージョン 2016-01-0187



exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

Oracle ソースが AWS RDS データベース内にある場合は、バックアップを有効にしているときに限り、ARCHIVELOG MODE に配置されます。

3. 以下のコマンドを実行して、AWS DMS で必要なサプリメンタルロギングをデータベースレベルで有効にします。• Oracle SQL の場合:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

• RDS の場合:

exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');

4. 次のコマンドを使用して、識別キーのサプリメンタルロギングをデータベースレベルで有効にします。AWS DMS では、データベースレベルでのサプリメンタルキーロギングが必要です。ただし、サプリメンタルロギングを必要に応じて自動的に追加することを AWS DMS に許可したり、キーレベルのサプリメンタルロギングをテーブルレベルで有効にしたりする場合を除きます。• Oracle SQL の場合:

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

• RDS の場合:

exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');

キーレベルのサプリメンタルロギングを有効にすると、ソースデータベースで多少のオーバーヘッドが生じます。したがって、テーブルのサブセットのみを移行する場合は、テーブルレベルでのサプリメンタルロギングを有効にすることをお勧めします。

5. キーレベルのサプリメンタルロギングをテーブルレベルで有効にするには、次のコマンドを使用します。

ALTER TABLE table_name ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

テーブルにプライマリキーがない場合は、2 つのオプションを使用できます。

• テーブル (インデックス名でソート済み) の最初の固有なインデックスに関連するすべての列でサプリメンタルロギングを追加できます。

• テーブルのすべての列にサプリメンタルロギングを追加できます。

テーブル内の列のサブセット (固有なインデックスに関連する列など) にサプリメンタルロギングを追加するには、次のコマンドを実行します。

ALTER TABLE table_name ADD SUPPLEMENTAL LOG GROUP example_log_group (column_list) ALWAYS;

API バージョン 2016-01-0188

AWS Database Migration Service ステップバイステップ移行ガイドステップ 3: PostgreSQL ター

ゲットデータベースを設定する

テーブルのすべての列にサプリメンタルロギングを追加するには、次のコマンドを実行します。

ALTER TABLE table_name ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

6. AWS SCT のユーザーを作成します。

CREATE USER oracle_sct_user IDENTIFIED BY password; GRANT CONNECT TO oracle_sct_user;GRANT SELECT_CATALOG_ROLE TO oracle_sct_user;GRANT SELECT ANY DICTIONARY TO oracle_sct_user;

ステップ 3: PostgreSQL ターゲットデータベースを設定する1. 移行するスキーマが PostgreSQL データベースに存在しない場合は、スキーマを作成します。2. AWS DMS ユーザーを作成してターゲットデータベースに接続します。また、Superuser または必要

な個別の権限を付与します (あるいは、RDS 用のマスターユーザー名を使用します)。

CREATE USER postgresql_dms_user WITH PASSWORD 'password'; ALTER USER postgresql_dms_user WITH SUPERUSER;

3. AWS SCT のユーザーを作成します。

CREATE USER postgresql_sct_user WITH PASSWORD 'password';

GRANT CONNECT ON DATABASE database_name TO postgresql_sct_user;GRANT USAGE ON SCHEMA schema_name TO postgresql_sct_user;GRANT SELECT ON ALL TABLES IN SCHEMA schema_name TO postgresql_sct_user;GRANT ALL ON SEQUENCES IN SCHEMA schema_name TO postgresql_sct_user;

ステップ 4: AWS スキーマ変換ツール (AWS SCT) を使用して、Oracle スキーマを PostgreSQL に変換するPostgreSQL にデータを移行する前に、Oracle スキーマを PostgreSQL スキーマに変換します。

AWS SCT を使用して Oracle スキーマを PostgreSQL スキーマに変換するには

1. AWS SCT を起動します。AWS SCT で [File] を選択し、[New Project] を選択します。AWS SchemaConversion Tool Oracle to PostgreSQL という新しいプロジェクトを作成します。[NewProject] ウィンドウに次の情報を入力し、[OK] を選択します。

API バージョン 2016-01-0189


ステップ 4: AWS スキーマ変換ツール (AWS SCT) を使用して、Oracle スキーマを PostgreSQL に変換する


プロジェクト名 AWS Schema Conversion Tool Oracle toPostgreSQL と入力します。


Source Database Engine [Oracle] を選択します。

Target Database Engine [Amazon RDS for PostgreSQL] を選択します。





Server port Oracle ポート番号を入力します。デフォルト: 1521。

Oracle SID データベース SID を入力します。

ユーザー名 Oracle 管理者のユーザー名を入力します。


API バージョン 2016-01-0190



3. [OK] を選択してアラートボックスを閉じ、[OK] を選択してダイアログボックスを閉じて、Oracle DBインスタンスへの接続を開始します。Oracle DB インスタンス上のデータベース構造が表示されます。

4. [Connect to Amazon RDS for PostgreSQL] を選択します。[Connect to Amazon PostgreSQL] ダイアログボックスに次の情報を入力して、[Test Connection] を選択します。



Server port PostgreSQL のポート番号を入力します。デフォルト:5432。

データベースデータベース名を入力します。

ユーザー名 PostgreSQL 管理者のユーザー名を入力します。


API バージョン 2016-01-0191



5. [OK] を選択してアラートボックスを閉じ、[OK] を選択してダイアログボックスを閉じて、PostgreSQL DB インスタンスへの接続を開始します。

6. 移行するスキーマのコンテキスト (右クリック) メニューを開き、[Convert schema] を選択します。

API バージョン 2016-01-0192



7. 確認メッセージで、[Yes] を選択します。AWS SCT でスキーマがターゲットデータベース形式に変換されます。

API バージョン 2016-01-0193



AWS SCT はスキーマを分析し、PostgreSQL への変換に関するデータベース移行評価レポートを作成します。

8. [View] から [Assessment Report View] を選択し、レポートを確認します。

このレポートは、各オブジェクトタイプ別の情報と、正しい変換に必要な手動の変更の量を示しています。

一般的に、パッケージ、手順、および関数で、解決が必要な問題が多く発生します。これは、最もカスタムな PL/SQL コードが含まれているためです。AWS SCT は、これらのオブジェクトの修正方法に関するヒントも提供します。

API バージョン 2016-01-0194



9. [Action Items] タブを選択します。

[Action Items] タブには、オブジェクトごとに注意が必要な問題が表示されます。

変換の問題ごとに、次のいずれかのアクションを完了できます。• ソースの Oracle データベースのオブジェクトを変更して、AWS SCT がそれらのオブジェクトを

ターゲットの PostgreSQL データベースに変換できるようにします。

1. ソース Oracle データベースでオブジェクトを変更します。2. 前のステップを繰り返してスキーマを変換し、評価レポートを確認します。

API バージョン 2016-01-0195



3. 必要に応じて、変換の問題がなくなるまでこのプロセスを繰り返します。4. [View] から [Main View] を選択し、ターゲット PostgreSQL スキーマのコンテキスト (右ク

リック) メニューを開き、[Apply to database] を選択してスキーマの変更を PostgreSQL データベースに適用します。

• ソーススキーマを変更する代わりに、AWS SCT によって生成されたスクリプトを変更してから、そのスクリプトをターゲットの PostgreSQL データベースに適用します。

1. ターゲットの PostgreSQL スキーマ名のコンテキストメニューを開き (右クリック)、[Saveas SQL] を選択します。次に、スクリプトの名前と保存先を選択します。

2. スクリプトで、変換の問題を修正するオブジェクトを変更します。3. ターゲットの PostgreSQL データベースでスクリプトを実行します。

詳細については、『AWS Schema Conversion Tool ユーザーガイド』の「AWS Schema ConversionTool を使用した Amazon RDS へのデータベーススキーマの変換」を参照してください。

10. AWS SCT を使用してマッピングルールを作成します。

a. [Settings] の [Mapping Rules] を選択します。b. スキーマ名とテーブル名を小文字に変換する 2 つのデフォルトマッピングルールに加えて、アク

ション項目に基づいて必要になる追加のマッピングルールを作成します。c. マッピングルールを保存します。

API バージョン 2016-01-0196





d. [Export script for DMS (DMS にスクリプトをエクスポート)] をクリックし、ソースのオブジェクトとターゲットのオブジェクトの対応を判断するために AWS DMS タスクで使用されるすべての変換の JSON 形式をエクスポートします。[Save] をクリックします。

ステップ 5: AWS DMS レプリケーションインスタンスを作成するソースおよびターゲットデータベース間のスキーマ構造を検証したら、このチュートリアルの核心であるデータ移行に進みます。次の図は、移行プロセスの概要を示しています。

AWS DMS レプリケーションインスタンスは、ソースとターゲットの間で実際のデータ移行を行います。また、レプリケーションインスタンスは移行中にトランザクションログもキャッシュします。レプリケーションインスタンスで使用できる CPU およびメモリ容量に応じて、移行全体の所要時間が変わります。


1. AWS マネジメントコンソールにサインインし、https://console.aws.amazon.com/dms/ で [AWS DMS]を選択します。次に、[Create Migration] を選択します。AWS Identity and Access Management (IAM)ユーザーとしてサインインしている場合、AWS DMS にアクセスするには適切なアクセス許可が必要です。必要なアクセス許可の詳細については、「AWS DMS を使用するのに必要な IAM アクセス許可」を参照してください。

2. [Next] を選択して、コンソールの [Welcome] ページからデータベースの移行を開始します。3. [Create replication instance] ページで、レプリケーションのインスタンス情報を指定します。


名前レプリケーションインスタンスの名前を選択します。複数のレプリケーションサーバーを使用するか、アカウントを

API バージョン 2016-01-0197






パラメータ説明共有する場合、異なるサーバーをすばやく区別できるような名前を選択します。

説明短い説明を入力します。

インスタンスクラス作成するレプリケーションサーバーのタイプを選択します。インスタンスクラスの各サイズとタイプでは、CPU、メモリ、I/O キャパシティーが増えます。一般的に、低負荷のタスクには t2 インスタンスを使用し、高負荷で数が多いタスクには c4 インスタンスを使用します。

VPC レプリケーションインスタンスを起動する VPC を選択します。可能であれば、ソースデータベースまたはターゲットデータベース (あるいはその両方) が存在しているのと同じ VPC を選択します。

マルチ AZ [Yes] を選択すると、プライマリレプリケーションサーバーに問題がある場合に、フェイルオーバーのため、AWSDMS により、別のアベイラビリティーゾーンで 2 番目のレプリケーションサーバーが作成されます。

パブリックアクセス可能ソースデータベースまたはターゲットデータベースのいずれかが、レプリケーションサーバーが存在している VPCの外部にある場合は、レプリケーションサーバーポリシーをパブリックアクセス可能にする必要があります。

4. [Advanced] セクションで、以下の情報を指定します。


Allocated storage (GB) 履歴のタスクログを含む、AWS DMS タスクログ用のレプリケーションサーバー上のストレージの量。また、AWSDMS は、ディスクストレージを使用して、ソースからターゲットにレプリケートする間に特定のデータをキャッシュします。さらに、通常はストレージが増えれば、サーバー上の IOPS も向上します。

レプリケーションサブネットグループマルチ AZ 設定で実行している場合は、少なくとも 2 つのサブネットグループが必要です。

アベイラビリティーゾーン通常、プライマリレプリケーションサーバーをターゲットデータベースと同じアベイラビリティーゾーンに配置した場合にパフォーマンスが向上します。

VPC セキュリティグループセキュリティグループを使用すると、VPC への出入りを制御できます。AWS DMS は、レプリケーションサーバーが起動される VPC に 1 つ以上のセキュリティグループを関連付けることができます。

KMS マスターキー AWS DMS では、すべてのデータが保管中に KMS 暗号化キーで暗号化されます。デフォルトでは、AWS DMS で、レプリケーションサーバー用に新しい暗号化キーが作成されます。ただし、既存のキーを使用することもできます。

KMS マスターキーの詳細については、「暗号化キーの設定と KMS のアクセス許可の指定」を参照してください。

API バージョン 2016-01-0198

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Security.EncryptionKey.html



5. [Next] をクリックします。


コンソールを使用して、ソースおよびターゲットデータベースエンドポイントを指定するには

1. ソース Oracle データベースとターゲット PostgreSQL データベースの接続情報を指定します。次の表はソース設定の説明です。


エンドポイント識別子 Orasource などの名前を入力します。


サーバー名 Oracle DB インスタンスのサーバー名を入力します。

ポートデータベースのポート。Oracle のデフォルト値は 1521 です。

SSL モード接続のトラフィック暗号化を有効にする場合は、SSL モードを選択します。

[Username] ソースデータソースに接続するために使用するユーザー。


SID Oracle データベースの名前を入力します。

次の表は詳細なソース設定の説明です。


追加の接続属性エンドポイントで設定して機能を追加したり、AWS DMSの動作を変更したりする追加のパラメータ。Oracle ソースデータベースに対して設定する最も一般的で便利なパラメータの一部には、以下のものがあります。複数を追加する場合はセミコロン (;) で区切ります。

• addSupplementalLogging - このパラメータは、Y に設定されると自動的にサプリメンタルロギングを設定します。

• useLogminerReader - デフォルトでは、AWS DMS はOracle データベースで Logminer を使用して、ソースデータベースのすべての変更をキャプチャします。もう1 つのモードは Binary Reader と呼ばれます。Logminerの代わりに Binary Reader を使用すると、AWS DMS はアーカイブされた redo ログをソースの Oracle データベースからレプリケーションサーバーにコピーし、変更

API バージョン 2016-01-0199



パラメータ説明をキャプチャするためにログ全体を読み込みます。ASMを使用している場合は、ASM 上の Logminer よりもパフォーマンスの利点があるため、Binary Reader オプションが推奨されます。ソースデータベースが 12c の場合、Binary Reader のオプションが、現在 LOB オブジェクトについて Oracle で CDC の変化をキャプチャする唯一の方法です。

Logminer を使用するには、次のように入力します。

useLogminerReader=Y

Binary Reader を使用するには、次のように入力します。

useLogminerReader=N; useBfile=Y


追加の接続属性の詳細については、「AWS Database Migration Service での追加の接続属性の使用」を参照してください。



エンドポイント識別子 Postgrestarget などの名前を入力します。

Target Engine [postgres] を選択します。

Servername PostgreSQL DB インスタンスのサーバー名を入力します。

ポートデータベースのポート。PostgreSQL のデフォルト値は5432 です。


[Username] ターゲットデータソースに接続するために使用するユーザー。

パスワード PostgreSQL DB インスタンスのパスワードを入力します。

以下は完了したページの例です。

API バージョン 2016-01-01100

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introduction.ConnectionAttributes.html



2. エンドポイントおよびレプリケーションインスタンスが作成された後、ソースおよびターゲットエンドポイントに対して [Run test] を選択して、各エンドポイント接続をテストします。

3. 外部キーの制約とトリガーをターゲットデータベースにドロップします。

全ロードプロセス中に、AWS DMS は特定の順序でデータをロードしないため、親テーブルデータより前に子テーブルデータをロードする場合があります。その結果、外部キーの制約が有効になっている場合、それらの制約に違反する可能性があります。また、ターゲットデータベースにトリガーが存在している場合は、AWS DMS によってロードされたデータが予期しない方法で変更される可能性があります。

4. 外部キー制約とトリガーを有効にするスクリプトを生成します (ない場合)。

その後、移行されたデータベースに追加する場合、このスクリプトを実行できます。5. (オプション) ターゲットデータベースのセカンダリインデックスを削除します。

(すべてのインデックスと同様に) セカンダリインデックスは、ロードプロセス中に保持および更新する必要があるため、テーブルへのデータの全ロード速度が低下する原因となる場合があります。セカ

API バージョン 2016-01-01101



ンダリインデックスを削除することで、全ロードプロセスのパフォーマンスを向上させることができます。インデックスを削除する場合、全ロードの完了後に、再度追加する必要があります。


ステップ 7: AWS DMS 移行タスクの作成と実行AWS DMS タスクを使用して、移行するスキーマと、移行のタイプを指定できます。既存のデータを移行するか、既存のデータを移行して継続的な変更をレプリケートするか、またはデータ変更のみをレプリケートするかを選択できます。このウォークスルーでは、既存のデータを移行し、継続的な変更をレプリケートします。




タスク名移行タスクの名前を入力します。


ソースエンドポイント Oracle ソースエンドポイントを表示します。

アカウント内に複数のエンドポイントがある場合は、リストから正しいエンドポイントを選択します。

ターゲットエンドポイント PostgreSQL のターゲットエンドポイントを表示します。

レプリケーションインスタンス AWS DMS レプリケーションインスタンスを表示します。

移行タイプ [Migrate existing data and replicate ongoing changes] オプションを選択します。


このページは次のようになります。

API バージョン 2016-01-01102



2. [Task Settings] で、[ターゲットテーブル作成モード] の [何もしない] または [切り詰め] を選択します。これは、既に AWS スキーマ変換ツールを使用してテーブルを作成したためです。

Oracle データベースで LOB が作成された場合、すべてのテーブルの LOB 全体をレプリケートするには、[レプリケーションに LOB 列を含める] の [完全 LOB モード] を選択します。LOB を特定のサイズまでのみレプリケートする場合は、[制限付き LOB モード] を選択します。移行する LOB のサイズは、[最大 LOB サイズ (KB)] で指定します。

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

3. 詳細設定はデフォルト値のままにしておきます。

API バージョン 2016-01-01103



4. [Table mappings] を選択し、[JSON] タブを選択します。次に、[Enable JSON editing] を選択し、「ステップ 4: AWS スキーマ変換ツール (AWS SCT) を使用して、Oracle スキーマを PostgreSQL に変換する (p. 89)」の最後のステップで保存したテーブルマッピングを入力します。

スキーマ名とテーブル名を小文字に変換するマッピングの例を次に示します。

{ "rules": [ { "rule-type": "transformation", "rule-id": "100000", "rule-name": "Default Lowercase Table Rule", "rule-action": "convert-lowercase", "rule-target": "table", "object-locator": { "schema-name": "%", "table-name": "%" } }, { "rule-type": "transformation", "rule-id": "100001", "rule-name": "Default Lowercase Schema Rule", "rule-action": "convert-lowercase", "rule-target": "schema", "object-locator": { "schema-name": "%" } } ]}

5. [タスクの作成] を選択します。タスクは直ちに開始されます。


タスクの設定時に [Enable logging] を選択すると、タスクをモニタリングできます。次に、以下の操作を行って CloudWatch メトリクスを表示できます。


1. ナビゲーションペインで、[Tasks] を選択します。2. 移行タスクを選択します。3. [Task monitoring] タブを選択し、そのタブで進行中のタスクをモニタリングします。

全ロードが完了しキャッシュされた変更が適用されると、タスクは自動的に停止します。

API バージョン 2016-01-01104


ステップ 8: PostgreSQL にカットオーバーする

4. ターゲット PostgreSQL データベースで、前に保存したスクリプトを使用して外部キー制約とトリガーを有効にします。

5. ターゲット PostgreSQL データベースで、以前に削除した場合はセカンダリインデックスを再作成します。

6. AWS DMS コンソールで、タスクの [Start/Resume (開始/再開)] をクリックして AWS DMS タスクを起動します。

AWS DMS タスクは、ソースデータベースの変更を使用して、ターゲット PostgreSQL データベースを最新の状態に保ちます。AWS DMS は、アプリケーションの移行を実行する時までタスクのすべてのテーブルを最新の状態に保ちます。ターゲットがソースに追いつくと、レイテンシーはゼロ、またはゼロに近くなります。

ステップ 8: PostgreSQL にカットオーバーする次のステップを実行して、Oracle データベースから PostgreSQL データベースに接続を移動します。

PostgreSQL にカットオーバーするには

1. 実行中のスクリプトやクライアント接続など、すべての Oracle データベースの依存関係とアクティビティを終了します。

次のクエリは結果を返しません。

SELECT MACHINE, COUNT FROM V$SESSION GROUP BY MACHINE;

2. 残りのセッションをリストし、強制終了します。

SELECT SID, SERIAL#, STATUS FROM V$SESSION; ALTER SYSTEM KILL 'sid, serial_number' IMMEDIATE;

3. Oracle データベースのすべてのリスナーをシャットダウンします。4. AWS DMS タスクで、PostgreSQL データベースの Oracle データベースから最終的な変更を適用しま

す。

ALTER SYSTEM CHECKPOINT;

5. AWS DMS コンソールで、タスクの [Stop (停止)] をクリックして、タスクを停止することを確認し、AWS DMS タスクを停止します。

6. (オプション) ロールバックを設定します。

表示が停止する問題が発生した場合は、反対方向に進むタスクを作成して、オプションでロールバックタスクを設定できます。すべてのテーブルは両方のデータベース間で同期されるため、CDC タスクを設定するだけです。したがって、外部キーの制約を無効にする必要はありません。ソースおよびターゲットデータベースが反転されたため、次のセクションの手順に従う必要があります。

• PostgreSQL データベースを AWS Database Migration Service のソースとして使用する• Oracle データベースを AWS Database Migration Service のターゲットとして使用する

a. ソース Oracle データベースでトリガーを無効化します。

API バージョン 2016-01-01105

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.Oracle.html


移行のロールバック

SELECT 'ALTER TRIGGER' || owner || '.' || trigger_name || 'DISABLE;' FROM DBA_TRIGGERS WHERE OWNER = 'schema_name';

外部キーの制約を無効にする必要はありません。CDC プロセス中に、外部キー制約はアプリケーションユーザーによる更新と同じ順序で更新されます。

b. エンドポイントを反転 (ソースの PostgreSQL エンドポイントデータベースとターゲットのOracle エンドポイントデータベース) して、新しい CDC 専用の AWS DMS タスクを作成します。「ステップ 7: AWS DMS 移行タスクの作成と実行 (p. 102)」を参照してください。

ロールバックタスクの場合、[移行タイプ] を [データ変更のみをレプリケートする] に設定し、[ターゲットテーブル作成モード] を [何もしない] に設定します。

c. AWS DMS タスクを開始して、ロールバックが必要な場合に、新しい PostgreSQL データベースから元のソース Oracle データベースに変更をプッシュできるようにします。

7. PostgreSQL データベースに接続して、トリガーを有効にします。

ALTER TABLE table_name ENABLE TRIGGER ALL;

8. ロールバックを設定したら、ロールバックのセットアップを完了します。

a. 新しいターゲット PostgreSQL データベース (スクリプト、クライアントソフトウェアなどを含む) で、アプリケーションサービスを開始します。

b. 新しい PostgreSQL データベースで CloudWatch モニタリングを追加します。「Amazon RDS のモニタリング」を参照してください。

移行のロールバック移行についてタイムリーに解決できない大きな問題がある場合は、移行をロールバックできます。各ステップでは、「ステップ 8: PostgreSQL にカットオーバーする (p. 105)」の説明に従ってロールバックが準備済みであることを前提とします。

移行をロールバックするには

1. ターゲット PostgreSQL データベースですべてのアプリケーションサービスを停止します。2. AWS DMS タスクで、残りの変更をソース Oracle データベースにレプリケートします。3. PostgreSQL を Oracle AWS DMS タスクに対して停止します。4. すべてのアプリケーションをソース Oracle データベースで起動します。

トラブルシューティングOracle をソースとし、PostgreSQL をターゲットとして使用するときに最も問題が発生しやすい 2 つの領域として、サプリメンタルロギングと大文字/小文字の区別があります。

• サプリメンタルロギング – Oracle で変更データをレプリケートするにはサプリメンタルロギングを有効にする必要があります。ただし、サプリメンタルロギングをデータベースレベルで有効にした場合は、新しいテーブルの作成時に再度有効にする必要があります。この最良の対策としては、追加の接続属性を使用してサプリメンタルロギングを自動的に有効にすることを AWS DMS に許可します。

API バージョン 2016-01-01106

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html


トラブルシューティング


• 大文字/小文字の区別: Oracle では大文字と小文字が区別されます (オブジェクト名を引用符で囲んだ場合を除きます)。ただし、テキストは大文字で表示されます。したがって、AWS DMS ではデフォルトでターゲットオブジェクト名が大文字になります。通常は、変換を使用してスキーマ、テーブル、および列の名前を小文字に変更します。

詳細なヒントについては、『AWS DMS ユーザーガイド』のAWS DMSトラブルシューティングのセクションを参照してください。

Oracle 固有の問題のトラブルシューティングを行うには、以下の Oracle のトラブルシューティングセクションを参照してください。

Oracle 固有の問題のトラブルシューティング

PostgreSQL の問題のトラブルシューティングを行うには、PostgreSQL のトラブルシューティングのセクションを参照してください。

PostgreSQL 固有の問題のトラブルシューティング

API バージョン 2016-01-01107



https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.PostgreSQL


前提条件

Amazon RDS for Oracle Database のAmazon Redshift への移行

このチュートリアルでは、AWS Database Migration Service (AWS DMS) と AWS スキーマ変換ツール(AWS SCT) を使用した、Amazon RDS for Oracle から Amazon Redshift への異種データベースの移行について説明します。この基本実習ではすべてのシナリオをカバーしているわけではありませんが、この種の移行を行うためのステップは十分にご理解いただけます。

重要な点として、AWS DMS と AWS SCT は 2 つの異なるツールであり、異なるニーズに対応します。両者が移行プロセスで連携することはありません。この移行手順の概略は以下のとおりです。

1. AWS SCT を使用して以下を行います。• Oracle から Amazon Redshift への変換レポートを実行して、スキーマ変換の問題、制約、および必要

なアクションを確認します。• AWS DMS でデータをロードする前に、スキーマスクリプトを生成してターゲットに適用しま

す。AWS SCT でプロシージャやビューなどのオブジェクトに必要なコード変換が実行されます。2. AWS SCT から報告された問題を確認し、解決策を実行します。3. AWS DMS データのロードに影響する可能性がある外部キーやその他の制約を無効にします。4. AWS DMS では、全ロードアプローチを使用してソースからターゲットにデータをロードします。AWS

DMS では、ロードの一環としてターゲット内でオブジェクトを作成できますが、必要最低限の権限で効率的な移行を行うために、スキーマ構造全体はソースからターゲットにコピーされません。

5. 追加のインデックスの作成、外部キーの有効化、新しいデータベースを参照するために必要なアプリケーションの変更など、移行後の処理を行います。

このチュートリアルでは、AWS CloudFormation テンプレートをカスタマイズして Oracle と AmazonRedshift の RDS DB インスタンスを作成します。次に SQL コマンドスクリプトを使用し、AmazonRedshift に移行するサンプルスキーマとデータを最初に RDS Oracle DB インスタンスにインストールします。

このチュートリアルの所要時間は約 2 時間です。追加料金が発生しないように、チュートリアルが終了したら、手順に従って必ずリソースを削除してください。

トピック• 前提条件 (p. 108)• 移行アーキテクチャ (p. 109)• ステップバイステップ移行 (p. 110)• 次のステップ (p. 143)

前提条件このチュートリアルを実施する前提条件として以下も必要です。

• Amazon RDS、Amazon Redshift、該当するデータベーステクノロジー、および SQL に関する知識。• 移行するテーブルと移行を確認する SQL クエリの作成に必要な以下のカスタムスクリプト。

• Oracle_Redshift_For_DMSDemo.template— AWS CloudFormation テンプレート

Oraclesalesstarschema.sql—SH スキーマを構築するための SQL ステートメント

スクリプトは、次のリンクで入手できますdms-sbs-RDSOracle2Redshift.zip。

API バージョン 2016-01-01108

http://docs.aws.amazon.com/dms/latest/sbs/samples/dms-sbs-RDSOracle2Redshift.zip


移行アーキテクチャ

チュートリアルの各ステップには、関連ファイルをダウンロードするためのリンクや、該当するクエリが含まれています。

• AWS アカウントと AWS Identity and Access Management (IAM) 認証情報。この認証情報で、AWSリージョンでの RDS、AWS Database Migration Service (AWS DMS) インスタンス、および AmazonRedshift クラスターの起動が許可されます。IAM 認証情報の詳細については、「IAM ユーザーの作成」を参照してください。

• Amazon Virtual Private Cloud (Amazon VPC) サービスとセキュリティグループに関する基本的な知識。Amazon RDS での Amazon VPC の使用方法については、「Virtual Private Cloud (VPC) および Amazon RDS」を参照してください。Amazon RDS セキュリティグループの詳細については、「Amazon RDS セキュリティグループ」を参照してください。VPC での Amazon Redshift の使用方法については、「Amazon Virtual Private Cloud (VPC) でクラスターを管理する」を参照してください。

• AWS DMS でサポートされている機能と制限についての理解。AWS DMS の詳細については、「AWSDatabase Migration Service とは」を参照してください。

• Oracle と Amazon Redshift でサポートされているデータ型変換オプションの知識。ソースとしてのOracle のデータ型については、「AWS Database Migration Service のソースとしての Oracle データベースの使用」を参照してください。ターゲットとしての Amazon Redshift のデータ型の詳細については、「AWS Database Migration Service のターゲットとしての Amazon Redshift データベースの使用」を参照してください。

AWS DMS の詳細については、「AWS DMS ドキュメント」を参照してください。

移行アーキテクチャこのチュートリアルでは、AWS CloudFormation を使用してデータベース移行用の単純なネットワークトポロジーを作成します。このトポロジーでは、ソースデータベース、レプリケーションインスタンス、ターゲットデータベースを同じ VPC 内に配置します。AWS CloudFormation の詳細については、CloudFormation のドキュメントを参照してください。

この AWS DMS チュートリアルで使用する AWS リソースは AWS CloudFormation でプロビジョニングされます。これらのリソースには、VPC、Amazon RDS for Oracle インスタンス、Amazon Redshift クラスターなどが含まれます。CloudFormation でプロビジョニングすると、プロセスが簡素化されて、データ移行に関連するタスクに専念できます。CloudFormation テンプレートからスタックを作成すると、以下のリソースがプロビジョニングされます。

• VPC。この VPC はリージョンで CIDR (10.0.0.0/24) と 2 つのパブリックサブネットを持ちます。1 つのサブネット DBSubnet1 は、アベイラビリティーゾーン (AZ) 1 にあり、アドレスが 10.0.0.0/26 です。もう 1 つのサブネット DBSubnet2 は、AZ 12 にあり、アドレスが 10.0.0.64/26 です。

• DB サブネットグループ。これには DBSubnet1 と DBSubnet2 が含まれます。• Oracle RDS Standard Edition Two。これには、以下のデプロイメントオプションがあります。

• ライセンス込み• シングル AZ のセットアップ• db.m3.medium または同等のインスタンスクラス• ポート 1521• デフォルトのオプションとパラメータグループ

• Amazon Redshift クラスター。これには、以下のデプロイオプションがあります。• dc1.large• ポート 5439• デフォルトのパラメータグループ

• セキュリティグループ。入力パラメータに基づいてコンピュータからの着信アクセスを制御するか、0.0.0.0/0 ですべての場所からのアクセスを許可します。

API バージョン 2016-01-01109

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SettingUp.html#CHAP_SettingUp.IAM




https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html





https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.Redshift.html


https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html



今回設計した CloudFormation テンプレートでは、ユーザーの入力はほとんど必要ありません。最小限の推奨設定で、必要な AWS リソースがプロビジョニングされます。ただし、テンプレートの更新は自由です。必要に応じて設定やパラメータ (VPC CIDR ブロックや Amazon RDS インスタンスタイプなど) の一部を変更できます。

レプリケーションインスタンス、エンドポイント、タスクなどの AWS DMS リソースのプロビジョニングには、AWS マネジメントコンソールを使用します。SQL Workbench/J、AWS Schema Conversion Tool(AWS SCT) などのクライアントツールをローカルコンピュータにインストールし、Amazon RDS インスタンスに接続します。

次の図は、このチュートリアルでの移行アーキテクチャです。

ステップバイステップ移行以下のセクションでは、Amazon RDS for Oracle データベースを Amazon Redshift に移行するための詳細な手順を示します。各ステップでは、これまでのセクションの説明に従ってソースデータベースが準備済みであることを前提とします。

トピック

API バージョン 2016-01-01110



• ステップ 1: CloudFormation テンプレートを使用して VPC で RDS インスタンスを起動する (p. 111)• ステップ 2: SQL ツールと AWS Schema Conversion Tool をローカルコンピュータにインストールす

る (p. 115)• ステップ 3: Oracle DB インスタンスへの接続をテストしてサンプルスキーマを作成する (p. 118)• ステップ 4: Amazon Redshift データベースへの接続をテストする (p. 122)• ステップ 5: AWS SCT を使用して Oracle スキーマを Amazon Redshift に変換する (p. 124)• ステップ 6: スキーマ変換を検証する (p. 131)• ステップ 7: AWS DMS レプリケーションインスタンスを作成します。 (p. 132)• ステップ 8: AWS DMS のソースとターゲットのエンドポイントを作成する (p. 133)• ステップ 9: AWS DMS 移行タスクの作成と実行 (p. 136)• ステップ 10: データ移行が正常に完了したことを検証する (p. 140)• ステップ 11: チュートリアルのリソースを削除する (p. 142)

ステップ 1: CloudFormation テンプレートを使用してVPC で RDS インスタンスを起動する開始する前に、AWS CloudFormation テンプレートをダウンロードする必要があります。以下の手順に従います。

1. 以下のアーカイブをコンピュータにダウンロードします http://docs.aws.amazon.com/dms/latest/sbs/samples/dms-sbs-RDSOracle2Redshift.zip。

2. アーカイブから CloudFormation テンプレート (Oracle_Redshift_For_DMSDemo.template) を抽出します。

3. Oracle_Redshift_For_DMSDemo.template ファイルを現在のディレクトリにコピーアンドペーストします。

まず、このウォークスルーで使う AWS リソースをプロビジョニングする必要があります。

AWS CloudFormation を使用して、このチュートリアルの Amazon RDS リソースを作成するには


2. [Create Stack] を選択します。3. [Select Template (テンプレートを選択)] ページで、[Upload a template to Amazon S3 (Amazon S3 に

テンプレートをアップロード)] を選択します。4. [Choose File (ファイルを選択)] をクリックして dms-sbs-RDSOracle2Redshift.zip アーカイブ

から抽出した Oracle_Redshift_For_DMSDemo.template ファイルを選択します。5. [Next (次へ)] を選択します。[Specify Details] ページで、以下のようにパラメータ値を指定します。


スタックの名前 OracletoRedshiftDWusingDMS と入力します。

OracleDBName データベースの一意の名前を指定します。名前は文字で始める必要があります。デフォルト: ORCL。

OracleDBUsername Oracle インスタンスを管理する管理者 (DBA) ユーザーを指定します。デフォルト: oraadmin。

API バージョン 2016-01-01111







OracleDBPassword 管理者ユーザーのパスワードを入力します。デフォルトはです。oraadmin123

RedshiftDBName データベースの一意の名前を指定します。名前は文字で始める必要があります。デフォルト: test。

RedshiftDBUsername マスターユーザーのパスワードを入力します。デフォルト:Redshift#123。

ClientIP ローカルコンピュータの IP アドレスを CIDR (x.x.x.x/32)形式で指定します。IP アドレスは whatsmyip.org から取得できます。RDS インスタンスのセキュリティグループは、この IP アドレスへのアクセスを許可します。デフォルトは、すべての場所 (0.0.0.0/0) からのアクセスを許可するため、お勧めできません。このチュートリアル用の IPアドレスを使用してください。

API バージョン 2016-01-01112



6. [Next (次へ)] を選択します。[Options] ページで、[Next] を選択します。7. [Review] ページで詳細を確認し、正しい場合は [Create] を選択します。

API バージョン 2016-01-01113



API バージョン 2016-01-01114



8. AWS では、Amazon RDS Oracle インスタンスと Amazon Redshift クラスターのスタックの作成には20 分以上かかる場合があります。

9. スタックが作成されたら、[OracletoRedshiftDWusingDMS] スタックを選択し、[Outputs] ビューを選択します。JDBC 接続文字列の OracleJDBCConnectionString と RedshiftJDBCConnectionString を記録します。後ほど、このチュートリアルで Oracle および Amazon Redshift データベースに接続するときに使用します。

ステップ 2: SQL ツールと AWS Schema ConversionTool をローカルコンピュータにインストールする次に、SQL クライアントと AWS SCT をローカルコンピュータをインストールします。

このチュートリアルでは、SQL Workbench/J クライアントを使用して RDS インスタンスに接続し、移行の検証を行うことを前提としています。

API バージョン 2016-01-01115




1. SQL Workbench/J のウェブサイトから SQL Workbench/J をダウンロードし、ローカルコンピュータにインストールします。この SQL クライアントは無料のオープンソースであり、DBMS に依存しません。


3. 次の説明に従って、Amazon Redshift ドライバーファイル RedshiftJDBC41-1.1.17.1017.jar をダウンロードします。

a. Amazon Redshift クラスター管理ガイドの「前バージョンの JDBC ドライバー」で、ファイルのAmazon S3 URL を探します。

b. 同じガイドの「Amazon Redshift JDBC ドライバーのダウンロード」の説明に従って、ドライバーをダウンロードします。

4. SQL Workbench/J を使用して、次に示すように Oracle および Amazon Redshift 用の JDBC ドライバーの接続を設定します。

a. SQL Workbench/J で、[File] を選択し、[Manage Drivers] を選択します。b. ドライバーのリストから、[Oracle] を選択します。c. [Open (オープン)] アイコンを選択し、前のステップでダウンロードした ojdbc.jar ファイルを

選択します。[OK] を選択します。

d. ドライバーのリストから、[Redshift] を選択します。e. [Open (オープン)] アイコンを選択し、前のステップでダウンロードした Amazon Redshift JDBC

ドライバーを選択します。[OK] を選択します。

API バージョン 2016-01-01116

http://www.sql-workbench.net/downloads.html



https://docs.aws.amazon.com/redshift/latest/mgmt/jdbc-previous-versions.html

https://docs.aws.amazon.com/redshift/latest/mgmt/configure-jdbc-connection.html#download-jdbc-driver



次に、AWS SCT と必要な JDBC ドライバーをインストールします。

AWS SCT と必要な JDBC ドライバーをインストールするには

1. AWS Schema Conversion Tool ユーザーガイドの「AWS Schema Conversion Tool のインストールと更新」から AWS SCT をダウンロードします。

2. 手順に従って AWS SCT をインストールします。デフォルトでは、ツールのインストール先が C:\Program Files\AWS Schema Conversion Tool\AWS ディレクトリになります。

3. AWS SCT を起動します。4. AWS SCT で、[Settings] の [Global Settings] を選択します。5. [Settings] で、[Global Settings]、[Drivers] の順に選択し、[Oracle Driver Path] の [Browse] を選択しま

す。Oracle JDBC ドライバーを見つけ、[OK] を選択します。6. [Amazon Redshift Driver Path] の [Browse] を選択します。Amazon Redshift JDBC ドライバーを見つ

け、[OK] を選択します。[OK] を選択してダイアログボックスを閉じます。

API バージョン 2016-01-01117





ステップ 3: Oracle DB インスタンスへの接続をテストしてサンプルスキーマを作成するCloudFormation スタックを作成したら、SQL Workbench/J を使用して Oracle DB インスタンスへの接続をテストし、HR サンプルスキーマを作成します。

SQL Workbench/J を使用して Oracle DB インスタンスへの接続をテストし、サンプルスキーマを作成するには

1. SQL Workbench/J で、[File] を選択し、[Connect window] を選択します。以下の情報を使用して新しい接続プロファイルを作成します。


[New profile] の名前 RDSOracleConnection と入力します。

ドライバー Oracle (oracle.jdbc.OracleDriver) を選択します。

API バージョン 2016-01-01118




URL 前のステップで DMSdemo スタックの出力詳細を調べたときに記録した OracleJDBCConnectionString の値を使用します。


パスワード oraadmin123 と入力します。


API バージョン 2016-01-01119



Note

接続が失敗した場合は、CloudFormation テンプレートの作成時に割り当てた IP アドレスが、接続元の IP アドレスになっていることを確認します。これはインスタンスへの接続問題の最も一般的な原因です。

3. カスタム SQL スクリプト (Oraclesalesstarschema.sql) を使用して、移行に使用する SH スキーマを作成します。このスクリプトを取得するには、以下を実行します。

• 以下のアーカイブをコンピュータにダウンロードします http://docs.aws.amazon.com/dms/latest/sbs/samples/dms-sbs-RDSOracle2Redshift.zip。

• アーカイブから SQL スクリプト Oraclesalesstarschema.sql を抽出します。• Oraclesalesstarschema.sql ファイルを現在のディレクトリにコピーアンドペーストします。

a. テキストエディターで SQL スクリプトを開きます。スクリプト全体をコピーします。b. SQL Workbench/J で、Statement 1 が表示されている Default.wksp ウィンドウに SQL スクリプ

トを貼り付けます。c. [SQL] を選択し、[Execute All] を選択します。

API バージョン 2016-01-01120





4. 次の SQL クエリを実行し、HR スキーマに設定されたタイプと数のオブジェクトが正常に作成されたことを確認します。

Select OBJECT_TYPE, COUNT(*) from dba_OBJECTS where owner='SH' GROUP BY OBJECT_TYPE;

このクエリの結果は次のようになります。

API バージョン 2016-01-01121


ステップ 4: Amazon Redshift データベースへの接続をテストする

OBJECT_TYPE | COUNT(*)----------------+---------INDEX PARTITION | 40TABLE PARTITION | 8TABLE | 5INDEX | 15

5. 次の SQL クエリを実行して、テーブルの合計数と各テーブルの行数を確認します。

Select table_name, num_rows from dba_tables where owner='SH' order by 1;


TABLE_NAME | NUM_ROWS-----------+---------CHANNELS | 5CUSTOMERS | 8PRODUCTS | 66PROMOTIONS | 503SALES | 553

6. テーブルの整合性を確認します。次の SQL クエリを実行して、チャネル別の販売数を確認します。

Select b.channel_desc,count(*) from SH.SALES a,SH.CHANNELS b where a.channel_id=b.channel_id group by b.channel_desc order by 1;


CHANNEL_DESC | COUNT(*)-------------+---------Direct Sales | 710Internet | 52Partners | 344

Note

上に示したのは、検証クエリの一般例です。実際の移行を行うときに、同様のクエリを作成してスキーマとデータの整合性を検証してください。

ステップ 4: Amazon Redshift データベースへの接続をテストする次に、Amazon Redshift データベースへの接続をテストします。

SQL Workbench/J を使用して Amazon Redshift データベースへの接続をテストするには

1. SQL Workbench/J で、[File] を選択し、[Connect window] を選択します。[Create a new connectionprofile] アイコンを選択します。以下の情報を使用して、SQL Workbench/J で Amazon Redshift データベースに接続します。

API バージョン 2016-01-01122


ステップ 4: Amazon Redshift データベースへの接続をテストする


[New profile] の名前 RedshiftConnection と入力します。

ドライバー Redshift(com.amazon.redshift.jdbc42.Driver) を選択します。

URL 前のステップで DMSdemo スタックの出力詳細を調べたときに記録した RedshiftJDBCConnectionString の値を使用します。

[Username] redshiftadmin と入力します。

パスワード Redshift#123 と入力します。


Note

接続が失敗した場合は、CloudFormation テンプレートの作成時に割り当てた IP アドレスが、接続元の IP アドレスになっていることを確認します。これはインスタンスへの接続問題の最も一般的な原因です。

3. select current_date; などのサンプル SQL コマンドを実行して、Amazon Redshift DB インスタンスへの接続を検証します。

API バージョン 2016-01-01123


ステップ 5: AWS SCT を使用して Oracleスキーマを Amazon Redshift に変換する

ステップ 5: AWS SCT を使用して Oracle スキーマをAmazon Redshift に変換するデータを Amazon Redshift に移行する前に、次に示すように Oracle スキーマを Amazon Redshift スキーマに変換します。

AWS SCT を使用して Oracle スキーマを Amazon Redshift スキーマに変換するには

1. AWS SCT を起動します。AWS SCT で [File] を選択し、[New Project] を選択します。DWSchemaMigrationDemoProject という新しいプロジェクトを作成します。[New Project]ウィンドウに次の情報を入力し、[OK] を選択します。


プロジェクト名 DWSchemaMigrationDemoProject と入力します。

場所デフォルトの [Projects] フォルダとデフォルトの [DataWarehouse (OLAP)] オプションを使用します。

Source Database Engine [Oracle DW] を選択します。

Target Database Engine [Amazon Redshift] を選択します。




サーバー名 Oracle DB インスタンスへの接続に使用した[OracleJDBCConnectionString] の値を使用します。ただし、JDBC プレフィックス情報、ポートおよび

API バージョン 2016-01-01124



パラメータ操作データベース名のサフィックスは削除します。たとえば、SQL Workbench/J で使用したサンプル接続文字列が "jdbc:oracle:thin:@abc12345678.cqi87654abc.us-west-2.rds.amazonaws.com:1521:ORCL" であるとします。AWS SCT の [Server name (サーバー名)] では、"jdbc:oracle:thin:@" および ":1521:ORCL" を削除してサーバー名のみを使用します"abc12345678.cqi87654abc.us-west-2.rds.amazonaws.com"。


Oracle SID ORCL と入力します。

ユーザー名 oraadmin と入力します。


3. [OK] を選択してアラートボックスを閉じ、[OK] を選択してダイアログボックスを閉じて、Oracle DBインスタンスへの接続を開始します。Oracle DB インスタンス上のデータベース構造が、次のように表示されます。SH スキーマのみを選択します。

Note

SH スキーマがリストに表示されていない場合は、[Actions]、[Refresh from Database] の順に選択します。

API バージョン 2016-01-01125



4. [Connect to Amazon Redshift ( に接続)] を選択します。[Connect to Amazon Redshift ( に接続)] ダイアログボックスに次の情報を入力して、[Test Connection (テスト接続)] を選択します。



サーバー名 Amazon Redshift クラスターへの接続に使用した [RedshiftJDBCConnectionString] の値を使用します。ただし、JDBC プレフィックス情報とポートのサフィックスは削除します。たとえば、SQLWorkbench/J で使用したサンプル接続文字列が「jdbc:redshift://oracletoredshiftdwusingdms-redshiftcluster-abc123567.abc87654321.us-west-2.redshift.amazonaws.com:5439/test」であるとします。AWS SCT の [Server name] では、「jdbc:redshift://」と「:5439/test」を削除し、サーバー名として「oracletoredshiftdwusingdms-redshiftcluster-abc123567.abc87654321.us-west-2.redshift.amazonaws.com」のみを使用します。


ユーザー名 redshiftadmin と入力します。

API バージョン 2016-01-01126





AWS SCT は SH スキーマを分析して、Amazon Redshift への変換に関するデータベース移行評価レポートを作成します。

5. [OK] を選択してアラートボックスを閉じ、[OK] を選択してダイアログボックスを閉じて、AmazonRedshift DB インスタンスへの接続を開始します。

6. [Oracle DW] ビューで、[SH] スキーマのコンテキスト (右クリック) メニューを開き、[Create Report]を選択します。

7. レポートの概要を確認します。レポートを保存するには、[Save to CSV] または [Save to PDF] を選択します。

レポートには、AWS SCT を使用して変換できるオブジェクトのタイプ、移行に伴って発生する可能性がある問題、これらの問題の解決策についての説明があります。このチュートリアルでは、次のように表示されます。

API バージョン 2016-01-01127



API バージョン 2016-01-01128



8. [Action Items] タブを選択します。レポートには、AWS SCT を使用して変換できるオブジェクトのタイプ、移行に伴って発生する可能性がある問題、これらの問題の解決策についての説明があります。このチュートリアルでは、次のように表示されます。

9. [Schemas] リストの [SH] 項目でコンテキスト (右クリック) メニューを開き、[Collect Statistics] を選択します。AWS SCT でソースデータが分析され、ターゲット Amazon Redshift データベースに最適なキーが推奨されます。詳細については、「AWS Schema Conversion Tool の統計の収集またはアップロード」を参照してください。

10. [SH] スキーマのコンテキスト (右クリック) メニューを開き、[Convert schema] を選択します。11. 確認メッセージで、[Yes] を選択します。AWS SCT でスキーマがターゲットデータベース形式に変換

されます。

API バージョン 2016-01-01129

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_SchemaConversionTool.DW.Statistics.html

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_SchemaConversionTool.DW.Statistics.html



Note

Amazon Redshift のソートキーと分散キーの選択は最適なパフォーマンスに重要な影響を与えます。キーの選択は AWS SCT のキー管理を使用してカスタマイズできます。このチュートリアルでは、AWS SCT で推奨されているデフォルトを使用します。詳細については、「AWS スキーマ変換ツールを使用した Amazon Redshift の最適化」を参照してください。

12. Amazon Redshift ビューで、[SH] スキーマのコンテキスト (右クリック) メニューを開き、[Apply todatabase (データベースに適用)] を選択してスキーマスクリプトをターゲット Amazon Redshift インスタンスに適用します。

API バージョン 2016-01-01130

https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.RedshiftOpt.html



13. [SH] スキーマのコンテキスト (右クリック) メニューを開き、[Refresh from Database] を選択してターゲットデータベースから更新します。

データベーススキーマが変換されてソースからターゲットへインポートされます。

ステップ 6: スキーマ変換を検証するスキーマ変換を検証するには、Oracle データベースと Amazon Redshift データベースで見つかったオブジェクトを SQL Workbench/J で比較します。

SQL Workbench/J を使用してスキーマ変換を検証するには

1. SQL Workbench/J で、[File] を選択し、[Connect window] を選択します。前のステップで作成したRedshiftConnection を選択します。[OK] を選択します。

2. 次のスクリプトを実行して、ターゲットの Amazon Redshift データベースの SH スキーマのオブジェクトタイプと数を確認します。これらの値は、ソース Oracle データベースのオブジェクトの数と一致する必要があります。

SELECT 'TABLE' AS OBJECT_TYPE, TABLE_NAME AS OBJECT_NAME, TABLE_SCHEMA AS OBJECT_SCHEMAFROM information_schema.TABLESWHERE TABLE_TYPE = 'BASE TABLE'AND OBJECT_SCHEMA = 'sh';


object_type | object_name | object_schema------------+-------------+--------------TABLE | channels | sh TABLE | customers | sh TABLE | products | sh TABLE | promotions | sh TABLE | sales | sh

3. 次のクエリを使用して、Amazon Redshift クラスター内に作成されたソートキーと分散キーを検証します。

set search_path to '$user', 'public', 'sh';

SELECT tablename, "column", TYPE, encoding, distkey, sortkey, "notnull"FROM pg_table_defWHERE (distkey = TRUE OR sortkey <> 0);

クエリの結果に、AWS SCT のキー管理で選択された分散キー (distkey) とソートキー (sortkey)が反映されます。

tablename | column | type | encoding | distkey | sortkey | notnull-----------+---------------------+-----------------------------+----------+---------+---------+--------

API バージョン 2016-01-01131



めの適切なアクセス許可が必要です。必要なアクセス許可の詳細については、「AWS DMS を使用するのに必要な IAM アクセス許可」を参照してください。

2. [Create migration] を選択してデータベースの移行を開始します。3. [Welcome] ページで、[Next] を選択します。4. [Create replication instance] ページで、次に示すようにレプリケーションのインスタンス情報を指定

します。


名前 DMSdemo-repserver と入力します。

説明 DMS demo replication server などの簡単な説明を入力します。

インスタンスクラス [dms.t2.medium] を選択します。このインスタンスクラスでは小さいテーブルのセットを十分に移行できます。

VPC OracletoRedshiftusingDMS を選択します。これは、CloudFormation スタックによって作成された VPC です。

マルチ AZ No を選択します。

パブリックアクセス可能この項目は選択したままにします。

5. [Advanced] セクションで、デフォルト設定のままにして、[Next] を選択します。



1. ソース Oracle データベースとターゲット Amazon Redshift データベースの接続情報を指定します。次の表はソース設定の説明です。


エンドポイント識別子 Orasource (Amazon RDS Oracle エンドポイント) と入力します。


サーバー名 Oracle DB インスタンス名を入力します。この名前は AWS SCT で使用した [Server name]の値です (「abc123567.abc87654321.us-west-2.rds.amazonaws.com」など)。



API バージョン 2016-01-01133








SID ORCL と入力します。



エンドポイント識別子 Redshifttarget (Amazon Redshift エンドポイント) と入力します。

Target Engine [redshift] を選択します。

Servername Amazon Redshift DB インスタンス名を指定します。この名前は AWS SCT で使用した [Server name (サーバー名)] の値です (例: "oracletoredshiftdwusingdms-redshiftcluster-abc123567.abc87654321.us-west-2.redshift.amazonaws.com")。。



[Username] redshiftadmin と入力します。


データベース名 test と入力します。


API バージョン 2016-01-01134



2. ステータスが [Replication instance created successfully.] になるのを待ちます。3. ソースとターゲットの接続をテストするには、ソースとターゲットの接続で [Run Test] を選択しま

す。4. [Next (次へ)] を選択します。

API バージョン 2016-01-01135



ステップ 9: AWS DMS 移行タスクの作成と実行AWS DMS タスクを使用して、移行するスキーマと、移行のタイプを指定できます。既存のデータを移行するか、既存のデータを移行して継続的な変更をレプリケートするか、またはデータ変更のみをレプリケートするかを選択できます。このチュートリアルでは、既存のデータのみを移行します。




タスク名 migrateSHschema と入力します。

レプリケーションインスタンス DMSdemo-repserver (以前のステップで作成した AWSDMS レプリケーションインスタンス) を表示します。

ソースエンドポイント orasource (Amazon RDS for Oracle エンドポイント) と表示します。

ターゲットエンドポイント redshifttarget (Amazon Redshift エンドポイント) を表示します。

移行タイプ [Migrate existing data] オプションを選択します。



API バージョン 2016-01-01136



2. [Task Settings] セクションで、次の表に示すように設定を指定します。


ターゲットテーブル作成モード [Do nothing] を選択します。

レプリケーションに LOB 列を含める [Limited LOB mode] を選択します。

最大 LOB サイズ (KB) デフォルト値 (32) を受け入れます。


API バージョン 2016-01-01137



3. [Selection rules] セクションで、次の表に示すように設定を指定します。


スキーマ名 Enter a schema を選択します。

スキーマ名の例 SH% と入力します。

テーブル名の例タイプ %.

アクション Include を選択します。


API バージョン 2016-01-01138



4. [Add selection rule] を選択します。5. [タスクの作成] を選択します。

5.[タスクの作成] を選択します。タスクがすぐに開始されます。[Tasks] セクションでは、移行タスクのステータスが表示されます。

API バージョン 2016-01-01139



ステップ 10: データ移行が正常に完了したことを検証する移行タスクの完了後に、タスクの結果と予測結果を比較できます。

移行タスクの結果と予測結果を比較するには

1. ナビゲーションペインで、[Tasks] を選択します。2. 移行タスク (migrateSHschema) を選択します。3. 次に示すように、[Table statistics] タブを選択します。

API バージョン 2016-01-01140



4. SQL Workbench/J を使用して Amazon Redshift インスタンスに接続し、次に示すように SQL スクリプトを実行して、データベーステーブルが Oracle から Amazon Redshift に正常に移行されたかどうかを確認します。

select "table", tbl_rowsfrom svv_table_infowhereSCHEMA = 'sh'

API バージョン 2016-01-01141


ステップ 11: チュートリアルのリソースを削除する

order by 1;

結果は以下のようになります。

table | tbl_rows-----------+---------channels | 5customers | 8products | 66promotions | 503sales | 1106

5. 上のクエリで出力されたテーブルの合計数と各テーブルの行数が、RDS Oracle の予測結果と一致しているかどうかを検証するには、結果を以前のステップの結果と比較します。

6. 次のクエリを実行してテーブルの関係を確認します。このクエリでは従業員数が 10 人より多い部門を確認します。

Select b.channel_desc,count(*) from SH.SALES a,SH.CHANNELS b where a.channel_id=b.channel_id group by b.channel_desc order by 1;


channel_desc | count-------------+------Direct Sales | 355Internet | 26Partners | 172

7. 列の圧縮エンコードを検証します。

DMS では、Amazon Redshift の COPY オペレーションを使用してデータをロードします。デフォルトでは、COPY コマンドは空のターゲットテーブルをロードするたびに自動圧縮を適用します。このチュートリアルのサンプルデータは、自動圧縮を適用するほどの大きさではありません。より大きなデータセットを移行するときに、COPY によって自動圧縮が適用されます。

Amazon Redshift テーブルの自動圧縮の詳細については、「自動圧縮でテーブルをロードする」を参照してください。

圧縮エンコードを確認するには、次のクエリを実行します。

SELECT *FROM pg_table_defWHERE schemaname = 'sh’;

これで、Amazon RDS for Oracle DB インスタンスから Amazon Redshift へのデータベース移行が正常に完了しました。

ステップ 11: チュートリアルのリソースを削除するこのチュートリアルを完了したら、チュートリアルで使用した AWS リソースに対する課金を避けるために、以下の手順を実行します。必ず手順どおりに実行してください。そうしないと、リソース間に依存関係がある場合に、一部のリソースが削除されません。

API バージョン 2016-01-01142

https://docs.aws.amazon.com/redshift/latest/dg/c_Loading_tables_auto_compress.html


次のステップ

AWS DMS リソースを削除するには

1. ナビゲーションペインで、[Tasks (タスク)]、移行タスク (migratehrschema)、[Delete (削除)] の順に選択します。

2. ナビゲーションペインで、[Endpoints (エンドポイント)]、Oracle のソースエンドポイント(orasource)、[Delete (削除)] の順に選択します。

3. Amazon Redshift ターゲットエンドポイント (redshifttarget) を選択してから、[Delete (削除)] を選択します。

4. ナビゲーションペインで、[Replication instances (レプリケーションインスタンス)]、レプリケーションインスタンス (DMSdemo-repserver)、[Delete (削除)] の順に選択します。

次に、AWS CloudFormation スタック DMSdemo を削除する必要があります。

AWS CloudFormation スタックを削除するには


IAM ユーザーとしてサインインしている場合は、AWS CloudFormation にアクセスするための適切なアクセス権限が必要です。

2. CloudFormation スタック、OracletoRedshiftDWusingDMS を選択します。3. [Actions] の [Delete stack] を選択します。

OracletoRedshiftDWusingDMS スタックに関連付けられたリソースが AWS CloudFormation によってクリーンアップされている間は、スタックのステータスが [DELETE_IN_PROGRESS] に変わります。AWS CloudFormation でリソースのクリーンアップが終了すると、スタックがリストから削除されます。

次のステップこのチュートリアルでは取り上げていませんが、AWS DMS の以下のような機能も試すことができます。

• AWS DMS の変更データのキャプチャ (CDC) 機能。データの継続的なレプリケーションに役立ちます。• 変換アクション。移行プロセスの一環として、選択されたスキーマやテーブルに変換を指定して適用で

きます。

詳細については、AWS DMS のドキュメントを参照してください。

API バージョン 2016-01-01143




MySQL との互換性があるデータベースを AWS に移行する

アマゾンウェブサービス (AWS) のいくつかのサービスでは、MySQL との互換性があるデータベースを実行できます。Amazon Relational Database Service (Amazon RDS) は、MySQL、MariaDB、AmazonAurora MySQL など、MySQL との互換性があるデータベースをサポートします。AWS Elastic CloudComputing Service (EC2) は、MySQL との互換性があるデータベースを実行するためのプラットフォームを提供します。

移行元ソリューション

RDS MySQL DB インスタンス Amazon RDS MySQL DB スナップショットから Amazon AuroraMySQL DB クラスターに直接データを移行できます。詳細については、「Amazon RDS MySQL DB インスタンスから DB クラスターにデータを移行するAmazon Aurora MySQL (p. 156)」を参照してください。

Amazon RDS 外部の MySQLデータベース

データベースが InnoDB または MyISAM のテーブルスペースをサポートしている場合、これらのオプションを使用して、データを AmazonAurora MySQL DB クラスターに移行できます。

• mysqldump ユーティリティを使用してデータのダンプを作成し、そのデータを既存の Amazon Aurora MySQL DB クラスターにインポートできます。

• データベースから Amazon Simple Storage Service (Amazon S3)バケットにソースファイルをコピーし、これらのファイルからAmazon Aurora MySQL DB クラスターを復元できます。このオプションは、mysqldump を使用したデータの移行よりもかなり高速になる場合があります。

詳細については、「mysqldump を使用した MySQL への移行AmazonAurora MySQL (p. 156)」を参照してください。

MySQL と互換性がないデータベース

AWS Database Migration Service (AWS DMS) を使用して、MySQLデータベースからデータを移行することもできます。ただし、非常に大きいデータベースの場合は、「Amazon S3 MySQLを使用した外部Amazon Aurora MySQLデータベースからへのデータの移行 (p. 145)」で説明しているように、データベースのソースファイルをコピーし、Amazon Aurora MySQL DB インスタンスにそれらのファイルを復元することで、データの移行にかかる時間を大幅に短縮できます。

AWS DMS の詳細については、「AWS Database Migration サービスとは」を参照してください。

API バージョン 2016-01-01144




Amazon S3 MySQLを使用した外部Amazon AuroraMySQLデータベースからへのデータの移行

との互換性があるデータベースのへの移行MySQLAmazon AuroraMySQL

データベースが InnoDB テーブルスペースMyISAMまたはテーブルスペースをサポートしている場合、これらのオプションを使用して、データを Amazon Aurora MySQL DB クラスターに移行できます。

• mysqldump ユーティリティを使用してデータのダンプを作成し、そのデータを既存の Amazon AuroraMySQL DB クラスターにインポートできます。詳細については、を参照してください mysqldump を使用した MySQL への移行Amazon Aurora MySQL (p. 156)。

• データベースから Amazon S3 バケットにソースファイルをコピーし、これらのファイルから AmazonAurora MySQL DB クラスターを復元できます。このオプションは、を使用したデータの移行よりもかなり高速になる場合がありますmysqldump。詳細については、「」を参照してくださいAmazon S3MySQLを使用した外部Amazon Aurora MySQLデータベースからへのデータの移行 (p. 145)。

Amazon S3 MySQLを使用した外部Amazon AuroraMySQLデータベースからへのデータの移行

ソースMySQLバージョン 5.5、5.6、または 5.7 データベースから Amazon S3バケットにソースファイルをコピーし、それらのファイルから Amazon Aurora MySQL DB クラスターを復元できます。

このオプションは、mysqldump を使用したデータ移行よりもかなり高速になる場合があります。これは、mysqldump を使用することですべてのコマンドが再実行され、新しい Amazon Aurora MySQL DB クラスターのソースデータベースからスキーマとデータが再作成されるためです。ソースMySQLデータファイルをコピーすることで、 Amazon Aurora MySQLはこれらのファイルを即座に DB クラスター用のデータとして使用できます。

Note

Amazon Aurora MySQL バケットのバックアップファイルからの Amazon S3 DB クラスターの復元は、アジアパシフィック (ムンバイ) リージョンではサポートされていません。

Amazon Aurora MySQL は、データベースからすべてを復元するわけではありません。ソースMySQLまたはデータベースからデータベーススキーマと以下の項目の値を保存し、作成後に復元された MariaDB DBクラスターに追加する必要があります。Amazon Aurora MySQL

• ユーザーアカウント• 関数• ストアドプロシージャ• タイムゾーン情報。タイムゾーン情報は、Amazon Aurora MySQL DB クラスターのローカルオペレー

ティングシステムからロードされます。

PrerequisitesAmazon S3 バケットにデータをコピーし、それらのファイルから DB クラスターを復元するには、事前に以下の作業を行う必要があります。

API バージョン 2016-01-01145


Prerequisites

• Percona をローカルサーバーにインストールします。XtraBackup• お客様に代わって Amazon Aurora MySQL が Amazon S3 バケットにアクセスすることを許可します。

Percona のインストールXtraBackupAmazon Aurora MySQLは、Percona を使用して作成されたファイルから DB XtraBackup クラスターを復元できます。 Percona は、Percona XtraBackup のウェブサイト (https://www.percona.com/doc/percona-xtrabackup/2.4/installation) からインストールできます。

必要なアクセス権限MySQLデータを Amazon Aurora MySQL DB クラスターに移行するには、複数のアクセス権限が必要です。

• Amazon S3 バケットから新しいクラスターを作成することを Amazon RDS に依頼するユーザーは、AWS アカウントのバケットを一覧表示するためのアクセス許可を必要とします。このアクセス権限は、AWS Identity and Access Management (IAM) ポリシーを使用してユーザーに付与します。

• Amazon RDS は、ユーザーに代わって Amazon Aurora MySQL DB クラスターを作成するために必要なファイルが保存されている Amazon S3 バケットにアクセスするためのアクセス許可を必要とします。IAM サービスロールを使用して、Amazon RDS に必要なアクセス権限を付与します。

• リクエストを実行するユーザーには、AWS アカウントの IAM ロールをリストするアクセス権限も必要です。

• リクエストを実行するユーザーが IAM サービスロールを作成するか、Amazon RDS による IAM サービスロールの作成をリクエストする場合 (コンソールを使用)、ユーザーには AWS アカウントの IAM ロールを作成するアクセス権限が必要です。

たとえば、次の IAM ポリシーでは、コンソールを使用して IAM ロールをリストし、IAM ロールを作成して、アカウントの S3 バケットをリストするために必要な最小のアクセス権限をユーザーに付与します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:ListRoles", "iam:CreateRole", "iam:CreatePolicy", "iam:AttachRolePolicy", "s3:ListBucket", "s3:ListObjects" ], "Resource": "*" } ]}

さらに、ユーザーが IAM ロールを S3 バケットに関連付けるためには、IAM ユーザーに、その IAM ロールの iam:PassRole アクセス権限が必要です。このアクセス権限により、ユーザーが S3 バケットに関連付けることができる IAM ロールを管理者が制限できます。

たとえば、次の IAM ポリシーでは、S3Access という名前のロールをユーザーが S3 バケットに関連付けることができます。

{ "Version":"2012-10-17", "Statement":[

API バージョン 2016-01-01146

https://www.percona.com/doc/percona-xtrabackup/2.4/installation


Prerequisites

{ "Sid":"AllowS3AccessRole", "Effect":"Allow", "Action":"iam:PassRole", "Resource":"arn:aws:iam::123456789012:role/S3Access" } ]}

IAM サービスロールの作成[新規ロールの作成] オプション (このトピックで後述) を選択して、Amazon RDS マネジメントコンソールでロールを作成することができます。このオプションを選択して新しいロールの名前を指定すると、Amazon RDS は指定された名前で S3 バケットに Amazon RDS がアクセスするために必要な IAMサービスロールを作成します。

または、次の手順を使用して手動でロールを作成できます。

Amazon RDS が Amazon S3 にアクセスするための IAM ロールを作成するには

1. AWS マネジメントコンソールにサインインし、IAM コンソール（https://console.aws.amazon.com/iam/）を開きます。

2. 左のナビゲーションペインで、[Roles] を選択します。3. [新しいロールの作成] を選択し、新しいロールの [ロール名] の値を指定して、[次のステップ] を選択

します。4. [AWS Service Roles] で [Amazon RDS] を見つけ、[Select] を選択します。5. [Attach Policy] ステップで、アタッチするポリシーを選択しないでください。代わりに、[Next Step]

を選択します。6. ロール情報を確認し、[Create Role] を選択します。7. ロールのリストで、新しく作成したロールの名前を選択します。[Permissions] タブを選択します。8. [Inline Policies] を選択します。新しいロールにアタッチされたポリシーはないため、作成するよう求

められます。リンクをクリックして新しいポリシーを作成します。9. [Set Permissions] ページで、[Custom Policy] を選択し、次に [Select] をクリックします。10. ポリシー名 ( など) S3-bucket-policy を入力します。ポリシードキュメントで次のコードを追加

し、を置き換えます。<bucket name> アクセスを許可する S3 バケットの名前に置き換えます。

ポリシードキュメントの一部として、ファイル名プレフィックスを含めることもできます。プレフィックスを指定すると、Amazon Aurora MySQL は指定されたプレフィックスで始まる S3 バケットのファイルを使用して DB クラスターを作成します。プレフィックスを指定しない場合、AmazonAurora MySQL は S3 バケット内のすべてのファイルを使用して DB クラスターを作成します。

プレフィックスを指定するには、を置き換えます。<prefix> 以下をファイル名のプレフィックスで囲みます。プレフィックスの後にアスタリスク (*) を含めます。プレフィックスを指定しない場合は、アスタリスクのみを指定します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::<bucket name>" ]

API バージョン 2016-01-01147

https://console.aws.amazon.com/iam/

https://console.aws.amazon.com/iam/


ステップ 1: DB クラスターとして復元するためのファイルのバックアップ

}, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::<bucket name>/<prefix>*" ] } ]}

11. [Apply Policy (ポリシーの適用)] を選択します。

ステップ 1: DB クラスターとして復元するためのファイルのバックアップDB クラスターを作成するために S3 から復元できるMySQLデータベースファイルのバックアップを作成するには、Percona Xtrabackup ユーティリティ (Amazon Aurora MySQL) を使用してデータベースをバックアップします。innobackupex

たとえば、次のコマンドはデータベースのバックアップを作成し、ファイルをMySQLフォルダに保存します。/s3-restore/backup

innobackupex --user=myuser --password=<password> --no-timestamp /s3-restore/backup

バックアップを 1 つのファイル (必要に応じて分割できます) に圧縮する場合、以下のいずれかの形式を使用して --stream オプションを使用してバックアップを保存できます。

• Gzip (.gz)• tar (.tar)• Percona xbstream (.xbstream)

たとえば、次のコマンドでは、複数の Gzip ファイルに分割されたMySQLデータベースのバックアップを作成します。パラメータの値は、小規模なテストデータベースを対象にして示されています。実際のシナリオでは、必要なパラメータ値を決定する必要があります。

innobackupex --user=myuser --password=<password> --stream=tar \ /mydata/s3-restore/backup | split -d --bytes=512000 \ - /mydata/s3-restore/backup3/backup.tar.gz

たとえば、次のコマンドでは、複数の tar ファイルに分割されたMySQLデータベースのバックアップを作成します。

innobackupex --user=myuser --password=<password> --stream=tar \ /mydata/s3-restore/backup | split -d --bytes=512000 \ - /mydata/s3-restore/backup3/backup.tar

たとえば、次のコマンドでは、複数の xbstream ファイルに分割されたMySQLデータベースのバックアップを作成します。

innobackupex --stream=xbstream \ /mydata/s3-restore/backup | split -d --bytes=512000 \ - /mydata/s3-restore/backup/backup.xbstream

API バージョン 2016-01-01148


ステップ 2: Amazon S3 バケットにファイルをコピーする

Amazon S3 では、バケットにアップロードされるファイルのサイズは 5 テラバイト (TB) に制限されます。データベースのバックアップデータが 5 TB を超える場合は、split コマンドを使用して、それぞれが 5 TB 未満の複数のファイルにバックアップファイルを分割する必要があります。

Amazon Aurora MySQL では、Percona Xtrabackup を使用して作成された部分バックアップがサポートされていません。データベースのソースファイルをバックアップするときに、--include、--tables-file、または --databases オプションを使用して部分バックアップを作成することはできません。

詳細については、「The innobackupex Script」を参照してください。

Amazon Aurora MySQL では、ファイル名に基づいてバックアップファイルを使用します。ファイル形式に基づいた適切なファイル拡張子でバックアップファイルの名前を付けてください。たとえば、Perconaxbstream 形式を使用して保存されるファイルでは、.xbstream のようにします。

Amazon Aurora MySQL では、アルファベット順および通常の数値順にバックアップファイルが消費されます。バックアップファイルが適切な順序で書き込まれ、名前が付けられるように、split コマンドを発行するときは必ず innobackupex オプションを使用します。

ステップ 2: Amazon S3 バケットにファイルをコピーするPercona Xtrabackup ユーティリティを使用してMySQLデータベースをバックアップしたら、バックアップファイルを Amazon S3バケットにコピーできます。

ファイルを作成して Amazon S3バケットにアップロードする方法については、Amazon S3 入門ガイドの「Amazon Simple Storage Service の開始方法」を参照してください。

ステップ 3: Amazon S3 バケットからの AuroraMySQL DB クラスターの復元Amazon RDS コンソールを使用して、Amazon S3 バケットから新しい Amazon Aurora MySQL DB クラスターにバックアップファイルを復元できます。

Amazon Aurora MySQL DB クラスターをファイルから S3 バケットに復元するには

1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

2. RDS ダッシュボードで、[S3 から Aurora MySQL DB クラスターを復元] を選択します。3. [Specify Source Backup Details] で、以下を指定します。


ソースエンジン現在、Amazon Aurora MySQL は mysql データベースエンジン用のバックアップファイルからのみの復元をサポートしています。

ソースエンジンのバージョンバックアップファイルの作成元のMySQLデータベースのバージョンを指定します 5.6.22 (バージョン5.5、5.6、5.7 など)。MySQL

S3 バケットの選択バックアップファイルが保存されている Amazon S3 バケットを選択します。

S3 バケットプレフィックス (オプション)

Amazon S3 バケットに保存されているファイルのファイルパスプレフィックスを指定します。[S3 バケットプレ

API バージョン 2016-01-01149

https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html

https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html

https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html

https://console.aws.amazon.com/rds/



ステップ 3: Amazon S3 バケットからの Aurora MySQL DB クラスターの復元

使用するオプション操作フィックス] はオプションです。プレフィックスを指定しない場合、Amazon Aurora MySQL は S3 バケットのルートフォルダにあるすべてのファイルを使用して DBクラスターを作成します。プレフィックスを指定すると、Amazon Aurora MySQL はファイルのフルパスが指定されたプレフィックスで始まる S3 バケットのファイルを使用して DB クラスターを作成します。

Amazon Aurora MySQL は、S3 バケットのサブフォルダを走査してバックアップファイルを探しません。[S3 バケットプレフィックス] により識別されるフォルダのファイルのみ使用されます。バックアップファイルを S3 バケットのサブフォルダに保存する場合、ファイルが保存されるフォルダのフルパスを識別するプレフィックスを指定する必要があります。

たとえば、S3 バケットの backups というサブフォルダにバックアップファイルを保存し、複数のバックアップファイルセットがそれぞれ独自のディレクトリ (gzip_backup1、gzip_backup2 など) にある場合、gzip_backup1 フォルダのファイルから復元するにはプレフィックス backups/gzip_backup1 を指定します。

IAM ロールお客様に代わって Amazon S3 にアクセスすることをAmazon Aurora MySQL に許可するために作成した IAMロールを選択します。IAM ロールを作成していない場合は、[Create a New Role] を選択して作成できます。

4. [Next Step (次のステップ)] を選択します。5. [Specify DB Details] ページで、DB クラスターの情報を指定します。次の表は、DB インスタンスの設

定を示しています。


DB インスタンスクラス DB クラスターの各インスタンスの処理条件やメモリ要件を定義する DB クラスターを選択します。Aurora MySQLは、db.r3.large、db.r3.xlarge、db.r3.2xlarge、db.r3.4xlarge、db.r3.8xlargeDB インスタンスクラスをサポートしています。DB インスタンスクラスのオプションの詳細については、AmazonRDS のドキュメントを参照してください。

マルチ AZ 配置フェイルオーバーのサポート用に他のアベイラビリティーゾーンで Aurora MySQL レプリカを作成するかどうかを決めます。各アベイラビリティーゾーンの詳細については、Amazon RDS のドキュメントを参照してください。

DB Instance Identifier DB クラスターのプライマリインスタンスの名前を入力します。この識別子は、DB クラスターのプライマリインスタンスのエンドポイントアドレスで使用されます。

DB インスタンス識別子には次の制約があります。

• 1 ～ 63 文字の英数字またはハイフンを使用する必要があります。

• 1 字目は文字である必要があります。

API バージョン 2016-01-01150

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html



使用するオプション操作• ハイフンを、文字列の最後に使用したり、2 つ続けて使

用したりすることはできません。• 各リージョンの各 AWS アカウントのすべての DB イン

スタンスの中で一意である必要があります。

Master Username DB クラスターにログオンするためのマスターユーザー名を英数字で入力します。マスターユーザー名アカウントに付与されるデフォルト権限には以下が含まれます。create, drop, references, event,alter, delete, index, insert, select,update, create temporary tables, locktables, trigger, create view, show view,alter routine, create routine, execute,create user, process, show databases, grantoption。

マスターパスワードマスターユーザーのパスワードを 8 ～ 41 文字で入力します。使用できるのは印刷可能な ASCII 文字 (/、"、@ を除く) です。

一般的な [Specify DB Details] ページは次のようになります。

6. マスターパスワードを確認し、[Next] を選択します。

API バージョン 2016-01-01151



7. [Configure Advanced Settings] ページで、Aurora MySQL DB クラスターのその他の設定をカスタマイズできます。次の表は、DB クラスターの詳細設定を示しています。


VPC DB クラスターをホストする VPC を選択します。[新しいVPC の作成] を選択して、Amazon RDS で自動的に VPCを作成します。詳細については、このトピックで前述した「」を参照してください。

サブネットグループ DB クラスターで使用する DB サブネットグループを選択します。[Create a New DB Subnet Group] を選択し、Amazon RDS で DB サブネットグループを作成します。詳細については、このトピックで前述した「」を参照してください。

パブリックアクセス可能 DB クラスターにパブリック IP アドレスを指定するには[Yes] を選択します。それ以外の場合は [No] を選択します。 DB クラスターのインスタンスは、パブリック DB インスタンスとプライベート DB インスタンスの両方を混在させることができます。インスタンスをパブリックアクセスから隠す方法については、Amazon RDS のドキュメントを参照してください。

アベイラビリティーゾーン特定のアベイラビリティーゾーンを指定するかどうかを指定します。各アベイラビリティーゾーンの詳細については、Amazon RDS のドキュメントを参照してください。

VPC セキュリティグループ DB クラスターへのネットワークアクセスの保護用に 1 つ以上の VPC セキュリティグループを選択します。[Createa New VPC Security Group] を選択して、Amazon RDS でVPC セキュリティグループを作成します。詳細については、このトピックで前述した「」を参照してください。

DB クラスター識別子 DB クラスターの名前を入力します。この名前は選択したリージョン内で、お客様のアカウントに対して一意である必要があります。この識別子は、DB クラスターのクラスターエンドポイントアドレスで使用されます。クラスターエンドポイントの詳細については、Amazon RDS のドキュメントを参照してください。

DB クラスター識別子には以下の制約があります。

• 1 ～ 63 文字の英数字またはハイフンを使用する必要があります。

• 1 字目は文字である必要があります。• ハイフンを、文字列の最後に使用したり、2 つ続けて使

用したりすることはできません。• 各リージョンの各 AWS アカウントのすべての DB クラ

スターの中で一意である必要があります。

Database Name データベースの名前を、英数字 8 文字以内で入力します。名前の指定がない場合、Amazon RDS は DB クラスターにデータベースを作成しません。

API バージョン 2016-01-01152

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.CreateInstance.html


https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html






Database Port データベースにアクセスするためにアプリケーションやユーティリティで使用されるポートを指定します。AuroraMySQLDB クラスターのデフォルトMySQLポートは 3306です。会社のファイアウォールによっては、デフォルトMySQLポートへの接続がブロックされます。会社のファイアウォールがデフォルトのポートをブロックする場合は、新しい DB クラスター用に別のポートを選択します。

パラメーターグループパラメータグループを選択します。Aurora MySQL にはデフォルトのパラメータグループが用意されています。また、独自のパラメータグループを作成することもできます。パラメータグループの詳細については、Amazon RDSのドキュメントを参照してください。

Option Group オプショングループを選択します。Aurora MySQL にはデフォルトのオプショングループが用意されています。また、独自のオプショングループを作成することもできます。オプショングループの詳細については、Amazon RDSのドキュメントを参照してください。

暗号を有効化この DB クラスターを保管時に暗号化するには、[Yes] を選択します。詳細については、「Amazon RDS ドキュメント」を参照してください。

優先度インスタンスのフェイルオーバー優先度を選択します。値を選択しない場合、デフォルト値は tier-1 になります。この優先度により、プライマリインスタンスの障害からの復旧時に、Aurora MySQL レプリカを昇格する順序が決まります。詳細については、「Amazon RDS ドキュメント」を参照してください。

バックアップ保持期間 Aurora MySQL がデータベースのバックアップコピーを保持する期間 (1 ～ 35 日) を選択します。バックアップコピーは、データベースの秒単位のポイントインタイム復元(PITR) で使用できます。

Enable Enhanced Monitoring DB クラスターが実行されているオペレーティングシステムに対してリアルタイムでのメトリクスの収集を有効にするには、[Yes] を選択します。詳細については、「AmazonRDS ドキュメント」を参照してください。

詳細度このオプションは、[Enable Enhanced Monitoring] が [Yes]に設定されている場合にのみ使用できます。DB クラスターのメトリクスを収集する間隔を秒単位で設定します。

Auto Minor Version Upgrade DB クラスターで Aurora MySQL DB エンジンのマイナーバージョンアップグレードをリリースと同時に自動的に受信するには、[MySQLYes] を選択します。

マイナーバージョン自動アップグレードオプションは、MySQLDB クラスターのAmazon Aurora MySQLマイナーエンジンバージョンに対するアップグレードのみに適用されます。システム安定性を維持するために適用される定期的なパッチは適用されません。

メンテナンスウィンドウ週 1 回のシステムメンテナンスを実行できる時間帯を選択します。

API バージョン 2016-01-01153












一般的な [Configure Advanced Settings] ページは次のようになります。

API バージョン 2016-01-01154



API バージョン 2016-01-01155


mysqldump を使用した MySQL への移行Amazon Aurora MySQL

8. [DB インスタンスの起動] を選択して Aurora MySQL DB インスタンスを起動し、[Close (閉じる)] を選択してウィザードを閉じます。

Amazon RDS コンソールでは、新しい DB インスタンスが DB インスタンスのリストに表示されます。DB インスタンスが作成されて使用できるようになるまで、DB インスタンスのステータスは [作成中] となります。ステータスが [available] に変わったら、DB クラスターのプライマリインスタンスに接続できます。DB インスタンスクラスと割り当てられたストレージによっては、新しいインスタンスを使用できるようになるまで数分かかることがあります。

新しく作成したクラスターを表示するには、Amazon RDS コンソールで [クラスター] ビューを選択します。詳細については、「Amazon RDS ドキュメント」を参照してください。

クラスターのポートとエンドポイントをメモします。クラスターのエンドポイントとポートは、書き込みまたは読み取りオペレーションを実行するすべてのアプリケーション用の JDBC 接続文字列とODBC 接続文字列で使用します。

mysqldump を使用した MySQL への移行AmazonAurora MySQL

mysqldump ユーティリティを使用してデータのダンプを作成し、そのデータを既存の Amazon AuroraMySQL DB クラスターにインポートできます。

Amazon Aurora MySQLは MySQL と互換性のあるデータベースであるため、このmysqldumpユーティリティを使用して MySQLまたは MariaDB データベースから既存の Amazon Aurora MySQL DB クラスターにデータをコピーできます。

Amazon RDS MySQL DB インスタンスから DBクラスターにデータを移行するAmazon AuroraMySQL

以下で説明するように、Amazon RDS スナップショットから Amazon Aurora MySQL DB クラスターにデータを移行 (コピー) できます。

API バージョン 2016-01-01156

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Viewing.html


RDS MySQL スナップショットのへの移行Aurora MySQL

Note

Amazon Aurora MySQLMySQLはと互換性があるため、MySQLデータベースと MySQL DB クラスターの間でレプリケーションをセットアップすることで、Amazon Aurora MySQLデータベースのデータを移行できます。MySQLデータベースではMySQLバージョン 5.5 以降を実行することをお勧めします。

RDS MySQL スナップショットのへの移行AuroraMySQLDB インスタンスの DB スナップショットを移行して、 Amazon RDS DB クラスターを作成できます。MySQLAurora MySQL新しい DB クラスターには、元の Amazon RDS MySQL DB インスタンスのデータが入力されます。DB スナップショットは、Amazon RDS5.6 を実行している MySQL DB インスタンスから作成されている必要があります。

手動で作成された DB スナップショットと自動的に作成された DB スナップショットのどちらも移行できます。DB クラスターが作成された後、オプションの Aurora MySQL レプリカを作成できます。

実行する必要がある一般的な手順は次のとおりです。

1. Amazon Aurora MySQL DB クラスターをプロビジョニングするための容量を決定します。詳細については、Amazon RDS ドキュメントを参照してください。

2. コンソールを使用して、Amazon RDSMySQL5.6 インスタンスが配置されているリージョン内にスナップショットを作成します。

3. DB スナップショットが DB クラスターと同じリージョン内にない場合は、Amazon RDS コンソールを使用して DB スナップショットをそのリージョンにコピーします。DB スナップショットをコピーする方法については、Amazon RDS のドキュメントを参照してください。

4. コンソールを使用して DB スナップショットを移行し、Amazon Aurora MySQL5.6 の元の MySQL DBインスタンスと同じデータベースを持つ DB クラスターを作成します。

Warning

Amazon RDS では、各 AWS アカウントによる各リージョンへのスナップショットのコピーは 1度に 1 つに制限されています。

必要な容量MySQLDB インスタンスのスナップショットを Aurora MySQL DB クラスターに移行するとき、 AuroraMySQLは、スナップショットのデータを移行する前に Amazon Elastic Block Store (Amazon EBS) ボリュームを使用してそのデータの書式を設定します。移行するデータの書式を設定するために追加容量が必要になる場合があります。DB クラスターにデータを移行するときは、以下のガイドラインと制限に従ってください。

• Amazon Aurora MySQL では最大 64 TB のストレージがサポートされていますが、スナップショットのAurora MySQL DB クラスターへの移行処理は、スナップショットの EBS ボリュームのサイズに制限されます。したがって、お客様が移行できるスナップショットの最大サイズは 6 TB です。

• MyISAMテーブルではないテーブルおよび圧縮されていないテーブルのサイズは、最大 6 TB が可能です。MyISAMテーブルがある場合、では、と互換性のあるテーブルに変換するために、ボリュームに追加のスペースAurora MySQLが必要になりますAurora MySQL。圧縮されたテーブルの場合、AuroraMySQL では、圧縮されたテーブルを Aurora MySQL クラスターボリュームに保存する前に展開するため、ボリュームに追加のスペースが必要になります。追加のスペースが必要になるため、MyISAMDB インスタンスから移行される MySQLおよび圧縮テーブルのサイズが 3 TB を超えていないことを確認する必要があります。

API バージョン 2016-01-01157

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html



Amazon Aurora MySQL にデータを移行するために必要な領域の縮小Amazon Aurora MySQL に移行する前にデータベーススキーマを変更することもできます。このような変更は、次のような場合に便利です。

• 移行プロセスを迅速化したい。• プロビジョニングするために必要な領域の量がわからない場合。• データを移行しようとしたが、プロビジョニング済み領域の不足で移行が失敗した場合。

以下の変更を行うことで、データベースを Amazon Aurora MySQL に移行するプロセスを改善できます。

Important

これらの更新は、本稼働インスタンスではなく、本稼働データベースのスナップショットから復元された新しい DB インスタンスに対して実行します。その後、新しい DB インスタンスのスナップショットからデータを Amazon Aurora MySQL DB クラスターに移行することで、本稼働データベースに対するサービスの中断を回避できます。

テーブルタイプ制限またはガイドライン

MyISAM テーブル Amazon Aurora MySQLはInnoDBテーブルのみをサポートしています。データベースにMyISAMテーブルがある場合は、に移行する前にそれらのテーブルを変換する必要がありますAmazon Aurora MySQL。変換プロセスには、移行手順中に MyISAMがInnoDB変換するための追加領域が必要です。

領域不足が発生する可能性を低く抑えたり、移行プロセスを高速化するには、移行前にすべてのMyISAMテーブルをInnoDBテーブルに変換します。処理後のInnoDBテーブルのサイズは、がそのテーブルAmazon Aurora MySQLに対して必要とするサイズと同じになります。MyISAMテーブルを InnoDB に変換するには、次のコマンドを実行します。

alter table <schema>.<table_name> engine=innodb,algorithm=copy;

圧縮テーブル Amazon Aurora MySQL では、圧縮テーブル(ROW_FORMAT=COMPRESSED を使用して作成されたテーブル) をサポートしていません。

スペースが不足する可能性を減らしたり、移行処理を高速化するには、圧縮テーブルを、 ROW_FORMAT 、、または DEFAULT に設定して展開COMPACTします。DYNAMICREDUNDANT 詳細については、https://dev.mysql.com/doc/refman/5.6/en/innodb-row-format.htmlを参照してください。

既存の MySQL DB インスタンスで次の SQL スクリプトを使用して、データベース内のテーブルまたは圧縮テーブルとしてテーブルをリストできます。MyISAM

-- This script examines a MySQL database for conditions that will block-- migrating the database into an Amazon Aurora MySQL DB.-- It needs to be run from an account that has read permission for the-- INFORMATION_SCHEMA database.

API バージョン 2016-01-01158

https://dev.mysql.com/doc/refman/5.6/en/innodb-row-format.html



-- Verify that this is a supported version of MySQL.

select msg as `==> Checking current version of MySQL.`from ( select 'This script should be run on MySQL version 5.6. ' + 'Earlier versions are not supported.' as msg, cast(substring_index(version(), '.', 1) as unsigned) * 100 + cast(substring_index(substring_index(version(), '.', 2), '.', -1) as unsigned) as major_minor ) as Twhere major_minor <> 506;

-- List MyISAM and compressed tables. Include the table size.

select concat(TABLE_SCHEMA, '.', TABLE_NAME) as `==> MyISAM or Compressed Tables`,round(((data_length + index_length) / 1024 / 1024), 2) "Approx size (MB)"from INFORMATION_SCHEMA.TABLESwhere ENGINE <> 'InnoDB' and ( -- User tables TABLE_SCHEMA not in ('mysql', 'performance_schema', 'information_schema') or -- Non-standard system tables ( TABLE_SCHEMA = 'mysql' and TABLE_NAME not in ( 'columns_priv', 'db', 'event', 'func', 'general_log', 'help_category', 'help_keyword', 'help_relation', 'help_topic', 'host', 'ndb_binlog_index', 'plugin', 'proc', 'procs_priv', 'proxies_priv', 'servers', 'slow_log', 'tables_priv', 'time_zone', 'time_zone_leap_second', 'time_zone_name', 'time_zone_transition', 'time_zone_transition_type', 'user', 'general_log_backup','slow_log_backup' ) ) ) or ( -- Compressed tables ROW_FORMAT = 'Compressed' );

スクリプトでは、次の例のような出力が作成されます。この例では、からに変換する必要のある 2 つのテーブルを示していますMyISAM。InnoDB 出力には、各テーブルのおおよそのサイズがメガバイト (MB)単位でも含まれています。

+---------------------------------+------------------+| ==> MyISAM or Compressed Tables | Approx size (MB) |+---------------------------------+------------------+| test.name_table | 2102.25 || test.my_table | 65.25 |+---------------------------------+------------------+2 rows in set (0.01 sec)

API バージョン 2016-01-01159



コンソールを使用した DB スナップショットの移行DB インスタンスの DB スナップショットを移行して、 Amazon RDS DB クラスターを作成できます。MySQLAurora MySQL新しい DB クラスターには、元の Amazon RDS MySQL DB インスタンスのデータが入力されます。DB スナップショットは、Amazon RDS5.6 を実行する MySQL DB インスタンスから作成され、暗号化される必要があります。DB スナップショットを作成する方法については、AmazonRDS のドキュメントを参照してください。

DB スナップショットがデータを検索する AWS リージョン内にない場合は、Amazon RDS コンソールを使用してその DB スナップショットをそのリージョンにコピーします。DB スナップショットをコピーする方法については、Amazon RDS のドキュメントを参照してください。

コンソールを使用して DB スナップショットを移行すると、DB クラスターとプライマリインスタンスの両方を作成するために必要なアクションがコンソールによって実行されます。

新しい Aurora MySQL DB クラスターが、AWS Key Management Service (AWS KMS) の暗号化キーを使って「保管中」に暗号化されるよう選択することもできます。このオプションは、暗号化されていないDB スナップショットに対してのみ使用できます。

コンソールを使用して MySQL5.6 DB スナップショットを移行するには

1. AWS マネジメントコンソールにサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

2. [Snapshots] を選択します。3. [スナップショット] ページで、Aurora MySQL DB クラスターに移行するスナップショットを選択しま

す。4. [Migrate Database] を選択します。

5. [Migrate Database] ページで以下の値を設定します。

API バージョン 2016-01-01160

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html





• DB インスタンスクラス: データベースに必要なストレージと容量のある DB インスタンスクラスを選択しますdb.r3.large。たとえば、 . Aurora MySQLクラスターボリュームは、データベースのデータの量が増えるにつれて、64 テラバイト (TB) の最大サイズまで自動的に大きくなります。そのため、現在のストレージ要件を満たしている DB インスタンスクラスを選択する必要があります。

• DB インスタンス識別子: DB クラスター名を入力します。選択したリージョン内で、自分のアカウントに対して一意であることが必要です。この識別子は、DB クラスター内のインスタンスのエンドポイントアドレスで使用されます。名前には、選択したリージョンと DB エンジンなどを含めると理解しやすくなります (aurora-cluster1 など)。

DB インスタンス識別子には次の制約があります。• 1 ～ 63 文字の英数字またはハイフンを使用する必要があります。• 1 字目は文字である必要があります。• ハイフンを、文字列の最後に使用したり、2 つ続けて使用したりすることはできません。• 各 AWS リージョンの各 AWS アカウントのすべての DB インスタンスの中で一意である必要があ

ります。• VPC: 既存の VPC がある場合は、その VPC 識別子 ( など) を選択して、その VPC を Amazon

Aurora MySQL DB vpc-a464d1c1 クラスターで使用できます。既存の VPC の使用については、 Amazon RDS のドキュメントを参照してください。

または、[新しい VPC の作成] を選択し、Amazon RDS で自動的に VPC を作成します。• サブネットグループ: 既存のサブネットグループがある場合は、そのサブネットグループ識別子 ( な

ど) を選択することにより、そのサブネットグループを Amazon Aurora MySQL DB gs-subnet-group1 クラスターで使用できます。

または、[Create a new subnet group] を選択し、Amazon RDS で自動的にサブネットグループを作成します。

• パブリックアクセス可能: DB クラスターのインスタンスが VPC 内のリソースからのみアクセスできることを指定するには、[No] を選択します。DB クラスターのインスタンスがパブリックネットワーク上のリソースからアクセスできることを指定するには、[Yes] を選択します。デフォルトは[Yes] です。

Note

DB クラスターは、パブリックサブネット内に配置する必要がない可能性があります。これは、お客様のアプリケーションサーバーのみがお客様の DB クラスターへのアクセスを必要とするためです。DB クラスターをパブリックサブネットに配置する必要がない場合は、[Publicly Accessible] を [No] に設定します。

• アベイラビリティーゾーン: Aurora MySQLDB クラスターのプライマリインスタンスをホストするアベイラビリティーゾーンを選択します。Amazon RDS で自動的にアベイラビリティーゾーンを選択するには、[指定なし] を選択します。

• データベースポート: DB クラスターのインスタンスへの接続時に使用されるデフォルトのポートを入力します。デフォルト: 3306。

Note

会社のファイアウォールでデフォルトポートの 3306 などのMySQLデフォルトポートへのアクセスが許可されない場合があります。この場合は、会社のファイアウォールによって許可されるポート値を指定します。そのポート値を覚えておいてください。後で AuroraMySQL DB クラスターに接続するときに使用します。

• 暗号を有効化: 新しい DB クラスターを「保管中」に暗号化するには、[Aurora MySQLYes (はい)]を選択します。[Yes (はい)] を選択する場合、[マスターキー] 値として AWS KMS 暗号化キーを選択する必要があります。

• マイナーバージョン自動アップグレード: DB クラスターで DB エンジンのマイナーバージョンアップグレードをリリースと同時に自動的に受信するには、[Aurora MySQLYes] を選択します。MySQLAPI バージョン 2016-01-01

161

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.CreateVPC.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.CreateVPC.html



マイナーバージョン自動アップグレードオプションは、MySQLDB クラスターのAmazon AuroraMySQLマイナーエンジンバージョンに対するアップグレードのみに適用されます。システム安定性を維持するために適用される定期的なパッチは適用されません。

API バージョン 2016-01-01162



API バージョン 2016-01-01163



6. [Migrate] を選択して、DB スナップショットを移行します。7. [Instances] を選択して、矢印アイコンを選択して DB クラスターの詳細を表示し、移行の進行状況を

モニタリングします。詳細ページで、DB クラスターのプライマリインスタンスへの接続に使用されているクラスターエンドポイントがわかります。Amazon Aurora MySQL DB クラスターへの接続方法の詳細については、Amazon RDS のドキュメントを参照してください。

API バージョン 2016-01-01164

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Connect.html


MariaDBまたは Amazon RDSでのへのMySQLデータベースの移行Amazon Aurora MySQL

MariaDBAWS Database Migration Service (DMS) MariaDBを使用して、既存のオンプレミスまたは Amazon RDS for Amazon Aurora から Amazon Aurora MySQLにデータを移行できます。AmazonAurora は、クラウド向けに構築された MySQLおよび互換のリレーショナルデータベースです。PostgreSQLAmazon Aurora には、データベースインスタンスあたり最大 64 TB まで自動スケーリングできる、耐障害性を備えた分散型の自己修復ストレージシステムが用意されています。最大 15 個の低レイテンシーリードレプリカ、ポイントインタイムリカバリ、Amazon S3 への継続的なバックアップ、および 3 つのアベイラビリティーゾーン (AZ) 間のレプリケーションを使用して、高パフォーマンスと可用性を実現します。

に用意されている主な機能は以下のとおりです。Aurora MySQL

• 低レイテンシーで高スループット• プッシュボタンコンピューティングスケーリング• ストレージの自動スケーリング• カスタムデータベースエンドポイント• 迅速な分析のための並列クエリ

以下のセクションでは、AWS DMS を使用して、ソースデータベースMariaDBとしてからターゲットとして Aurora MySQL データベースに移行する方法を示します。大まかに述べると、この移行に関連するステップは次のとおりです。

• ソース DB インスタンスMariaDBとしてプロビジョニングし、データをロードする• ターゲット DB インスタンスとして Aurora Mysql をプロビジョニングします。• DMS レプリケーションインスタンスのプロビジョニングと DMS エンドポイントの作成• DMS タスクを作成し、データを移行して、検証を実行する

このセクションでは、用の Amazon RDS、Aurora CloudFormation データベース、および MariaDB AWSDMS レプリケーションインスタンスをソースとエンドポイントで作成するためのMySQLテンプレートを使用します。MariaDBにあるサンプルテーブルとデータをにロードGitHubします。

トピック• ソースデータベースMariaDBとしての設定 (p. 166)• ターゲットデータベースAurora MySQLとしてのセットアップ (p. 168)• AWS DMSレプリケーションインスタンスのセットアップ (p. 170)• エンドポイントをテストする (p. 171)• 移行タスクの作成 (p. 171)• 移行の検証 (p. 172)

API バージョン 2016-01-01165

https://aws.amazon.com/rds/mariadb/?nc=sn&loc=3&dn=4

https://aws.amazon.com/rds/aurora/

https://aws.amazon.com/rds/aurora/

https://aws.amazon.com/dms/

https://github.com/aws-samples/aws-database-migration-samples


ソースデータベースMariaDBとしての設定

• カットオーバー (p. 172)

ソースデータベースMariaDBとしての設定ソースデータベースとしてプロビジョニングするには、Maradb_CF.yaml テンプレートをダウンロードMariaDBします。https://aws-database-blog.s3.amazonaws.com/artifacts/mariadb-to-aurora-mysql-migration/Mariadb_CF.yamlこのAWS CloudFormationテンプレートでは、必要なパラメータを指定したAmazon RDS インスタンスのを作成します。MariaDB

1. AWS マネジメントコンソールの [サービス] で、[] を選択しますCloudFormation。2. [Create Stack] を選択します。3. [Specify template (テンプレートの指定)] で、[Upload a template file (テンプレートファイルのアップ

ロード)] を選択します。4. [Choose File (ファイルの選択)] を選択します。5. MariaDB.yamlファイルを選択します。6. [次] を選択します。7. [Specify Stack Details (スタック詳細の指定)] ページで、必要に応じて事前定義された値を編集し、

[次へ] を選択します。

• [–Stack name (スタック名)] スタックの名前を入力します。• CIDR インスタンスにアクセスする CIDR IP 範囲–を入力します。• DBAllocatedストレージデータベースストレージサイズ (GB 単位) – を入力します。デフォルトは

20 GB です。• バックアップを保持する日数。DBBackupRetentionPeriod–• データベースサーバーのインスタンスタイプDBInstanceClass–を入力します。• にデータベースログを発行するDBMonitoringInterval–間隔Amazon CloudWatch。• DB サブネットグループDBSubnetGroup–を入力します。• エンジンバージョンMariaDBEngine–MariaDBを入力します。• データベースの名前を入力します。RDSDBName–• VPCID DB インスタンスを起動する VPC –を入力します。

8. [Configure stack options] ページの [Tags] で、オプションのタグを指定し、[Next] を選択します。9. [Review] ページで、[I acknowledge that AWS CloudFormation might create IAM resources] を選択し

ます。10. [Create Stack] を選択します。

Amazon RDSインスタンスMariaDBのが作成されたら、にログインして次のステートメントを実行し、移行のために DMS インスタンスに接続するスーパーユーザーを作成して、必要な権限を付与します。MariaDBwebdb_user—

CREATE USER 'webdb_user'@'%' IDENTIFIED BY '******';GRANT ALL ON migrate.* TO 'webdb_user'@'%' with grant option;grant REPLICATION SLAVE ON *.* TO webdb_user;grant REPLICATION CLIENT ON *.* TO webdb_user;

このチュートリアルでは、移行というデータベースを作成し、いくつかのサンプルテーブルをストアドプロシージャ、トリガー、関数などとともに作成しました。以下のクエリでは、移行データベースのテーブルのリストを示します。

API バージョン 2016-01-01166

https://aws-database-blog.s3.amazonaws.com/artifacts/mariadb-to-aurora-mysql-migration/Mariadb_CF.yaml

https://aws-database-blog.s3.amazonaws.com/artifacts/mariadb-to-aurora-mysql-migration/Mariadb_CF.yaml


ソースデータベースMariaDBとしての設定

MariaDB [(none)]> use migration

Database changedMariaDB [migration]> show tables;+---------------------+| Tables_in_migration |+---------------------+| animal_count || animals || contacts || seat_type || sport_location || sport_team || sport_type |+---------------------+7 rows in set (0.000 sec)

次のクエリは、セカンダリインデックスのリストを返します。

MariaDB [migration]> SELECT DISTINCT TABLE_NAME, INDEX_NAME,NON_UNIQUE -> FROM INFORMATION_SCHEMA.STATISTICS -> WHERE TABLE_SCHEMA = 'migration' and INDEX_NAME <> 'PRIMARY';+----------------+-------------------+------------+| TABLE_NAME | INDEX_NAME | NON_UNIQUE |+----------------+-------------------+------------+| sport_location | city_id_sport_loc | 1 || sport_team | sport_team_u | 0 || sport_team | home_field_fk | 1 |+----------------+-------------------+------------+3 rows in set (0.000 sec)

次のクエリは、トリガーのリストを返します。

MariaDB [migration]> select TRIGGER_SCHEMA,TRIGGER_NAME -> from information_schema.triggers -> where TRIGGER_SCHEMA='migration';+----------------+-----------------------+| TRIGGER_SCHEMA | TRIGGER_NAME |+----------------+-----------------------+| migration | increment_animal || migration | contacts_after_update |+----------------+-----------------------+2 rows in set (0.001 sec)

次のクエリは、プロシージャと関数のリストを返します。

MariaDB [(none)]> select routine_schema as database_name, -> routine_name, -> routine_type as type, -> data_type as return_type -> from information_schema.routines -> where routine_schema not in ('sys', 'information_schema', -> 'mysql', 'performance_schema');+---------------+----------------+-----------+-------------+| database_name | routine_name | type | return_type |+---------------+----------------+-----------+-------------+| migration | CalcValue | FUNCTION | int || migration | loadMLBPlayers | PROCEDURE | || migration | loadNFLPlayers | PROCEDURE | |

API バージョン 2016-01-01167

AWS Database Migration Service ステップバイステップ移行ガイドターゲットデータベースAuroraMySQLとしてのセットアップ

+---------------+----------------+-----------+-------------+3 rows in set (0.000 sec)

すべてのデータがロードされたら、 mysqldump を使用してデータベースのメタデータをバックアップします。バックアップまたは転送のために 1 つ以上のデータベースをダンプするmysqldumpユーティリティ。通常、ダンプにはテーブルの作成、入力、またはその両方を行うための SQL ステートメントが含まれています。を使用して、ファイルをカンマ区切り値 (CSV)、その他の区切り文字付きテキスト、またはXML 形式で生成することもできます。mysqldump

次のコマンドを使用して、テーブルとインデックス定義をエクスポートします。

$ mysqldump --no-data --no-create-db --single_transaction -u root -p migration --skip-triggers > mysql_tables_indexes.sql

次のコマンドを使用して、ルーチン (ストアドプロシージャ、関数、トリガー) をファイルにエクスポートしますroutines.sql。

$ mysqldump -u root --routines --no-create-info --no-data --no-create-db --skip-opt -p migration > routines.sql

このmysqldumpユーティリティには、DEFINERステートメントを削除するオプションはありません。一部のMySQLクライアントでは、論理バックアップの作成時に定義を無視するオプションが用意されていますが、これはデフォルトの動作ではありません。UNIX または Linux 環境で次のコマンドを使用して、DEFINERを routines.sql から削除します。

$ sed -i -e 's/DEFINER=`root`@`localhost`/DEFINER=`master`@`%`/g' routines.sql

これで、2 つのMariaDBファイル ( .sqlと ) mysql_tables_indexes.sql にのバックアップが作成されましたroutines.sql。これらのファイルを使用して、テーブル定義を Aurora MySQLデータベースにロードします。

バックアップが 2 つの .sql ファイル (mysql_tables_indexes.sql、) routines.sql に完了した後に、これらのファイルを使用してテーブル定義を Aurora MySQLデータベースにロードします。

ターゲットデータベースAurora MySQLとしてのセットアップ

ターゲットデータベースAurora MySQLとしてプロビジョニングするには、AuroraMysql_CF.yaml テンプレートをダウンロードします。このテンプレートでは、必須パラメータを使用して Aurora MySQL データベースを作成します。


ロード)] を選択します。4. [Choose File (ファイルの選択)] を選択します。5. AuroraMySQL.yamlファイルを選択します。

API バージョン 2016-01-01168

https://aws-database-blog.s3.amazonaws.com/artifacts/mariadb-to-aurora-mysql-migration/AuroraMysql_CF.yaml

https://aws-database-blog.s3.amazonaws.com/artifacts/mariadb-to-aurora-mysql-migration/AuroraMysql_CF.yaml

AWS Database Migration Service ステップバイステップ移行ガイドターゲットデータベースAuroraMySQLとしてのセットアップ

6. [次] を選択します。7. [Specify Stack Details (スタック詳細の指定)] ページで、必要に応じて事前定義された値を編集し、


• [–Stack name (スタック名)] スタックの名前を入力します。• CIDR インスタンスにアクセスする CIDR IP 範囲–を入力します。• バックアップ保持期間の日数。DBBackupRetentionPeriod–• データベースサーバーのインスタンスタイプDBInstanceClass–を入力します。• DB インスタンスのマスターユーザー名DBMasterUsername–を入力する• DB インスタンスのマスターユーザー名DBMasterPassword–のパスワードを入力します。• DB サブネットグループDBSubnetGroup–を入力します。• –Engine Aurora エンジンのバージョンを入力します5.7.mysql-aurora.2.03.4。デフォルトは

です。• データベースの名前を入力します。DBName–• VPCID DB インスタンスを起動する VPC の ID –を入力します。



Aurora MySQLデータベースが作成されたら、Aurora MySQLインスタンスにログインします。

$ mysql -h mysqltrg-instance-1.xxxxxxxxx.us-east-1.rds.amazonaws.com -u master -p migration -P 3306MySQL [(none)]> show databases;+--------------------+| Database |+--------------------+| information_schema || awsdms_control || mysql || performance_schema || source || tmp || webdb |+--------------------+7 rows in set (0.001 sec)

MySQL [(none)]> create database migration;Query OK, 1 row affected (0.016 sec)

MySQL [(none)]> use migration;Database changed

MySQL [migration]> show tables;Empty set (0.001 sec)

を使用してmysql_tables_indexes.sql、でテーブルとインデックス構造を作成しますAuroraMySQL。

$ mysql -h mysqltrg-instance-1.xxxxxxxxx.us-east-1.rds.amazonaws.com -u master -p migration -P 3306 < mysql_tables_indexes.sqlEnter password:$

API バージョン 2016-01-01169


AWS DMSレプリケーションインスタンスのセットアップ

テーブルとインデックスが正常に作成されたら、次のステップはをセットアップして使用することですAWS DMS。

AWS DMSレプリケーションインスタンスのセットアップ

AWS DMSレプリケーションインスタンスをプロビジョニングするには、DMS_CF.yaml テンプレートをダウンロードします。


ロード)] を選択します。4. [Choose File (ファイルの選択)] を選択します。5. DMS_CF.yamlファイルを選択します。6. [次] を選択します。7. [Specify Stack Details (スタック詳細の指定)] ページで、必要に応じて事前定義された値を編集し、


• [–Stack name (スタック名)] スタックの名前を入力します。• ストレージサイズ (GB) AllocatedStorageSize–を入力します。デフォルトは 200 GB です。• DMS レプリケーション用のサブネットグループDMSReplicationSubnetGroup–を入力します。• DMS レプリケーション用のセキュリティグループDMSSecurityGroup–を入力します。• インスタンスタイプInstanceType–を入力します。• ソースデータベースポートSourceDBPort–を入力します。• ソースデータベース名を入力します。SourceDatabaseName–• ソースデータベースサーバーの IP SourceServerName – アドレスを入力します。• ソースデータベースのユーザー名SourceUsername–を入力します。• ソースデータベースのパスワードを入力します。SourcePassword–• ターゲットデータベースポートTargetDBPort–を入力します。• ターゲットデータベース名を入力します。TargetDatabaseName–• ターゲットデータベースサーバーの IP TargetServerName – アドレスを入力します。• ターゲットデータベースのユーザー名TargetUsername–を入力します。• ターゲットデータベースのパスワードを入力します。TargetPassword–



このAWS CloudFormationテンプレートでは、という名前のレプリケーションインスタンスを作成しますmariadb-mysql。このレプリケーションインスタンスには、という名前のソースエンドポイントmaria-on-premとという名前のターゲットエンドポイントがありますmysqltrg-rds。このターゲットエンドポイントには、レプリケーション中に外部キー制約チェックを無効にする追加の接続属性があります。AWS DMS

ExtraConnectionAttributes : "initstmt=SET FOREIGN_KEY_CHECKS=0;parallelLoadThreads=1"

API バージョン 2016-01-01170

https://aws-database-blog.s3.amazonaws.com/artifacts/mariadb-to-aurora-mysql-migration/DMS_CF.yaml

AWS Database Migration Service ステップバイステップ移行ガイドエンドポイントをテストする

エンドポイントをテストするエンドポイントをテストするには

1. ナビゲーションペインで、[ Endpoints ( エンドポイント)] を選択します。2. ソースエンドポイント名 (maria-on-prem) を選択し、次の操作を行います。

a. [Test connections (テスト接続)] を選択します。b. テストするレプリケーションインスタンスを選択します (mariadb-mysql)。c. [Run Test] を選択し、ステータスが成功するまで待ちます。

3. ナビゲーションペインで、[ Endpoints ( エンドポイント)] を選択します。4. ターゲットエンドポイント名 (mysqltrg-rds) を選択し、次の操作を行います。

a. [Test Connections] を選択します。b. テストするレプリケーションインスタンスを選択します (mariadb-mysql)。c. [Run Test] を選択し、ステータスが成功するまで待ちます。

Note

[Run Test (テストの実行)] が成功以外のステータスを返すと、失敗の理由が表示されます。先に進む前に、この問題を解決してください。

移行タスクの作成これで、レプリケーションインスタンスがソースとターゲットの両方のエンドポイントに接続できることを確認しました。次のステップは、データベース移行タスクを作成することです。

データベース移行タスクを作成するには

1. ナビゲーションペインで、[Database Migration Tasks (データベース移行タスク)] を選択します。2. [タスクの作成] を選択します。指定した値を次のように指定し、[次へ] を選択します。

• タスク識別子–maria-mysql• –Replication instance レプリケーションインスタンス、を選択しますmariadb-mysql。• ソースデータベースエンドポイントソースデータベース、を選択します。–maria-on-prem• –Target database endpoint (ターゲットデータベースエンドポイント) ターゲットデータベース、を

選択しますmysqltrg-rds。• 移行タイプ – [Migrate existing data and replicate ongoing changes for CDC, or Migrate existing

data for full load (既存のデータを移行して全ロード)] を選択します。3. [Task settings (タスク設定)] で、次の設定を選択します。

• ターゲットテーブル作成モード – 何もしない• 全ロードの完了後にタスクを停止する – 停止しない• レプリケーション–制限付き LOB モードに LOB 列を含める• 最大 LOB サイズ (KB) – 32• 検証の有効化• CloudWatchログの有効化

4. [Table mappings (テーブルマッピング)] で、以下の設定を選択します。API バージョン 2016-01-01

171


移行の検証

• –Schema [Choose migration (移行を選択)] (移行するスキーマとデータベースが正しく表示されると仮定)。

• テーブル名テーブル名–を入力するか、データベース内のすべてのテーブルを指定します。%

• アクション – Enter Include を使用して特定のテーブルを含めるか、Exclude を使用して特定のテーブルを除外します。

5. [タスクの作成] を選択します。

新しいAWS DMS移行タスクでは、MariaDBソースのテーブルからデータを読み取り、Aurora MySQLターゲットにデータを移行します。

移行の検証AWS DMS は、データの検証を実行して、データがソースデータベースをターゲットに正常に移行したことを確認します。テーブル統計ページを確認して、AWS DMS タスクの開始後に発生した DML の変更を確認できます。データの検証中に、AWS DMS はソースの各行をターゲットの対応する行と比較し、それらの行に同じデータが含まれていることを確認します。これを達成するために、AWS DMS は適切なクエリを発行してデータを取得します。

データが正常にロードされたら、ページでタスクを選択し、[AWS DMSTable statistics (テーブル統計)] を選択して、移行に関する統計を表示できます。次のスクリーンショットは、[Table statistics] ページとその関連するエントリを示しています。

次のスクリーンショットは、テーブルの静的ページとその関連するエントリを示しています。

AWS DMS は、ソースとターゲットのエンジン間のデータを検証できます。[Validation state] 列は、データ移行の検証に役立ちます。これにより、データはソースからターゲットに正確に移行されます。

カットオーバーデータの検証が完了し、問題が解決したら、データベースのトリガー、関数、および手順をロードできます。

これを行うには、から生成されたroutines.sqlファイルを使用して、で必要なルーチンを作成しますMariaDB。Aurora MySQL次のステートメントでは、すべてのプロシージャ、関数、およびトリガーをAurora MySQLデータベースにロードします。

$ mysql -h mysqltrg-instance-1.xxxxxxxxx.us-east-1.rds.amazonaws.com -u master -p migration -P 3306 < routines.sql

API バージョン 2016-01-01172


カットオーバー

ルーチンがロードされたら、データベースに接続して、次のように検証します。Aurora MySQL

$ mysql -h mysqltrg-instance-1.xxxxxxxxx.us-east-1.rds.amazonaws.com -u master -p migration -P 3306Enter password:Reading table information for completion of table and column namesYou can turn off this feature to get a quicker startup with -A

Welcome to the MariaDB monitor. Commands end with ; or \g.Your MySQL connection id is 957Server version: 5.6.10 MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [migration]> select routine_schema as database_name, -> routine_name, -> routine_type as type, -> data_type as return_type -> from information_schema.routines -> where routine_schema not in ('sys', 'information_schema', -> 'mysql', 'performance_schema');+---------------+----------------+-----------+-------------+| database_name | routine_name | type | return_type |+---------------+----------------+-----------+-------------+| migration | CalcValue | FUNCTION | int || migration | loadMLBPlayers | PROCEDURE | || migration | loadNFLPlayers | PROCEDURE | |+---------------+----------------+-----------+-------------+3 rows in set (0.002 sec)

MySQL [migration]> select TRIGGER_SCHEMA, TRIGGER_NAME from information_schema.triggers where TRIGGER_SCHEMA='migration';+----------------+-----------------------+| TRIGGER_SCHEMA | TRIGGER_NAME |+----------------+-----------------------+| migration | increment_animal || migration | contacts_after_update |+----------------+-----------------------+2 rows in set (0.009 sec)

上記の出力は、すべてのプロシージャ、トリガー、関数がAurora MySQLデータベースに正常にロードされたことを示しています。

API バージョン 2016-01-01173


Amazon EC2インスタンスを起動する

MongoDB から AmazonDocumentDB への移行

次のチュートリアルを使用して、からに移行するプロセスを案内MongoDBします。AmazonDocumentDB (MongoDB 互換)このチュートリアルでは、以下の作業を行います。

• MongoDBインスタンスにをインストールします。Amazon EC2• サンプルデータを入力します。MongoDB• AWS DMSレプリケーションインスタンス、ソースエンドポイント ( MongoDB の場合)、ターゲットエ

ンドポイント ( の場合) Amazon DocumentDB を作成します。• AWS DMS タスクを実行して、ソースエンドポイントからターゲットエンドポイントにデータを移行す

る。

Important

開始する前に、デフォルトの仮想プライベートクラウド (VPC) で Amazon DocumentDB クラスターを起動してください。詳細については、開発者ガイドの「開始方法」を参照してください。Amazon DocumentDB

トピック• Amazon EC2インスタンスを起動する (p. 174)• MongoDBCommunity Edition のインストールと設定 (p. 175)• AWS DMSレプリケーションインスタンスを作成します。 (p. 176)• ソースおよびターゲットエンドポイントの作成 (p. 177)• 移行タスクを作成して実行する (p. 179)

Amazon EC2インスタンスを起動するこのチュートリアルでは、デフォルトの VPC でAmazon EC2インスタンスを起動します。

Amazon EC2 インスタンスを起動するには

1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。2. [Launch Instance] (インスタンスの起動) を選択して、以下を実行します。

a. [Choose an Amazon Machine Image (AMI)] AMIs ページで、のリストの一番上にある [AmazonLinux AMI] に移動して、[Select] を選択します。

b. [インスタンスタイプの選択] ページで、インスタンスタイプのリストの一番上にある [t2.micro] を選択します。続いて、[次へ] を選択します。インスタンスの詳細を設定します。

c. [インスタンスの詳細の設定] ページの [ネットワーク] でデフォルトの VPC を選択します。続いて、[次へ] を選択します。ストレージを追加します。

d. [ストレージの追加] ページで、[次へ] を選択してこのステップをスキップします。タグを追加します。

e. [タグの追加] ページで、[次へ] を選択してこの手順をスキップします。セキュリティグループを設定します。

f. [セキュリティグループの設定] ページで、次の操作を行います。

1. [Select an existing security group] を選択します。

API バージョン 2016-01-01174

https://docs.aws.amazon.com/documentdb/latest/developerguide/getting-started.html

https://console.aws.amazon.com/ec2/


MongoDBCommunity Edition のインストールと設定

2. セキュリティグループのリストで、[default] を選択します。これにより、VPC のデフォルトのセキュリティグループが選択されます。デフォルトでは、このセキュリティグループは TPCポート 22 でインバウンド Secure Shell (SSH) 接続を受け入れます。VPC でこれが該当しない場合は、このルールを追加しますhttps://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html。詳細については、 Amazon VPC ユーザーガイドの「Amazon VPC とは」を参照してください。

3. [Next (次へ)] を選択します。確認して起動します。g. 情報を確認して [作成] を選択します。

3. [Select an existing key pair or create a new key pair] ウィンドウで、次のいずれかを実行します。

• Amazon EC2 キーペアがない場合は、新しいキーペアの作成を選択して指示に従います。プライベートキーファイル (.pem ファイル) をダウンロードするよう求められます。このファイルは、後で Amazon EC2 インスタンスにログインするときに必要になります。

• Amazon EC2 キーペアが既にある場合は、[キーペアの選択] でリストからキーペアを選択します。Amazon EC2 インスタンスにログインするには、既にプライベートキーファイル (.pem ファイル) が利用可能になっている必要があります。

4. キーペアを設定したら、[インスタンスの作成] を選択します。

コンソールナビゲーションペインで [EC2 ダッシュボード] を選択し、起動したインスタンスを選択します。下のペインの [Description] タブで、インスタンスのパブリック DNS の場所を見つけます。次に例を示します。ec2-11-22-33-44.us-west-2.compute.amazonaws.com。

Amazon EC2 インスタンスが使用可能になるには数分かかります。5. 次の例のように、ssh コマンドを使用して Amazon EC2 インスタンスにログインします。

chmod 400 my-keypair.pemssh -i my-keypair.pem ec2-user@public-dns-name

プライベートキーファイル (.pem ファイル) と EC2 インスタンスのパブリック DNS 名を指定します。ログイン ID はですec2-user。パスワードは不要です。

EC インスタンスへの接続の詳細については、の「SSH を使用した Linux インスタンスへの接続」を参照してください。Linux インスタンス用 Amazon EC2 ユーザーガイド

MongoDBCommunity Edition のインストールと設定「Amazon EC2インスタンスを起動する (p. 174)」で起動した Amazon EC2 インスタンスで次の手順を実行します。

EC2 インスタンスに MongoDBCommunity Edition をインストールして設定するには

1. ドキュメントで Amazon Linux の MongoDB Community Edition のインストールに移動し、手順に従います。MongoDB

2. デフォルトでは、MongoDBサーバー (mongod) は IP アドレス 127.0.0.1 (localhost) からのループバック接続のみを許可します。Amazon VPC のその他の場所からの接続を許可するには、次の操作を行います。

a. /etc/mongod.conf ファイルを開いて次の行を見つけます。

# network interfacesnet: port: 27017 bindIp: 127.0.0.1 # Enter 0.0.0.0,:: to bind to all IPv4 and IPv6 addresses or, alternatively, use the net.bindIpAll setting.

API バージョン 2016-01-01175

https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html

https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

https://docs.mongodb.com/manual/tutorial/install-mongodb-on-amazon/


AWS DMSレプリケーションインスタンスを作成します。

b. bindIp の行を次のように変更します。

bindIp: public-dns-name

c. public-dns-name をインスタンスの実際のパブリック DNS 名に置き換えます(ec2-11-22-33-44.us-west-2.compute.amazonaws.com など)。

d. /etc/mongod.conf ファイルを保存して、mongod を再起動します。

sudo service mongod restart

3. 次の手順を実行して、MongoDBインスタンスにデータを入力します。

a. wget コマンドを使用して、サンプルデータを含む JSON ファイルをダウンロードします。

wget http://media.mongodb.org/zips.json

b. mongoimport コマンドを使用して、そのデータを新しいデータベース (zips-db) にインポートします。

mongoimport --host public-dns-name:27017 --db zips-db --file zips.json

c. インポートが完了したら、mongoシェルを使用してに接続し、データが正常にロードされたことを確認します。MongoDB

mongo --host public-dns-name:27017

d. public-dns-name をインスタンスの実際のパブリック DNS 名に置き換えます。e. mongo シェルプロンプトで次のコマンドを入力します。

use zips-db db.zips.count()

db.zips.aggregate( [ { $group: { _id: { state: "$state", city: "$city" }, pop: { $sum: "$pop" } } }, { $group: { _id: "$_id.state", avgCityPop: { $avg: "$pop" } } }] )

出力に次の情報が表示されます。

• データベースの名前 (zips-db)• zips コレクションのドキュメントの数 (29353)• 各州の都市の平均人口

f. 次のコマンドを使用して、mongo シェルを終了してコマンドプロンプトに戻ります。

exit

AWS DMSレプリケーションインスタンスを作成します。

AWS DMS でレプリケーションを実行するにはレプリケーションインスタンスが必要です。API バージョン 2016-01-01

176


ソースおよびターゲットエンドポイントの作成


1. AWS DMS コンソール (https://console.aws.amazon.com/dms/) を開きます。2. ナビゲーションペインで [Replication instances] を選択します。3. [Create replication instance (レプリケーションインスタンスの作成)] を選択し、次の情報を入力しま

す。

• [Name (名前)] に mongodb2docdb と入力します。• [説明] に「MongoDB to Amazon DocumentDB replication instance」と入力します。• [Instance class (インスタンスクラス)] はデフォルト値のままにします。• [Engine version (エンジンバージョン)] はデフォルト値のままにします。• [VPC] でデフォルトの VPC を選択します。• マルチ AZ には、[No] を選択します。• [Publicly accessible (パブリックアクセス可能)] を有効にします。

すべての設定が正しいことを確認したら、[Create replication instance (レプリケーションインスタンスの作成)] を選択します。

Note

ステータスが [available (使用可能)] になったらレプリケーションインスタンスを使用できます。これには数分間かかる場合があります。

ソースおよびターゲットエンドポイントの作成ソースエンドポイントは、MongoDBインスタンスで実行するAmazon EC2インストールのエンドポイントです。

ソースエンドポイントを作成するには

1. AWS DMS コンソール (https://console.aws.amazon.com/dms/) を開きます。2. ナビゲーションペインで、[エンドポイント] を選択します。3. [Create endpoint (エンドポイントの作成)] を選択し、次の情報を入力します。

• [Endpoint type (エンドポイントタイプ)] で [Source (ソース)] を選択します。• [Endpoint identifier (エンドポイント識別子)] に、覚えやすい名前を入力します (例: mongodb-source)。

• [Source engine (ソースエンジン)] で [mongodb] を選択します。• [Server name (サーバー名)] に Amazon EC2 インスタンスのパブリック DNS 名を入力します

(ec2-11-22-33-44.us-west-2.compute.amazonaws.com など)。• [Port (ポート)] に「27017」と入力します。• [SSL mode (SSL モード)] で [none (なし)] を選択します。• [Authentication mode (認証モード)] で [none (なし)] を選択します。• [Database name (データベース名)] に「zips-db」と入力します。• [Authentication mechanism (認証メカニズム)] で [default (デフォルト)] を選択します。• [Metadata mode (メタデータモード)] で [document (ドキュメント)] を選択します。

すべての設定が正しいことを確認したら、[Create endpoint (エンドポイントの作成)] を選択します。API バージョン 2016-01-01

177




ソースおよびターゲットエンドポイントの作成

次にターゲットエンドポイントを作成します。ターゲットエンドポイントは Amazon DocumentDB クラスターのエンドポイントで、既に起動している必要があります。Amazon DocumentDBクラスターの起動の詳細については、開発者ガイドの「ご利用開始にあたって」を参照してください。AmazonDocumentDB

Important

先に進む前に以下の作業を行います。

• Amazon DocumentDB クラスターのマスターユーザー名とマスターパスワードを確認します。• AWS DMS から接続できるように、Amazon DocumentDB クラスターの DNS 名とポート番号

を確認します。この情報を確認するには、次の AWS CLI コマンドを使用します。cluster-idを Amazon DocumentDB クラスターの名前に置き換えてください。

aws docdb describe-db-clusters \ --db-cluster-identifier cluster-id \ --query "DBClusters[*].[Endpoint,Port]"

• Amazon DocumentDB で SSL 接続を確認するために使用できる証明書バンドルをダウンロードします。これを行うには、次のコマンドを入力します。ここで、aws-api-domain は、指定された S3 バケットとそれが提供する rds-combined-ca-bundle.pem ファイルにアクセスするために必要な AWS リージョンの Amazon S3 ドメインを完了します。

wget https://s3.aws-api-domain/rds-downloads/rds-combined-ca-bundle.pem

ターゲットエンドポイントを作成するには

1. ナビゲーションペインで、[エンドポイント] を選択します。2. [Create endpoint (エンドポイントの作成)] を選択し、次の情報を入力します。

• [Endpoint type (エンドポイントタイプ)] で [Target (ターゲット)] を選択します。• [Endpoint identifier (エンドポイント識別子)] に、覚えやすい名前を入力します (例: docdb-target)。

• [Target engine (ターゲットエンジン)] で [docdb] を選択します。• [Server name (サーバー名)] に Amazon DocumentDB クラスターの DNS 名を入力します。• [Port (ポート)] に Amazon DocumentDB クラスターのポート番号を入力します。• [SSL mode (SSL モード)] で [verify-full] を選択します。• [CA certificate (CA 証明書)] で、次のいずれかを実行して SSL 証明書をエンドポイントにアタッチ

します。• 使用可能な場合、[Choose a certificate (証明書の選択)] ドロップダウンから既存の rds-

combined-ca-bundle 証明書を選択します。• [Add new CA certificate (新しい CA 証明書の追加)] を選択します。次に、証明書の識別子にと

入力します。rds-combined-ca-bundle [Import certificate file (証明書ファイルのインポート)]で、ファイルを選択し、以前にダウンロードしたファイルに移動します。rds-combined-ca-bundle.pemファイルを選択して開きます。[Import certificate] を選択し、[Choose a certificate] ドロップダウンから rds-combined-ca-bundle を選択します。

• [User name (ユーザー名)] に Amazon DocumentDB クラスターのマスターユーザー名を入力します。

• [Password (パスワード)] に Amazon DocumentDB クラスターのマスターパスワードを入力します。• [Database name (データベース名)] に「zips-db」と入力します。

すべての設定が正しいことを確認したら、[Create endpoint (エンドポイントの作成)] を選択します。

API バージョン 2016-01-01178

https://docs.aws.amazon.com/documentdb/latest/developerguide/getting-started.html

AWS Database Migration Service ステップバイステップ移行ガイド移行タスクを作成して実行する

ソースとターゲットのエンドポイントを作成できたので、それらをテストして正しく動作することを確認します。また、AWS DMS がそれぞれのエンドポイントでデータベースオブジェクトにアクセスできることを確認するために、エンドポイントのスキーマを更新します。

エンドポイントをテストするには

1. ナビゲーションペインで、[エンドポイント] を選択します。2. ソースエンドポイント (mongodb-source) を選択し、[Test connection (接続のテスト)] を選択しま

す。3. レプリケーションインスタンス (mongodb2docdb) を選択し、[Run test (テストの実行)] を選択しま

す。テストが完了して [Status (ステータス)] が [successful (成功)] に変わるまでに数分かかります。

[Status (ステータス)] が [failed (失敗)] になった場合はエラーメッセージを確認します。エラーがあった場合は修正し、再度エンドポイントをテストします。

Note

この手順をターゲットエンドポイント (docdb-target) に対して繰り返します。

スキーマを更新するには

1. ナビゲーションペインで、[エンドポイント] を選択します。2. ソースエンドポイント (mongodb-source) を選択し、[Refresh schemas (スキーマの更新)] を選択し

ます。3. レプリケーションインスタンス (mongodb2docdb) を選択し、[Refresh schemas (スキーマの更新)] を

選択します。

Note

この手順をターゲットエンドポイント (docdb-target) に対して繰り返します。

移行タスクを作成して実行するこれで、 AWS DMS からにzipsデータを移行するために、移行タスクを起動する準備ができましたMongoDB。Amazon DocumentDB

1. AWS DMS コンソール (https://console.aws.amazon.com/dms/) を開きます。2. ナビゲーションペインで、[Tasks] を選択します。3. [Create task (タスクの作成)] を選択し、次の情報を入力します。

• [Task name (タスク名)] に、覚えやすい名前を入力します (例: my-dms-task)。• [Replication instance (レプリケーションインスタンス)] で、「AWS DMSレプリケーションインスタ

ンスを作成します。 (p. 176)」で作成したレプリケーションインスタンスを選択します。• [Source endpoint (ソースエンドポイント)] で、「ソースおよびターゲットエンドポイントの作

成 (p. 177)」で作成したソースエンドポイントを選択します。• [Target endpoint (ターゲットエンドポイント)] で、「ソースおよびターゲットエンドポイントの作

成 (p. 177)」で作成したターゲットエンドポイントを選択します。• [Migration type (移行タイプ)] で [Migrate existing data (既存のデータを移行する)] を選択します。• [Start task on create (作成時にタスクを開始)] を有効にします。

[Task Settings (タスク設定)] セクションのオプションはすべてデフォルト値のままにします。

API バージョン 2016-01-01179


AWS Database Migration Service ステップバイステップ移行ガイド移行タスクを作成して実行する

[Table mappings (テーブルマッピング)] セクションで [Guided (ガイド)] タブを選択して、次の情報を入力します。

• [Schema name is (スキーマ名)] で [Enter a schema (スキーマの入力)] を選択します。• [Schema name is like (スキーマ名の例)] はデフォルト設定 (%) のままにします。• [Table name is like (テーブル名の例)] はデフォルト設定 (%) のままにします。

[Add selection rule (選択ルールの追加)] を選択して、情報が正しいことを確認します。

すべての設定が正しいことを確認したら、[Create task (タスクの作成)] を選択します。

AWS DMSは、から MongoDB へのデータの移行を開始しますAmazon DocumentDB。タスクのステータスが [Starting (開始中)] から [Running (実行中)] に変わります。進捗状況をモニタリングするには、AWSDMS コンソールで [Tasks (タスク)] を選択します。数分後、ステータスが [Load complete (ロード完了)]に変わります。

Note

移行が完了したら、mongo シェルを使用して Amazon DocumentDB クラスターに接続し、zipsのデータを表示できます。詳細については、 DocumentDB 開発者ガイドの「mongo シェルを使用して Amazon クラスターにアクセスする」を参照してください。Amazon DocumentDB

API バージョン 2016-01-01180

https://docs.aws.amazon.com/documentdb/latest/developerguide/getting-started.connect.html

https://docs.aws.amazon.com/documentdb/latest/developerguide/getting-started.connect.html


ドキュメント履歴次の表は、AWS Database Migration Service のステップバイステップ移行ガイドの前回のリリース以後に行われた重要なドキュメントの変更を示しています。

• API バージョン: 20160101• 最終更新: 2017 年 8 月 30 日

変更説明日付

Microsoft SQL Server の Auroraへの移行ガイドが追加されました

Microsoft SQL Server からMySQL の互換性を備えたAmazon Aurora へのデータベース移行ガイドを追加しました。

2017 年 8 月 30 日

Oracle の PostgreSQL への移行ガイドが追加されました

Oracle の PostgreSQL へのデータベース移行ガイドを追加しました。

2017 年 8 月 18 日

オンプレミス Oracle の AmazonAurora への移行ガイドが追加されました

オンプレミス Oracle の AmazonAurora へのデータベース移行ガイドを追加しました。

2016 年 11 月 17 日

API バージョン 2016-01-01181


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

API バージョン 2016-01-01clxxxii

aws database migration service - ステップバイス …aws database migration service ス...

Documents