Sinkronisasi database penuh Real-time: Operasi dan tuning - DataWorks

Tugas sinkronisasi database penuh Real-time mencakup beberapa tahap, termasuk migrasi skema, inisialisasi penuh, dan Sinkronisasi inkremental. Karena tugas ini sering mengelola banyak tabel dalam periode panjang, operasinya kompleks. Dokumen ini menjelaskan operasi inti seperti memulai dan menghentikan tugas, mengubah konfigurasi, serta menyiapkan alert. Selain itu, dokumen ini juga memberikan rekomendasi troubleshooting dan tuning untuk membantu Anda mengelola tugas sinkronisasi secara efisien.

Prasyarat

Sebelum melakukan operasi atau troubleshooting masalah, pastikan kondisi berikut terpenuhi:

Permission requirements

Source account: Akun harus memiliki izin untuk membaca metadata, seperti database, tabel, kolom, primary key, dan indeks. Akun juga memerlukan izin untuk membaca change log sumber, seperti Binlog, WAL (Write-Ahead Logging), atau Oplog.
Target account: Akun harus memiliki izin untuk membuat tabel, mengubah struktur tabel, dan menulis data.

Network connectivity

Kelompok sumber daya harus memiliki koneksi jaringan ke sumber maupun target. Masalah jaringan dapat menyebabkan migrasi skema gagal, inisialisasi penuh macet, atau Sinkronisasi inkremental terganggu.

Source log retention

Periode retensi log yang tidak mencukupi merupakan penyebab paling umum kegagalan melanjutkan tugas dari offset aslinya setelah dihentikan.

Data source and channel compatibility

Kemampuan sinkronisasi (seperti full load, inkremental, dan DDL) bervariasi tergantung pada sumber data. Opsi yang tersedia di halaman UI merepresentasikan fitur-fitur yang didukung. Pastikan versi sumber dan target Anda didukung oleh channel tersebut.

Cakupan dan penerapan

Sebelum melakukan troubleshooting tugas sinkronisasi database penuh Real-time, tinjau jenis tugas, kemampuan channel, dan area troubleshooting utama untuk memastikan dokumen ini berlaku bagi skenario Anda.

Kriteria	Cakupan yang berlaku	Tidak berlaku / fokus utama
Jenis tugas	Real-time Change Data Capture (CDC) untuk beberapa tabel atau seluruh database.	Dokumen ini tidak berlaku untuk sinkronisasi Real-time satu tabel. Untuk troubleshooting tugas satu tabel, lihat Operasi dan Tuning untuk Sinkronisasi Real-time Satu Tabel.
Channel khas	Sumber database ke Hologres, MaxCompute, ADB (AnalyticDB), Doris, StarRocks, SelectDB, Kafka, DLF (Data Lake Formation), Lindorm, Elasticsearch, atau OSS (Object Storage Service).	Tidak berlaku untuk jenis channel lainnya.
Fokus troubleshooting	Retensi log, offset, primary key, DDL, beban sumber, performa penulisan target, partisi, commit, small file, rate limiting, dan backlog.	Selain status tugas, gunakan metrik dan log untuk troubleshooting detail halus.

Penting

Sinkronisasi database penuh Real-time bergantung pada sumber untuk terus-menerus menyediakan change log (seperti Binlog, WAL, atau Oplog). Target harus mendukung mode penulisan saat ini, semantik primary key atau unique key, serta perubahan skema yang diperlukan. Jika kondisi ini tidak terpenuhi, tugas mungkin tidak berjalan dengan benar atau menjamin konsistensi data.

Tahapan tugas

Tugas sinkronisasi database penuh Real-time biasanya mencakup tahapan berikut, masing-masing dengan fokus operasional yang berbeda.

