Redshift と Aurora PostgreSQL のゼロ ETL 統合時に発生したカラム長によるエラーへの対応

事象

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 バイト

https://www.postgresql.jp/docs/9.4/datatype-character.html

haracter varying(n)とcharacter(n)です。 ここでnは正の整数です。 これらのデータ型は2つともn文字長（バイト数ではなく）までの文字列を保存できます。

https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_Character_types.html#r_Character_types-varchar-or-character-varying

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 側でオーバーした場合に、自動的にデータが切り捨てられます。エラーは回避できますが、データ欠損リスクがある点に注意が必要です。

• Amazon Redshift がゼロ ETL 統合用の新しい SQL 機能を導入

• Redshift 公式ドキュメント: ALTER DATABASE

まとめ

まだ新しい機能のため、TRUNCATECOLUMNSのような新機能が続々と発表され、リアルタイムに進化を感じられるのは楽しいですね！本記事がどなたかの役に立てば幸いです。