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

Sinkronisasi database penuh Real-time mencakup migrasi skema, inisialisasi penuh, dan sinkronisasi inkremental pada banyak tabel selama periode yang panjang. Pelajari cara memulai dan menghentikan tugas, mengubah konfigurasi, menyiapkan notifikasi, serta menerapkan praktik terbaik untuk troubleshooting dan tuning.

Prasyarat

Sebelum melakukan operasi atau troubleshooting, pastikan kondisi berikut terpenuhi:

Persyaratan izin

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

Konektivitas jaringan

Kelompok sumber daya harus dapat mengakses baik sumber maupun target. Masalah jaringan dapat menyebabkan kegagalan migrasi skema, inisialisasi penuh yang mandek, atau sinkronisasi inkremental yang terputus.

Periode retensi log sumber

Retensi log yang tidak mencukupi adalah alasan paling umum mengapa tugas gagal melanjutkan dari offset aslinya setelah dihentikan.

Kompatibilitas sumber data dan channel

Kemampuan sinkronisasi (seperti full load, inkremental, dan DDL) bervariasi tergantung pada sumber data. Opsi yang dapat dikonfigurasi pada UI merepresentasikan fitur-fitur yang didukung. Pastikan versi sumber dan target Anda kompatibel dengan channel tersebut.

Cakupan dan penerapan

Sebelum melakukan troubleshooting pada tugas sinkronisasi database penuh Real-time, tinjau jenis tugas, kemampuan channel, dan area troubleshooting utama untuk memastikan topik ini relevan dengan skenario Anda.