Tahap	Deskripsi	Fokus operasional
Schema migration	Membaca informasi database, tabel, dan kolom dari sumber serta membuat atau memperbarui struktur tabel di target.	Izin metadata sumber, izin pembuatan tabel target, pemetaan tipe data, aturan pemetaan nama tabel.
Full initialization	Membaca data historis dari sumber dan menuliskannya ke target untuk mengisi ulang data yang sudah ada sebelum tugas dimulai.	Split key, konkurensi full load, jumlah koneksi sumber, kelompok sumber daya, kapasitas penulisan target, pengejaran antara data penuh dan inkremental.
Incremental synchronization	Terus-menerus mengonsumsi perubahan sumber dan menuliskannya ke target.	Lag offset, throughput baca dan tulis, failover, checkpoint, event DDL, retensi log sumber.

Penting

Tugas sinkronisasi database penuh Real-time biasanya menyelesaikan schema migration dan full initialization terlebih dahulu, lalu terus-menerus memproses incremental synchronization.

Data inkremental yang dihasilkan selama full initialization bergantung pada retensi log sumber dan kemampuan pipeline Real-time untuk mengejar ketertinggalan. Oleh karena itu, saat memulai, menghentikan, menjalankan ulang, atau menambahkan tabel ke tugas, Anda harus memantau Progress Inisialisasi Penuh dan Latensi Real-time.

Operasi

Memulai dan menghentikan tugas

Setelah memulai tugas, verifikasi bahwa tugas berjalan dengan benar dengan memeriksa hal-hal berikut secara berurutan:

Verifikasi bahwa migrasi skema telah selesai dan struktur tabel telah dibuat di target.
Amati inisialisasi penuh untuk memastikan proses membaca dan menulis data berjalan normal. Laju baca penuh dan laju tulis harus stabil, serta jumlah tabel yang selesai harus terus meningkat.
Konfirmasi bahwa Sinkronisasi inkremental berjalan normal. Latensi Real-time harus berada dalam rentang wajar, tanpa failover yang sering, dan commit checkpoint berhasil.

Sebelum menghentikan tugas, pastikan periode retensi log sumber cukup panjang untuk mencakup waktu downtime. Jika tugas dihentikan terlalu lama, log sumber seperti Binlog, WAL, atau message log mungkin dipurge, sehingga tugas tidak dapat dilanjutkan dari offset terakhir yang disimpan. Saat Anda melanjutkan tugas, tugas akan berlanjut dari offset terakhir yang disimpan. Jika offset telah kedaluwarsa, Anda harus menilai risiko mereset offset atau menginisialisasi ulang tugas. Untuk informasi lebih lanjut, lihat bagian "Tidak dapat melanjutkan tugas dari offset sebelumnya setelah dihentikan" di bagian FAQ.

Modifikasi konfigurasi

Untuk tugas sinkronisasi database penuh Real-time yang sedang berjalan, Anda mungkin perlu menambah atau menghapus tabel, menyesuaikan pemetaan tabel, atau mengubah sumber daya untuk beban kerja penuh atau inkremental. Setelah mengubah konfigurasi, kirim dan terapkan pembaruan sesuai prompt di layar.

Jenis perubahan	Risiko	Rekomendasi
Add table	Memerlukan pembacaan ulang metadata dan, tergantung pada kemampuan channel, menjalankan migrasi skema, inisialisasi penuh, serta memulai Sinkronisasi inkremental.	Konfirmasi bahwa tabel baru sesuai dengan aturan seleksi, lalu refresh pemetaan tabel. Pantau progress inisialisasi penuh, status onboarding inkremental, dan retensi log sumber untuk tabel baru.
Delete table	Menghapus tabel dari tugas yang sedang berjalan dapat memengaruhi pemetaan tabel yang ada, data target, dan dependensi downstream.	Sebelum menghapus, pastikan bisnis tidak lagi bergantung pada tabel tersebut. Dalam kasus luar biasa, buat tugas baru untuk menangani cakupan baru.
Modify mapping rules	Dapat menyebabkan konflik nama tabel target, kolom hilang, perubahan partisi, atau perubahan cara penanganan data yang sudah ada.	Sebelum mengirim, periksa nama tabel target, tipe kolom, primary key, partisi, kolom tambahan, dan data yang sudah ada di target.
Adjust resources	Sumber daya, konkurensi, dan jumlah koneksi dapat berbeda antara inisialisasi penuh dan Sinkronisasi inkremental. Penyesuaian yang tidak tepat dapat meningkatkan beban pada sumber atau target.	Sesuaikan sumber daya secara bertahap. Setelah setiap perubahan, pantau laju inisialisasi penuh, latensi Real-time, failover, checkpoint, dan pemanfaatan sumber daya.

