見出し画像

【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コンソールより、「エンドポイント」タブを押下。

・エンドポイント一覧画面より、「エンドポイントの作成」ボタンを押下。

・エンドポイントタイプは「ソースエンドポイント」を選択。

画像1

・エンドポイント識別子：「test-source-endpoint」

・ARN名：「test-source-endpoint」※任意

・ソースエンジン：「Amazon Aurora MySQL」

画像2

・エンドポイントデータベースへのアクセス：「手動で提供する」を選択

・サーバー名：RDSで移行したいAurora MySQLのクラスタを確認し、「接続とセキュリティ」タブの「エンドポイント」欄にあるライターインスタンスのエンドポイント名をコピペする。

画像3

・ポートは3306、ユーザはRDSのマスタユーザ名を適宜入力。

・テスト接続：VPCはお使いのセキュアなもの、レプリケーションインスタンスは1項で作成した「test-rep-instance」をそれぞれ選択。

その後、「テストの実行」ボタンを押下して接続が成功すれば「エンドポイントの作成」ボタンを押下して作成完了！


3.ターゲットエンドポイントの作成

同様に、出力先となるエンドポイントの作成を行います。

今回のターゲットはS3とし、出力フォーマットはParquetファイルとします。

・エンドポイント識別子：「test-target-endpoint」

・ARN名：「test-target-endpoint」※任意

・ソースエンジン：「Amazon S3」

画像4

・サービスへのアクセスロールの 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


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 再起動を聞いてくるので、初回なのでフルロード（再起動）を行う。

『ロード完了、レプリケーション進行中』

となったら設定完了！

画像6

最後に、S3の設定箇所にparquetファイルが作成されているかを確認し、作成できていればOK！


X.エラーになったら

ねすたが起動チェックしていてエラーになった箇所を記載しておきます。

①致命的なエラー

ソースエンドポイントの指定でリーダーインスタンスを指定しているとFATAL ERRORでエラー内容も吐かれないので必ずライターインスタンスを指定するようにしてください。エラー内容出ないとホントに訳がわからなくなります。

②バイナリログ系のエラー

エラー内容が出力されるようになり、再び起動チャレンジすると、バイナリログが云々...みたいなエラーが出力された。

解決策としては、ソースエンドポイントの参照元Aurora MySQLに紐づけているクラスタパラメータグループのパラメータの1つにある「binlog_format」が「OFF」になっていたら原因の可能性が非常に高い。

画像7

これを「ROW」に変更し、対象クラスタのライターインスタンス（と念の為リーダーインスタンス）の再起動を行う。

これでいけるはずです！

※上記以外は遭遇していないので、適宜ググっていただけるとmm


こちらからは以上です。

いいなと思ったら応援しよう！