All Products
Search
Document Center

AnalyticDB:Berlangganan log biner dengan DTS

Last Updated:Jul 10, 2026

Topik ini menjelaskan cara menggunakan Data Transmission Service (DTS) untuk berlangganan log biner AnalyticDB for MySQL, sehingga memungkinkan sinkronisasi data dan migrasi inkremental antar kluster AnalyticDB for MySQL.

Prasyarat

  • Kluster AnalyticDB for MySQL Anda harus merupakan salah satu edisi berikut: Enterprise Edition, Basic Edition, Data Lakehouse Edition, atau Data Warehouse Edition (dalam mode elastis).

  • Kluster AnalyticDB for MySQL harus memenuhi persyaratan versi kernel berikut:

    • Mesin tabel xuanwu_v1: 3.2.1.0 atau lebih baru.

    • Mesin tabel xuanwu_v2: 3.2.6.0 atau lebih baru.

    • Untuk berlangganan log biner dari tampilan yang di-materialisasi secara inkremental, versi kernel harus 3.2.6.9, 3.2.7.1, atau lebih baru.

    Catatan

    Untuk melihat dan memperbarui versi minor, buka bagian Configuration Information pada halaman Cluster Information di Konsol AnalyticDB for MySQL.

  • Change Data Capture (CDC) telah diaktifkan untuk kluster AnalyticDB for MySQL.

    Catatan

    Change Data Capture (CDC) menangkap perubahan data untuk mendukung sinkronisasi data inkremental dan migrasi. Untuk mengaktifkan CDC atau memeriksa statusnya, hubungi dukungan teknis.

Prosedur

  1. Masuk ke Konsol AnalyticDB for MySQL. Di pojok kiri atas konsol, pilih wilayah. Di panel navigasi sebelah kiri, klik Clusters. Temukan kluster yang ingin Anda kelola lalu klik ID kluster tersebut.

  2. Aktifkan binary logging. Contoh ini menggunakan tabel bernama source_table.

    Catatan

    AnalyticDB for MySQL hanya mendukung pengaktifan binary logging pada tingkat tabel.

    Saat membuat tabel

    CREATE TABLE source_table (
      `id` INT,
      `num` BIGINT,
      PRIMARY KEY (`id`)
    )DISTRIBUTED BY HASH (id) BINLOG=true;

    Untuk tabel yang sudah ada

    ALTER TABLE source_table BINLOG=true;
  3. (Opsional) Ubah periode retensi log biner.

    Anda dapat mengubah parameter binlog_ttl untuk menyesuaikan periode retensi log biner. Nilai default parameter ini adalah 6 jam. Sebagai contoh, Anda dapat mengatur periode retensi log biner untuk tabel source_table menjadi 1 hari.

    ALTER TABLE source_table binlog_ttl='1d';

    Parameter binlog_ttl mendukung format berikut:

    • Milidetik: Nilai numerik. Contoh: 60 merepresentasikan 60 milidetik.

    • Detik: Angka + s. Contoh: 30s merepresentasikan 30 detik.

    • Jam: Angka diikuti h. Contoh: 2h merepresentasikan 2 jam.

    • Hari: Angka diikuti d. Contoh: 1d merepresentasikan 1 hari.

    Catatan
    • Periode retensi log biner maksimum adalah 365 hari untuk kluster dengan versi kernel berikut atau versi yang lebih baru dalam seri masing-masing: 3.2.1.9, 3.2.2.14, 3.2.3.8, 3.2.4.4, dan 3.2.5.1. Untuk kluster dengan versi kernel sebelumnya, periode retensi maksimum adalah 21 hari.

    • Kami menyarankan agar Anda mengatur periode retensi log biner tidak kurang dari nilai default parameter binlog_ttl. Jika periode retensi terlalu singkat, file dapat di-purge, yang dapat memengaruhi sinkronisasi data.

    • Jika Anda perlu melihat periode retensi log biner saat ini, jalankan SHOW CREATE TABLE source_table;.

  4. Berlangganan log biner dengan DTS.

    DTS berlangganan log biner untuk mengaktifkan sinkronisasi data dan migrasi inkremental antar kluster AnalyticDB for MySQL.

  5. (Opsional) Lihat informasi log biner.

    Catatan

    Pernyataan berikut mengembalikan nilai 0 jika Anda telah mengaktifkan binary logging tetapi belum berlangganan menggunakan DTS. Informasi log biner hanya muncul setelah langganan berhasil dibuat.

    • Untuk mendapatkan nama file dan posisi entri log biner terbaru, jalankan pernyataan SQL berikut:

      SHOW MASTER STATUS FOR source_table;
    • Untuk melihat semua file log biner yang belum di-purge beserta ukurannya, jalankan pernyataan SQL berikut:

      SHOW BINARY LOGS FOR source_table;

Dampak performa dari pengaktifan binary logging

Setelah binary logging diaktifkan, AnalyticDB for MySQL mencatat log perubahan data tambahan, yang berdampak pada kluster sebagai berikut:

  • Overhead CPU: Tabel yang diaktifkan binary logging-nya menimbulkan overhead CPU tambahan selama operasi INSERT, UPDATE, dan DELETE. Pada beban kerja umum, peningkatan CPU biasanya tidak melebihi 10%, tetapi pada skenario penulisan dengan konkurensi sangat tinggi, angkanya dapat mencapai sekitar 40%. Kami menyarankan agar Anda mengaktifkan binary logging pada jam sepi atau mengevaluasi dampaknya terlebih dahulu di database uji.

  • Overhead penyimpanan: File log biner bertambah seiring dengan volume perubahan data dan mengonsumsi disk space. Penggunaan penyimpanan sebanding dengan periode retensi binlog_ttl. Tetapkan periode retensi yang wajar berdasarkan kebutuhan sinkronisasi aktual untuk menghindari penggunaan penyimpanan yang tidak perlu oleh file yang telah kedaluwarsa.

  • Performa kueri: Pengaktifan binary logging tidak memengaruhi performa kueri.