Zero-ETL mengalirkan data dari ApsaraDB RDS for MySQL ke ApsaraDB for ClickHouse secara real time tanpa perlu membangun atau memelihara pipa data. Fitur ini didukung oleh Data Transmission Service (DTS) dan tidak dikenai biaya.
Cara kerja
Zero-ETL menangani tiga fase secara otomatis:
Sinkronisasi skema — DTS membaca skema sumber dan membuat tabel yang sesuai di ClickHouse. Fitur ini menambahkan field
_sign,_is_deleted, dan_versionke setiap tabel tujuan.Sinkronisasi data penuh — DTS menyalin semua baris yang ada dari sumber ke ClickHouse.
Sinkronisasi data inkremental — DTS membaca log biner dari instans MySQL sumber dan menerapkan perubahan INSERT, UPDATE, dan DELETE ke ClickHouse secara berkelanjutan.
Ketika operasi UPDATE atau DELETE dijalankan pada sumber, ClickHouse menambahkan catatan baru dan menggunakan _sign, _is_deleted, dan _version untuk melacak perubahan tersebut. Akibatnya, ukuran database tujuan bisa lebih besar daripada sumber. Untuk mengkueri hanya baris terkini, tambahkan FINAL setelah nama tabel atau filter berdasarkan _sign atau _is_deleted.
Pipa yang didukung
| Sumber | Tujuan | Metode akses | Fase yang didukung |
|---|---|---|---|
| ApsaraDB RDS for MySQL | ApsaraDB for ClickHouse | Instans Alibaba Cloud | Sinkronisasi skema, sinkronisasi penuh, sinkronisasi inkremental |
Penagihan
Pipa sinkronisasi Zero-ETL tidak dikenai biaya.
Prasyarat
Sebelum memulai, pastikan bahwa:
Kluster ApsaraDB for ClickHouse dan instans RDS for MySQL berada di wilayah yang sama.
Akun database tersedia untuk instans RDS for MySQL sumber. Lihat Buat akun untuk instans ApsaraDB RDS for MySQL.
Akun database tersedia untuk kluster ClickHouse tujuan. Lihat Buat akun untuk kluster ApsaraDB for ClickHouse.
Batasan
Database sumber (RDS for MySQL)
| Batasan | Detail |
|---|---|
| Kunci primer | Semua tabel yang akan disinkronkan harus memiliki kunci primer. |
| Ubah nama tabel | RENAME TABLE tidak disinkronkan. |
| Batas sinkronisasi tingkat tabel | Sinkronisasi tabel individual (bukan seluruh database) mendukung hingga 1.000 tabel per tugas. Untuk lebih dari 1.000 tabel, bagi menjadi beberapa tugas atau sinkronkan pada tingkat database. |
| DDL selama sinkronisasi skema atau sinkronisasi penuh | Jangan menjalankan operasi DDL saat sinkronisasi skema atau sinkronisasi data penuh sedang berlangsung. Melakukannya menyebabkan tugas gagal. |
pt-online-schema-change | Jika Anda memilih satu atau beberapa tabel (bukan seluruh database) sebagai objek yang akan disinkronkan, jangan gunakan pt-online-schema-change atau alat serupa untuk operasi DDL pada tabel-tabel tersebut selama sinkronisasi. Jika tidak, data mungkin gagal disinkronkan. |
| DDL non-standar | Pernyataan DDL pada sumber yang tidak sesuai dengan sintaksis standar MySQL dapat menyebabkan tugas gagal atau mengakibatkan kehilangan data. |
| Pencatatan log biner | binlog_row_image harus diatur ke full. Pencatatan log biner diaktifkan secara default untuk ApsaraDB RDS for MySQL. Untuk MySQL yang dikelola sendiri, atur juga binlog_format=row. Untuk database MySQL yang dikelola sendiri dalam arsitektur primary/primary, aktifkan log_slave_updates |
| Retensi log biner | Pertahankan log biner lokal minimal selama 3 hari (disarankan 7 hari) untuk ApsaraDB RDS for MySQL; minimal 7 hari untuk MySQL yang dikelola sendiri. Tugas gagal jika DTS tidak dapat membaca log biner yang diperlukan, dan masalah yang disebabkan oleh retensi yang tidak mencukupi berada di luar Perjanjian Tingkat Layanan (SLA) DTS. |
| Kolom tak terlihat (MySQL 8.0.23+) | Kolom tak terlihat tidak disinkronkan dan data mungkin hilang. Jalankan ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; untuk membuatnya terlihat sebelum memulai tugas. |
| Always-confidential (EncDB) | Sinkronisasi data penuh tidak didukung saat EncDB diaktifkan. Enkripsi Data Transparan (TDE) didukung untuk sinkronisasi skema, sinkronisasi data penuh, dan sinkronisasi data inkremental. |
| Instans read-only tanpa log transaksi | Tidak dapat digunakan sebagai sumber (misalnya, instans RDS for MySQL 5.6 read-only). |
| Pernyataan heartbeat | Tugas zero-ETL secara berkala menjalankan CREATE DATABASE IF NOT EXISTS \test\`` pada sumber untuk memajukan offset log biner. |
| Perubahan yang tidak ada di log biner | Perubahan yang diterapkan melalui pemulihan backup fisik atau operasi kaskade tidak disinkronkan. Jika hal ini terjadi, hapus dan tambahkan kembali objek yang terpengaruh dari cakupan sinkronisasi. |
Jika Anda menyinkronkan data dari beberapa instans ke satu kluster ApsaraDB for ClickHouse, pastikan bahwa objek sinkronisasi dalam tugas yang berbeda tidak tumpang tindih.
Batasan umum
| Batasan | Detail |
|---|---|
| Maksimum database per kluster | Hingga 256 database dapat disinkronkan ke satu kluster ApsaraDB for ClickHouse |
| Konvensi penamaan | Nama database, tabel, dan kolom harus mematuhi konvensi penamaan ApsaraDB for ClickHouse. Lihat Batasan pada konvensi penamaan objek |
| Rentang DATETIME | Nilai DATETIME di sumber harus berada dalam rentang waktu yang didukung oleh kluster tujuan. Lihat bagian Rentang waktu |
Pemetaan tipe data
Tipe data RDS for MySQL dan ApsaraDB for ClickHouse tidak memiliki pemetaan satu-ke-satu. Selama sinkronisasi skema, DTS memetakan tipe field sumber ke tipe terdekat yang didukung di ClickHouse. Untuk tabel pemetaan lengkap, lihat Pemetaan tipe data untuk sinkronisasi skema.
Catatan penggunaan
Jumlah maksimum tugas zero-ETL per kluster
Jumlah maksimum tugas zero-ETL yang dapat Anda buat untuk suatu kluster bergantung pada edisi:
Edisi Perusahaan:
ceil(batas CCU bawah / 8). Untuk kluster dengan batas ClickHouse Compute Unit (CCU) bawah sebesar 22, perhitungannya adalahceil(22 / 8) = 3.Edisi Komunitas:
ceil(total core CPU / 8). Untuk kluster dua node dengan masing-masing node memiliki 8 core, perhitungannya adalahceil(16 / 8) = 2.
Jika kluster mencapai batasnya, hapus tugas yang tidak digunakan atau buat tugas sinkronisasi tambahan langsung di konsol DTS.
Struktur tabel di tujuan
Selama sinkronisasi skema, fitur zero-ETL menambahkan field _sign, _is_deleted, dan _version ke setiap tabel tujuan.
Untuk kluster Edisi Kompatibel Komunitas, tugas membuat tabel lokal dan tabel terdistribusi untuk setiap tabel sumber:
Tabel terdistribusi: Nama sama dengan tabel sumber. Gunakan tabel ini untuk kueri.
Tabel lokal: Dinamai
<distributed_table_name>_local. Digunakan secara internal oleh ClickHouse untuk penyimpanan tingkat shard.
Penjadwalan dan kinerja
Jalankan tugas selama jam sepi. Selama sinkronisasi data penuh, DTS menggunakan resource baca dan tulis baik di sumber maupun tujuan, yang dapat meningkatkan beban server.
Persiapan
Sebelum membuat tugas zero-ETL, siapkan peran terkait layanan dan izin Pengguna Resource Access Management (RAM) yang diperlukan.
Langkah 1: Buat peran terkait layanan
Buat peran terkait layanan AliyunServiceRoleForClickHouseZeroETL.
Saat Anda memilih ID instans database selama konfigurasi tugas, konsol akan meminta Anda untuk membuat peran ini secara otomatis. Pembuatan manual tidak diperlukan dalam kasus tersebut.
Langkah 2: Berikan izin Pengguna RAM
Untuk mengizinkan Pengguna RAM membuat tugas zero-ETL, berikan izin berikut. Lihat Kelola izin Pengguna RAM.
Source RDS for MySQL:
AliyunRDSFullAccessKluster ClickHouse tujuan:
AliyunClickHouseFullAccessDTS: Buat kebijakan kustom menggunakan skrip berikut. Lihat Buat kebijakan izin kustom.
{
"Version": "1",
"Statement": [
{
"Action": "dts:*",
"Resource": "*",
"Effect": "Allow"
},
{
"Action": "ram:PassRole",
"Resource": "*",
"Effect": "Allow",
"Condition": {
"StringEquals": {
"acs:Service": "dts.aliyuncs.com"
}
}
}
]
}Buat dan mulai tugas zero-ETL
Alur keseluruhan terdiri dari lima langkah: navigasi ke halaman zero-ETL, konfigurasi database sumber dan tujuan, pilih objek untuk disinkronkan, konfigurasi field tabel, dan jalankan pemeriksaan awal sebelum memulai.
Langkah 1: Buka halaman zero-ETL
Login ke Konsol ApsaraDB for ClickHouse.
Di pojok kiri atas, pilih wilayah kluster Anda.
Pada halaman Cluster List, klik tab List of Community Edition Instances, lalu klik ID kluster target.
Di panel navigasi kiri, klik Zero-ETL (Seamless Integration).
Langkah 2: Konfigurasi database sumber dan tujuan
Klik Create Zero-ETL Task.
Masukkan Task Name.
Konfigurasi database sumber dan tujuan.
Konfigurasikan database sumber dan tujuan berdasarkan parameter berikut. Setelah menyelesaikan konfigurasi, klik Next.
Database sumber
Parameter
Deskripsi
Database type
RDS for MySQL (satu-satunya opsi yang didukung)
Access method
Instans Alibaba Cloud (satu-satunya opsi yang didukung)
Instance region
Wilayah instans RDS for MySQL sumber
RDS instance ID
ID instans RDS for MySQL sumber
Database account
Akun database untuk instans RDS for MySQL
Database password
Password untuk akun database instans RDS for MySQL
Encryption
Pilih Non-encrypted atau SSL-encrypted. Jika Anda memilih SSL-encrypted, aktifkan enkripsi SSL untuk instans RDS for MySQL terlebih dahulu. Lihat Gunakan sertifikat cloud untuk mengaktifkan enkripsi tautan SSL dengan cepat.
Database tujuan
Parameter
Deskripsi
Database type
ClickHouse
Connection type
Instans Alibaba Cloud (satu-satunya opsi yang didukung)
Instance region
Wilayah kluster tujuan
Cluster ID
ID kluster tujuan
Cluster type
Edisi Komunitas atau Edisi Perusahaan
Database account
Akun database untuk kluster tujuan
Database password
Password untuk akun database kluster tujuan
Klik Test Connectivity and Proceed.
Langkah 3: Pilih objek untuk disinkronkan
Pada bagian Source Objects, pilih database atau tabel yang akan disinkronkan. Klik
untuk memindahkannya ke bagian Selected Objects.

