Realtime Compute for Apache Flink:Flink CDC を使用したデータインジェストに関するよくある質問

影響範囲

• 影響を受けるジョブ: MySQL ソースを使用するデータインジェストジョブ。

• 影響を受けるバージョン: すべての Ververica Runtime (VVR) エンジンバージョンで発生する可能性があります。

説明

• スナップショットフェーズ中にジョブが頻繁に再起動することがあります。JobManager のログには OutOfMemoryError (OOM) のスタックトレースが表示されます。

• さらに、[アラーム] タブで、Num of remaining SnapshotSplits および Num of processed SnapshotSplits メトリックの値が異常に高い場合は、問題を示しています。

原因

この問題はスナップショットフェーズ中に発生します。MySQL ソースは、すべてのテーブルシャードのメタデータを Flink ジョブの状態に永続化します。ジョブが大量のデータを処理する場合や、非常に小さいシャードサイズを使用する場合、JobManager は読み取るために過剰な数のシャードを作成することがあります。この多数のシャードがメモリを過剰に消費し、JobManager が OOM を経験することになります。

解決策

• JobManager に割り当てられるメモリリソースを増やします。

• JobManager のヒープメモリとオフヒープメモリを増やすために、jobmanager.memory.heap.size および jobmanager.memory.off-heap.size パラメーターを調整します。

影響範囲

• 影響を受けるジョブ: MySQL ソースを使用するデータインジェストジョブ。

• 影響を受けるバージョン: VVR 11.1 以前で発生する可能性があります。

説明

• Flink ジョブは増分フェーズに入りますが、状態の復元中に失敗します。JobManager のログには OOM が表示されます。

原因

VVR 11.1 以前のバージョンでは、スナップショットフェーズから増分フェーズに移行した後、ジョブの状態から永続化されたテーブルスキーマ情報が適切にクリーンアップされない場合があります。この残された管理されていないスキーマ情報が蓄積され、ジョブがチェックポイントから状態を復元しようとすると OOM が発生します。

解決策

• VVR 11.2 以降にアップグレードします。

影響範囲

• 影響を受けるジョブ: MySQL ソースを使用するデータインジェストジョブ。

• 影響を受けるバージョン: すべての Ververica Runtime (VVR) エンジンバージョンで発生する可能性があります。

説明

• スナップショットフェーズの後半、通常は処理すべきシャードが少数残っている場合に TaskManager の OOM が発生することが観察されます。

• キーワード using select statement で TaskManager のログを調べると、最後の無制限クエリが非常に大量のデータを含んでいることがわかる場合があります。

原因

この問題は、スナップショットフェーズ中の長時間のデータ読み取りに起因します。これにより、最後のシャードに大量の増分データが蓄積されます。TaskManager がこの大量に蓄積されたシャードを処理しようとすると、メモリが不足し、OOM エラーが発生します。

解決策

• オプション scan.incremental.snapshot.unbounded-chunk-first.enabled: true を設定します。このパラメーターを設定した後、スナップショットを再実行します。

影響範囲

• 影響を受けるジョブ: MySQL ソースを使用するデータインジェストジョブ。

• 影響を受けるバージョン: VVR 11.1 以前で発生する可能性があります。

説明

• ロックフリーのテーブルスキーマ変更後も、Flink ジョブは再起動せずに実行を続けます。

• CurrentFetchTimeLag メトリックは期待どおりに進み、データがフェッチされていることを示します。

• しかし、MySQL ソースは新しいデータの生成を停止し、CurrentEmitTimeLag メトリックの更新が停止します。これはデータ処理または発行が停止したことを意味します。

原因

VVR 11.1 以前のバージョンでは、pt-osc などのロックフリースキーマ変更ツールによって生成されたデータ定義言語 (DDL) 変更イベントを正しく処理できませんでした。これらの特定の DDL イベントを処理できないため、スキーマ変更後にデータパイプラインが停止します。

解決策

• VVR 11.2 以降にアップグレードします。

• オプション scan.parse.online.schema.changes.enabled: true を設定します。

影響範囲

• 影響を受けるジョブ: MySQL ソースを使用するデータインジェストジョブ。

• 影響を受けるバージョン: VVR 11.1 以前で発生する可能性があります。

説明

• ロックフリーのテーブルスキーマ変更 (例: pt-osc を使用) の後、Flink ジョブが予期せず再起動します。Transform オペレーターのログには、列の型不一致エラーが示されます。

原因

VVR 11.1 には既知の問題があります。ロックフリーのスキーマ変更操作中に大量のデータがテーブルに挿入されると、エンジンが解析不能なイベントを生成する可能性があります。

解決策

• VVR バージョン 11.2 以降にアップグレードし、ロックフリーのスキーマ変更前のチェックポイントからステートフルに再起動します。

影響範囲

• 影響を受けるジョブ: MySQL ソースを使用するデータインジェストジョブ。

• 影響を受けるバージョン: VVR 11.1 以前で発生する可能性があります。

説明

• テーブルスキーマ変更前に作成されたチェックポイントからステートフルに再起動しようとすると、ジョブは失敗します。エラーメッセージは通常、ジョブがバイナリログを消費している間にテーブルスキーマの不一致例外を示します。

原因

VVR 11.1 以前のバージョンでは、互換性のないテーブルスキーマを含むチェックポイントからのステートフルな再起動をサポートしていません。

解決策

VVR 11.2 以降にアップグレードします。アップグレード後、スキーマ変更前のチェックポイントからジョブを再起動します。