こんにちは、Tunnelでエンジニアをしている谷(naotee)です。
RedShiftはwindow関数が使えますし、大量のレコードがあったとしても、集計や分析系のクエリが早く返ってきて便利ですよね。 また、RedShiftに突っ込んだログ系のデータのidの詳細を持っているのがMySQLなんですが、JOINさせる際にできる限り新しいデータで見れる方が良いですよね。 ということで、今回AWS DMSのOngoind Replicationを利用し、MySQL(RDS)とRedshiftをリアルタイム同期させてみました。
DMSとは
「AWS Database Migration Service は、広く普及しているほとんどの商用データベースとオープンソースデータベース間のデータ移行にご利用いただけます。」
AWS Database Migration Service（データベースを簡単かつ安全に AWS へ移行） | AWS
DMSを利用するにあたって必要なもの
- 同期元DB(source endpoint)
- 同期先DB(target endpoint)
- DMS用ec2インスタンス
上記3つは全て同じリージョンである必要があります。 弊社のMySQL(RDS)は東京リージョンに、RedShiftはコスト対策のためバージニアにありましたので、 MySQL(RDS)のクロスリージョンレプリカを利用してバージニアに同期元DBを設置し、バージニアでDMSを設定しました。
同期(タスク)の種類は３つあります。
- migrate existing data(初期転送のみ)
- migrate existing data and replicate ongoing changes(初期転送後、差分転送開始)
- replicate data changes only(差分転送のみ)
今回はRedShiftに0から同期するので「migrate existing data and replicate ongoing changes(初期転送後、差分転送開始)」をタスクで指定します。
DMSの画面での作業の流れ
「Get started」に従うと下記のような流れになります。「cancel」をクリックして、個別に設定することもできます。
- sourceとtargetにアクセス可能なレプリケーションインスタンスを立ち上げます
- endpointのsourceとtargetを指定します
- taskを指定します
MySQL(RDS)で注意が必要な設定
MySQL(RDS)で差分転送を利用するためにはbinログの設定が必要となります。下記を参照ください。
MySQL 互換データベースの AWS Database Migration Service のソースとしての使用
エラー事例
「Check 'stl_load_errors' system table for details. [122502] ODBC general error. (ar_odbc_stmt.c:4063)」というエラーが出たため、stl_load_errorsテーブルを確認すると「Invalid timestamp format or value [YYYY-MM-DD HH24:MI:SS]」というメッセージを確認しました。 MySQLにある0000-00-00 00:00:00というレコードを適切なものに修正すればエラーがなくなりました。
運用中のエラー検知について
タスクがエラーとなって止まった時の検知方法ですが、 AWSのサポートセンターに確認しましたところ、直接アラートを上げる方法ないみたいです。
大きく２つのやり方を紹介してもらいました。
1.AWS CLI にてレプリケーションタスクの状態を取得する方法
例：「aws dms describe-replication-tasks --filter Name=replication-task-id,Values=[レプリケーションタスクID]」
ただし、値を検知してアラートを上げる仕組みを構築する必要があります
2.DMSで出力しているCloudWatchのログから、フィルタパターンに例えば「"]E:"」を指定するようなカスタムメトリックスを作成し、アラームを利用して検知する方法
やってみて
運用中2回停止したことがあり、本番環境から直接参照するデータベースに同期先データベースを利用することは要検証かと思いますが、日々の数値確認や、バッチ処理によるデータ作成のときに利用するには十分活用できると感じました。
参照サイト
この記事を書いた人：naotee
エンジニアのnaoteeです。 サーバーまわりやwebまわりを触っています。データーまわり触るの好きです。