RedshiftとAurora MySQLのZero-ETLの検証メモ
RedshiftとAurora MySQLのZero-ETLの検証メモです。
基本的な動作確認は、すでに他の方やクラメソさんがやっているので、ここでは個人的に気になった部分を中心にメモしています。
Redshiftのデスティネーションデータベースは、Zero-ETLを作り直すたびに新規作成する必要がある
そもそもデスティネーションデータベースって言葉が初耳だったんですが、Zero-ETLの送信先データベースのことみたいですね。
ドキュメントでは、下記のようにCREATE DATABASEでデスティネーションデータベースを作成するように記載があります。
CREATE DATABASE destination_db_name FROM INTEGRATION 'integration_id';
Zero-ETLを作り直すと統合IDが変わるので、デスティネーションデータベースを再作成する必要があります。
余談ですが、Zero-ETLはBlue/Greenデプロイメントに対応していません。
Blue/Greenデプロイメントをするたび、Zero-ETLの再作成とデスティネーションデータベースの再作成が必要になります。
頻繁にBlue/Greenデプロイメントをすることはないとは思いますが、その度にデスティネーションデータベースを再作成するのは面倒ですね。
切り替え中、ブルー環境とグリーン環境では Amazon Redshift とのゼロ ETL 統合はできません。最初に統合を削除してから切り替えて、統合を再作成する必要があります。
CREATE DATABASEではなく、既存データベースにALTER DATABASEで統合IDを変更できれば良かったんですが、現時点では対応していないようです。
Redshiftのデスティネーションデータベースの作成時にオーナーが指定できない
ドキュメントを見ると[ OWNER [=] db_owner ]でオーナーが指定できそうですが、デスティネーションデータベースを作成する際にオーナーを指定するとエラーになります。
AWSサポートに問い合わせてみたらドキュメント直しておきますと言っていたので、大元のドキュメントを見たら修正されてました。
オーナーが指定できないので、Zero-ETL用のユーザー作成時にCREATEDB権限を付与してCREATE DATABASEを実行する必要があります。
なんでオーナー指定できないんですかね？
MEDIUMTEXT/LONGTEXT型のカラムがあるテーブルは、Zero-ETLでエラーになる
ドキュメントを見ると、MEDIUMTEXT/LONGTEXT型はVARCHAR(65,535)にマッピングされています。
MEDIUMTEXT/LONGTEXT型は、65,535バイト以上の文字列を格納できるので、RedshiftのVARCHAR(65,535)を超過する文字列があるとエラーになります。
DMSみたいに切り捨ててくれる設定があれば良いんですが、結構不便ですね。
現時点だとRedshift Federated Queryを利用してAurora MySQLへ直接クエリするか、超過した文字列を切り捨てたテーブルを作って複製するか、何かしらの対応が必要になります。
Redshift Federated Queryを利用しても、Value of VARCHAR type is too longというエラーが発生するため、超過した文字列を切り捨てたテーブルを作って複製するしかなさそうです。
Redshiftの拡張VPCルーティングに対応していない
上記の問題があったため、Redshift Federated Queryを利用しようと考えていましたが、RedshiftとAurora MySQLのVPCが異なっていました。
ドキュメントを見た感じ、RedshiftとAurora MySQLのVPCが異なっている場合、拡張VPCルーティングを有効にする必要があるようでした。
注記
Amazon Redshift クラスターが RDS または Aurora MySQL インスタンスとは異なる VPC にある場合は、拡張 VPC ルーティングを有効にします。そうしないと、横串検索の実行時にタイムアウトエラーが発生することがあります。
Redshiftの拡張VPCルーティングを有効にしたところ、Zero-ETLが失敗し、Redshiftの設定が変更できなくなりました。
=> AWSサポートに依頼して解決しました
Redshiftの拡張VPCルーティングを無効にして、Auroraをパブリックにアクセス可能な設定にすれば、Redshift Federated Queryを利用できるようになりました。
Auroraをパブリックアクセス可能にするのは、セキュリティ的にやりたくないですね。
無効な文字コードのデータがあるとエラーになる
無効な文字コードがあり、同期エラーとなっていました。
おそらく、マルチバイト文字のロードエラーだとは思うんですが、レコード数が多いとエラー原因が特定しづらいです。
SYS_LOAD_ERROR_DETAILからエラー内容を確認できるみたいなんですが、エラーメッセージが512文字で切り捨てられていて、対象レコードとエラーになった文字が特定できずに四苦八苦しています。
同期したテーブルに知らないカラムが追加されていた
Zero-ETLで利用してるカラムなんですかね？
ドキュメントにも特に記載はなかったので詳細は不明ですが、SELECT *では表示されないのであまり影響はなさそうです。
- padb_internal_txn_seq_col
- padb_internal_txn_id_col
Discussion