DataWorks:FAQ sinkronisasi Real-time

Sumber data apa saja yang didukung oleh sinkronisasi real-time?

Untuk daftar sumber data yang didukung oleh sinkronisasi real-time, lihat Sumber data yang didukung.

Mengapa latensi tugas sinkronisasi real-time saya tinggi?

Jika Anda mengkueri data pada tabel hasil sinkronisasi real-time dan menemukan bahwa data belum tersinkronisasi, kemungkinan penyebabnya adalah latensi tinggi pada tugas tersebut. Buka halaman Tugas sinkronisasi real-time di Operation Center untuk memeriksa apakah nilai Business Latency terlalu besar. Untuk informasi lebih lanjut, lihat Solusi untuk latensi tinggi pada tugas sinkronisasi real-time.

Jika business latency tinggi, kemungkinan penyebabnya sebagai berikut:

Mengapa penggunaan internet publik tidak direkomendasikan untuk tugas sinkronisasi real-time?

Menggunakan internet publik untuk tugas sinkronisasi real-time memiliki risiko berikut:

• Jaringan mungkin tidak stabil, dan kehilangan paket mungkin sering terjadi, yang memengaruhi kinerja sinkronisasi.

• Keamanan rendah.

Format kolom dalam sinkronisasi real-time

Ketika Data Integration menyinkronkan data dari MySQL, Oracle, Loghub, atau PolarDB ke DataHub atau Kafka secara real-time, lima kolom tambahan ditambahkan ke tujuan untuk manajemen metadata, pengurutan, deduplikasi, dan operasi lainnya. Untuk informasi lebih lanjut, lihat Kolom tambahan dalam sinkronisasi real-time.

Bagaimana sinkronisasi real-time menangani operasi TRUNCATE?

Sinkronisasi real-time mendukung operasi TRUNCATE, yang berlaku selama inkremental dan full merge. Jika Anda memilih untuk mengabaikan TRUNCATE, data tambahan mungkin muncul selama sinkronisasi data real-time.

Bagaimana cara meningkatkan kecepatan dan kinerja sinkronisasi real-time?

Jika kecepatan tulis lambat, Anda dapat meningkatkan konkurensi tulis dan menyesuaikan parameter JVM. Parameter JVM tidak terkait dengan jumlah database yang disinkronisasi, melainkan dengan frekuensi perubahan. Jika mesin kelompok sumber daya saat ini memungkinkan, semakin banyak memori yang dialokasikan, semakin rendah frekuensi Full GC, dan semakin tinggi kinerja sinkronisasi real-time. Atur Concurrency ke 3. Di panel Basic Configuration tugas, atur JVM Parameters ke -Xms8192m -Xmx8192m.

Apakah saya dapat menjalankan tugas sinkronisasi real-time di Konsol?

Tugas sinkronisasi real-time tidak dapat dijalankan langsung di Konsol DataWorks. Setelah Anda mengonfigurasi tugas sinkronisasi real-time, Anda harus commit dan deploy node sinkronisasi real-time, lalu menjalankan node tersebut di lingkungan produksi. Untuk informasi lebih lanjut, lihat Deploy node sinkronisasi real-time.

Mengapa sinkronisasi real-time melambat saat menggunakan sumber data MySQL?

Salah satu alasannya adalah peningkatan volume binlog yang harus diproses. Karena binlog dihasilkan di tingkat instans, bahkan jika tugas sinkronisasi dikonfigurasi hanya untuk menyinkronkan tabel A, perubahan pada tabel lain seperti tabel B atau C juga menghasilkan binlog. Binlog tambahan ini memperlambat kecepatan pemrosesan sinkronisasi.

Mengapa penggunaan memori berbeda antara memilih satu database dan beberapa database dalam sinkronisasi real-time?

Ketika Anda memilih dua atau lebih database, tugas memasuki mode sinkronisasi real-time "full-instance", yang mengonsumsi lebih banyak sumber daya dibandingkan dua tugas terpisah yang masing-masing menyinkronkan satu database.

Kebijakan DDL apa saja yang didukung oleh sinkronisasi real-time?

Metode pemrosesan sebagai berikut:

Kategori jenis DDL:

Pertimbangan untuk operasi DDL dan DML sumber saat menulis ke sumber data tujuan