Cara perubahan konfigurasi diterapkan:

Refresh pemetaan tabel dan penambahan tabel baru biasanya tidak memerlukan penghentian tugas.
Menyesuaikan spesifikasi sumber daya, seperti CU (Compute Unit), mungkin memerlukan restart tugas atau menunggu hingga checkpoint berikutnya untuk diterapkan. Ikuti prompt di layar.
Disarankan memodifikasi aturan pemetaan saat tugas dijeda untuk menghindari dampak pada data yang sedang diproses.
Jika perubahan konfigurasi gagal, kembalikan ke konfigurasi sebelumnya dan kirim ulang.

Konfigurasi alert

Untuk tugas sinkronisasi database penuh Real-time, disarankan mengonfigurasi alert untuk setidaknya event berikut:

Jenis alert	Kasus penggunaan	Deskripsi
Abnormal task status	Semua tugas	Memicu alert segera jika tugas gagal atau keluar secara tidak terduga.
Business latency	Semua tugas	Memicu alert saat latensi Real-time melebihi ambang batas yang dapat diterima bisnis.
Failover	Semua tugas	Failover yang sering biasanya menunjukkan masalah yang memerlukan intervensi manual.
Resource utilization	Skenario dengan kendala sumber daya	Memicu alert saat pemanfaatan CPU, memori, atau jaringan terlalu tinggi.
DDL notification	Channel yang memproses event DDL	Event DDL dapat memengaruhi skema target dan harus dipantau.
Backlog	Sumber Kafka, DataHub, atau LogHub	Pantau backlog untuk partisi, shard, atau topik menggunakan Konsol sumber atau metrik tugas.

Untuk sumber berbasis log seperti MySQL dan PostgreSQL, Anda juga perlu memantau periode retensi log seperti Binlog dan WAL untuk mencegah kegagalan pemulihan tugas akibat kedaluwarsa log.

Untuk langkah-langkah terperinci tentang mengonfigurasi aturan alert, lihat Aturan Alert Umum.

Metode troubleshooting

Kegagalan migrasi skema

Kegagalan migrasi skema sering disebabkan oleh izin, pembacaan metadata, tipe data, atau pembuatan tabel di target. Lakukan troubleshooting dengan urutan berikut:

Periksa apakah akun sumber memiliki izin untuk membaca metadata, termasuk database, tabel, kolom, primary key, dan indeks.
Verifikasi koneksi jaringan antara kelompok sumber daya tugas dengan sumber dan target.
Periksa apakah akun target memiliki izin untuk membuat tabel, mengubah tabel, dan menulis data.
Periksa apakah aturan pemetaan untuk nama tabel, database, atau skema menghasilkan nama duplikat atau tidak valid.
Periksa apakah tipe data, primary key, kolom partisi, dan kolom tambahan kompatibel dengan target.

Saat memilih tabel dengan ekspresi reguler atau secara massal, disarankan menguji dengan jumlah kecil tabel sebelum memperluas cakupan sinkronisasi.

Inisialisasi penuh lambat atau gagal

Jika inisialisasi penuh lambat atau gagal, pertama-tama tentukan apakah tugas macet selama inisialisasi sumber daya, membaca dari sumber, menulis ke target, atau menunggu mengejar perubahan inkremental. Saat troubleshooting, periksa metrik seperti laju baca penuh, laju tulis, jumlah tabel yang selesai, shard yang tersisa, jumlah koneksi sumber, dan latensi tulis target.