Kriteria	Cakupan yang berlaku	Tidak berlaku / fokus utama
Jenis tugas	Real-time Change Data Capture (CDC) untuk beberapa tabel atau seluruh database.	Tidak berlaku untuk sinkronisasi Real-time satu tabel. Untuk 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 files, 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 log perubahan (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 melewati tahapan berikut, masing-masing dengan fokus operasional yang berbeda.

Tahap	Deskripsi	Fokus operasional
Migrasi skema	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.
Inisialisasi penuh	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.
Sinkronisasi inkremental	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 migrasi skema dan inisialisasi penuh terlebih dahulu, lalu terus-menerus memproses sinkronisasi inkremental.

Data inkremental yang dihasilkan selama inisialisasi penuh 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 baik Kemajuan Inisialisasi Penuh maupun 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 log pesan mungkin telah dipurge, sehingga mencegah tugas dilanjutkan dari offset terakhir yang disimpan. Saat Anda melanjutkan tugas, tugas akan berlanjut dari offset terakhir yang disimpan. Jika offset tersebut 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" dalam bagian FAQ.

Memodifikasi konfigurasi

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

Jenis perubahan	Risiko	Rekomendasi
Tambah tabel	Memerlukan pembacaan ulang metadata dan, tergantung pada kemampuan channel, dapat memicu migrasi skema, inisialisasi penuh, dan sinkronisasi inkremental.	Konfirmasi bahwa tabel baru sesuai dengan aturan seleksi, lalu refresh pemetaan tabel. Pantau kemajuan inisialisasi penuh, status onboarding inkremental, dan retensi log sumber untuk tabel-tabel baru.
Hapus tabel	Menghapus tabel dari tugas yang sedang berjalan dapat memengaruhi pemetaan tabel yang ada, data target, dan dependensi downstream.	Sebelum menghapus tabel, pastikan tidak ada proses bisnis yang bergantung padanya. Jika diperlukan, buat tugas baru untuk menangani cakupan yang diperbarui.
Ubah aturan pemetaan	Dapat menyebabkan konflik nama tabel target, kolom yang hilang, perubahan partisi, atau perubahan cara penanganan data yang sudah ada.	Sebelum mengirimkan, verifikasi nama tabel target, tipe kolom, primary key, partisi, kolom tambahan, dan data yang sudah ada di target.
Atur ulang sumber daya	Alokasi sumber daya, konkurensi, dan jumlah koneksi berbeda antara inisialisasi penuh dan sinkronisasi inkremental. Penyesuaian yang tidak tepat dapat meningkatkan beban pada sumber atau target.	Atur ulang 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 agar efektif. Ikuti petunjuk di layar.
Ubah 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 notifikasi

Untuk tugas sinkronisasi database penuh Real-time, konfigurasikan notifikasi untuk setidaknya event-event berikut:

Jenis notifikasi	Kasus penggunaan	Deskripsi
Status tugas abnormal	Semua tugas	Memicu notifikasi segera jika tugas gagal atau keluar secara tak terduga.
Latensi bisnis	Semua tugas	Memicu notifikasi ketika latensi Real-time melebihi ambang batas yang dapat diterima oleh bisnis.
Failover	Semua tugas	Failover yang sering biasanya menandakan adanya masalah yang memerlukan intervensi manual.
Pemanfaatan sumber daya	Skenario dengan keterbatasan sumber daya	Memicu notifikasi ketika pemanfaatan CPU, memori, atau jaringan terlalu tinggi.
Notifikasi DDL	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, pantau juga periode retensi log seperti Binlog dan WAL untuk mencegah kegagalan pemulihan tugas akibat kedaluwarsa log.

Untuk langkah-langkah terperinci tentang mengonfigurasi aturan notifikasi, lihat Aturan Notifikasi Umum.

Metode troubleshooting

Kegagalan migrasi skema

Kegagalan migrasi skema biasanya disebabkan oleh masalah izin, kesalahan pembacaan metadata, ketidakcocokan tipe data, atau masalah pembuatan tabel di target. Lakukan troubleshooting dalam urutan berikut:

Periksa apakah akun sumber memiliki izin untuk membaca metadata, termasuk database, tabel, kolom, primary key, dan indeks.
Verifikasi konektivitas 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 yang duplikat atau tidak valid.
Periksa apakah tipe data, primary key, kolom partisi, dan kolom tambahan kompatibel dengan target.

Saat memilih tabel menggunakan ekspresi reguler atau secara massal, uji terlebih dahulu dengan jumlah tabel yang kecil sebelum memperluas cakupan sinkronisasi.

Inisialisasi penuh lambat atau gagal

Jika inisialisasi penuh lambat atau gagal, tentukan apakah tugas macet selama inisialisasi sumber daya, membaca dari sumber, menulis ke target, atau menunggu untuk mengejar perubahan inkremental. 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 yang tidak merata, query SQL sumber tidak menggunakan indeks, beban sumber tinggi, atau koneksi atau kuota yang tidak mencukupi.	Periksa split key dan indeks, lalu sesuaikan konkurensi full load secara moderat. Jika beban sumber tinggi, terapkan rate limiting atau jalankan tugas pada jam sepi.
Laju tulis penuh rendah.	Kapasitas tulis target tidak mencukupi, desain partisi buruk, atau parameter batch write yang tidak sesuai.	Periksa beban target, QPS tulis, latensi commit batch, dan jumlah partisi.
Pengejaran inkremental lambat setelah inisialisasi penuh selesai.	Volume perubahan besar 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 perubahan inkremental besar 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 volume perubahan sumber yang tiba-tiba, 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 kesalahan 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 sumbernya 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 membantu.

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, ubah konfigurasi dan publikasikan ulang, atau buat tugas baru untuk menangani tabel-tabel baru tersebut. Jika tabel baru memerlukan data historis, konfirmasi apakah channel tersebut melakukan inisialisasi penuh untuk tabel tersebut. Jika tidak, gunakan proses 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 pada 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 pengurangan latensi secara berkelanjutan. Setelah tuning, amati performa setidaknya selama satu periode stabil. Menilai efektivitas 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 diambil dari riwayat troubleshooting tugas sinkronisasi database penuh Real-time dan diorganisasikan berdasarkan fase tugas. Saat melakukan troubleshooting, pertama-tama konfirmasi fase tugas Anda 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 oleh 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 telah dibangun ulang atau lognya telah dihapus.	Sebelum menghentikan tugas, pastikan periode retensi log mencakup waktu downtime yang diharapkan. Jika offset tidak tersedia, Anda biasanya perlu meresetnya atau menginisialisasi ulang tugas. Nilai risiko duplikasi dan kehilangan data sebelum melanjutkan. Jika target adalah MaxCompute Delta Table, tabel tersebut menghapus duplikat data berdasarkan primary key, sehingga data dalam rentang yang sudah disinkronkan tidak ditulis ulang setelah Anda mereset offset. Delta Table dibuat dengan deklarasi PRIMARY KEY dan properti `transactional=true`. Untuk memeriksa apakah suatu tabel adalah Delta Table, jalankan `SHOW CREATE TABLE table_name` dan pastikan keduanya muncul dalam output.
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 jauh.	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 yang 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.
Timeout checkpoint atau error kehabisan memori (OOM) akibat jumlah partisi dinamis yang berlebihan	Jumlah partisi dinamis yang dikomit dalam satu checkpoint, misalnya apakah mencapai ratusan, waktu interaksi metadata partisi, penggunaan memori tugas dan Pengumpulan sampah, serta durasi dan catatan kegagalan checkpoint	Saat tugas melibatkan banyak partisi dinamis, meng-commit terlalu banyak partisi sekaligus menyebabkan overhead interaksi metadata dan penggunaan memori tinggi, yang dapat menyebabkan timeout checkpoint atau error kehabisan memori (OOM). Sesuaikan konfigurasi sinkronisasi sehingga semua data historis penuh ditulis ke satu partisi statis yang ditentukan, seperti partisi hari sebelumnya, dan hanya data yang dihasilkan setelah tugas dimulai yang ditulis ke partisi dinamis baru. Ini mencegah satu checkpoint meng-commit terlalu banyak partisi. Untuk informasi lebih lanjut, lihat "Granularitas partisi dinamis" dalam bagian Rekomendasi tuning.

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 tersebut. 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 dengan kebijakan Tata kelola data Anda.
Jumlah data kotor yang abnormal dihasilkan	Periksa apakah tugas dikonfigurasi untuk mentoleransi data kotor. Periksa perubahan pada 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 tersebut akan menyebabkan kehilangan data 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 menumpuk 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 membuat perubahan parameter besar, verifikasi 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 pembersihan yang jelas telah disiapkan sebelum Anda 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 terjadi?
Apakah notifikasi mencakup status tugas, exception inisialisasi penuh, latensi bisnis, failover, dan DDL?