• Setelah kolom ditambahkan di sumber dan DDL berhasil dieksekusi di tujuan, batasan berikut berlaku:

  • Setelah kolom dengan DEFAULT VALUE ditambahkan, kolom baru di tabel tujuan tidak memiliki nilai dan tetap NULL. Ketika data baru kemudian dimasukkan ke kolom yang ditambahkan di sumber, tugas sinkronisasi real-time menyinkronkan data baru tersebut ke kolom tersebut.

  • Setelah kolom VIRTUAL ditambahkan, kolom baru di tabel tujuan tidak memiliki nilai dan tetap NULL. Ketika data baru kemudian dimasukkan ke kolom yang ditambahkan di sumber, tugas sinkronisasi real-time menyinkronkan data baru tersebut ke kolom tersebut.

• Untuk sinkronisasi real-time dari sumber MySQL atau PolarDB MySQL, kami merekomendasikan agar Anda menambahkan kolom di akhir saat menambahkan kolom di sumber. Jangan menambahkan kolom di tengah kolom yang sudah ada. Jika menambahkan kolom di tengah tidak dapat dihindari di sumber, perhatikan batasan berikut:

  • Dalam solusi full-plus-incremental, jangan menambahkan kolom di tengah selama fase sinkronisasi penuh. Jika tidak, exception data akan terjadi selama fase sinkronisasi inkremental.

  • Selama fase sinkronisasi inkremental, waktu reset checkpoint sinkronisasi harus diatur ke titik setelah event DDL yang menambahkan kolom di tengah. Jika tidak, data sinkronisasi inkremental berikutnya mungkin abnormal.

• Jika terjadi exception data, Anda dapat menjalankan ulang inisialisasi data penuh (Anda hanya perlu menghapus tabel yang memiliki kolom ditambahkan di tengah dan menginisialisasi ulang tabel tersebut, bukan menginisialisasi ulang semua tabel dalam tugas) untuk memulihkan data yang benar.

Mengapa latensi tinggi setelah tugas sinkronisasi real-time yang membaca dari PostgreSQL mengalami failover?

Ini adalah karakteristik dari database PostgreSQL itu sendiri. Jika latensi tidak dapat diterima, Anda dapat menghentikan tugas dan me-restart-nya untuk melakukan sinkronisasi data full-plus-incremental.

Bagaimana cara melakukan sinkronisasi penuh untuk tugas sinkronisasi yang sudah ada?

Di Data Integration, temukan tugas sinkronisasi target di daftar tugas, lalu klik More > Rerun di kolom Actions.

Apakah tugas sinkronisasi real-time DataWorks mendukung konfigurasi ambang batas data kotor (errorLimit) atau mengabaikan data kotor?

Tugas sinkronisasi real-time tidak mendukung konfigurasi ambang batas data kotor (errorLimit) atau mengabaikan data kotor. Jika data kotor ditemui selama sinkronisasi, tugas akan diblokir.

Solusi alternatif:

• Ganti tugas sinkronisasi real-time dengan tugas sinkronisasi batch terjadwal per jam atau per menit. Sinkronisasi batch mendukung konfigurasi ambang batas data kotor dan mengabaikan data kotor.

• Tambahkan node pemrosesan data di pipeline sinkronisasi real-time untuk membersihkan dan memfilter data, mencegah data kotor mencapai tujuan.

• Lokalisasi dan perbaiki data sumber berdasarkan pesan error tugas untuk menghilangkan data kotor di sumber.

Saat menyinkronkan data dari sumber data MySQL secara real-time, data awalnya dibaca tetapi berhenti setelah beberapa saat. Bagaimana cara menyelesaikannya?

1. Jalankan perintah berikut di database untuk memeriksa file binlog yang sedang ditulis oleh instans database saat ini.

   show master status 

2. Bandingkan file binlog yang dibaca di log. Cari di log journalName=MySQL-bin.000001,position=50 untuk memverifikasi apakah data sedang ditulis ke database.

3. Jika data sedang ditulis tetapi binlog tidak maju, hubungi DBA Anda untuk bantuan.

Tugas sinkronisasi real-time untuk Oracle, PolarDB, dan MySQL berulang kali melaporkan error