Klik Next: Configure Database and Table Fields.
Langkah 4: Konfigurasi field tabel
Pada halaman Configurations for Databases, Tables, and Columns, atur hal berikut untuk setiap tabel:
| Field | Deskripsi |
|---|---|
| Type | Jenis engine tabel |
| Primary key column | Satu atau beberapa kolom yang membentuk kunci primer. Kunci komposit didukung |
| Sort key | Satu atau beberapa kolom untuk pengurutan. Kunci komposit didukung |
| Distribution key | Satu kolom untuk distribusi data di seluruh shard |
| Partition key | (Opsional) Kolom non-kosong untuk partisi. Kolom tidak boleh kosong jika diatur |
Secara default, hanya tabel dengan konfigurasi yang belum ditentukan yang ditampilkan. Untuk melihat semua tabel, atur Definition Status ke All. Kunci partisi harus dipilih dari kolom kunci primer. Untuk detail tentang field-field ini, lihat CREATE TABLE.
Klik Next: Save Task Settings and Precheck. Tugas akan disimpan terlepas dari apakah pemeriksaan awal berhasil atau tidak.
Langkah 5: Jalankan pemeriksaan awal dan mulai tugas
Saat Success Rate mencapai 100%, klik Start.
Jika pemeriksaan awal gagal, perbaiki masalah yang dilaporkan di sumber atau tujuan, lalu modifikasi dan jalankan ulang pemeriksaan awal dari halaman zero-ETL.
Setelah tugas dimulai, halaman zero-ETL menampilkan ID/nama tugas, sumber/tujuan, dan status.
Monitor tugas zero-ETL
Gunakan satu atau beberapa metode berikut untuk melacak kesehatan tugas. Untuk beban kerja produksi yang sedang berjalan, konfigurasikan notifikasi atau langganan event agar Anda menerima pemberitahuan otomatis saat terjadi masalah.
| Metode | Paling cocok untuk | Batasan |
|---|---|---|
| Melihat aktif di konsol ClickHouse | Meninjau kinerja replikasi, detail sinkronisasi, dan log tugas | Tidak ada notifikasi otomatis |
| Notifikasi latensi sinkronisasi di CloudMonitor | Menerima notifikasi otomatis saat latensi melebihi ambang batas | Hanya memantau latensi |
| Langganan event di CloudMonitor | Menerima notifikasi saat tugas gagal dan pulih | Hanya memantau kegagalan dan pemulihan |
Monitor tugas di konsol ApsaraDB for ClickHouse
Login ke Konsol ApsaraDB for ClickHouse.
Di pojok kiri atas, pilih wilayah kluster Anda.
Pada halaman Cluster List, klik tab List of Community Edition Instances, lalu klik ID kluster.
Di panel navigasi kiri, klik Zero-ETL (Seamless Integration).
Temukan tugas dan klik Task Details di kolom Actions.
Halaman detail tugas menampilkan kinerja replikasi, status sinkronisasi, dan log.

