AWS DMSを利用して既存RDSからRedshiftへの継続的なデータレプリケーション環境を構築
AWS Database Migration Serviceは、AWSが提供するデータベース間の移行を簡単に行うことができるサービスです。 今回はこのサービスを利用して、既存のRDSからデータ基盤として活用を目的とするRedshiftへデータを移行してみたので、その際の構築手順等を紹介します。
環境構築手順
事前準備
RDSの環境設定を確認&変更する
継続的なレプリケーションを実現するために、RDSの設定をいくつか変更しておく必要があります。
こちらの設定変更をせずにタスクを実行したら不明なエラーで何時間も消耗してしまいました
1.自動バックアップが有効になっている
# 現状の設定確認 mysql> call mysql.rds_show_configuration; +------------------------+-------+-----------------------------------------------------------------------------------------------------------+ | name | value | description | +------------------------+-------+-----------------------------------------------------------------------------------------------------------+ | binlog retention hours | NULL | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. | | source delay | 0 | source delay specifies replication delay in seconds between current instance and its master. | | target delay | 0 | target delay specifies replication delay in seconds between current instance and its future read-replica. | +------------------------+-------+-----------------------------------------------------------------------------------------------------------+ 3 rows in set (0.01 sec) # 保存期間を24hに変更する mysql> call mysql.rds_set_configuration('binlog retention hours', 24);
3.binlog_formatの値がROWに設定されていること
4.binlog_checksumの値がNONEに設定されていること
３と4のパラメータは、RDSの管理画面より確認し変更します。
サブネットの追加
レプリケーションインスタンスの作成時に、この作成したサブネットを指定する必要があるので、はじめに作成しておきます。
サブネットグループの設定
- 名前
- 適当な名前を設定します
- 説明
- 適当な説明を設定します
- VPC
- 既存のVPCが選択できるようになっているので該当するVPCを選択します
サブネットの追加
- 上記で選択したVPC環境のサブネットが選択できるようになっています。アベイラビリティゾーンが異なる２つを最低でも選択します。
レプレイケーションインスタンス
レプリケーションインスタンスの設定
- 名前
- 適当な名前を設定する
- 説明
- 適当な説明を設定する
- インスタンスクラス
- デフォルトのdms.t2.mediumを選択
- エンジンバージョン
- デフォルトの最新バージョンを選択
- 割り当てられたストレージ(GB)
- デフォルトのまま(50GB)
- VPC
- 該当するVPCを選択する
- マルチAZ
- 今回はそれほど高可用性、耐障害性は求めていなかったのでチェックはつけませんでした
- パブリックアクセス可能性
- チェックをつけましたが、下記で選択するVPCセキュリティグループにて自社IPアドレスからのインバウンドのみを受け付けるよう設定してます
セキュリティとネットワークの詳細設定
- レプリケーションサブネットグループ
- 「サブネットの追加」で作成したものを選択します
- アベイラビリティーゾーン
- デフォルトの指定なしでも問題ありませんが、明示的にアベイラビリティーゾーンを選択することも可能です
- VPCセキュリティグループ
- 新規にこのDMSようにセキュリティグループを作成し、ここに設定しました。（セキュリティグループは自社IPアドレスからのインバウンドのみを受け付けるよう設定してます)
- KMSマスターキー
- デフォルトのまま
メンテナンス
- デフォルトのまま
ソース
ソースには、RDSの設定を行います。
エンドポイントタイプ
- ソースエンドポイントを選択します
- RDS DB インスタンスの選択チェックボックスをチェックします
- RDS インスタンス
- 該当するRDSを選択します
エンドポイント設定
- 以下はRDSインスタンスを選択したら値は設定されます
- エンドポイント識別子
- ソースエンジン
- サーバー名
- ポート
- ユーザー名
- パスワード
- パスワードを設定します
エンドポイント固有の設定
特に設定はしてません
KMS マスターキー
デフォルトのまま
エンドポイント接続のテスト
タスクを実行する前には、ソース・ターゲットでの接続テストが「successful」になっている必要があります。
テストの実行ボタンを押して、「successful」になることを確認しておきます
ターゲット
ターゲットには、Redshiftを設定します
エンドポイントタイプ
- ターゲットエンドポイントを選択
エンドポイント設定
- エンドポイント識別子
- ターゲットエンドポイントとわかるような識別子を設定しておくと良い
- ターゲットエンジン
- redsihftを選択
- サーバー名
- redshiftのエンドポイントを設定
- ポート
- デフォルトのままであれば5439
- ユーザー名
- redshift作成じに設定したユーザー名
- パスワード
- redshift作成じに設定したパスワード
- データベース名
- redshift作成じに設定したデータベース名
エンドポイント固有の設定
特に設定はしてません
KMS マスターキー
デフォルトのまま
エンドポイント接続のテスト
テストの実行ボタンを押して、「successful」になることを確認しておきます
タスク
タスクの設定
- タスク識別子
- タスクを判別できる識別子を設定
- レプリケーションインスタンス
- 上記で作成したレプリケーションインスタンスを選択
- ソースデータベースエンドポイント
- 上記で作成したソースデータベースエンドポイントを選択
- ターゲットデータベースエンドポイント
- 上記で作成したターゲットデータベースエンドポイントを選択
- 移行タイプ
- 既存のデータを移行して、継続的な変更をレプリケートするを選択
タスク設定
- ターゲットテーブル作成モード
- ターゲット上のテーブルを削除
- レプリケーションにLOB列を含める
- 制限付きLOBモード
- 最大LOBサイズ(KB)
- 32(デフォルトのまま)
- 検証の有効化
- 未チェック
- CloudWatchログを有効化
- 未チェック
テーブルマッピング
- 編集モード
- ガイド付きUIを選択
- 選択ルール
- ここで移行するテーブルとかカラムとか細かく制御を書くことができる
- 全てのテーブルを移行するのであれば、移行するスキーマを選択し、テーブル名は%のままで、アクションを「含む」設定でOK
詳細設定を使用する
ここの設定は基本デフォルトのまま
並列にロードするテーブルの最大数
- これは構築した環境にもよると思うので、一旦実行してみてエラーが出るようであれば調整するとかで良いと思う。
上記全てを設定し、「タスクの作成」ボタンをクリックするとタスクが実行されます。
データ移行時にエラーが発生した場合の確認方法
ステータスがエラーとなり、ロード状態に「Table error」となっているテーブルが数件存在。
解決方法
- エラーとなったテーブルの個別のタスクを作成する。その際に、CloudWatchログの設定をonにしておく
- タスクを実行し、Cloudwatchログを参照する
- Check 'stl_load_errors'とあったので、SQLWorkbenchJを利用してredshiftのstl_load_errosを確認する
- stl_load_errosのerr_reasonにエラー内容が記載されているので、その問題を解消する。今回自分が該当したエラーは、日付の所におかしなデータが登録されておりフォーマットエラーとなっていたので該当するデータを修正し問題を解決しました。
所感
基本的には、管理画面からポチポチしていくだけで、簡単にデータの移行ができてしまう。100近いテーブル数にデータ数もそれなりにあるものですが、移行時間は１時間もかからない感じで終了しました。その後も現在数日間稼働していますが、問題なく「レプリケーション進行中」と安定稼働しています。
