【DMS】Aurora MySQLのテーブルをAthanaで使えるようにするまでの軌跡
おはようございます、ねすたです、よろしくどうぞお願いします。
今回はDatabase Migration Service(DMS)を利用してAurora MySQLのテーブルのデータをAthanaでSELECTできるようにするまでを記述したいと思います。
0.前提
AWSで以下の機能が使える状態になっていることが前提となります。
■RDS:Aurora MySQL(バージョンはおそらく不問)
■Athana
1.レプリケーションインスタンスの作成
自分は既に作成されたものを使ってしまっていますが、仮にすべてデフォルトのままのインスタンスを作成したとします。
作成したインスタンス:「test-rep-instance」
2.ソースエンドポイントの作成
DMSはソースとなるデータソースを別のデータソースとして出力できるようにする機能なので、まずはソースとなるデータソースのエンドポイントを作成します。
・DMSコンソールより、「エンドポイント」タブを押下。
・エンドポイント一覧画面より、「エンドポイントの作成」ボタンを押下。
・エンドポイントタイプは「ソースエンドポイント」を選択。
・エンドポイント識別子:「test-source-endpoint」
・ARN名:「test-source-endpoint」※任意
・ソースエンジン:「Amazon Aurora MySQL」
・エンドポイントデータベースへのアクセス:「手動で提供する」を選択
・サーバー名:RDSで移行したいAurora MySQLのクラスタを確認し、「接続とセキュリティ」タブの「エンドポイント」欄にあるライターインスタンスのエンドポイント名をコピペする。
・ポートは3306、ユーザはRDSのマスタユーザ名を適宜入力。
・テスト接続:VPCはお使いのセキュアなもの、レプリケーションインスタンスは1項で作成した「test-rep-instance」をそれぞれ選択。
その後、「テストの実行」ボタンを押下して接続が成功すれば「エンドポイントの作成」ボタンを押下して作成完了!
3.ターゲットエンドポイントの作成
同様に、出力先となるエンドポイントの作成を行います。
今回のターゲットはS3とし、出力フォーマットはParquetファイルとします。
・エンドポイント識別子:「test-target-endpoint」
・ARN名:「test-target-endpoint」※任意
・ソースエンジン:「Amazon S3」
・サービスへのアクセスロールの ARN:IAMコンソールにて、格納したいS3バケットへのアクセスを許可したポリシーがアタッチされたIAMロールを作成しておき、そのARNをコピペする。
・バケット名:格納したいバケット名を指定する。
・バケットフォルダ:バケット内でのパス(格納しておきたいディレクトリ)を指定
→同様に接続テストを行い、成功したら完了。
4.移行タスクの作成
最後に本編となるデータベース移行タスクを作成します。
DMSコンソールから「データベース移行タスク」タブを押下し、移行タスク一覧から「タスクの作成」ボタンを押下。
・タスク識別子:「test-task」
・説明的な Amazon リソースネーム (ARN):「test-task」※任意
・レプリケーションインスタンス:test-rep-instanceを選択
・ソースデータベースエンドポイント:test-source-endpointを選択
・ターゲットデータベースエンドポイント:test-target-endpointを選択
・移行タイプ:「既存のデータを移行して、継続的な変更をレプリケートする」を選択する
※レコードの追加等なく、1回きりの移行で問題ない場合は既存のデータを移行するだけでOK。
ここまで選択したら、「タスクの作成」ボタンを押下して移行タスクの作成を完了させる。
移行タスクが作成できました。(識別子違うのは許してください)
5.テーブルマッピング設定
移行タスクを起動する前に、ソースエンドポイント(RDS側)で移行したいテーブルを指定します。原則的に指定したテーブルしか移行できません。
4項で作成した移行タスクのチェックボックスをONにして「アクション」→「変更」を押下。
「テーブルマッピング」内のJSONエディタモードを指定後、以下のJSON内容を入力します。
{
"rules": [
-- 複数テーブルを連携したい場合、この単位のブロックをカンマ区切りで追加していく
{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "1",
"object-locator": {
"schema-name": "{対象RDSクラスタのスキーマ名}",
"table-name": "{移行したいテーブル名}"
},
"rule-action": "include",
"filters": []
}
]
}
上記設定を行い、「保存」ボタンを押下して変更を完了させる。
その後、移行タスク一覧画面より対象タスクをチェックON→「開始/再開」を押下する。
再開 or 再起動を聞いてくるので、初回なのでフルロード(再起動)を行う。
『ロード完了、レプリケーション進行中』
となったら設定完了!
最後に、S3の設定箇所にparquetファイルが作成されているかを確認し、作成できていればOK!
X.エラーになったら
ねすたが起動チェックしていてエラーになった箇所を記載しておきます。
①致命的なエラー
ソースエンドポイントの指定でリーダーインスタンスを指定しているとFATAL ERRORでエラー内容も吐かれないので必ずライターインスタンスを指定するようにしてください。エラー内容出ないとホントに訳がわからなくなります。
②バイナリログ系のエラー
エラー内容が出力されるようになり、再び起動チャレンジすると、バイナリログが云々...みたいなエラーが出力された。
解決策としては、ソースエンドポイントの参照元Aurora MySQLに紐づけているクラスタパラメータグループのパラメータの1つにある「binlog_format」が「OFF」になっていたら原因の可能性が非常に高い。
これを「ROW」に変更し、対象クラスタのライターインスタンス(と念の為リーダーインスタンス)の再起動を行う。
これでいけるはずです!
※上記以外は遭遇していないので、適宜ググっていただけるとmm
こちらからは以上です。
この記事が気に入ったらサポートをしてみませんか?