この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
データアナリティクス事業本部のkobayashiです。
Aurora MySQLクラスターのバイナリログを使ってレプリケートする必要があり、その手段としてをAWS DMS(Database Migration Service)を使う機会がありました。検証の途中で、RDS for MySQLとAurora MySQLとの設定の違う箇所があったりしてハマった箇所もあるためその内容をまとめます。
- AWS Database Migration Service とは - AWS Database Migration Service
- MySQL 互換データベースの AWS DMS のソースとしての使用 - AWS Database Migration Service
今回検証を行ったきっかけ
元々はAurora MySQLのデータをSnowflakeに連携したいがどのような方法があるかを調べているなかで以下のブログをたどり着き、参考にさせていただきました。
今回はこちらで紹介されている連携方法のうち「Aurora」から「S3」へ連携する箇所を実際に試してみたいと思います。
なお、「S3」から「Snowflake」へ連携する箇所は別エントリで検証を行っているのでこちらも併せて御覧ください。
AWS DMSとは
様々なデータベース（RDB,NoSQL,DWH）を他のデータベースへ移行する際に役立つサービスです。 移行にはワンタイムだけの移行だけでなく、レプリケーション機能を使い継続的に移行元と移行先のデータベースを同期することもできます。
今回は Aurora MySQLのCDC（Change Data Capture）としてAWS DMS使ってみます。なお移行先としてはデータベースでなくS3へCSV形式として出力します。
DMSを使ったAurora MySQLのデータ移行
MySQLデータベースでAWS DMSを使う際のドキュメントが「MySQL 互換データベースの AWS DMS のソースとしての使用 - AWS Database Migration Service 」にありますのでこのドキュメントを参考にしながら作業を進めると以下の通りになります。
- Aurora MySQLのパラメータグループの設定
- バイナリログの設定
- AWS DMSの構築
- エンドポイントの作成
- サブネットグループの作成
- レプリケーションインスタンスの作成
- データベース移行タスクの作成
なお、今回ソースとなるAuroraのエンジンは5.7.mysql_aurora.2.07.2で、 すでにクラスターを作成して起動中の状態から進めていきます。
Aurora MySQLのパラメータグループの設定
AWS DMSではMySQLのバイナリログを使いますが、デフォルトのパラメータグループでは有効になっていないため、専用のパラメータグループを作成しそれをAuroa MySQLにアタッチします。Aurora MySQLでのバイナリログの設定は「Amazon Aurora MySQL クラスターのバイナリログを有効にする 」にも記載がありますのでここを参考にします。
手順1）マネージメントコンソールよりパラーメタグループを選択しパラメータグループの作成ボタンを押下する。
手順2）パラメータグループの作成の設定を行い作成を押下する。
- パラメータグループファミリー :
aurora-mysql5.7を選択 - タイプ :
DB Cluster Parameter Groupを選択 - グループ名 : 適切な値を入力
- 説明 : 適切な値を入力
手順3）作成したパラメータグループ名を選択してパラメータの設定を変更する。
binlog_format:ROWを選択binlog_row_image:FULLを選択binlog_checksum:NONEを選択
手順4）データベース > 対象のAuroraクラスタ > 変更でバイナリログ出力の設定を行ったパラメータグループをAuroraクラスターにアタッチします。
手順5）Auroraクラスターを再起動する。
これでAurora MySQLからAWS DMSで取り込めるバイナリログが出力されるようになリます。
AWS DMSの構築
次に実際にレプリケーションを行うDMSの構築を行います。
エンドポイントの作成
はじめにソースとターゲットのエンドポイントを作成します。今回ソースは先に設定を行ったAurora MySQLなので改めてリソースを作成する必要はありませんが、ターゲットはS3としています。バケットとバケットへ書き込むことのできるロールが必要となりますので予め作成しておきます。
今回はS3のバケットをcm-kobayashi-dms-test、読み書きできるロールをdmsAuroraToS3として作成してある状態から進めます。
手順1）AWS DMSからエンドポイントを選択し、エンドポイントの作成を押下する。
手順2）エンドポイントの作成の設定を行いエンドポイントの作成を押下する。
- エンドポイントタイプ :
ソースエンドポイントを選択- RDS DBインスタンスの選択 : チェック
- RDSインスタンスでAuroraを選択
- エンドポイント設定
- エンドポイント識別子 : RDSインスタンスを選択すると自動入力
- ソースエンジン : RDSインスタンスを選択すると自動入力
- エンドポイントデータベースへのアクセス :
アクセス情報を手動で提供するを選択 - サーバー名 : RDSインスタンスを選択すると自動入力
- ポート :
3306を入力 - ユーザー名 : ユーザー名を入力
- パスワード : パスワードを入力
Auroraへの接続情報をAWS Secrets Managerで管理していればエンドポイントデータベースへのアクセスで[AWS Secrets Manager]を選択するを選択すれば良いですが、今回は手動で提供にしてあります。
次にターゲットエンドポイントの設定を行います。
手順3）エンドポイントの作成の設定を行いエンドポイントの作成を押下する。
- エンドポイントタイプ :
ターゲットエンドポイントを選択 - エンドポイント設定
- エンドポイント識別子 : 適当な名前を入力
- ターゲットエンジン :
Amazon S3を選択 - サービスへのアクセスロールのARN : ターゲットとなるバケットに書き込み権限のあるロールを入力
- バケット名 : ターゲットとなるバケット名を入力
- エンドポイント設定 :
{ "CsvRowDelimiter": "\\n", "CsvDelimiter": ",", "CompressionType": "NONE", "EnableStatistics": true, "DatePartitionEnabled": false, "IncludeOpForFullLoad": true }を入力
ターゲットをS3とする場合の出力ファイルの設定はエンドポイント設定で設定を行います。 特に指定しないとCSVで出力される以下の設定値がデフォルト設定として登録されます。
{
"CsvRowDelimiter": "\\n",
"CsvDelimiter": ",",
"CompressionType": "NONE",
"EnableStatistics": true,
"DatePartitionEnabled": false
}今回はこの設定に加えて"IncludeOpForFullLoad": trueを加えています。これは移行タイプでFullロードを選んだ際にも最初の列にInsertを示すIを付け加えることができます。
以上でエンドポイントの設定は終わりです。次にサブネットグループの作成をおこないます。
サブネットグループの作成
レプリケーションインスタンスを配置するサブネットグループを作成します。
手順1）AWS DMSからサブネットグループを選択し、サブネットグループの作成を押下する。
手順2）レプリケーションサブネットグループの作成の設定を行いレプリケーションサブネットグループの作成を押下する。
- サブネットグループの設定
- 名前 : 適当な名前を入力
- 説明 : 適当な説明を入力
- VPC : レプリケーションインスタンスを配置するVPCを選択
- サブネットの追加 : サブネットを2つ以上追加
レプリケーションインスタンスの作成
次にレプリケーションタスクを行うレプリケーションインスタンスの作成を行います。
手順1）AWS DMSからレプリケーションインスタンスを選択し、レプリケーションインスタンスの作成を押下する。
手順2）レプリケーションインスタンスの作成の設定を行いレプリケーションインスタンスの作成を押下する。
- レプリケーションインスタンスの設定
- 名前 : 適当な名前を入力
- 説明 : 適当な説明を入力
- インスタンスクラス : タスクを実行するのに十分なリソースを持ったインスタンスクラスを選択
- エンジンバーション : 特に制限がなければ最新バージョンを選択
- 割り当てられたストレージ : 特に制限がなければデフォルトの
50を入力 - VPC : 先に作成したサブネットグループで設定したVPCを選択
- パブリック・アクセス可能 : チェックを外す
- セキュリティとネットワーク詳細設定
- レプリケーションサブネットグループ : 先に作成したサブネットグループを選択
作成を押して暫く経つとステータスが利用可能になります。
インスタンスが作成できたらここまでの設定が問題ないかを確認します。
再びエンドポイントの画面に戻り、作成したエンドポイントを選択してアクション > 接続テストを押下すると設定に問題がなければステータスがsuccessfulになります。
今回は動作確認のための設定なので最低限の設定となっています。環境に応じて設定を変更してみてください。
データベース移行タスクの作成
最後にレプリケーションインスタンスで実行するでデータベース移行タスクを作成します。
手順1）AWS DMSからデータベース移行タスクを選択し、データ移行タスクの作成を押下する。
手順2）データ移行タスクの作成の設定を行いデータ移行タスクの作成を押下する。
- タスクの設定
- タスク識別子 : 適当な名前を入力
- レプリケーションインスタンス : 先に作成したものを選択
- ソースデータベースエンドポイント : 先に作成したものを選択
- ターゲットデータベースエンドポイント : 先に作成したものを選択
- 移行タイプ :
既存のデータを移行して、継続的な変更をレプリケートするを選択
- タスク設定 :
ウィザードを選択し、デフォルト値のまま - テーブルマッピング :
ウィザードを選択し、対象のスキーマを絞る場合は設定
これで移行タスクが設定できたのでAurora MySQLからS3へのデータ移行の準備ができました。
タスクを実行してみる
では最後に作成したデータベース移行タスクを実行してみます。
データベース移行タスクを選択し、作成したタスクにチェックを入れ、アクション > 開始/再開を押下してタスクを開始します。
しばらくすると実行中になりロードが完了するとロード完了、レプリケーション実行中とステータスが変わります。
タスク名からタスクの詳細を確認してみるとタスクの状況やデータ移行の統計情報が確認できます。
ターゲットの確認
ターゲットのS3を見てみるとファイルができています。また適当なクエリを実行すると新たにCSVファイルが出来上がります。
ファイルの中身を見ると以下のように行データがどのように変更されたかが記録されています。
$ head -n 5 LOAD00000001.csv
I,1,Kabul,AFG,Kabol,1780000
I,2,Qandahar,AFG,Qandahar,237500
I,3,Herat,AFG,Herat,186800
I,4,Mazar-e-Sharif,AFG,Balkh,127800
I,5,Amsterdam,NLD,Noord-Holland,731200
$ head -n 5 20211116-030109755.csv
D,1752,Sakata,JPN,Yamagata,101651
I,4080,u02naeNPL1hGghP1okO6Ca3St904Ez9cBFp,JPN,G5WISS6KAqkixVQWpkFO,16889
U,1309,A4vBcfzBUknhHPbMVgbZS5NyOiErCgKim34,IND,H1qlDm3K3O8rFTjt9Hld,35906まとめ
Aurora MySQLのデータをAWS DMSを使い移行タイプとしてFullロードとCDCでS3へCSV出力してみました。 設定もマネージメントコンソールから簡単に行えるのでS3を起点としてその先にデータをレプリケーションしたい場合には有効に機能すると思われます。
また、S3からの連携先としてSnowflakeへの検証を別エントリで行っているのでこちらも併せてご覧ください。
最後まで読んで頂いてありがとうございました。
2
