All Products
Search
Document Center

Data Transmission Service:FAQ pelacakan perubahan

Last Updated:Sep 24, 2026

  • T: Bagaimana cara kerja pelacakan perubahan?

    J: Untuk informasi tentang cara kerja pelacakan perubahan, lihat Arsitektur dan fitur.

  • T: Data apa saja yang dapat dilacak oleh instans pelacakan perubahan, dan informasi apa yang dapat saya peroleh?

    Anda dapat melacak perubahan tingkat skema (pembuatan, penghapusan, dan modifikasi) pada objek yang dilacak, serta pembaruan data (operasi INSERT, DELETE, dan UPDATE) pada objek tersebut.

    Catatan

    Ketika beberapa database digunakan sebagai sumber, hanya pembaruan data yang dapat dilacak.

  • T: Apakah kelompok konsumen dihapus setelah tugas pelacakan perubahan kedaluwarsa?

    J: Setelah instans pelacakan perubahan DTS kedaluwarsa, kelompok konsumen data dipertahankan selama 7 hari. Jika instans tidak diperpanjang dalam waktu 7 hari setelah kedaluwarsa, instans tersebut akan dirilis dan kelompok konsumen yang sesuai akan dihapus.

  • T: Apakah instans hanya baca dapat digunakan sebagai instans sumber dari tugas pelacakan perubahan?

    Ada dua kasus:

    • Jika instans tersebut adalah instans hanya baca yang mencatat log transaksi (misalnya, instans ApsaraDB RDS for MySQL 5.7 atau 8.0), instans tersebut dapat digunakan sebagai instans sumber.

    • Jika instans tersebut adalah instans hanya baca yang tidak mencatat log transaksi (misalnya, instans ApsaraDB RDS for MySQL 5.6), instans tersebut tidak dapat digunakan sebagai instans sumber.

  • T: Bagaimana cara mengonsumsi data yang dilacak?

    Untuk informasi lebih lanjut, lihat Mengonsumsi data yang dilacak.

  • T: Mengapa format tanggal berubah setelah data ditransfer menggunakan fitur pelacakan perubahan?

    J: Format penyimpanan default untuk nilai tanggal di DTS adalah YYYY:MM:DD. YYYY-MM-DD hanyalah format tampilan; format penyimpanan aktualnya adalah YYYY:MM:DD. Oleh karena itu, terlepas dari format penulisan data selama transfer, data tersebut pada akhirnya dikonversi ke format default.

  • Q: Bagaimana cara memecahkan masalah pada Tugas pelacakan perubahan?

    J: Untuk informasi tentang cara memecahkan masalah tugas pelacakan perubahan, lihat Memecahkan masalah pada tugas pelacakan perubahan.

  • T: SDK tiba-tiba berhenti selama pengunduhan data normal dan tidak dapat melacak data. Bagaimana cara mengatasi masalah ini?

    J: Periksa apakah kode SDK memanggil metode ackAsConsumed untuk melaporkan offset konsumen. Jika ackAsConsumed tidak dipanggil untuk melaporkan offset, cache catatan yang dikonfigurasi di dalam SDK tidak akan dibersihkan. Ketika cache penuh, data baru tidak dapat ditarik, sehingga SDK berhenti dan tidak lagi melacak data.

  • T: SDK gagal melacak data setelah di-restart. Bagaimana cara mengatasi masalah ini?

    J: Sebelum menjalankan SDK, ubah offset konsumen agar berada dalam rentang data. Untuk informasi tentang cara mengubah offset konsumen, lihat Simpan dan kueri titik pemeriksaan konsumsi.

  • T: Bagaimana cara klien menentukan titik waktu untuk mulai mengonsumsi data?

    J: Saat mengonsumsi data yang dilacak, tentukan titik waktu dengan mengatur parameter initCheckpoint. Untuk informasi lebih lanjut, lihat Mengonsumsi data langganan menggunakan kode contoh SDK.

  • T: Tugas pelacakan perubahan DTS mengalami akumulasi data. Bagaimana cara mengatur ulang offset?

    1. Buka file kode yang sesuai berdasarkan mode penggunaan client SDK. Misalnya, DTSConsumerAssignDemo.java atau DTSConsumerSubscribeDemo.java.

      Catatan

      Untuk informasi lebih lanjut, lihat Mengonsumsi data langganan menggunakan kode contoh SDK.

    2. Pada daftar tugas pelacakan perubahan, di kolom Data Range, lihat rentang offset yang dapat dimodifikasi untuk instans pelacakan perubahan target.

    3. Pilih offset konsumen baru sesuai kebutuhan Anda dan konversikan ke timestamp Unix.

    4. Pada file kode, ganti offset konsumen lama (parameter initCheckpoint) dengan offset konsumen baru.

    5. Mulai ulang Klien.

  • T: Client tidak dapat terhubung ke tugas pelacakan perubahan melalui titik akhir VPC. Bagaimana cara mengatasi masalah ini?

    J: Mesin tempat client dijalankan mungkin tidak berada di VPC yang Anda tentukan saat mengonfigurasi tugas pelacakan perubahan (misalnya, VPC client telah diubah). Anda harus mengonfigurasi ulang tugas tersebut.

  • T: Mengapa offset konsumen yang ditampilkan di Konsol lebih besar daripada nilai maksimum rentang data?

    J: Rentang data saluran pelacakan perubahan diperbarui setiap 1 menit, sedangkan offset konsumen diperbarui setiap 10 detik. Oleh karena itu, saat data dikonsumsi secara real time, nilai offset konsumen mungkin lebih besar daripada nilai maksimum rentang data saluran pelacakan perubahan.

  • T: Bagaimana DTS memastikan bahwa data yang dilacak oleh SDK merupakan transaksi lengkap?

    J: Berdasarkan offset konsumen yang diberikan, server DTS mencari transaksi lengkap yang sesuai dengan offset tersebut dan mendistribusikan data downstream mulai dari pernyataan BEGIN transaksi. Oleh karena itu, Anda menerima konten transaksi lengkap.

  • T: Bagaimana cara memastikan bahwa data dikonsumsi secara normal?

    J: Jika data dikonsumsi secara normal, offset konsumen di Konsol Layanan Transmisi Data akan maju sesuai harapan.

  • T: Apa arti usePublicIp=true dalam SDK pelacakan perubahan?

    J: Menyetel usePublicIp=true dalam SDK pelacakan perubahan menunjukkan bahwa SDK mengakses saluran pelacakan perubahan DTS melalui Internet.

  • T: Apakah bisnis saya terpengaruh ketika terjadi alih bencana primary/secondary atau restart database utama pada instans RDS sumber dari tugas pelacakan perubahan?

    J: Saat terjadi failover primer/sekunder atau restart pada instans ApsaraDB RDS for MySQL, ApsaraDB RDS for PostgreSQL, PolarDB for MySQL, PolarDB for PostgreSQL, atau PolarDB-X 1.0 (dengan tipe penyimpanan RDS MySQL), DTS secara otomatis menyesuaikan diri dengan failover tersebut sehingga bisnis Anda tidak terganggu.

  • T: Apakah ApsaraDB RDS mendukung pengunduhan binlog otomatis ke server on-premises?

    J: Pelacakan perubahan DTS mendukung pelacakan binlog ApsaraDB RDS secara real time. Anda dapat mengaktifkan layanan pelacakan perubahan DTS dan menggunakan SDK DTS untuk melacak data binlog ApsaraDB RDS serta menyinkronkan data tersebut ke server on-premises secara real time.

  • T: Apakah data inkremental real time yang dilacak oleh pelacakan perubahan hanya mencakup data baru, atau juga mencakup data yang dimodifikasi?

    J: Data inkremental yang dapat dilacak oleh pelacakan perubahan DTS mencakup semua operasi insert, delete, dan update, serta perubahan skema (DDL).

  • T: Catatan di sisi konsumen tugas pelacakan perubahan tidak di-ACK. Mengapa SDK menerima data duplikat setelah di-restart?

    J: Saat SDK memiliki pesan yang belum di-ACK, server terus mendorong semua pesan dalam buffer. Setelah proses dorong selesai, SDK tidak dapat menerima pesan tambahan. Pada titik ini, offset konsumen yang disimpan di server adalah offset pesan terakhir sebelum pesan yang belum di-ACK. Saat SDK di-restart, untuk memastikan tidak ada pesan yang hilang, server mendorong data kembali mulai dari offset yang sesuai dengan pesan sebelum pesan yang belum di-ACK. Oleh karena itu, SDK menerima beberapa pesan duplikat.

  • T: Seberapa sering offset konsumen pelacakan perubahan diperbarui? Mengapa SDK kadang menerima data duplikat setelah di-restart?

    J: Setelah SDK pelacakan perubahan mengonsumsi setiap pesan, SDK harus memanggil ackAsConsumed untuk mengirim ACK ke server. Setelah server menerima ACK, server memperbarui offset konsumen di memori dan kemudian menyimpan offset tersebut setiap 10 detik. Jika SDK di-restart sebelum ACK terbaru disimpan, server akan mendorong pesan mulai dari offset konsumen yang terakhir disimpan untuk memastikan tidak ada pesan yang hilang. Akibatnya, SDK menerima pesan duplikat.

  • T: Apakah instans pelacakan perubahan dapat melacak beberapa instans RDS?

    J: Tidak. Satu instans pelacakan perubahan saat ini hanya dapat melacak satu instans RDS.

  • T: Apakah ketidakkonsistenan data dapat terjadi pada instans pelacakan perubahan?

    J: Tidak. Tugas pelacakan perubahan hanya mengambil perubahan dari database sumber dan tidak melibatkan ketidakkonsistenan data. Jika data yang dikonsumsi oleh client tidak sesuai ekspektasi Anda, lakukan pemecahan masalah di sisi Anda.

  • T: Bagaimana cara menangani pesan UserRecordGenerator yang muncul saat saya mengonsumsi data yang dilacak?

    J: Saat mengonsumsi data yang dilacak, jika muncul pesan seperti UserRecordGenerator: haven't receive records from generator for 5s, periksa apakah offset konsumen berada dalam rentang offset modul pengumpulan data inkremental dan pastikan konsumen berjalan dengan baik.

  • T: Apakah topik mendukung beberapa partisi?

    J: Tidak. Untuk memastikan pengurutan pesan global, setiap topik pelacakan perubahan hanya memiliki satu partisi, yang bersifat tetap dan ditetapkan ke partisi 0.

  • T: Apakah SDK pelacakan perubahan mendukung Go?

    J: Ya. Untuk kode contoh, lihat dts-subscribe-demo.

  • T: Apakah SDK pelacakan perubahan mendukung Python?

    J: Ya. Untuk kode contoh, lihat dts-subscribe-demo.

  • T: Apakah flink-dts-connector mendukung konsumsi data yang dilacak secara konkuren multi-threaded?

    J: Tidak.

  • T: Apa yang harus saya lakukan jika lupa username atau password kelompok konsumen instans pelacakan perubahan?

    J: Jika bisnis Anda memungkinkan, Anda dapat menghapus kelompok konsumen tersebut lalu membuat yang baru (dengan username asli dan password baru).

  • T: Apakah tugas pelacakan perubahan dan tugas sinkronisasi data dapat dikonfigurasi pada instans RDS yang sama?

    J: Ya. Kedua tugas tersebut dapat dikonfigurasi secara bersamaan tanpa saling memengaruhi. Pelacakan perubahan dan sinkronisasi data adalah dua jenis tugas independen yang dapat berjalan berdampingan pada instans RDS yang sama tanpa gangguan.