• Symptom: Tugas sinkronisasi real-time berulang kali melaporkan error.

  Ketika sumber tugas sinkronisasi real-time adalah sumber data Oracle, PolarDB, atau MySQL, pesan DDL dari sumber tidak diproses secara default. Ketika perubahan DDL selain pembuatan tabel dilakukan, tugas real-time melaporkan error dan keluar. Dalam skenario pemulihan berbasis checkpoint, tugas sinkronisasi mungkin masih melaporkan error meskipun tidak ada pesan DDL yang dihasilkan dari sumber.

  Catatan

  Untuk menghindari kehilangan data atau ketidakteraturan selama periode tertentu, jangan gunakan perintah Rename untuk menukar nama dua kolom. Misalnya, menukar nama kolom A dan kolom B tidak diizinkan.

• Cause: Sinkronisasi real-time mendukung pemulihan berbasis checkpoint. Untuk mencegah kehilangan data, ketika sinkronisasi di-restart, offset mungkin digulir balik untuk memutar ulang beberapa data. Proses ini dapat menyebabkan pesan DDL yang sebelumnya ditemui dibaca lagi dan memicu peringatan lain.

• Solution:

  1. Ketika perubahan DDL dilakukan di sumber, lakukan secara manual perubahan DDL yang sesuai di database tujuan.

  2. Jalankan tugas sinkronisasi real-time dan ubah kebijakan pemrosesan pesan DDL dari Error ke Ignore.

     Catatan

     Karena pemulihan berbasis checkpoint masih berlangganan event DDL ini, event tersebut sementara diatur untuk diabaikan guna mencegah tugas gagal lagi.

  3. Hentikan tugas sinkronisasi real-time, ubah kembali kebijakan pemrosesan pesan DDL dari Ignore ke Error, dan restart tugas sinkronisasi real-time.

Error sinkronisasi real-time Kafka: Startup mode for the consumer set to timestampOffset, but no begin timestamp was specified.

Reset offset awal. Di kotak dialog Start tugas, temukan opsi Reset Offset dan centang kotak Reset Offset untuk mengaktifkan fitur ini.

Fitur Reset Offset dari Data Integration digunakan untuk mengatur ulang posisi awal sinkronisasi data. Anda dapat menggunakan fitur ini ketika perlu memulai ulang sinkronisasi dari titik waktu atau posisi data tertentu. Misalnya, jika terjadi error selama sinkronisasi data atau Anda perlu menyinkronkan ulang sebagian data, mengatur ulang offset memungkinkan Anda memulai ulang sinkronisasi dari posisi yang ditentukan untuk memastikan konsistensi dan kelengkapan data.

Error sinkronisasi real-time MySQL: Cannot replicate because the master purged required binary logs.

Error sinkronisasi real-time MySQL: Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup.. Error ini mungkin terjadi karena catatan binlog untuk offset konsumsi tidak dapat ditemukan di MySQL. Periksa periode retensi binlog instans MySQL Anda dan pastikan offset dikonfigurasi dalam rentang waktu ini saat Anda memulai tugas sinkronisasi.

Jika Anda tidak dapat berlangganan binlog, coba atur ulang offset ke waktu saat ini.

Error sinkronisasi real-time MySQL: MySQLBinlogReaderException

Error sinkronisasi real-time MySQL: MySQLBinlogReaderException: The database you are currently syncing is the standby database, but the current value of log_slave_updates is OFF, you need to enable the binlog log update of the standby database first. . Error ini mungkin terjadi karena binlog tidak diaktifkan untuk database standby. Jika Anda ingin menyinkronkan data dari database standby, Anda perlu mengaktifkan cascading binlog di database standby. Hubungi DBA Anda untuk bantuan.

Untuk informasi lebih lanjut tentang cara mengaktifkan binlog, lihat Langkah 3: Aktifkan MySQL binlog.

Error sinkronisasi real-time MySQL: show master status' has an error!

Error sinkronisasi real-time MySQL: show master status' has an error!. Detail error adalah Caused by: java.io.IOException: message=Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation, with command: show master status. Error ini mungkin terjadi karena sumber data tidak memiliki izin database yang diperlukan.

