Sinkronisasi data dari TiDB ke AnalyticDB for MySQL 3.0 - Data Transmission Service

Gunakan Data Transmission Service (DTS) untuk menyinkronkan data dari database TiDB yang dikelola sendiri ke kluster AnalyticDB for MySQL V3.0 guna analitik real-time.

Cara kerja

DTS membaca perubahan inkremental dari TiDB melalui kluster Kafka yang berfungsi sebagai buffer change data capture (CDC), lalu menulis data tersebut ke AnalyticDB for MySQL V3.0. Alur lengkapnya adalah:

TiDB → Kafka cluster → DTS → AnalyticDB for MySQL V3.0

TiDB tidak mengekspos log biner secara langsung ke DTS. Anda harus menyiapkan salah satu komponen CDC berikut untuk memublikasikan perubahan inkremental ke topik Kafka:

TiDB Binlog — menggunakan komponen Pump dan Drainer
TiCDC — menggunakan format Canal-JSON

DTS membaca dari partisi 0 topik Kafka dan menerapkan perubahan ke kluster tujuan.

Batasan

Tinjau batasan berikut sebelum mengonfigurasi tugas.

Batasan database sumber

Batasan	Detail
Kunci primer atau kendala unik wajib	Tabel yang akan disinkronkan harus memiliki PRIMARY KEY atau UNIQUE constraint dengan semua bidang unik. Tabel tanpa constraint ini dapat menghasilkan catatan duplikat di tujuan.
Pembatasan DDL selama sinkronisasi	Jangan menjalankan pernyataan DDL yang mengubah skema database atau tabel selama sinkronisasi skema atau sinkronisasi data penuh. Tugas akan gagal.
Kehilangan panjang indeks awalan	TiDB tidak menyimpan panjang indeks awalan dalam metadata. Panjang tersebut hilang saat data disinkronkan ke AnalyticDB for MySQL V3.0, yang dapat menyebabkan instans tujuan gagal. Perbaiki secara manual panjang indeks awalan untuk tabel apa pun yang menggunakannya.
Batas tabel per tugas	Jika Anda memilih tabel individual (bukan seluruh database) dan mengganti namanya, satu tugas mendukung hingga 1.000 tabel. Jika melebihi batas ini, konfigurasikan beberapa tugas atau sinkronkan seluruh database.
Persyaratan penyiapan Kafka	Terapkan kluster Kafka dan instal TiDB Binlog atau TiCDC sebelum membuat tugas DTS.
Bandwidth keluar	Server yang menjalankan TiDB harus memiliki bandwidth keluar yang mencukupi. Bandwidth yang tidak mencukupi mengurangi kecepatan sinkronisasi.

Batasan tujuan dan tugas

Batasan	Detail
Partisi Kafka	DTS hanya membaca dari partisi 0 topik Kafka. Buat topik dengan tepat satu partisi.
Kunci primer kustom wajib	Tentukan kunci primer kustom di AnalyticDB for MySQL V3.0, atau konfigurasikan Primary Key Column pada langkah Configurations for Databases, Tables, and Columns. Jika tidak, tugas dapat gagal.
Ambang batas penggunaan disk	Jika penggunaan disk pada node mana pun di kluster AnalyticDB for MySQL V3.0 melebihi 80%, tugas DTS tertunda dan mengembalikan error. Perkirakan ruang disk yang dibutuhkan sebelum memulai.
Konflik backup	Jika kluster tujuan sedang dibackup saat DTS berjalan, tugas gagal.
Tipe data heterogen	Tipe data TiDB dan AnalyticDB for MySQL V3.0 tidak memiliki pemetaan satu-ke-satu. Lihat Pemetaan tipe data untuk sinkronisasi skema awal untuk detailnya.
Presisi FLOAT/DOUBLE	DTS menggunakan `ROUND(COLUMN,PRECISION)` untuk mengambil nilai FLOAT dan DOUBLE. FLOAT default ke presisi 38 digit, DOUBLE ke 308 digit. Verifikasi bahwa nilai default ini memenuhi kebutuhan Anda.
Tampilan yang di-materialisasi tidak didukung	Selama sinkronisasi skema, DTS tidak mendukung penyinkronan materialized views ke instans AnalyticDB for MySQL tujuan. Untuk menggunakan materialized views, buat secara manual di instans tujuan setelah sinkronisasi selesai.
Inisialisasi offset tugas	Setelah membuat tugas, segera lakukan operasi pada database sumber atau masukkan data uji. Ini memperbarui offset tugas. Jika langkah ini dilewati, tugas dapat gagal karena latensi berlebihan.
Data dari sumber lain	Jangan menulis data ke kluster tujuan dari sumber lain selama sinkronisasi. Hal ini menyebabkan ketidakkonsistenan data.
Pelanjutan tugas gagal	DTS secara otomatis mencoba ulang tugas yang gagal hingga 7 hari. Sebelum memindahkan beban kerja ke kluster tujuan, hentikan atau lepas tugas yang gagal. Atau, jalankan `REVOKE` untuk mencabut izin tulis DTS dari database tujuan agar tugas yang dilanjutkan tidak menimpa data baru.
Kinerja sinkronisasi data penuh	Sinkronisasi data penuh meningkatkan beban pada database sumber dan tujuan. Jalankan selama jam sepi, saat penggunaan CPU di bawah 30%.
Ukuran ruang tabel setelah sinkronisasi penuh	Operasi INSERT konkuren selama sinkronisasi data penuh menyebabkan fragmentasi tabel. Ruang tabel tujuan akan lebih besar daripada sumber.
Kegagalan DDL	Jika pernyataan DDL gagal di database tujuan, tugas tetap berlanjut. Periksa log tugas untuk melihat pernyataan DDL yang gagal.
SLA dukungan teknis DTS	Jika tugas DTS gagal berjalan, dukungan teknis DTS akan mencoba memulihkan tugas dalam waktu 8 jam. Selama pemulihan, tugas mungkin dimulai ulang dan parameter tugas mungkin dimodifikasi. Hanya parameter tugas yang dapat diubah — parameter database tidak diubah.

