Realtime Compute for Apache Flink：FAQ dan solusi untuk ingesti data

Gejala

• Pekerjaan berulang kali restart selama fase snapshot.

• Log JobManager berisi stack trace OutOfMemoryError (OOM).

• Pada tab Alarm, metrik Num of remaining SnapshotSplits dan Num of processed SnapshotSplits menunjukkan nilai yang sangat tinggi.

Penyebab

Selama fase snapshot, source MySQL menyimpan semua metadata shard tabel ke dalam state pekerjaan Flink. Jika pekerjaan menangani volume data yang besar atau menggunakan ukuran shard yang sangat kecil, JobManager membuat jumlah shard yang berlebihan. Hal ini mengonsumsi terlalu banyak memori dan menyebabkan JobManager kehabisan memori.

Solusi

1. Tingkatkan sumber daya memori yang dialokasikan untuk JobManager.

2. Sesuaikan parameter berikut untuk menambah memori heap dan off-heap JobManager:

   • jobmanager.memory.heap.size

   • jobmanager.memory.off-heap.size

Gejala

• TaskManager kehabisan memori pada akhir fase snapshot, biasanya saat hanya tersisa sedikit shard.

• Pencarian log TaskManager untuk using select statement menunjukkan bahwa kueri tak terbatas terakhir melibatkan volume data yang sangat besar.

Penyebab

Pembacaan data yang berkepanjangan selama fase snapshot menyebabkan akumulasi data inkremental yang signifikan untuk shard terakhir atau beberapa shard terakhir. Saat TaskManager memproses shard besar yang terakumulasi ini, ia kehabisan memori.

Solusi

1. Atur opsi berikut:

      scan.incremental.snapshot.unbounded-chunk-first.enabled: true

2. Jalankan ulang snapshot.

Gejala

• Pekerjaan memasuki fase inkremental tetapi gagal selama pemulihan state.

• Log JobManager menunjukkan OOM.

Penyebab

Versi VVR 11.1 dan sebelumnya mungkin tidak membersihkan informasi skema tabel yang dipertahankan dari state pekerjaan secara tepat setelah transisi dari fase snapshot ke fase inkremental. Informasi skema yang tersisa ini menumpuk dan menyebabkan OOM saat pekerjaan memulihkan state-nya dari checkpoint.

Solusi

1. Lakukan upgrade ke VVR 11.2 atau versi yang lebih baru.

Gejala

• Pekerjaan terus berjalan tanpa restart setelah perubahan skema tabel tanpa lock.

• Metrik CurrentFetchTimeLag berjalan sesuai ekspektasi, menunjukkan bahwa data sedang diambil.

• Source MySQL berhenti menghasilkan data baru dan metrik CurrentEmitTimeLag berhenti diperbarui.

Penyebab

Versi VVR 11.1 dan sebelumnya tidak dapat menangani event perubahan DDL yang dihasilkan oleh alat perubahan skema tanpa lock seperti pt-osc secara benar. Hal ini menyebabkan pipa data macet setelah perubahan skema.

Solusi

1. Lakukan upgrade ke VVR 11.2 atau versi yang lebih baru.

2. Atur opsi berikut:

      scan.parse.online.schema.changes.enabled: true

Gejala

• Pekerjaan tiba-tiba restart setelah perubahan skema tabel tanpa lock (misalnya, menggunakan pt-osc).

• Log operator Transform menunjukkan error ketidaksesuaian tipe kolom.

Penyebab

Ini merupakan isu yang diketahui pada VVR 11.1. Jika volume data yang signifikan dimasukkan ke dalam tabel selama operasi perubahan skema tanpa lock, mesin dapat menghasilkan event yang tidak dapat diurai.

Solusi

1. Lakukan upgrade ke VVR 11.2 atau versi yang lebih baru.

2. Lakukan restart stateful dari titik simpan yang dibuat sebelum perubahan skema tanpa lock.

Gejala

• Restart stateful dari titik simpan yang dibuat sebelum perubahan skema tabel gagal.

• Pesan error menunjukkan pengecualian ketidaksesuaian skema tabel saat mengonsumsi log biner.

Penyebab

Versi VVR 11.1 dan sebelumnya tidak mendukung restart stateful dari titik simpan yang berisi skema tabel yang tidak kompatibel.

Solusi

1. Lakukan upgrade ke VVR 11.2 atau versi yang lebih baru.

2. Setelah upgrade, restart pekerjaan dari titik simpan sebelum perubahan skema.