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 menuliskan data tersebut ke AnalyticDB for MySQL V3.0. Alur lengkapnya adalah:
TiDB → kluster Kafka → 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 sebagai gantinya. |
| Penyiapan Kafka wajib | 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
| Batas | 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 default ini sesuai dengan kebutuhan Anda. |
| 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 inkonsistensi data. |
| Pelanjutan tugas gagal | DTS secara otomatis mencoba ulang tugas yang gagal hingga 7 hari. Sebelum beralih beban kerja ke kluster tujuan, hentikan atau lepaskan 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, ketika 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. |
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, pernyataan tersebut secara otomatis dikonversi menjadi REPLACE INTO. Jika pernyataan UPDATE memengaruhi kunci primer, DTS mengonversinya menjadi DELETE diikuti oleh 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 instance 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 | Manajemen Hak Istimewa |
| 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 log biner TiDB default | Format Canal-JSON |
| Cocok untuk | Penerapan TiDB Binlog yang sudah ada | Pengaturan baru dan TiDB v4.0+ |
| Pengaturan DTS | Gunakan format log biner default database TiDB | Gunakan format TiCDC Canal-JSON |
Siapkan kluster Kafka
Kedua metode memerlukan kluster Kafka. Gunakan salah satu opsi berikut:
Kluster Kafka yang dikelola sendiri: Terapkan Apache Kafka. Lihat Dokumentasi Apache Kafka
Instance ApsaraMQ for Kafka: Buat instance. Lihat Ikhtisar memulai
Terlepas dari 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.bytesdanreplica.fetch.max.byteske nilai besar, dan atur parameter konsumenfetch.message.max.byteske 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 beberapa partisi akan menyebabkan kehilangan data.
Opsi 1: TiDB Binlog
Terapkan Pump dan Drainer pada server di 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 sudah 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 createdan 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 untuk memudahkan identifikasi. 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 Mendaftarkan instans database Alibaba Cloud dan Mendaftarkan database yang dihosting 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 instance 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 sebagai gantinya. 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 instance ECS tempat kluster Kafka diterapkan. |
| Port Number | Port layanan Kafka. |
| Kafka Cluster Account / Kafka Cluster Password | Username dan kata sandi Kafka. Biarkan kosong jika autentikasi tidak diaktifkan. |
| Kafka Version | Versi Kafka. Jika versi 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 DTS belum ditambahkan ke pengaturan keamanan database Anda, tambahkan terlebih dahulu sebelum melanjutkan. Lihat Tambahkan blok CIDR server DTS.
Langkah 4: Konfigurasi objek untuk 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 dalam pemeriksaan awal 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: melewati pemeriksaan awal untuk nama tabel identik. Selama sinkronisasi penuh, catatan tujuan yang sudah ada dipertahankan. Selama sinkronisasi inkremental, catatan tujuan ditimpa. Gunakan dengan hati-hati — ini dapat menyebabkan inkonsistensi 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 untuk disinkronkan dan klik ikon panah untuk memindahkannya ke Selected Objects. |
| Selected Objects | Untuk mengganti nama objek di tujuan, klik kanan objek tersebut dan gunakan pemetaan nama objek. Untuk mengganti nama beberapa objek sekaligus, klik Batch Edit. Untuk memfilter baris dengan kondisi WHERE SQL, 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 hal berikut.
| Parameter | Deskripsi |
|---|---|
| Retry Time for Failed Connections | Berapa lama DTS mencoba ulang koneksi yang gagal setelah tugas dimulai. Rentang: 10–1.440 menit. Default: 720 menit. Atur lebih dari 30 menit. Jika beberapa tugas berbagi database sumber atau tujuan yang sama, waktu coba ulang terpendek yang berlaku. |
| Retry Time for Other Issues | Berapa lama DTS mencoba ulang operasi DDL atau DML yang gagal. Rentang: 1–1.440 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 ekstrak, transformasi, muat (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. Lihat Konfigurasi 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 inkonsistensi data.
Langkah 9: Beli instans
Tunggu hingga Success Rate mencapai 100%, lalu klik Next: Purchase Instance.
Di halaman pembelian, konfigurasikan hal 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 Manajemen Sumber Daya? |
| Instance Class | Tier kecepatan sinkronisasi. Lihat Kelas instans 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.