Siapkan notifikasi latensi sinkronisasi di CloudMonitor
Buat aturan notifikasi di CloudMonitor. Lihat Buat aturan notifikasi di konsol CloudMonitor. Atur parameter berikut:
Parameter Nilai Product Clickhouse - ZeroETL Latency Monitoring metrics Synchronization Latency Untuk melihat latensi saat ini, login ke Konsol CloudMonitor. Di daftar ClickHouse - ZeroETL Latency, klik Monitoring Charts di kolom Actions untuk kluster target.
Berlangganan event tugas zero-ETL di CloudMonitor
Berlangganan event sistem untuk menerima notifikasi otomatis saat tugas gagal atau pulih. Lihat Kelola langganan event.
Saat membuat kebijakan langganan, atur parameter berikut:
| Event | Parameter | Nilai |
|---|---|---|
| Kegagalan tugas | Subscription type | System Event |
| Product | ApsaraDB Clickhouse | |
| Event type | Abnormal | |
| Event name | ZeroETL task abnormal | |
| Pemulihan tugas | Subscription type | System Event |
| Product | ApsaraDB Clickhouse | |
| Event type | Restore | |
| Event name | ZeroETLTaskRestore |
FAQ
Mengapa ukuran database tujuan lebih besar daripada sumber setelah sinkronisasi?
ClickHouse tidak menimpa baris saat UPDATE atau DELETE. Sebagai gantinya, ClickHouse menambahkan catatan baru dan menggunakan _sign, _is_deleted, dan _version untuk melacak perubahan tersebut. Akibatnya, jumlah baris di tujuan bertambah seiring waktu dibandingkan dengan sumber.
Untuk mengkueri hanya data terbaru, tambahkan FINAL setelah nama tabel, atau filter berdasarkan _sign atau _is_deleted (field yang tepat tergantung pada versi kluster Anda). Untuk detailnya, lihat Informasi field.
Mengapa tabel bernama `<table>_local` muncul di database tujuan?
Untuk kluster Edisi Kompatibel Komunitas, zero-ETL membuat tabel lokal dan tabel terdistribusi untuk setiap tabel sumber. Tabel terdistribusi (dinamai sesuai tabel sumber) adalah tabel yang Anda kueri. Tabel _local digunakan secara internal oleh ClickHouse untuk penyimpanan tingkat shard.
Apa yang terjadi jika periode retensi log biner terlalu singkat?
DTS menggunakan log biner untuk menerapkan perubahan inkremental. Jika log biner yang diperlukan untuk melanjutkan replikasi telah dipurge, tugas gagal dan tidak dapat dilanjutkan. Dalam kasus ini, hapus database atau tabel yang terpengaruh dari cakupan sinkronisasi dan tambahkan kembali untuk memicu sinkronisasi penuh baru. Untuk ApsaraDB RDS for MySQL, pertahankan log biner minimal selama 3 hari (disarankan 7 hari). Untuk MySQL yang dikelola sendiri, pertahankan log biner minimal selama 7 hari.
Apa penyebab tugas zero-ETL gagal dengan error offset log biner?
Tugas kehilangan posisinya di log biner jika file log dipurge sebelum DTS membacanya, biasanya karena periode retensi yang singkat. Saat hal ini terjadi, tugas tidak dapat dilanjutkan secara otomatis. Hapus tabel atau database yang terpengaruh dari cakupan sinkronisasi dan tambahkan kembali untuk memicu sinkronisasi penuh baru. Untuk mencegah kejadian serupa, untuk ApsaraDB RDS for MySQL, pertahankan log biner minimal selama 3 hari (disarankan 7 hari); untuk MySQL yang dikelola sendiri, pertahankan log biner minimal selama 7 hari.