Gejala	Kemungkinan penyebab	Rekomendasi
Tugas inisialisasi penuh tidak dimulai dalam waktu lama.	Antrian kelompok sumber daya, kegagalan inisialisasi sumber daya, atau masalah konektivitas dengan sumber atau target.	Periksa status kelompok sumber daya dan konektivitas jaringan. Verifikasi bahwa izin akun sumber dan target benar.
Laju baca penuh rendah.	Split key tidak merata, query SQL sumber tidak menggunakan indeks, beban sumber tinggi, atau koneksi atau kuota tidak mencukupi.	Periksa split key dan indeks, lalu sesuaikan konkurensi full load secara moderat. Jika beban sumber tinggi, terapkan rate limiting atau jalankan tugas selama jam sepi.
Laju tulis penuh rendah.	Kapasitas tulis target tidak mencukupi, desain partisi buruk, atau parameter batch write tidak sesuai.	Periksa beban target, QPS tulis, latensi commit batch, dan jumlah partisi.
Pengejaran inkremental lambat setelah inisialisasi penuh selesai.	Volume besar perubahan terjadi di sumber selama inisialisasi penuh, dan pipeline Real-time perlu memproses backlog log.	Periksa apakah latensi Real-time terus menurun dan pastikan periode retensi log sumber mencukupi.

Latensi Real-time tinggi

Saat latensi Real-time meningkat, pertama-tama tentukan apakah tugas masih dalam fase pengejaran inisialisasi penuh. Kemudian, identifikasi apakah bottleneck berada di reader, pipeline pemrosesan, atau writer.

Gejala	Kemungkinan penyebab	Rekomendasi
Latensi tetap tinggi setelah inisialisasi penuh selesai.	Backlog besar perubahan inkremental terakumulasi selama inisialisasi penuh; pembacaan log sumber lambat; penulisan pengejaran ke target lambat.	Pantau laju baca inkremental, laju tulis, dan waktu retensi log sumber untuk memastikan latensi terus menurun.
Waktu tunggu reader tinggi.	Kenaikan tiba-tiba volume perubahan sumber, transaksi besar, backlog log sumber, atau ketimpangan partisi/shard.	Periksa lonjakan penulisan sumber, pertumbuhan log, dan distribusi partisi atau shard.
Waktu tunggu writer tinggi.	Performa tulis target lambat, rate limiting, koneksi tidak mencukupi, atau terlalu banyak partisi dinamis.	Periksa sumber daya target, QPS tulis, latensi commit batch, dan desain partisi.
Failover sering terjadi.	Memori tidak mencukupi, ketidakstabilan layanan eksternal, kegagalan checkpoint, atau error pemrosesan DDL.	Periksa log sebelum dan sesudah failover. Analisis memori, pemanfaatan sumber daya, dan metrik checkpoint untuk menyelesaikan masalah.
Latensi meningkat setelah event DDL.	Pemrosesan DDL yang memakan waktu atau kegagalan mengubah skema di target.	Tinjau event DDL dan izin target untuk memastikan kebijakan penanganan DDL sesuai harapan.

Jika sumber adalah Kafka, DataHub, atau LogHub, satu partisi atau shard biasanya hanya dapat dikonsumsi oleh satu proses konkuren. Jika data terkonsentrasi di beberapa partisi, meningkatkan konkurensi tugas secara keseluruhan mungkin tidak efektif.

Tabel baru tidak disinkronkan

Jika tabel baru tidak disinkronkan, periksa hal-hal berikut secara berurutan:

Apakah tabel baru sesuai dengan aturan seleksi database dan tabel saat ini?
Apakah pemetaan tabel berhasil direfresh?
Periksa apakah tabel telah dibuat atau skema telah dimigrasikan di target.
Apakah tugas mendukung penambahan tabel secara dinamis saat runtime?
Periksa detail eksekusi untuk migrasi skema, inisialisasi penuh, atau event Real-time dari tabel yang bersangkutan.

