事象
Aurora PostgreSQL と Amazon Redshift のゼロ ETL 統合によるデータ同期中、一部テーブルで以下のエラーメッセージが出力し、初回レプリケーションが失敗しました。
Replicating initial data for table "<schema>"."<table>" failed.
Column '<column>' length XXXX is longer than in the table YYYY.
Check the data that might be causing issues. If the issue persists, contact AWS Support.
原因
Aurora PostgreSQL の VARCHAR(n) とRedshift の VARCHAR(n) の定義の違いが原因でした。
- Aurora の
VARCHAR(n)= n 文字 - Redshift の
VARCHAR(n)= n バイト
haracter varying(n)とcharacter(n)です。 ここでnは正の整数です。 これらのデータ型は2つともn文字長（バイト数ではなく）までの文字列を保存できます。
VARCHAR(120) 列は、最大で 120 個のシングルバイト文字、60 個の 2 バイト文字、40 個の 3 バイト文字、または 30 個の 4 バイト文字で構成されます。
そのため、日本語など 1 文字あたり 2～3 バイト以上が必要なマルチバイト文字を使っている場合、Aurora 側での文字数が Redshift では実際のバイト長を上回ってしまい、エラーとなっていました。
対策
この問題を回避する方法として、主に以下の 2 つが考えられます。
1. Aurora 側のカラム定義を広げる
全文の連携が必要な場合、VARCHAR(1024) や TEXT を使用してAurora 側のカラム長を十分に確保することで対応が可能になります。
ただし、既存のアプリケーションのDBカラムの更新となるため、事前に影響範囲の検証が必要です。
2. Redshift 側で TRUNCATECOLUMNS = TRUE を設定する
もし「一部のデータが切り捨てられても構わない」要件であれば、2025年1月に導入されたTRUNCATECOLUMNSを有効化することで対応可能になります。
ALTER DATABASE <integration_db_name> INTEGRATION SET TRUNCATECOLUMNS = TRUE;
ALTER DATABASE <integration_db_name> INTEGRATION REFRESH ALL TABLES;
この設定によりAurora 側で格納された長大な文字列が Redshift 側でオーバーした場合に、自動的にデータが切り捨てられます。エラーは回避できますが、データ欠損リスクがある点に注意が必要です。
まとめ
まだ新しい機能のため、TRUNCATECOLUMNSのような新機能が続々と発表され、リアルタイムに進化を感じられるのは楽しいですね！本記事がどなたかの役に立てば幸いです。
Discussion