Catatan

Jika tujuannya adalah kluster AnalyticDB for MySQL, DTS hanya mendukung penulisan tipe data yang didukung secara native oleh AnalyticDB for MySQL. Ini mencakup tipe data dasar dan tipe data kompleks seperti ARRAY, MAP, dan JSON. Tipe data seperti MULTIVALUE tidak didukung.

Operasi SQL untuk sinkronisasi inkremental

Jenis operasi	Pernyataan yang didukung
DML	INSERT, UPDATE, DELETE
DDL	CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE, ADD COLUMN, DROP COLUMN

Saat DTS menulis pernyataan UPDATE ke AnalyticDB for MySQL V3.0, secara otomatis mengonversinya menjadi REPLACE INTO. Jika pernyataan UPDATE memengaruhi kunci primer, DTS mengonversinya menjadi DELETE diikuti INSERT.

Penagihan

Jenis sinkronisasi	Biaya
Sinkronisasi skema dan sinkronisasi data penuh	Gratis
Sinkronisasi data inkremental	Dikenai biaya. Lihat Ikhtisar penagihan.

Prasyarat

Sebelum memulai, pastikan Anda telah:

Kluster AnalyticDB for MySQL V3.0 dengan penyimpanan tersedia lebih besar dari ukuran total data database TiDB Anda. Lihat Buat kluster
Kluster Kafka atau instans ApsaraMQ for Kafka yang telah diterapkan dan dapat diakses dari server TiDB
Izin akun database yang diperlukan (lihat Izin yang diperlukan)

Izin yang diperlukan

Database	Izin yang diperlukan	Referensi
TiDB	SELECT pada objek yang akan disinkronkan, SHOW VIEW	Privilege Management
AnalyticDB for MySQL V3.0	Izin baca dan tulis pada database tujuan	Buat akun database

Siapkan tangkapan data inkremental

DTS memerlukan event perubahan inkremental dari TiDB dipublikasikan ke topik Kafka. Pilih salah satu metode berikut.

Pilih metode

	TiDB Binlog	TiCDC
Komponen	Pump + Drainer	TiCDC (dikelola melalui TiUP)
Format output	Format binlog TiDB default	Format Canal-JSON
Paling cocok untuk	Implementasi TiDB Binlog yang sudah ada	Pengaturan baru dan TiDB v4.0+
Pengaturan DTS	Gunakan format binlog default database TiDB	Gunakan format TiCDC Canal-JSON

Siapkan kluster Kafka

Kedua metode memerlukan kluster Kafka. Gunakan salah satu berikut:

Kluster Kafka yang dikelola sendiri: Terapkan Apache Kafka. Lihat Dokumentasi Apache Kafka
Instans ApsaraMQ for Kafka: Buat instans. Lihat Ikhtisar memulai

Apa pun opsi yang Anda pilih:

Terapkan kluster Kafka di jaringan atau virtual private cloud (VPC) yang sama dengan server TiDB untuk meminimalkan latensi jaringan.
Atur parameter broker Kafka message.max.bytes dan replica.fetch.max.bytes ke nilai besar, dan atur parameter konsumen fetch.message.max.bytes ke nilai besar yang sesuai. Ini memastikan kluster dapat menangani volume data log biner dari TiDB. Lihat Referensi konfigurasi Kafka.

Setelah menyiapkan Kluster, buat topik dengan exactly one partition. DTS hanya membaca dari partisi 0, sehingga penggunaan beberapa partisi dapat menyebabkan kehilangan data.

Opsi 1: TiDB Binlog

Terapkan Pump dan Drainer di server dalam jaringan internal yang sama dengan TiDB. Lihat Penerapan kluster TiDB Binlog.
Edit file konfigurasi Drainer agar mengarah ke kluster Kafka Anda sebagai sink downstream. Lihat Panduan pengguna Binlog Consumer Client. Verifikasi bahwa server TiDB dapat terhubung ke kluster Kafka sebelum melanjutkan.
Tambahkan blok CIDR server DTS ke daftar izin database TiDB. Lihat Tambahkan blok CIDR server DTS.

Opsi 2: TiCDC

Instal TiCDC menggunakan TiUP. Tambahkan node TiCDC baru atau scale out node yang ada di kluster TiDB. Lihat Terapkan dan kelola TiCDC.
Buat changefeed untuk mereplikasi data inkremental dari TiDB ke kluster Kafka Anda. Gunakan tiup cdc cli changefeed create dan tentukan URI sink Canal-JSON. Lihat Replikasi data ke KafkaSinkronisasi data ke Kafka. Verifikasi bahwa server TiDB dapat terhubung ke kluster Kafka sebelum melanjutkan.

Buat tugas sinkronisasi data

Langkah 1: Buka halaman Sinkronisasi Data

Gunakan konsol DTS atau konsol DMS.

Konsol DTS

Masuk ke Konsol DTS.Konsol DTS
Di panel navigasi kiri, klik Data Synchronization.
Di pojok kiri atas, pilih wilayah tempat instans sinkronisasi akan berada.

Konsol DMS

Langkah-langkah dapat berbeda tergantung tata letak konsol DMS. Lihat Mode simple dan Sesuaikan tata letak dan gaya konsol DMS.

Masuk ke Konsol DMS.Konsol DMS
Di bilah navigasi atas, arahkan pointer ke Data + AI lalu pilih DTS (DTS) > Data Synchronization.
Dari daftar drop-down di sebelah kanan Data Synchronization Tasks, pilih wilayah tempat instans sinkronisasi akan berada.

Langkah 2: Konfigurasi database sumber dan tujuan

Klik Create Task, lalu konfigurasikan parameter berikut.

Database sumber

Parameter	Deskripsi
Task Name	Nama untuk tugas DTS. DTS menghasilkan nama secara otomatis. Tentukan nama deskriptif agar mudah diidentifikasi. Nama tidak perlu unik.
Select a DMS database instance	Pilih database yang telah terdaftar, atau biarkan kosong dan isi parameter di bawah ini. Untuk mendaftarkan database: di konsol DMS, klik Add DMS Database Instance; di konsol DTS, gunakan halaman Database Connections. Lihat Daftarkan instans database Alibaba Cloud dan Daftarkan database yang di-host di layanan cloud pihak ketiga atau database yang dikelola sendiri.
Database Type	Pilih TiDB.
Access Method	Pilih metode akses yang sesuai dengan tempat TiDB diterapkan. Contoh ini menggunakan Self-managed Database on ECS. Untuk metode akses lain, siapkan lingkungan yang diperlukan terlebih dahulu. Lihat Ikhtisar persiapan.
Instance Region	Wilayah tempat TiDB berada.
ECS Instance ID	ID instans ECS yang menjalankan TiDB.
Port Number	Port layanan TiDB. Default: 4000.
Database Account	Akun TiDB dengan izin yang diperlukan.
Database Password	Kata sandi untuk akun TiDB.
Migrate Incremental Data	Selalu atur ke Yespengaturan pemberitahuan peringatan. Ini tidak dapat diubah. Untuk menyinkronkan tanpa data inkremental, buat tugas migrasi data. Lihat Migrasi data dari database TiDB yang dikelola sendiri ke kluster AnalyticDB for MySQL V3.0.
Kafka Cluster Type	Pilih metode akses yang sesuai dengan tempat kluster Kafka Anda diterapkan. Contoh ini menggunakan Self-managed Database on ECS. Jika Anda memilih Express Connect, VPN Gateway, or Smart Access Gateway, pilih juga VPC dari Connected VPC dan tentukan Domain Name or IP.
Kafka Data Source Component	Pilih Use the default binlog format of the TiDB database (untuk TiDB Binlog) atau Use the TiCDC Canal-JSON format (untuk TiCDC), berdasarkan yang Anda siapkan di Siapkan tangkapan data inkremental.
ECS Instance ID	ID instans ECS tempat kluster Kafka diterapkan.
Port Number	Port layanan Kafka.
Kafka Cluster Account / Kafka Cluster Password	Username dan password Kafka. Biarkan kosong jika autentikasi tidak diaktifkan.
Kafka Version	Versi Kafka. Jika versinya 1.0 atau lebih baru, pilih 1.0.
Encryption	Pilih Non-encrypted atau SCRAM-SHA-256 berdasarkan kebutuhan keamanan Anda.
Topic	Topik Kafka yang menerima data inkremental dari TiDB.

Database tujuan

Parameter	Deskripsi
Select a DMS database instance	Pilih database terdaftar yang sudah ada, atau biarkan kosong dan isi parameter di bawah.
Database Type	Pilih AnalyticDB for MySQL 3.0.
Access Method	Pilih Alibaba Cloud Instance.
Instance Region	Wilayah tempat kluster AnalyticDB for MySQL V3.0 berada.
Instance ID	ID kluster AnalyticDB for MySQL V3.0 tujuan.
Database Account	Akun database dengan izin baca dan tulis.
Database Password	Kata sandi untuk akun database.

Langkah 3: Uji konektivitas

Klik Test Connectivity and Proceed. Di kotak dialog CIDR Blocks of DTS Servers, klik Test Connectivity.

Jika blok CIDR server DTS belum ditambahkan ke pengaturan keamanan database Anda, tambahkan sebelum melanjutkan. Lihat Tambahkan blok CIDR server DTS.

Langkah 4: Konfigurasi objek yang akan disinkronkan

Pada langkah Configure Objects, atur parameter berikut.

Parameter	Deskripsi
Synchronization Types	Pilih Schema Synchronization, Full Data Synchronization, dan Incremental Data Synchronization. Ketiganya wajib. Incremental Data Synchronization dipilih secara default; Anda juga harus memilih dua lainnya. Sinkronisasi data penuh menyediakan garis dasar data historis untuk sinkronisasi inkremental.
Processing Mode of Conflicting Tables	Precheck and Report Errors (default): gagal precheck jika tabel dengan nama identik ada di tujuan. Gunakan pemetaan nama objek untuk menyelesaikan konflik tanpa menghapus tabel tujuan. Lihat Pemetaan nama objek. Ignore Errors and Proceed: lewati precheck untuk nama tabel identik. Selama sinkronisasi penuh, catatan tujuan yang ada dipertahankan. Selama sinkronisasi inkremental, catatan tujuan ditimpa. Gunakan dengan hati-hati — ini dapat menyebabkan ketidakkonsistenan data.
Capitalization of Object Names in Destination Instance	Mengontrol kapitalisasi nama database, tabel, dan kolom di tujuan. Default: DTS default policy. Lihat Tentukan kapitalisasi nama objek di instans tujuan.
Source Objects	Pilih database atau tabel yang akan disinkronkan dan klik ikon panah untuk memindahkannya ke Selected Objects.
Selected Objects	Untuk mengganti nama objek di tujuan, klik kanan dan gunakan pemetaan nama objek. Untuk mengganti nama beberapa objek sekaligus, klik Batch Edit. Untuk memfilter baris dengan kondisi SQL WHERE, klik kanan tabel dan tentukan kondisi. Lihat Tentukan kondisi filter. Mengganti nama objek dapat merusak objek dependen.

Langkah 5: Konfigurasi pengaturan lanjutan

Klik Next: Advanced Settings dan konfigurasikan berikut.

Parameter	Deskripsi
Retry Time for Failed Connections	Berapa lama DTS mencoba ulang koneksi yang gagal setelah tugas dimulai. Rentang: 10–1440 menit. Default: 720 menit. Atur lebih dari 30 menit. Jika beberapa tugas berbagi database sumber atau tujuan yang sama, waktu retry terpendek yang berlaku.
Retry Time for Other Issues	Berapa lama DTS mencoba ulang operasi DDL atau DML yang gagal. Rentang: 1–1440 menit. Default: 10 menit. Atur lebih dari 10 menit. Nilai ini harus kurang dari Retry Time for Failed Connections.
Enable Throttling for Full Data Synchronization	Membatasi beban baca dan tulis selama sinkronisasi data penuh. Konfigurasikan QPS (queries per second) to the source database, RPS of Full Data Migration, dan Data migration speed for full migration (MB/s). Tersedia hanya jika Full Data Synchronization dipilih.
Enable Throttling for Incremental Data Synchronization	Membatasi beban tulis selama sinkronisasi data inkremental. Konfigurasikan RPS of Incremental Data Synchronization dan Data synchronization speed for incremental synchronization (MB/s).
Environment Tag	Tag opsional untuk mengidentifikasi instans DTS berdasarkan lingkungan (misalnya, produksi atau uji).
Configure ETL	Pilih Yes untuk mengaktifkan extract, transform, and load (ETL) dan masukkan pernyataan pemrosesan data. Pilih No untuk melewati. Lihat Apa itu ETL?
Monitoring and Alerting	Pilih Yes untuk mengonfigurasi peringatan untuk kegagalan tugas atau pelanggaran ambang batas latensi. Konfigurasikan ambang batas peringatan dan pengaturan notifikasi. Lihat Konfigurasi pemantauan dan peringatan.

Langkah 6: Konfigurasi verifikasi data (opsional)

Klik Next Step: Data Verification untuk menyiapkan verifikasi data. Untuk informasi selengkapnya, lihat Mengonfigurasi tugas verifikasi data.

Langkah 7: Konfigurasi bidang database dan tabel (opsional)

Klik Next: Configure Database and Table Fields untuk mengonfigurasi pengaturan khusus AnalyticDB for MySQL V3.0 untuk setiap tabel.

Langkah ini hanya tersedia jika Schema Synchronization dipilih. Atur Definition Status ke All untuk melihat dan memodifikasi semua tabel.

Parameter	Deskripsi
Type	Jenis tabel di AnalyticDB for MySQL V3.0.
Primary Key Column	Kolom kunci primer untuk tabel. Mendukung kunci primer komposit.
Distribution Key	Kunci distribusi untuk tabel. Harus berupa satu atau lebih kolom kunci primer.
Partition Key / Partitioning Rules / Partition Lifecycle	Pengaturan partisi untuk tabel. Lihat CREATE TABLE.

Langkah 8: Simpan tugas dan jalankan pemeriksaan awal

Untuk melihat pratinjau parameter API untuk konfigurasi tugas ini, arahkan pointer ke Next: Save Task Settings and Precheck lalu klik Preview OpenAPI parameters.
Klik Next: Save Task Settings and Precheck untuk menyimpan dan memulai pemeriksaan awal.

Jika pemeriksaan awal gagal:

Klik View Details di sebelah setiap item yang gagal, perbaiki masalahnya, lalu jalankan pemeriksaan awal lagi.
Jika suatu item menampilkan peringatan yang dapat diabaikan, klik Confirm Alert Details, lalu Ignore, lalu OK, dan kemudian Precheck Again. Mengabaikan peringatan dapat menyebabkan ketidakkonsistenan data.

Langkah 9: Beli instans

Tunggu hingga Success Rate mencapai 100%, lalu klik Next: Purchase Instance.
Di halaman pembelian, konfigurasikan berikut.

Parameter	Deskripsi
Billing Method	Subscription: bayar di muka untuk jangka waktu tetap. Lebih hemat biaya untuk penggunaan jangka panjang. Pay-as-you-go: ditagih per jam. Cocok untuk penggunaan jangka pendek. Lepaskan instans saat tidak diperlukan lagi untuk menghindari biaya berlebihan.
Resource Group Settings	Kelompok sumber daya untuk instans sinkronisasi. Default: default resource group. Lihat Apa itu Resource Management?
Instance Class	Tier kecepatan sinkronisasi. Lihat Kelas instans untuk instansi sinkronisasi data.
Subscription Duration	Tersedia untuk metode penagihan subscription. Opsi: 1–9 bulan, 1 tahun, 2 tahun, 3 tahun, atau 5 tahun.

Baca dan pilih Data Transmission Service (Pay-as-you-go) Service Terms.
Klik Buy and Start, lalu klik OK di kotak dialog konfirmasi.

Tugas muncul di daftar tugas. Pantau perkembangannya di sana.

Data Transmission Service:Sinkronisasi data dari database TiDB yang dikelola sendiri ke kluster AnalyticDB for MySQL V3.0