Untuk channel yang tidak mendukung penambahan tabel secara dinamis, Anda harus mengubah konfigurasi dan republish, atau membuat tugas baru untuk menangani tabel baru tersebut. Jika tabel baru memerlukan data historis, pastikan channel akan melakukan inisialisasi penuh untuk tabel tersebut. Jika fitur ini tidak didukung, gunakan pengisian ulang data atau kemampuan sinkronisasi penuh terpisah.

Rekomendasi tuning

Item tuning	Skenario	Rekomendasi
Spesifikasi sumber daya full load / Compute Unit (CU)	Inisialisasi penuh dalam antrian, kecepatan eksekusi rendah, atau pemanfaatan kelompok sumber daya tinggi.	Tingkatkan sumber daya full load secara bertahap atau jalankan tugas selama jam sepi. Pantau laju baca full load, laju tulis, dan beban sumber.
Konkurensi full load dan split key	Fase full load berjalan, tetapi kecepatan keseluruhan lambat.	Pilih split key yang terdistribusi merata dan memiliki indeks. Tingkatkan konkurensi secara moderat. Jika beban sumber tinggi, kurangi konkurensi atau terapkan rate limiting.
Koneksi sumber / Kuota	Inisialisasi penuh melaporkan error terkait koneksi, Kuota, atau rate limiting.	Kurangi konkurensi tugas dari sumber yang sama. Atau, tingkatkan jumlah koneksi dan Kuota jika kapasitas sumber memungkinkan.
Spesifikasi sumber daya inkremental / CU	Pemanfaatan CPU, memori, jaringan, atau kelompok sumber daya tinggi.	Tingkatkan sumber daya secara bertahap. Amati apakah latensi, failover, dan performa checkpoint membaik.
Konkurensi inkremental	Banyak tabel, partisi, atau shard memiliki paralelisme yang cukup.	Pertama, pastikan tidak ada hotspot satu tabel atau bottleneck satu shard. Kemudian, tingkatkan konkurensi.
Interval Checkpoint / Flush	Target melakukan commit terlalu sering, atau overhead untuk commit batch tinggi.	Tingkatkan interval sedikit demi sedikit dan amati throughput serta latensi visibilitas data. Jangan meningkatkannya terlalu banyak sekaligus.
Parameter batch write target	Waktu tunggu target tinggi.	Sesuaikan parameter batch, flush, commit, atau kolam koneksi berdasarkan batasan Produk target.
Granularitas partisi dinamis	Target memiliki terlalu banyak partisi atau tekanan flush tinggi.	Utamakan menyesuaikan granularitas partisi. Hindari menggunakan bidang dengan kardinalitas tinggi untuk partisi, seperti timestamp tingkat detik, ID pesanan, atau ID pengguna.

Catatan

Inisialisasi penuh dan Sinkronisasi inkremental memiliki tujuan tuning yang berbeda. Inisialisasi penuh berfokus pada penyelesaian penulisan data historis secara stabil. Sinkronisasi inkremental berfokus pada pengejaran latensi inkremental secara berkelanjutan. Setelah tuning, amati performa setidaknya selama satu jendela stabil. Menilai efek hanya berdasarkan throughput jangka pendek setelah restart bisa menyesatkan.

Untuk pengaturan sumber daya yang direkomendasikan, lihat CU yang Direkomendasikan untuk integrasi data. Sesuaikan pengaturan sesuai kebutuhan.

Pertanyaan yang sering diajukan

Pertanyaan berikut didasarkan pada riwayat troubleshooting tugas sinkronisasi database penuh Real-time dan dikategorikan berdasarkan fase tugas. Saat troubleshooting, pertama-tama konfirmasi fase tugas saat ini. Kemudian, verifikasi silang menggunakan event tugas, log eksekusi, metrik, retensi log sumber, dan hasil target.

Masalah dengan migrasi skema

