Sinkronisasi offline untuk seluruh database mencakup beberapa tahap, seperti migrasi skema, sinkronisasi penuh, dan sinkronisasi inkremental offline. Jumlah tabel yang besar serta kepadatan tinggi instans terjadwal menyulitkan pemeliharaan & operasional (O&M). Topik ini menjelaskan operasi O&M inti, seperti memulai dan menghentikan tugas, memodifikasi konfigurasi, serta menjalankan ulang tugas untuk mengisi kembali data. Topik ini juga menyediakan metode troubleshooting dan rekomendasi penyetelan untuk membantu Anda mengelola tugas tersebut secara efisien. Untuk informasi tentang cara mengonfigurasi tugas ini, lihat Konfigurasikan tugas untuk sinkronisasi offline seluruh database.
Kesesuaian
Sebelum melakukan troubleshooting masalah sinkronisasi offline untuk seluruh database, evaluasi jenis tugas, kemampuan channel, dan fokus troubleshooting untuk memastikan topik ini berlaku dalam skenario Anda.
Kriteria | Skenario yang berlaku | Skenario yang tidak berlaku/Fokus utama |
Jenis tugas | Sinkronisasi batch offline untuk seluruh database atau beberapa tabel: sinkronisasi penuh satu kali, sinkronisasi penuh periodik, atau sinkronisasi inkremental periodik yang menggunakan nilai bidang untuk menentukan kondisi inkremental. | Tugas CDC Real-time atau konsumsi message. Metode troubleshooting offline tidak berlaku. |
Channel umum | Sumber: Baca offline dari database, gudang data, atau file. Tujuan: MaxCompute, Hologres, Hive, DLF, Elasticsearch, StarRocks, dan lainnya. | Jangan anggap suatu tugas sebagai tugas sinkronisasi inkremental offline jika tidak tersedia bidang inkremental yang stabil. |
Fokus troubleshooting | Instans terjadwal, tanggal bisnis, kondisi WHERE, | Tidak melibatkan offset log waktu nyata atau failover. |
Sinkronisasi offline untuk seluruh database bergantung pada kemampuan baca dan tulis offline. Tugas ini tidak bergantung pada Binlog, WAL, atau Oplog, dan tidak menyediakan semantik pemulihan offset log waktu nyata.
Tahapan tugas
Sinkronisasi offline untuk seluruh database biasanya mencakup tahapan berikut. Setiap tahap memiliki prioritas O&M yang berbeda.
Tahap | Deskripsi | Fokus O&M |
Migrasi skema | Membaca skema tabel dari sumber dan membuat atau memperbarui tabel di tujuan. | Izin metadata, izin pembuatan tabel tujuan, pemetaan tipe bidang, dan pemetaan nama tabel. |
Sinkronisasi penuh satu kali | Menulis data historis dari sumber ke tujuan secara batch. | Kunci split, konkurensi offline, koneksi sumber, kapasitas tulis tujuan, dan spesifikasi resource. |
Sinkronisasi inkremental offline periodik | Menyinkronkan data baru atau yang berubah berdasarkan siklus penjadwalan. | Waktu penjadwalan, dependensi hulu, parameter tanggal bisnis, partisi tujuan, dan nama output. |
Sinkronisasi inkremental offline bergantung pada bidang yang mengidentifikasi data inkremental, seperti timestamp pembaruan atau bidang auto-increment. Jika tabel sumber tidak memiliki bidang inkremental yang stabil, Anda biasanya harus melakukan sinkronisasi penuh periodik atau memodifikasi tabel sumber sebelum mengonfigurasi sinkronisasi inkremental offline.
Tugas sinkronisasi offline untuk seluruh database biasanya menghasilkan beberapa subtugas offline. Seiring bertambahnya jumlah tabel, tekanan pada instans terjadwal, konsumsi resource, dan penulisan ke tujuan meningkat secara signifikan.
Operasi O&M
Memulai dan menghentikan tugas
Setelah mengirim tugas sinkronisasi penuh satu kali, pantau subtugas sinkronisasi penuh untuk memastikan berjalan dengan baik. Untuk tugas offline periodik, Anda juga harus memeriksa apakah instans terjadwal dihasilkan sesuai harapan, dependensi hulu terpenuhi, dan tanggal bisnis benar.
Sebelum menghentikan tugas, pastikan apakah data dari beberapa tabel atau partisi telah ditulis ke tujuan. Jika tugas yang menulis ke tujuan menggunakan strategi overwrite atau pembersihan partisi, perhatikan isu idempotensi dan overwrite konkuren saat menjalankan ulang tugas.
Untuk operasi penjadwalan dan manajemen tugas umum seperti menjeda, melanjutkan, dan mengisi kembali data, lihat O&M tugas sinkronisasi offline.
Memodifikasi konfigurasi
Modifikasi umum untuk tugas sinkronisasi offline seluruh database mencakup menambah atau menghapus tabel, serta menyesuaikan pemetaan tabel, aturan partisi, konfigurasi penjadwalan, konkurensi, dan resource.
Jenis perubahan | Risiko potensial | Rekomendasi |
Tambah tabel | Menambah tabel memerlukan migrasi skema dan pembuatan instans terjadwal. | Setelah mengirim perubahan, periksa apakah tugas atau instans offline yang sesuai dihasilkan untuk tabel baru. |
Hapus tabel | Dapat memengaruhi node penjadwalan yang ada dan dependensi hilir. | Sebelum menghapus, pastikan konsumen hilir tidak lagi bergantung pada output yang sesuai. |
Ubah aturan partisi | Dapat menyebabkan data ditulis ke partisi baru atau menimpa partisi yang salah. | Sebelum pengiriman, pastikan parameter tanggal bisnis dan ekspresi partisi tujuan. |
Ubah penjadwalan | Dapat memengaruhi dependensi hulu dan waktu output hilir. | Setelah modifikasi, periksa apakah instans periodik dihasilkan pada waktu baru. |
Sesuaikan konkurensi dan resource | Dapat meningkatkan tekanan pada koneksi sumber, penulisan tujuan, dan kelompok sumber daya. | Lakukan penyesuaian secara bertahap dan pantau beban pada sumber, tujuan, dan kelompok sumber daya. |
Jalankan ulang tugas dan isi kembali data
Menjalankan ulang tugas atau mengisi kembali data dapat memperbaiki partisi tujuan yang hilang. Sebelum melakukan operasi ini, pastikan hal-hal berikut:
Tabel dan rentang tanggal bisnis mana yang perlu diperbaiki.
Mode tulis tujuan (append, overwrite, atau truncate and write).
Apakah instans lain sedang menulis ke tabel atau partisi tujuan yang sama.
Apakah tugas hilir telah mengonsumsi data yang salah.
Apakah perlu menjalankan ulang tugas hilir setelah tugas saat ini dijalankan ulang.
Jika mode tulis tujuan membersihkan partisi, jangan jalankan beberapa tugas yang menulis ke partisi yang sama secara bersamaan. Jika perlu, jeda instans yang bentrok terlebih dahulu atau atur waktu eksekusinya agar tidak tumpang tindih.
Untuk informasi lebih lanjut tentang cara menggunakan fitur isi kembali data, lihat O&M instans isi kembali.
Troubleshooting
Kegagalan refresh pemetaan tabel atau tabel tidak dapat dipilih
Penyebab umum meliputi izin sumber yang tidak mencukupi, masalah jaringan untuk kelompok sumber daya, jumlah metadata sumber yang berlebihan, cakupan filter tabel yang terlalu luas, terlalu banyak tabel yang dipilih, atau izin tujuan yang tidak mencukupi. Lakukan troubleshooting dalam urutan berikut:
Uji ulang konektivitas sumber dan tujuan menggunakan kelompok sumber daya dari konfigurasi tugas.
Pastikan akun sumber memiliki izin untuk membaca metadata database, tabel, dan bidang.
Jika cakupan filter tabel luas atau banyak tabel dipilih, persempit cakupan terlebih dahulu untuk memverifikasi konektivitas.
Periksa apakah akun tujuan memiliki izin pembuatan tabel atau tulis.
Periksa timeout antarmuka metadata jika jumlah tabel sumber sangat besar.
Kegagalan migrasi skema
Jika migrasi skema gagal, pertama-tama periksa izin pembuatan tabel tujuan, apakah database atau skema tujuan ada, apakah tipe bidang kompatibel, dan apakah pemetaan nama tabel bentrok. Untuk tabel partisi, pastikan juga bahwa bidang partisi, hierarki partisi, dan ekspresi partisi memenuhi batasan tujuan.
Tugas sinkronisasi penuh berjalan lambat
Item yang diperiksa | Cara mengidentifikasi | Tindakan yang direkomendasikan |
Kueri sumber lambat | CPU tinggi, I/O tinggi, kueri SQL lambat, atau lock waits pada database sumber. | Optimalkan kueri sumber, hindari jam sibuk bisnis, dan kurangi konkurensi jika perlu. |
Split tidak merata | Beberapa subtugas membutuhkan waktu jauh lebih lama untuk diselesaikan. | Pilih kunci split yang lebih sesuai, atau proses tabel besar secara terpisah. |
Konkurensi rendah | Throughput rendah meskipun beban pada sumber dan tujuan rendah. | Tingkatkan konkurensi offline dan spesifikasi resource secara bertahap. |
Koneksi tidak mencukupi | Log menunjukkan koneksi atau kuota tidak mencukupi. | Tingkatkan jumlah maksimum koneksi sumber atau kuota sumber data, dan pantau stabilitas database sumber. |
Penulisan tujuan lambat | Throttling, terlalu banyak partisi, atau commit batch lambat pada tujuan. | Atasi terlebih dahulu isu resource tujuan, throttling, dan desain partisi. |
Resource tidak mencukupi | Penggunaan CPU, memori, atau jaringan mendekati batas. | Tingkatkan spesifikasi resource atau CUs, dan pantau garbage collection (GC) serta tingkat kegagalan. |
Saat menyetel sinkronisasi offline untuk seluruh database, jangan langsung meningkatkan konkurensi secara signifikan. Peningkatan konkurensi juga meningkatkan jumlah koneksi sumber, tekanan tulis pada tujuan, dan konsumsi kelompok sumber daya. Jika bottleneck berada di sumber atau tujuan, peningkatan konkurensi biasanya memperparah masalah.
Untuk solusi skenario umum sinkronisasi data lambat, lihat Mempercepat atau membatasi kecepatan sinkronisasi offline.
Instans periodik tidak menghasilkan output
Jika instans offline periodik tidak menghasilkan output atau menghasilkan output yang salah, periksa item berikut secara berurutan:
Apakah penjadwalan periodik diaktifkan dan waktu penjadwalan benar.
Apakah dependensi hulu telah selesai.
Apakah parameter tanggal bisnis benar.
Apakah nama output dan ekspresi partisi tujuan benar.
Apakah terjadi kegagalan tulis atau masalah izin di tujuan.
Apakah tugas hilir bergantung pada output atau partisi yang salah.
Rentang data untuk instans inkremental offline ditentukan oleh kondisi inkremental dan parameter penjadwalan. Saat melakukan troubleshooting instans periodik, periksa apakah Bidang Kondisi Inkremental ada, apakah Tipe Bidang dapat dibandingkan, dan apakah Parameter Penjadwalan diteruskan dengan benar ke partisi tujuan atau kondisi filter WHERE.
Rekomendasi penyetelan
Item penyetelan | Rekomendasi |
Total CUs | Tingkatkan total resource untuk jumlah tabel yang besar atau subtugas paralel. Jika sumber atau tujuan mengalami throttling, peningkatan CUs saja memiliki efek terbatas. |
CUs per Tugas | Tingkatkan resource per tugas untuk tabel lebar, kolom besar, atau volume data besar dalam satu tabel. |
Konkurensi Offline | Tingkatkan secara bertahap berdasarkan kapasitas koneksi sumber dan kapasitas tulis tujuan. |
Koneksi Sumber Maksimum | Sesuaikan bersamaan dengan konkurensi offline. Mengatur nilai ini terlalu tinggi dapat memengaruhi stabilitas database sumber. |
Konfigurasi Pembatasan Laju | Jika pembatasan laju diaktifkan, throughput secara aktif dikurangi. Sebelum menyetel, pastikan apakah Anda perlu menonaktifkan atau meningkatkan batas laju. |
Desain partisi | Hindari partisi yang terlalu detail halus, karena dapat menyebabkan file kecil, terlalu banyak partisi, atau overhead tulis berlebihan. |
Untuk tugas sinkronisasi offline seluruh database yang melibatkan banyak tabel, kelompokkan pengamatan Anda berdasarkan tabel besar, tabel lebar, dan tabel kecil. Beberapa tabel besar dapat menentukan waktu penyelesaian keseluruhan, dan throughput rata-rata tidak mencerminkan bottleneck sebenarnya.
Untuk informasi lebih lanjut tentang hubungan antara konkurensi dan pembatasan laju, lihat Hubungan antara konkurensi dan pembatasan laju dalam sinkronisasi offline.
Alert dan pemantauan
Untuk tugas sinkronisasi offline seluruh database, fokuslah pada alert untuk penjadwalan dan instans offline. Alert biasanya perlu dikonfigurasi pada subtugas periodik atau instans offline yang dihasilkan di O&M Center. Anda tidak boleh hanya mengandalkan status tugas solusi utama.
Konfigurasikan aturan alert berikut:
Instans Gagal: Memberi alert segera ketika eksekusi tugas gagal.
Instans Melebihi Waktu: Memberi alert ketika tugas berjalan lebih lama dari yang diharapkan.
Dependensi Hulu Belum Selesai: Memberi alert ketika tugas hulu yang menjadi dependensi tidak selesai tepat waktu.
Instans Periodik Tidak Dihasilkan: Memberi alert ketika instans tidak dihasilkan setelah siklus penjadwalan dimulai.
Partisi Target Tidak Dihasilkan: Memberi alert ketika partisi tujuan yang diharapkan tidak dihasilkan tepat waktu.
Koneksi Sumber/Tujuan Gagal: Memberi alert untuk pengecualian koneksi sumber data.
Jika ketepatan waktu data untuk tugas hilir sangat penting, Anda harus mengonfigurasi alert untuk timeout instans dan validasi output. Mengonfigurasi hanya alert kegagalan tidak dapat mendeteksi kasus di mana tugas berjalan lama tanpa menghasilkan output tepat waktu.
Untuk petunjuk spesifik tentang cara mengonfigurasi aturan alert, lihat Konfigurasikan tugas untuk sinkronisasi offline seluruh database > Langkah 6: Konfigurasikan Aturan Alert.
Daftar periksa untuk operasi berisiko tinggi
Sebelum melakukan operasi skala besar seperti menjalankan ulang tugas, mengisi kembali data, menghapus tabel, memodifikasi aturan partisi, atau meningkatkan konkurensi secara signifikan, pastikan hal-hal berikut: tabel dan tanggal bisnis yang terdampak; mode tulis tujuan dan potensinya untuk menimpa atau menghapus data; adanya penulisan konkuren ke tujuan yang sama; apakah tugas hilir telah mengonsumsi data tersebut; kapasitas sumber dan tujuan untuk menangani konkurensi lebih tinggi; dan apakah tugas hilir juga perlu dijalankan ulang.
FAQ
Pertanyaan berikut berasal dari kasus troubleshooting terakumulasi untuk tugas periodik yang menyinkronkan seluruh database. Saat melakukan troubleshooting, pertama-tama pastikan jenis tugas, sumber, dan tujuan, lalu cross-check konfigurasi halaman, instans terjadwal, log eksekusi, dan hasil tujuan.
Menghentikan instans lama setelah menambahkan kembali tabel
Troubleshooting: Setelah menghapus tabel dan menerapkan pembaruan, node penjadwalan periodik berikutnya dinonaktifkan. Anda tidak boleh mengasumsikan bahwa instans yang sudah dihasilkan atau sedang berjalan akan berhenti secara otomatis.
Mitigasi: Jika Anda perlu menghentikan penulisan segera, periksa status instans periodik yang sesuai di O&M Center. Jika perlu, hentikan atau jeda instans yang relevan secara manual sebelum menambahkan, menjalankan ulang, atau mengisi kembali data untuk tabel tersebut.
Tujuan salah untuk tabel baru
Troubleshooting: Periksa apakah aturan pemetaan skema, nama database, atau nama tabel telah berubah. Pastikan apakah tabel baru menggunakan pemetaan default.
Mitigasi: Periksa dan konfigurasikan aturan pemetaan skema, nama database, atau nama tabel untuk mencegah tabel baru ditulis ke lokasi tujuan yang berbeda.
Kegagalan refresh pemetaan tabel atau tabel tidak dapat dipilih
Troubleshooting: Periksa konektivitas kelompok sumber daya, latensi kueri metadata sumber, jumlah tabel yang dipilih, dan izin akun sumber.
Mitigasi: Pertama, persempit cakupan database dan tabel untuk verifikasi. Periksa parameter koneksi sumber data dan kinerja kueri metadata sumber. Jika suatu objek tidak dapat dipilih, cakupan yang didukung yang ditampilkan di halaman berlaku.
Hasil kondisi inkremental tidak konsisten
Troubleshooting: Pastikan apakah kondisi inkremental telah dimodifikasi, apakah Parameter Penjadwalan dihitung berdasarkan tanggal bisnis atau waktu eksekusi, dan apakah partisi tujuan dan kondisi filter menggunakan parameter yang sama.
Mitigasi: Periksa kondisi inkremental, Parameter Penjadwalan, dan ekspresi partisi tujuan secara bersamaan. Saat mengisi kembali data, pastikan rentang tanggal bisnis.
Instans periodik menunggu dependensi hulu
Pemecahan Masalah: Periksa apakah Upstream Node ID atau aturan nama node hulu tambahan telah dikonfigurasi di Advanced Parameters.
Mitigasi: Hapus konfigurasi dependensi hulu yang tidak perlu, publikasikan ulang tugas, lalu amati dependensi instans.
Output partisi tujuan hilang atau tidak normal
Troubleshooting: Pastikan apakah kolom partisi benar-benar ada, ekspresi partisi benar, dan hierarki partisi, kapitalisasi, serta spasi memenuhi persyaratan tujuan.
Mitigasi: Periksa metadata tabel tujuan dan parameter periodik. Jika perlu, gunakan satu tabel atau jumlah kecil tabel untuk memverifikasi penulisan partisi terlebih dahulu.
Konflik nama output atau karakter khusus
Troubleshooting: Periksa apakah aturan nama output untuk node penjadwalan menghasilkan output duplikat atau berisi karakter khusus yang tidak didukung oleh scheduler tujuan.
Mitigasi: Sesuaikan aturan nama output untuk menghindari penggunaan karakter khusus seperti $. Setelah menyimpan dan mempublikasikan, periksa dependensi hilir.
View atau objek khusus tidak dapat dipilih
Troubleshooting: Pastikan apakah tipe objek sumber didukung oleh channel saat ini untuk sinkronisasi offline seluruh database.
Mitigasi: Hanya objek yang dapat dipilih di halaman yang didukung. Jika tidak didukung, gunakan tugas sinkronisasi offline satu tabel, atau materialisasikan hasil view ke tabel fisik sebelum sinkronisasi.
splitPk tidak efektif atau menyebabkan distribusi data tidak merata
Troubleshooting: Pastikan apakah tipe bidang kunci split didukung oleh sumber data dan channel, apakah distribusi data merata, dan apakah terdapat banyak nilai null.
Mitigasi: Gunakan bidang kunci split yang didukung dengan distribusi lebih merata. Anda dapat memproses tabel besar secara terpisah untuk penyetelan individual.
Untuk informasi lebih lanjut tentang batasan kunci split, lihat Konfigurasikan tugas untuk sinkronisasi offline seluruh database > Kuota dan batasan.
Pelajari lebih lanjut
Konfigurasikan tugas untuk sinkronisasi offline seluruh database — Proses lengkap untuk mengonfigurasi tugas sinkronisasi offline seluruh database
Mempercepat atau membatasi kecepatan sinkronisasi offline — Solusi untuk skenario umum sinkronisasi data lambat
Hubungan antara konkurensi dan pembatasan laju dalam sinkronisasi offline — Deskripsi cara mengonfigurasi konkurensi dan pembatasan laju dalam kontrol channel