DataWorks:FAQ sinkronisasi real-time

Sumber data yang didukung

Untuk daftar sumber data yang didukung, lihat Sumber Data yang Didukung untuk sinkronisasi real-time.

Latensi tinggi pada tugas sinkronisasi real-time

Jika Anda menemukan bahwa data tidak tersinkronisasi ke tabel tujuan, penyebabnya mungkin adalah latensi tinggi pada tugas sinkronisasi real-time. Periksa nilai Operation Center tugas tersebut di halaman Real-time Computing Nodes di Operation Center. Untuk informasi lebih lanjut, lihat Bagaimana cara mengatasi latensi tinggi pada tugas sinkronisasi real-time?.

Latensi tinggi dapat disebabkan oleh hal-hal berikut:

Risiko penggunaan jaringan publik

Penggunaan internet untuk tugas sinkronisasi real-time memiliki risiko berikut:

• Jaringan mungkin tidak stabil, dan masalah seperti kehilangan paket yang sering dapat memengaruhi kinerja sinkronisasi.

• Menawarkan keamanan yang lebih rendah.

Format kolom dalam sinkronisasi real-time

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

Penanganan operasi TRUNCATE

Sinkronisasi real-time mendukung operasi TRUNCATE, yang berlaku selama penggabungan inkremental dan penuh-inkremental. Jika Anda memilih untuk mengabaikan operasi TRUNCATE, hal ini dapat menghasilkan data redundan selama sinkronisasi real-time.

Meningkatkan kecepatan dan kinerja sinkronisasi

Jika kecepatan penulisan sinkronisasi lambat, Anda dapat meningkatkan concurrency sisi tulis dan menyesuaikan parameter JVM. Parameter JVM bergantung pada frekuensi perubahan, bukan jumlah library yang disinkronkan. Jika mesin dalam resource group saat ini memiliki sumber daya yang cukup, mengalokasikan lebih banyak memori mengurangi frekuensi Full GC dan meningkatkan kinerja sinkronisasi real-time.

Menjalankan tugas dari konsol

Anda tidak dapat menjalankan tugas sinkronisasi real-time langsung dari antarmuka pengguna DataWorks. Setelah mengonfigurasi tugas, Anda harus mengirim dan menerapkan node real-time tersebut, lalu menjalankannya di lingkungan produksi. Untuk detailnya, lihat Mengoperasikan dan memelihara tugas sinkronisasi real-time.

Sinkronisasi lambat dengan MySQL

Perlambatan ini mungkin disebabkan oleh peningkatan jumlah binlog yang perlu diproses. Binlog dihasilkan pada level instans. Bahkan jika tugas sinkronisasi Anda dikonfigurasi hanya untuk menyinkronkan Tabel A, perubahan pada tabel lain seperti Tabel B dan Tabel C juga akan menghasilkan binlog. Binlog tambahan ini dapat memperlambat proses sinkronisasi.

Penggunaan memori: satu vs. beberapa database

Saat Anda memilih dua atau lebih database, tugas tersebut masuk ke mode sinkronisasi real-time "full-instance". Mode ini mengonsumsi lebih banyak sumber daya dibandingkan menjalankan dua tugas real-time terpisah, masing-masing menyinkronkan satu database.

Kebijakan perubahan DDL

Metode penanganan:

Tipe DDL:

Pertimbangan DDL dan DML

• Setelah kolom sumber ditambahkan dan berhasil diproses oleh tujuan, batasan berikut berlaku:

  • Jika Anda menambahkan kolom dengan DEFAULT VALUE, kolom baru di tabel tujuan akan tetap NULL. Saat data baru ditambahkan ke kolom ini di sumber, tugas sinkronisasi real-time akan menyinkronkan data baru tersebut.

  • Jika Anda menambahkan kolom VIRTUAL, kolom baru di tabel tujuan akan tetap NULL. Saat data baru ditambahkan ke kolom ini di sumber, tugas sinkronisasi real-time akan menyinkronkan data baru tersebut.

• Saat melakukan sinkronisasi real-time dari sumber MySQL atau PolarDB for MySQL, tambahkan kolom baru di akhir tabel alih-alih menyisipkannya di tengah. Jika menyisipkan kolom di tengah tidak dapat dihindari, perhatikan batasan berikut:

  • Untuk solusi penuh dan inkremental, jangan menambahkan kolom di tengah tabel selama fase sinkronisasi penuh. Melakukannya akan menyebabkan anomali data selama fase sinkronisasi real-time.

  • Selama fase sinkronisasi real-time, Offset sinkronisasi harus diatur ulang ke waktu setelah event DDL yang menambahkan kolom tersebut. Jika tidak, anomali dapat terjadi selama sinkronisasi data real-time berikutnya.

• Jika terjadi anomali data, Anda dapat menginisialisasi ulang tabel dengan melakukan pemuatan data penuh.

Latensi tinggi di PostgreSQL setelah failover

Perilaku ini melekat pada PostgreSQL. Jika latensi ini tidak dapat diterima, Anda dapat menghentikan dan memulai ulang tugas untuk memicu sinkronisasi data penuh dan inkremental.

Menjalankan sinkronisasi penuh

Di Data Integration, temukan tugas yang sudah ada di daftar Synchronization Task. Di kolom Operation, klik More > Rerun.

