このトピックでは、Flink CDC を使用したデータインジェストジョブに関するよくある質問について説明します。
クイックリファレンス
| 症状 | フェーズ | 重要度 | リンク |
|---|---|---|---|
高い SnapshotSplits メトリック値での JobManager のメモリ不足 (OOM) | スナップショット | 重大 | FAQ 1 |
| 残りのシャードが少ない場合の TaskManager のメモリ不足 (OOM) | スナップショット | 重大 | FAQ 3 |
| 増分読み取り中の状態復元時の JobManager のメモリ不足 (OOM) | 増分 | 重大 | FAQ 2 |
ロックフリースキーマ変更後に新しいデータはありません。pt-osc | スキーマ変更 | 高 | FAQ 4 |
| ロックフリーのスキーマ変更後の Transform 列の型不一致 | スキーマ変更 | 高 | FAQ 5 |
| スキーマ変更前のセーブポイントからのジョブ復元失敗 | 状態回復 | 高 | FAQ 6 |
スナップショットフェーズ
FAQ 1: スナップショットフェーズ中の JobManager のメモリ不足 (OOM)
重要度: 重大 | フェーズ: スナップショット | 対象バージョン: すべての VVR エンジンバージョン
症状
スナップショットフェーズ中にジョブが繰り返し再起動します。
JobManager のログに
OutOfMemoryError(OOM) スタックトレースが含まれています。[アラーム] タブで、
Num of remaining SnapshotSplitsおよびNum of processed SnapshotSplitsメトリックが異常に高い値を示します。
原因
スナップショットフェーズ中、MySQL ソースはすべてのテーブルシャードのメタデータを Flink ジョブの状態に永続化します。ジョブが大量のデータを処理する場合、または非常に小さいシャードサイズを使用する場合、JobManager は過剰な数のシャードを作成します。これにより、メモリが過剰に消費され、JobManager のメモリ不足が発生します。
ソリューション
JobManager に割り当てられるメモリリソースを増やします。
JobManager のヒープメモリとオフヒープメモリを増やすために、次のパラメーターを調整します。
jobmanager.memory.heap.sizejobmanager.memory.off-heap.size
FAQ 3: スナップショットフェーズ終了時の TaskManager のメモリ不足 (OOM)
重要度: 重大 | フェーズ: スナップショット | 対象バージョン: すべての VVR エンジンバージョン
症状
TaskManager はスナップショットフェーズの終盤、通常は残りのシャードが少ない場合にメモリ不足になります。
TaskManager のログで
using select statementを検索すると、最後の無制限クエリが非常に大量のデータを伴うことが明らかになります。
原因
スナップショットフェーズ中のデータ読み取りが長期化すると、最終シャードまたは複数のシャードに大量の増分データが蓄積されます。TaskManager がこの大量に蓄積されたシャードを処理すると、メモリ不足が発生します。
ソリューション
次のオプションを設定します。
scan.incremental.snapshot.unbounded-chunk-first.enabled: trueスナップショットを再実行します。
増分フェーズ
FAQ 2: 増分フェーズ中の状態復元時の JobManager のメモリ不足 (OOM)
重要度: 重大 | フェーズ: 増分 | 対象バージョン: VVR 11.1 以前
症状
ジョブは増分フェーズに入りますが、状態復元中に失敗します。
JobManager のログに OOM が表示されます。
原因
VVR 11.1 以前のバージョンでは、スナップショットフェーズから増分フェーズへのトランジション後、ジョブの状態から永続化されたテーブルスキーマ情報が適切にクリーンアップされない場合があります。この残されたスキーマ情報が蓄積され、ジョブがチェックポイントから状態を復元する際に OOM が発生します。
ソリューション
VVR 11.2 以降にアップグレードします。
スキーマ変更
FAQ 4: pt-osc を使用したロックフリーのスキーマ変更後の新規データなし
重要度: 高 | フェーズ: スキーマ変更 | 対象バージョン: VVR 11.1 以前
症状
ロックフリーのテーブルスキーマ変更後も、ジョブは再起動せずに実行を継続します。
CurrentFetchTimeLagメトリックは期待どおりに進行し、データがフェッチされていることを示します。MySQL ソースは新規データの生成を停止し、
CurrentEmitTimeLagメトリックの更新が停止します。
原因
VVR 11.1 以前のバージョンでは、pt-osc などのロックフリーのスキーマ変更ツールによって生成された DDL 変更イベントを正しく処理できません。これにより、スキーマ変更後にデータパイプラインが停止します。
ソリューション
VVR 11.2 以降にアップグレードします。
次のオプションを設定します。
scan.parse.online.schema.changes.enabled: true
FAQ 5: ロックフリーのスキーマ変更後の Transform 列の型不一致
重要度: 高 | フェーズ: スキーマ変更 | 対象バージョン: VVR 11.1 以前
症状
ロックフリーのテーブルスキーマ変更 (たとえば、
pt-oscの使用) 後にジョブが予期せず再起動します。Transform オペレーターのログに列の型不一致エラーが示されます。
原因
これは VVR 11.1 の既知の問題です。ロックフリーのスキーマ変更操作中に大量のデータがテーブルに挿入されると、エンジンが解析不能なイベントを生成する可能性があります。
ソリューション
VVR 11.2 以降にアップグレードします。
ロックフリーのスキーマ変更前に作成されたセーブポイントからステートフル再起動を実行します。
状態回復
FAQ 6: スキーマ変更前のセーブポイントからのジョブ復元失敗
重要度: 高 | フェーズ: 状態回復 | 対象バージョン: VVR 11.1 以前
症状
テーブルスキーマ変更前に作成されたセーブポイントからのステートフル再起動が失敗します。
エラーメッセージは、バイナリログの消費中にテーブルスキーマ不一致例外が発生したことを示しています。
原因
VVR 11.1 以前のバージョンは、互換性のないテーブルスキーマを含むセーブポイントからのステートフル再起動をサポートしていません。
ソリューション
VVR 11.2 以降にアップグレードします。
アップグレード後、スキーマ変更前のセーブポイントからジョブを再起動します。