Masalah	Area utama yang perlu diperiksa	Tindakan yang direkomendasikan
Pemetaan tabel lambat direfresh, timeout, atau tabel tidak dapat dipilih	Konektivitas kelompok sumber daya, izin metadata sumber, jumlah database dan tabel, jumlah bidang, jenis objek sumber, dan cache sumber data	Pertama, persempit cakupan database dan tabel untuk pengujian. Konfirmasi bahwa akun memiliki izin untuk membaca database, tabel, bidang, primary key, dan indeks. Jika suatu objek tidak dapat dipilih, ketersediaannya ditentukan oleh cakupan yang didukung channel saat ini.

Masalah dengan inisialisasi penuh

Masalah	Area utama yang perlu diperiksa	Tindakan yang direkomendasikan
Inisialisasi penuh macet atau gagal dimulai	Antrian kelompok sumber daya, konektivitas sumber atau target, kuota sumber data, sumber daya untuk fase inisialisasi penuh, dan hasil pembuatan tabel di target	Pertama, konfirmasi bahwa migrasi skema telah selesai. Kemudian, periksa apakah sub-tugas penuh telah dimulai. Jika kuota atau jumlah koneksi tidak mencukupi, kurangi konkurensi atau tingkatkan kuota untuk sumber atau target.

Masalah dengan Sinkronisasi inkremental

Masalah	Area utama yang perlu diperiksa	Tindakan yang direkomendasikan
Latensi Real-time tetap tinggi setelah inisialisasi penuh selesai	Data inkremental yang terakumulasi selama inisialisasi penuh, kecepatan baca log sumber, kecepatan tulis target, checkpoint, dan failover	Amati apakah latensi terus menurun. Jika tidak, periksa offset baca, waktu tunggu tulis, kegagalan checkpoint, dan rate limiting di target.
Tugas tidak dapat dilanjutkan dari offset sebelumnya setelah dihentikan	Periksa apakah periode retensi untuk Binlog, Write-Ahead Logging (WAL), log pesan, atau offset konsumsi telah kedaluwarsa. Periksa apakah instans sumber dibangun ulang atau log-nya dihapus.	Sebelum menghentikan tugas, pastikan periode retensi log mencakup downtime yang diharapkan. Jika offset tidak tersedia, Anda biasanya perlu meresetnya atau menginisialisasi ulang tugas. Nilai risiko duplikasi dan kehilangan data sebelum melanjutkan.
Tugas gagal atau latensi meningkat setelah operasi Data Definition Language (DDL)	Jenis operasi DDL yang dapat dihasilkan sumber, aksi penanganan DDL yang didukung target, serta strategi dan izin DDL tugas	Tinjau event DDL dan hasil perubahan skema di target. Jangan abaikan operasi DDL yang tidak didukung. Pertama, konfirmasi dampaknya terhadap skema target dan konsistensi data.
Data target salah setelah operasi DELETE atau UPDATE	Apakah target memiliki primary key atau unique key untuk menemukan catatan. Apakah pemetaan primary key konsisten. Apakah mode tulis mendukung update dan delete.	Periksa primary key sumber, primary key target, pemetaan tabel, dan log data kotor. Jika target tidak memiliki primary key yang valid atau pemetaannya tidak konsisten, operasi UPDATE dan DELETE mungkin tidak diterapkan pada catatan target yang benar.

Masalah dengan sumber pesan

Masalah	Area utama yang perlu diperiksa	Tindakan yang direkomendasikan
Latensi tinggi dari sumber pesan seperti Kafka, DataHub, dan LogHub	Periksa hotspot di partisi, shard, atau topik. Periksa apakah konkurensi konsumsi melebihi jumlah partisi yang dapat dikonsumsi secara paralel. Periksa apakah offset konsumsi tertinggal signifikan.	Pertama, periksa bottleneck di satu partisi atau shard. Jika hotspot terkonsentrasi, meningkatkan konkurensi total mungkin tidak efektif. Sesuaikan partisi sumber atau kemampuan tulis target sebagai gantinya.

Masalah dengan penulisan ke target