Tugas MySQL berhenti membaca data

1. Jalankan perintah berikut di database untuk melihat file binlog yang sedang ditulis oleh instans:

   show master status 

2. Bandingkan ini dengan file binlog yang sedang dibaca oleh tugas. Cari log tugas untuk entri seperti journalName=MySQL-bin.000001,position=50 untuk memastikan apakah data sedang ditulis ke database.

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

Kegagalan tugas berulang

• Gejala: Tugas sinkronisasi real-time gagal berulang kali.

  Saat sumber adalah sumber data Oracle, PolarDB, atau MySQL, pesan DDL dari sumber tidak diproses secara default. Jika terjadi perubahan DDL selain CREATE TABLE, tugas real-time akan gagal. Karena fitur resume, tugas mungkin tetap gagal meskipun pesan DDL tersebut tidak lagi ada di sumber.

  Catatan

  Untuk mencegah kehilangan atau kerusakan data, jangan gunakan perintah Rename untuk menukar nama dua kolom, misalnya menukar nama Kolom A dan Kolom B.

• Penyebab: Fitur resume memastikan tidak ada data yang hilang dengan membaca dari Offset yang sedikit lebih awal saat dimulai ulang. Proses ini mungkin membaca ulang pesan DDL sebelumnya, menyebabkan tugas gagal lagi.

• Solusi:

  1. Jika terjadi perubahan DDL di sumber, terapkan secara manual perubahan yang sama ke database tujuan.

  2. Jalankan tugas sinkronisasi real-time dan ubah kebijakan penanganan pesan DDL dari Error reporting ke Ignoring.

     Catatan

     Perubahan ini bersifat sementara untuk mencegah tugas gagal lagi saat fitur resume membaca ulang event DDL.

  3. Hentikan tugas sinkronisasi real-time, ubah kembali kebijakan penanganan pesan DDL dari Ignoring ke Error reporting, lalu mulai ulang tugas tersebut.

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

Atur ulang Offset awal.

Fungsi Reset offset di Data Integration memungkinkan Anda menentukan ulang titik awal sinkronisasi data. Gunakan fungsi ini saat Anda perlu memulai ulang sinkronisasi dari waktu atau posisi data tertentu. Misalnya, jika terjadi error atau jika Anda perlu menyinkronkan ulang sebagian data, mengatur ulang Offset membantu Anda memulai dari posisi yang ditentukan, memastikan konsistensi dan integritas data.

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

Jika Anda mengalami error Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup. selama sinkronisasi real-time MySQL, artinya Offset binlog yang diperlukan tidak ditemukan di MySQL. Periksa periode retensi binlog di pengaturan MySQL Anda dan pastikan Offset awal tugas berada dalam periode tersebut.

Error sinkronisasi MySQL: MySQLBinlogReaderException

Jika Anda mengalami error 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. , penyebabnya mungkin binlog tidak diaktifkan di database standby. Jika Anda ingin menyinkronkan dari database standby, Anda harus mengaktifkan binlog cascaded. Hubungi administrator basis data Anda untuk bantuan.

Untuk detail cara mengaktifkan binlog, lihat Langkah 3: Aktifkan binlog untuk MySQL.

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

Jika Anda mengalami error show master status' has an error! dengan detail seperti 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, akun Sumber Data mungkin tidak memiliki izin database yang diperlukan.

Akun yang digunakan untuk konfigurasi Sumber Data memerlukan hak istimewa SELECT, REPLICATION SLAVE, dan REPLICATION CLIENT untuk database tersebut. Untuk detail cara memberikan izin ini, lihat Langkah 2: Buat akun dan konfigurasikan izin.

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

Tugas sinkronisasi tidak dapat menemukan Offset yang ditentukan. Atur ulang Offset.

Kesalahan sinkronisasi PolarDB: Server MySQL tidak mengaktifkan fungsi penulisan binlog. Aktifkan terlebih dahulu fungsi penulisan binlog MySQL

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

• Solusi: Aktifkan parameter loose_polar_log_bin. Untuk petunjuk lengkap, lihat Konfigurasi Sumber Data (Sumber PolarDB).

Error sinkronisasi Hologres: permission denied for database xxx

Saat menyinkronkan data ke Hologres secara real-time, Anda harus memberikan izin admin kepada pengguna saat ini untuk instans Hologres, yang mencakup izin untuk membuat skema. Untuk detailnya, lihat Model Izin Hologres.

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

Saat Anda menyinkronkan data ke sumber data MaxCompute menggunakan AccessKey sementara, kunci tersebut secara otomatis kedaluwarsa setelah tujuh hari, menyebabkan tugas gagal. Platform secara otomatis memulai ulang tugas saat mendeteksi kegagalan akibat kunci sementara yang kedaluwarsa. Jika Anda telah mengonfigurasi peringatan pemantauan untuk jenis kegagalan ini, Anda akan menerima pesan peringatan.

Error sinkronisasi Oracle: logminer doesn't init, send HeartbeatRecord

Saat tugas sinkronisasi real-time Oracle diinisialisasi untuk menemukan Offset sinkronisasi yang sesuai, tugas tersebut perlu memuat log arsip sebelumnya. Jika log arsip tersebut besar, fase inisialisasi ini dapat memakan waktu 3 hingga 5 menit untuk diselesaikan.