Akun yang dikonfigurasi untuk sumber data harus memiliki hak istimewa SELECT, REPLICATION SLAVE, dan REPLICATION CLIENT pada database. Untuk informasi lebih lanjut tentang cara memberikan hak istimewa yang diperlukan ke sumber data, lihat Langkah 2: Buat akun dan konfigurasi izin.

Error sinkronisasi real-time MySQL: parse.exception.PositionNotFoundException: can't find start position forxxx

Sinkronisasi tidak dapat menemukan offset. Atur ulang offset.

Error sinkronisasi real-time MySQL: Can't get position by timestamp

Kemungkinan penyebab: Binlog yang sesuai dengan waktu mulai sinkronisasi yang ditentukan telah dipurge oleh database sumber. Setelah binlog dipurge, tugas sinkronisasi real-time tidak dapat memperoleh offset berdasarkan titik waktu tersebut, sehingga menyebabkan error ini.

Solusi: Di halaman Data Source Configuration, aktifkan fitur Support OSS Binlog Reading untuk sumber data MySQL. Setelah fitur ini diaktifkan, tugas sinkronisasi dapat membaca binlog yang telah dipurge dari cadangan log OSS, mencegah gangguan sinkronisasi akibat kedaluwarsa binlog lokal.

Fitur ini hanya didukung untuk sumber data RDS MySQL, dan instans RDS harus berada di wilayah yang sama dengan ruang kerja DataWorks.

Error sinkronisasi real-time PolarDB:The mysql server does not enable the binlog write function. Please enable the mysql binlog write function first

• Kemungkinan penyebab: Parameter loose_polar_log_bin tidak diaktifkan untuk sumber data PolarDB.

• Solusi: Aktifkan parameter loose_polar_log_bin. Untuk informasi lebih lanjut, lihat Konfigurasi sumber data PolarDB untuk sinkronisasi real-time.

Error sinkronisasi real-time ke Hologres: permission denied for database xxx

Ketika Anda menyinkronkan data ke Hologres secara real-time, Anda harus memberikan izin admin kepada pengguna yang sedang beroperasi pada instans Hologres (diperlukan izin untuk membuat schema). Untuk informasi lebih lanjut, lihat Mengelola izin Hologres.

Error sinkronisasi real-time ke MaxCompute: ODPS-0410051:invalid credentials-accessKeyid not found

Ketika Anda menyinkronkan data ke sumber data MaxCompute secara real-time dan menggunakan Pasangan Kunci Akses temporary, Pasangan Kunci Akses temporary tersebut secara otomatis kedaluwarsa setelah 7 hari, yang menyebabkan tugas gagal. Platform secara otomatis me-restart tugas ketika mendeteksi bahwa Pasangan Kunci Akses temporary menyebabkan kegagalan tugas. Jika Anda telah mengonfigurasi aturan peringatan jenis ini untuk tugas, Anda akan menerima pemberitahuan peringatan.

Error sinkronisasi real-time dari Oracle: logminer doesn't init, send HeartbeatRecord

Ketika tugas sinkronisasi real-time dari Oracle diinisialisasi dan mencari checkpoint sinkronisasi yang sesuai, tugas tersebut perlu memuat log arsip sebelumnya. Jika log arsip besar, fase inisialisasi mungkin memerlukan waktu 3 hingga 5 menit untuk diselesaikan.

Apa yang harus saya lakukan jika error sinkronisasi real-time PostgreSQL menunjukkan bahwa alamat pemisahan baca/tulis atau mode Replication tidak didukung?

Kemungkinan penyebab: Sinkronisasi real-time PostgreSQL (CDC) bergantung pada mekanisme replikasi logis (Replication Mode) database dan hanya mendukung koneksi ke titik akhir instans utama. Alamat pemisahan baca/tulis, alamat proxy, dan alamat instans secondary tidak mendukung mekanisme ini. Oleh karena itu, tugas melaporkan error yang menunjukkan bahwa alamat pemisahan baca/tulis atau mode Replication tidak didukung.

Solusi: Ubah alamat koneksi sumber data PostgreSQL di konfigurasi sumber data menjadi titik akhir instans utama, simpan konfigurasi, uji kembali konektivitas, lalu jalankan ulang tugas sinkronisasi real-time setelah pengujian berhasil.