AWS Database Migration Serviceでデータ同期する

AWSのRDS環境をリアルタイム同期させる要望があり、今回初めてDatabase Migration Service(DMS)を使ってみた。
AWS自体頻繁に触るものではないので使い方をメモしておく。

動機

今回masterのDB(以下、ソースDB)を別用途(外部ツールとの連携)で使用したいという要望があった。
実装を行う上で下記の要件があがった。

  • ソースDBと外部ツールをリアルタイム同期したい
  • ソースDBのテーブル内には個人情報が含まれるカラムがあるので、特定のカラムを見えなくした状態で外部ツールと同期したい
  • ビューは外部ツールが読み取れないので使用できない

特にビューが使えないというのがネックで、ここでカラムの制限も考えたができないとなり「mysqldumpで出力したファイルの編集辛いかなあ」と知り合いに相談したらDMSを教えてもらったので使用してみた。
結果的にmysqldumpで出力したファイルを編集するくらいの学習コストはあったけども、普段AWSを触っていないので勉強としてはちょうど良かった。
以下、簡単な設定手順

ソースDBのテーブル構成をコピーする

この手順はスキップしても良いが、コピー先のテーブル定義を手動で調整したい場合はAWS Schema Conversion Tool(SCT)を使用する。

※SCTを使用しなくてもDMSでのデータ移行時にテーブルは自動で作成は可能だが一応記載。

SCTのセットアップ

Webでの操作ではなく、SCTは端末にアプリケーションをインストールする。

今回はソースDB元も移行先(以下、ターゲットDB)もMySQLになるため、MySQL用のドライバもインストールする

Global setting

ここでAWSで設定したキーペアを登録する。登録しておくと、該当ユーザーでDMSのタスクを作成したりできる。

Project定義

ProjectではソースDBの接続先とターゲットDBの接続先を設定する。
設定が完了してSCTで読み込みが完了すると画面内にDB構成が表示される。

移行対象のテーブルの設定方法は、

  • 左側の画面(ソースDB)で移行対象のテーブルを選択してチェックする
  • 左側画面の移行対象のテーブル名を右クリックして「Convert Schema」を選択。右側に移行するテーブルが表示される。
  • 画面中央には移行対象のテーブル定義のsqlが表示される。ここで不要なカラムは下の画面(移行先に適用するテーブル定義)で削除を行ったり、データ型を変更したりする。
  • 以上の操作を繰り返し、完了したら右側画面のDBのところを右クリックして「Apply to Database」を選択すると、ターゲットDBに今まで設定したテーブル定義の内容が適用される。

DMSを設定する

移行を行うDMSの設定を行う

レプリケーションインスタンスを設定

移行作業を実施するインスタンスを作成する。
インスタンスクラスは規模にもよるが今回はt2.mediumを選択した。
その他DMSで推奨となるマルチAZ構成を選択する。

サブネットグループを設定する

ソースDBとターゲットDB両方と疎通が取れるよう適切なサブネットを設定する。

エンドポイント

ソースDBとターゲットDBをそれぞれ設定する。

移行タスクの作成

今まで設定した内容を反映させる。
またデータ移行後もソースDBのデータをリアルタイム同期させるために「移行タイプ」は「既存のデータを移行して、継続的な変更をレプリケートする」を選択する。

テーブルマッピング

ここで移行から除外するテーブルやカラムを定義する。
定義はGUIでも可能だが、大量の設定が必要な場合はjsonで設定した方が楽。テーブル除外とカラム除外の定義方法の一例を記載する。

{
  "rules": [
    {
      "rule-type": "transformation",
      "rule-id": "1",
      "rule-name": "1",
      "rule-target": "column",
      "object-locator": {
        "schema-name": "db_name",
        "table-name": "table_name",
        "column-name": "column1"
      },
      "rule-action": "remove-column",
      "value": null,
      "old-value": null
    },
    {
      "rule-type": "selection",
      "rule-id": "2",
      "rule-name": "2",
      "object-locator": {
        "schema-name": "db_name",
        "table-name": "table_name"
      },
      "rule-action": "exclude",
      "filters": []
    },
    {
      "rule-type": "selection",
      "rule-id": "3",
      "rule-name": "3",
      "object-locator": {
        "schema-name": "db_name",
        "table-name": "%"
      },
      "rule-action": "include",
      "filters": []
    }
  ]
}

以上の設定を行ってタスクを実行すると移行がスタートする

DMSを使用する上での注意事項

  • リアルタイム同期をするためにはソースDBでbinlogを有効化する必要がある。
    • この制限があったためにリードレプリカをソースDBにすることを断念した
  • テーブルマッピングでは除外対象以外に移行対象のスキーマも指定する必要がある。(テーブル名「%」で全テーブルを指定)
    • この設定が抜けていてハマった。。

という感じで、移行だけでなくそのあとの差分も自動的に同期してくれるのでとても便利。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

5 × five =

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください