Tugas sinkronisasi penuh dan inkremental untuk database lengkap menyinkronkan skema database dan tabel, data historis, serta perubahan berkelanjutan dari database sumber ke tujuan seperti MaxCompute. Topik ini menjelaskan operasi O&M umum, metode troubleshooting, rekomendasi tuning, dan konfigurasi peringatan untuk tugas-tugas tersebut.
Cakupan dan batasan
Sebelum menerapkan topik ini, evaluasi bentuk tugas dan jalur data Anda.
| Item pemeriksaan | Cakupan yang berlaku | Kapan tidak berlaku |
| Bentuk tugas | Data penuh historis + inkremental Real-time + output terjadwal atau merge | Untuk sumber pesan yang hanya menulis data secara Real-time, lihat Sinkronisasi database penuh Real-time: Operasi dan tuning. |
| Jalur data | Sumber database → MaxCompute, data lake, atau tujuan yang menghasilkan snapshot atau partisi | Metode dalam topik ini tidak berlaku jika tujuan tidak mendukung output terjadwal atau merge. |
Metode dalam topik ini bergantung pada kemampuan tugas berikut: inisialisasi data penuh untuk tabel yang baru ditambahkan, pergantian antara tahap penuh dan Real-time, perlindungan checkpoint saat tabel ditambahkan, serta node output terjadwal atau merge. Jika tugas tidak mendukung salah satu kemampuan ini, hasil downstream mungkin tidak lengkap.
Topik ini hanya berlaku untuk tugas sinkronisasi penuh dan inkremental untuk database lengkap. Untuk tugas inkremental Real-time, lihat Sinkronisasi Database Penuh Real-time: Operasi dan Tuning. Untuk tugas yang hanya menyinkronkan data dalam batch terjadwal, lihat O&M dan Tuning untuk Sinkronisasi Database Offline.
Tahapan tugas
Tugas sinkronisasi penuh dan inkremental berjalan melalui tahapan berikut:
| Tahap | Deskripsi | Fokus O&M |
| Migrasi Skema | Memigrasikan skema database dan tabel sumber ke tujuan | Izin metadata sumber, izin pembuatan tabel tujuan, pemetaan tipe field, dan aturan pemetaan tabel |
| Inisialisasi Data Penuh | Menulis data historis dari sumber ke tujuan dalam satu kali proses | Kunci pemisahan (split key), konkurensi penuh, koneksi sumber, performa kueri sumber, dan kapabilitas penulisan tujuan |
| Inkremental Real-time | Secara berkelanjutan mengonsumsi perubahan sumber yang terjadi setelah tahap penuh dimulai | Delay checkpoint, failover, checkpoint, DDL, dan retensi log sumber |
| Merge Inkremental | Secara berkala menggabungkan data perubahan inkremental ke tabel snapshot tujuan atau partisi tujuan. Hanya beberapa solusi yang mencakup tahap ini. | Penjadwalan Merge Inkremental, apakah data inkremental upstream telah tersusul, waktu data, partisi tujuan, dan durasi eksekusi SQL |
Sumber mungkin terus menulis data selama inisialisasi data penuh. Setelah tahap penuh selesai, tugas memutar ulang data inkremental hingga tersusul dengan sumber. Penyelesaian tahap penuh tidak berarti seluruh tugas telah selesai. Anda juga harus memverifikasi bahwa inkremental Real-time telah tersusul.
Prasyarat
Sebelum mengoperasikan atau melakukan troubleshooting tugas sinkronisasi penuh dan inkremental, konfirmasi hal-hal berikut:
Ruang kerja DataWorks dan kelompok sumber daya untuk integrasi data.
Koneksi sumber data dan tujuan telah dikonfigurasi, dengan konektivitas jaringan antara kelompok sumber daya dan kedua titik akhir.
Akun sumber memiliki izin untuk membaca metadata database dan tabel serta log biner atau WAL.
Akun tujuan memiliki izin untuk membuat tabel, memodifikasi tabel, dan menulis data.
(Jika tugas mencakup Merge Inkremental) Tujuan yang mendukung node output terjadwal atau merge. Untuk MaxCompute, skema tabel tujuan harus mendukung eksekusi SQL merge.
(Jika Anda berencana menjalankan ulang tugas) Tujuan Hologres atau MaxCompute.
Temukan tugas Anda dan lihat detail eksekusi
Pilih Data Integration > Synchronization Task untuk membuka daftar tugas sinkronisasi. Daftar tugas menampilkan informasi dasar dan status berjalan saat ini dari setiap tugas. Anda dapat memfilter tugas berdasarkan nama tugas, status tugas, waktu pembuatan, jenis sumber data, dan jenis tujuan.
Klik nama tugas untuk membuka halaman detail eksekusi tugas. Gunakan halaman ini sebagai antarmuka pemantauan utama selama operasi rutin dan investigasi masalah. Halaman ini menampilkan informasi berikut:
Bilah progres tugas yang menunjukkan tahap saat ini: migrasi skema, inisialisasi data penuh, inkremental Real-time, atau Merge Inkremental. Gunakan untuk mengidentifikasi tahap mana yang sedang dijalani tugas.
Daftar subtugas setiap tahap. Gunakan untuk memeriksa subtugas individual dan mengidentifikasi subtugas mana yang gagal atau berjalan lambat.
Status sinkronisasi Real-time, termasuk delay checkpoint dan throughput. Gunakan metrik ini untuk menilai apakah inkremental Real-time mengimbangi perubahan sumber.
Tautan ke log tugas dan metrik pemantauan untuk investigasi lebih lanjut.
Operasi O&M umum
Lakukan operasi berikut dari kolom Operations pada daftar tugas.
Jalankan dan hentikan tugas
Untuk menjalankan tugas, klik Submit and Run. Setelah tugas dimulai, pertama-tama periksa apakah migrasi skema dan inisialisasi data penuh berjalan normal, lalu periksa apakah inkremental Real-time telah tersusul.
Untuk menghentikan tugas, klik Stop di kolom Operations. Sebelum menghentikan tugas, konfirmasi tahap saat ini:
Jika Anda menghentikan tugas selama inisialisasi data penuh, beberapa subtugas penuh mungkin perlu dijalankan ulang setelah pemulihan.
Jika Anda menghentikan tugas selama inkremental Real-time, pemulihan bergantung pada periode retensi log sumber.
Jika Anda menghentikan tugas yang mencakup Merge Inkremental, konfirmasi apakah partisi tujuan sudah berisi output sebagian.
Ubah konfigurasi dan terapkan pembaruan
Perubahan umum pada tugas sinkronisasi penuh dan inkremental untuk database lengkap mencakup penambahan tabel, penghapusan tabel, penyesuaian pemetaan tabel, penyesuaian sumber daya, dan modifikasi parameter advanced. Untuk mengubah tugas, pilih More > Modify Configuration di kolom Operations. Setelah melakukan perubahan, kirimkan tugas dan terapkan pembaruan. Perubahan hanya berlaku setelah Anda mengirimkannya.
Tabel berikut mencantumkan titik risiko dan rekomendasi untuk jenis perubahan paling umum. Untuk panduan tuning sumber daya dan parameter, lihat Rekomendasi Tuning.
| Jenis Perubahan | Titik Risiko | Rekomendasi |
| Tambah tabel | Tabel baru memerlukan migrasi skema dan inisialisasi data penuh, lalu bergabung ke inkremental Real-time setelah inisialisasi selesai | Hindari jam sibuk bisnis. Konfirmasi bahwa periode retensi log sumber cukup panjang. Periksa apakah tahap penuh dan tahap inkremental untuk tabel baru telah selesai. |
| Hapus tabel | Dapat memengaruhi pemetaan tabel yang ada, file sumber daya, dan data tujuan | Konfirmasi bahwa sistem downstream tidak lagi bergantung pada tabel sebelum penghapusan. Jika tugas yang ada tidak dapat dikirimkan berhasil, buat tugas baru untuk mengambil alih. |
| Ubah pemetaan tabel | Dapat memengaruhi penulisan penuh, penulisan Real-time, dan hasil Merge Inkremental | Periksa pemetaan tabel penuh, tabel inkremental, dan tabel tujuan akhir secara bersamaan. |
| Sesuaikan sumber daya | Mempengaruhi kueri sumber, penulisan tujuan, dan konsumsi kelompok sumber daya | Lakukan tuning berdasarkan tahap. Jangan terapkan kriteria yang sama untuk tahap penuh dan tahap Real-time. |
Daftar periksa operasi berisiko tinggi
Sebelum menjalankan ulang, pengisian ulang data, penambahan tabel batch besar, penghapusan tabel, atau perubahan parameter besar, konfirmasi hal-hal berikut:
Tahap mana masalah saat ini terjadi.
Cakupan operasi: seluruh database, tabel tertentu, waktu data tertentu, atau partisi tujuan tertentu.
Apakah periode retensi log sumber cukup panjang.
Apakah data tujuan yang ada dapat ditimpa atau ditulis ulang.
Apakah instance Merge Inkremental sedang berjalan atau akan segera berjalan, termasuk instance untuk waktu data atau partisi tujuan yang sama.
Apakah sistem downstream sedang membaca atau bergantung pada tabel tujuan, partisi, atau waktu data yang terpengaruh, dan apakah node downstream harus dijalankan ulang setelah operasi selesai.
Apakah sumber dan tujuan dapat menangani beban baca/tulis tambahan atau konkurensi yang lebih tinggi.
Jalankan ulang tugas
Pertimbangkan menjalankan ulang ketika data tujuan rusak, tugas Real-time gagal dalam periode panjang, log sumber tidak dapat diputar ulang, atau tugas harus diinisialisasi ulang. Di kolom Operations, pilih More > Rerun untuk memaksa re-inisialisasi penuh dan inkremental semua tabel sumber.
Batasan berikut berlaku untuk forced rerun:
Hanya tujuan Hologres dan MaxCompute yang mendukung forced rerun. Tugas sinkronisasi penuh dan inkremental yang di-shard tidak mendukung forced rerun.
Forced rerun menyinkronkan kolom dari tabel sumber ke tabel tujuan. Jika tabel tujuan kehilangan kolom yang ada di tabel sumber, kolom yang hilang akan ditambahkan.
Sebelum menjalankan ulang, selesaikan pemeriksaan di Daftar Periksa Operasi Berisiko Tinggi.
Pada tugas yang mencakup Merge Inkremental, rerun dan merge tidak boleh memproses waktu data atau partisi tujuan yang sama secara bersamaan. Eksekusi konkuren pada waktu data yang sama dapat menimpa data partisi atau tabel.
Jika konflik mungkin terjadi, gunakan salah satu metode berikut:
Jeda rerun, tunggu hingga instance Merge Inkremental yang bertabrakan selesai, lalu lakukan rerun.
Membekukan instance Merge Inkremental yang akan datang, tunggu hingga rerun selesai, lalu unfreeze instance tersebut.
Setelah rerun selesai, verifikasi bahwa instance Merge Inkremental melanjutkan eksekusi otomatis. Jika data tidak dihasilkan keesokan harinya atau instance Merge Inkremental tidak dilanjutkan, verifikasi dan lanjutkan instance secara manual.
Pengisian ulang data penuh
Ketika beberapa tabel, beberapa partisi, atau beberapa waktu data tidak memiliki data di tujuan, gunakan pengisian ulang data penuh untuk memperbaiki data. Hanya tugas sinkronisasi penuh dan inkremental database penuh yang mendukung pengisian ulang data penuh. Klik Backfill All Data di kolom Operations dan konfigurasikan parameter.
Sebelum menjalankan pengisian ulang data, selesaikan pemeriksaan di Daftar Periksa Operasi Berisiko Tinggi, dan konfirmasi item spesifik operasi berikut:
Apakah inkremental Real-time telah tersusul.
Saat mengisi ulang beberapa waktu data, jalankan pengisian ulang secara batch dan verifikasi setiap batch sebelum melanjutkan ke batch berikutnya. Ini mencegah gangguan antara pengisian ulang dan inkremental Real-time, Merge Inkremental, serta penjadwalan downstream.
Metode troubleshooting
Selain status tugas, gabungkan metrik dan log untuk troubleshooting detail halus. Objek troubleshooting khas meliputi migrasi skema, inisialisasi data penuh, inkremental Real-time, checkpoint, instance terjadwal, waktu data, partisi tujuan, dan SQL merge. Anda dapat melihat progres tugas, status subtugas, delay checkpoint, throughput, log, dan metrik pemantauan di halaman detail eksekusi tugas. Untuk informasi lebih lanjut, lihat Temukan Tugas Anda dan Lihat Detail Eksekusi.
Identifikasi tahap tempat masalah terjadi, lalu buka bagian yang sesuai:
| Gejala | Tahap | Bagian |
| Migrasi skema gagal karena izin, pembacaan metadata, pembuatan tabel tujuan, tipe field, atau pemetaan tabel | Migrasi Skema | Kegagalan migrasi skema |
| Inisialisasi data penuh macet, tidak dimulai, atau berjalan lambat | Inisialisasi Data Penuh | Inisialisasi data penuh lambat atau macet |
| Latensi inkremental Real-time meningkat, atau inkremental Real-time tidak dapat tersusul setelah tahap penuh selesai | Inkremental Real-time | Latensi inkremental Real-time |
| Output terjadwal atau Merge Inkremental tidak dihasilkan, atau data tidak lengkap | Merge Inkremental | Merge tidak menghasilkan atau data tidak lengkap |
| Gejala lain, seperti hasil tak terduga setelah menambah/menghapus tabel, error DDL, data kotor, atau konflik setelah rerun atau pengisian ulang | Beberapa tahap | FAQ |
Kegagalan migrasi skema
Kegagalan migrasi skema biasanya melibatkan izin, pembacaan metadata, pembuatan tabel tujuan, tipe field, dan pemetaan tabel. Periksa hal-hal berikut secara berurutan:
Periksa apakah akun sumber memiliki izin untuk membaca metadata database dan tabel.
Periksa apakah kelompok sumber daya tugas dapat terhubung ke sumber dan tujuan.
Periksa apakah akun tujuan memiliki izin untuk membuat tabel, memodifikasi tabel, dan menulis data.
Periksa apakah database, skema, atau namespace tujuan ada.
Periksa apakah pemetaan nama tabel bertabrakan, serta apakah tipe field dan field partisi kompatibel.
Inisialisasi data penuh lambat atau macet
Perlakukan inisialisasi data penuh yang lambat atau macet sebagai masalah subtugas batch. Jangan lakukan troubleshooting dengan metode latensi Real-time. Pertama-tama konfirmasi tahap mana yang macet, lalu periksa apakah subtugas penuh telah dimulai.
| Item Pemeriksaan | Metode Penilaian | Rekomendasi |
| Performa kueri sumber | Database sumber memiliki penggunaan CPU tinggi, I/O tinggi, kueri SQL lambat, antrian lock, atau banyak koneksi | Optimalkan kueri sumber, hindari jam sibuk bisnis, dan kurangi konkurensi jika perlu. |
| Kunci pemisahan | Beberapa slice membutuhkan waktu jauh lebih lama daripada yang lain | Pilih kunci pemisahan yang lebih merata. Jangan tingkatkan konkurensi jika tidak ada kunci pemisahan yang sesuai. |
| Koneksi atau kuota sumber | Log menunjukkan kuota tidak mencukupi atau koneksi terlalu sedikit | Tingkatkan koneksi sumber atau kuota sumber data sesuai kebutuhan, dan pantau beban database sumber. |
| Konkurensi penuh | Baik sumber maupun tujuan memiliki kapasitas cadangan, tetapi throughput rendah | Tingkatkan konkurensi secara bertahap. Jangan langsung menaikkannya ke nilai tinggi sekaligus. |
| Penulisan tujuan | Tujuan dibatasi laju (rate-limited), menulis lambat, atau memiliki terlalu banyak partisi | Atasi sumber daya tujuan, pembatasan laju, dan desain partisi terlebih dahulu. |
| Spesifikasi sumber daya | CPU, memori, atau jaringan menjadi bottleneck | Tingkatkan spesifikasi sumber daya atau unit komputasi, dan pantau pengumpulan sampah serta tingkat kegagalan. |
Latensi inkremental Real-time
Saat melakukan troubleshooting tahap inkremental Real-time, periksa delay checkpoint, throughput baca/tulis, dan waktu tunggu jendela terlebih dahulu. Lalu tinjau log, event failover, checkpoint, metrik JVM, pengumpulan sampah, tekanan balik (backpressure), dan event DDL.
Penyebab umum meliputi:
Transaksi sumber besar, atau pertumbuhan cepat log biner atau WAL.
Kemiringan partisi atau shard di sumber.
Pembatasan laju penulisan tujuan, koneksi tidak mencukupi, atau commit batch lambat.
Checkpoint yang memakan waktu terlalu lama atau sering gagal.
Kegagalan penanganan event DDL.
Error kehabisan memori (out-of-memory) tugas atau failover yang sering.
Jika inkremental Real-time tidak dapat tersusul dalam waktu lama setelah inisialisasi data penuh selesai, biasanya berarti terlalu banyak data inkremental terakumulasi selama tahap penuh, atau kapabilitas penulisan tujuan tidak mencukupi. Periksa laju pembuatan data inkremental oleh sumber dan throughput penulisan tujuan.
Periksa apakah delay terus berkurang. Jika tidak, periksa checkpoint ujung baca, waktu tunggu ujung tulis, dan pembatasan laju tujuan secara terpisah.
Merge tidak menghasilkan atau data tidak lengkap
Untuk tugas yang mencakup node Merge Inkremental, jangan hanya memeriksa apakah tugas Real-time berjalan. Tugas Real-time yang berjalan normal tidak menjamin tabel snapshot tujuan atau partisi tujuan dihasilkan. Periksa hal-hal berikut secara berurutan:
Periksa apakah instance terjadwal Merge Inkremental dihasilkan, apakah berjalan, dan apakah berhasil.
Periksa apakah dependensi upstream instance Merge Inkremental telah lengkap.
Pastikan inkremental real-time telah mencakup rentang waktu yang diperlukan oleh Instans Incremental Merge.
Periksa waktu data, partisi tujuan, dan durasi eksekusi SQL.
Jika rerun atau pengisian ulang data baru saja dijalankan, konfirmasi apakah memproses partisi yang sama.
Periksa instance terjadwal, output partisi tujuan, dan konsumsi downstream secara bersamaan.
Jika waktu event sumber atau log biner tidak berurutan, instance Merge Inkremental yang dipicu oleh waktu terjadwal mungkin berjalan sebelum beberapa event inkremental yang tertunda tiba. Sisakan buffer keamanan untuk penjadwalan Merge Inkremental, misalnya penundaan 30 menit, untuk mencakup jendela maksimum ketidakteraturan atau keterlambatan dari sumber.
Rekomendasi tuning
Tahap penuh dan tahap Real-time memiliki tujuan tuning yang berbeda. Tahap penuh bertujuan untuk inisialisasi efisien data historis. Tahap Real-time bertujuan untuk stabilitas berkelanjutan dan latensi rendah. Tahap Merge Inkremental berfokus pada ketepatan waktu output partisi dan integritas data.
| Item penyetelan | Tahap yang berlaku | Rekomendasi |
| Konkurensi penuh | Inisialisasi Data Penuh | Tingkatkan konkurensi secara bertahap berdasarkan kapasitas koneksi sumber dan kapabilitas penulisan tujuan. |
| Jumlah maksimum koneksi sumber | Inisialisasi Data Penuh | Terlalu sedikit koneksi membatasi kecepatan baca, dan terlalu banyak koneksi dapat memengaruhi stabilitas database sumber. Tingkatkan koneksi secara bertahap dan pantau utilisasi kolam koneksi database sumber. |
| Spesifikasi sumber daya batch atau unit komputasi | Inisialisasi Data Penuh | Tingkatkan spesifikasi sumber daya atau unit komputasi saat CPU, memori, atau jaringan menjadi bottleneck. Efeknya terbatas jika sumber atau tujuan dibatasi laju. |
| Spesifikasi sumber daya Real-time atau unit komputasi | Inkremental Real-time | Jika delay checkpoint melebihi 5 menit, pertimbangkan untuk menambah unit komputasi sebanyak 1 atau 2. Pantau frekuensi failover, status checkpoint, dan pengumpulan sampah sebelum melakukan penyesuaian lebih lanjut. |
| Interval checkpoint atau flush | Inkremental Real-time | Interval yang sedikit lebih panjang mengurangi commit yang sering tetapi meningkatkan delay sebelum data baru terlihat di tujuan. Jika delay checkpoint tinggi, verifikasi bahwa interval checkpoint tidak diatur terlalu rendah. |
| Waktu penjadwalan Incremental Merge | Merge Inkremental | Sisakan buffer untuk keterlambatan inkremental sumber dan event tidak berurutan untuk menghindari merge terlalu dini. Buffer 30 menit mencakup sebagian besar skenario keterlambatan umum. |
Peringatan dan metrik
Pantau minimal status tugas, delay bisnis, dan failover. Berdasarkan kemampuan channel dan konfigurasi tugas, tambahkan juga peringatan untuk utilisasi sumber daya, exception penulisan, notifikasi DDL, backlog pesan, dan data kotor. Untuk tugas yang dikonfigurasi dengan node output terjadwal atau merge, pantau juga kegagalan instance terjadwal dan output partisi tujuan.
Metrik peringatan berikut tersedia:
| Metrik | ID Metrik | Deskripsi |
| Delay Bisnis | DELAY | Selisih waktu antara perubahan data sumber dan penyelesaian penulisan tujuan |
| Data Kotor | DIRTY_RECORD_COUNT | Jumlah catatan yang gagal validasi atau penulisan karena masalah kualitas data |
| Failover | FAILOVER_COUNT | Jumlah event failover yang dipicu oleh error tugas atau kegagalan sumber daya |
| Backlog Pesan | OFFSET_DELAY | Volume pesan atau entri log yang belum diproses dan menunggu untuk dikonsumsi |
| Status Tugas | STATUS | Status berjalan saat ini dari tugas sinkronisasi |
| DDL Tidak Didukung | UNSUPPORTED_DDL | Operasi DDL yang tidak dapat ditangani tugas secara otomatis |
| Notifikasi DDL | DDL_REPORT | Notifikasi tentang event DDL yang diproses atau dilewati tugas |
| Utilisasi Sumber Daya Tugas | RESOURCE_UTILIZATION | Utilisasi CPU, memori, dan jaringan dari sumber daya tugas |
Metrik yang direkomendasikan berdasarkan tahap
Fokus pada metrik berikut untuk setiap tahap:
| Tahap | Metrik fokus |
| Inisialisasi Data Penuh | Tabel tersisa, tabel diproses, split tersisa, split diproses, dan jumlah penulisan penuh |
| Inkremental Real-time | Delay checkpoint, throughput baca/tulis, jumlah DML dan DDL, durasi checkpoint, dan jumlah failover |
| Merge Inkremental | Status instance Merge Inkremental, waktu penyelesaian upstream, waktu data, partisi tujuan, dan durasi eksekusi SQL |
| Sumber Daya | CPU, memori, pengumpulan sampah, jaringan, dan utilisasi kelompok sumber daya |
Respons terhadap peringatan
Saat peringatan dipicu, respons sebagai berikut:
| Kondisi peringatan | Respons yang direkomendasikan |
| Delay Bisnis melebihi 5 menit | Periksa status checkpoint dan verifikasi bahwa jendela retensi log sumber belum terlampaui. Tinjau throughput inkremental Real-time dan kapasitas penulisan tujuan. |
| Jumlah failover meningkat | Periksa log tugas untuk menemukan akar penyebab setiap failover. Penyebab umum meliputi kehilangan konektivitas sumber, error penulisan tujuan, dan kondisi kehabisan memori. |
| Jumlah Data Kotor meningkat | Tinjau log data kotor untuk mengidentifikasi field atau constraint yang gagal. Jangan tingkatkan ambang batas peringatan sebelum menentukan apakah data kotor menyebabkan data hilang, anomali field, atau update/delete gagal. |
| Peringatan DDL Tidak Didukung | Tinjau tipe event DDL dan kebijakan DDL tugas. Jangan abaikan operasi DDL yang tidak didukung. Verifikasi dampaknya terhadap integritas data dan terapkan perubahan skema manual jika perlu. |
| Status Tugas berubah menjadi Failed | Periksa tahap kegagalan di halaman detail eksekusi tugas, lalu ikuti panduan spesifik tahap di Metode troubleshooting. |
FAQ
Tabel berikut mencantumkan jawaban cepat untuk masalah umum. Untuk metode troubleshooting berbasis tahap, lihat Metode Troubleshooting.
| Masalah | Fokus Troubleshooting | Rekomendasi |
| Setelah tabel ditambahkan, hanya data inkremental berikutnya yang ada dan tidak ada data historis | Apakah tabel baru sesuai aturan seleksi; apakah inisialisasi data penuh diaktifkan atau dipicu; apakah retensi log sumber mencakup perubahan selama tahap penuh | Saat data historis diperlukan, konfirmasi bahwa tabel baru telah menyelesaikan inisialisasi data penuh. Jika inisialisasi tidak didukung atau tidak dipicu, lengkapi data melalui pengisian ulang data atau pipeline sinkronisasi penuh terpisah. |
| Setelah tabel ditambahkan, tugas meminta konfirmasi atau tidak dapat dilanjutkan | Apakah tugas telah menjalankan tahap penuh sebelumnya; apakah tabel baru ada; apakah checkpoint dihasilkan; apakah tugas berjalan dalam mode di mana tahap penuh dan Real-time tidak dipisahkan | Tunggu hingga tugas berjalan stabil dan menghasilkan checkpoint, lalu kirimkan tabel baru. Jangan memperluas cakupan sinkronisasi saat perlindungan checkpoint tidak tersedia. |
| Inisialisasi data penuh macet atau tidak dimulai | Apakah migrasi skema telah selesai | Lihat Inisialisasi Data Penuh Lambat atau Macet. |
| Inisialisasi data penuh lambat | — | Lihat Inisialisasi Data Penuh Lambat atau Macet. |
| Tahap penuh selesai, tetapi inkremental Real-time tidak dapat tersusul | — | Lihat Latensi Inkremental Real-time. |
| Ketidakkonsistenan data setelah tabel dihapus atau tabel sumber di-drop | Apakah aturan tugas masih sesuai tabel yang dihapus; bagaimana kebijakan DDL menangani DROP TABLE; apakah tujuan dan sistem downstream masih bergantung pada tabel | Konfirmasi bahwa bisnis tidak lagi bergantung pada tabel sebelum menghapusnya. Meng-drop tabel sumber tidak secara otomatis membersihkan tujuan. Tangani data tujuan yang ada secara terpisah berdasarkan kebutuhan bisnis. |
| Refresh batch pemetaan tabel timeout | Jumlah tabel, jumlah field, cakupan pencocokan ekspresi reguler, dan durasi pembacaan metadata tujuan | Persempit cakupan refresh dan proses pemetaan tabel secara batch. Setelah refresh batch besar, sampling hasil untuk mengonfirmasi tabel yang ditambahkan, dihapus, dan pemetaan field. |
| Output terjadwal atau Merge Inkremental tidak dihasilkan, atau data tidak lengkap | — | Lihat Merge Tidak Menghasilkan atau Data Tidak Lengkap. |
| Data duplikat, penimpaan, atau konflik partisi setelah pengisian ulang data atau rerun | Mode penulisan, data tujuan yang ada, dan apakah instance output terjadwal atau Merge Inkremental berjalan untuk partisi yang sama | Jeda atau atur jadwal instance yang bertabrakan sebelum rerun atau pengisian ulang data. Definisikan strategi overwrite, append, dan cleanup, lalu lakukan pemulihan. |
| Kegagalan tugas atau latensi lebih tinggi setelah operasi DDL | Tipe DDL saat ini, dukungan tujuan, kebijakan DDL tugas, dan izin serta pemetaan field tujuan | Periksa event DDL dan hasil perubahan skema tujuan. Jangan abaikan operasi DDL yang tidak didukung. Pertama-tama tentukan dampaknya terhadap integritas data. |
| Hasil UPDATE atau DELETE tidak sesuai harapan | Primary key sumber, primary key atau unique key tujuan, pemetaan primary key, mode penulisan, dan log data kotor | Bandingkan catatan sampel, event sumber, pemetaan tugas, dan hasil tujuan terlebih dahulu. Saat primary key tidak dapat menemukan baris, update dan delete mungkin tidak diterapkan pada baris tujuan yang benar. |
| Penulisan lambat ke MaxCompute atau tujuan lain | Granularitas field partisi, jumlah partisi yang terlibat dalam satu checkpoint, durasi Tunnel atau commit, dan pembatasan laju tujuan | Kurangi dispersi penulisan yang disebabkan oleh partisi pada field dengan kardinalitas tinggi terlebih dahulu, lalu sesuaikan sumber daya, commit batch, dan kuota tujuan. |
| Peningkatan peringatan data kotor | Tipe field, panjang, encoding, primary key, constraint non-null, dan batas penulisan tujuan | Jangan hanya menaikkan ambang batas. Pertama-tama tentukan apakah data kotor menyebabkan data hilang, anomali field, atau update/delete gagal. |
| Retensi log sumber tidak mencukupi | Durasi penghentian tugas, kebijakan retensi log biner atau WAL sumber, dan waktu pergantian antara tahap penuh dan inkremental | Saat data inkremental tidak dapat diputar ulang, inisialisasi ulang tugas atau isi ulang data berdasarkan cakupan bisnis. Konfirmasi jendela cakupan log sumber sebelum pemulihan. |