Masalah	Area utama yang perlu diperiksa	Tindakan yang direkomendasikan
Penulisan lambat ke target seperti MaxCompute karena jumlah partisi berlebihan	Granularitas bidang partisi dinamis, jumlah partisi dalam satu checkpoint, waktu Tunnel atau commit, dan rate limiting target	Kurangi granularitas partisi atau hindari menggunakan bidang dengan kardinalitas tinggi untuk partisi. Kemudian, sesuaikan commit batch, cache partisi, dan spesifikasi sumber daya berdasarkan kemampuan target.

Masalah dengan konsistensi data

Masalah	Area utama yang perlu diperiksa	Tindakan yang direkomendasikan
Data historis tidak disinkronkan setelah tabel baru ditambahkan	Periksa apakah tabel baru sesuai dengan aturan seleksi. Periksa apakah pemetaan tabel berhasil direfresh. Periksa apakah channel mendukung inisialisasi penuh untuk tabel baru. Periksa apakah tabel baru dikonfigurasi hanya untuk Sinkronisasi inkremental.	Jika Anda memerlukan data historis, pastikan inisialisasi penuh diaktifkan atau telah dipicu untuk tabel baru. Jika tidak didukung, gunakan proses pengisian ulang data atau tugas sinkronisasi penuh terpisah untuk mengisi data historis.
Data menjadi tidak konsisten setelah tabel dihapus selama runtime atau di sumber	Periksa apakah tabel yang dihapus masih sesuai dengan aturan tugas. Periksa bagaimana strategi DDL menangani DROP TABLE. Periksa dependensi downstream pada tabel target.	Sebelum menghapus tabel selama runtime, pastikan tidak ada proses bisnis yang bergantung padanya. Menghapus tabel di sumber tidak secara otomatis membersihkannya di target. Jika diperlukan, kelola tabel target secara terpisah sesuai kebijakan tata kelola data Anda.
Jumlah data kotor yang tidak normal dihasilkan	Periksa apakah tugas dikonfigurasi untuk mentoleransi data kotor. Periksa perubahan tipe bidang, panjang, primary key, batasan non-null, atau batas tulis target.	Jangan hanya meningkatkan ambang batas data kotor agar tugas dapat berlanjut. Pertama, tentukan apakah data kotor akan menyebabkan data hilang atau anomali bidang di target. Kemudian, putuskan apakah akan memperbaiki data, menyesuaikan pemetaan, atau sementara mentoleransi error tersebut.

Masalah khusus PostgreSQL

Masalah	Area utama yang perlu diperiksa	Tindakan yang direkomendasikan
File WAL terakumulasi di sumber PostgreSQL	Lag slot replikasi, offset konsumsi, checkpoint, dan apakah tugas melakukan commit offset dengan benar	Jika tugas mengonsumsi data secara normal tetapi ukuran WAL tidak berkurang, periksa lag slot replikasi dan status commit offset. Hal ini membantu mencegah disk sumber penuh oleh file WAL.

Daftar periksa operasi berisiko tinggi

Sebelum menghapus tabel, menambahkan banyak tabel, me-restart tugas, menjalankan ulang inisialisasi penuh, atau melakukan penyesuaian parameter besar, konfirmasi setiap item dalam daftar periksa ini. Jika suatu pemeriksaan gagal, lakukan tindakan yang direkomendasikan sebelum melanjutkan.

Apakah periode retensi log sumber cukup panjang untuk inisialisasi penuh dan pengejaran inkremental?
Jika target memiliki data yang sudah ada atau dependensi downstream, apakah strategi overwrite, append, atau cleanup yang jelas telah disiapkan sebelum menjalankan ulang inisialisasi penuh?
Apakah tabel baru memerlukan data historis, dan apakah channel saat ini mendukung inisialisasi penuh untuk tabel tersebut?
Apakah ada pernyataan Data Definition Language (DDL) yang belum diproses atau failover yang sering?
Apakah alert mencakup status tugas, exception inisialisasi penuh, latensi bisnis, failover, dan DDL?