Data Transmission Service (DTS) menggunakan arsitektur modular berbasis high availability (HA). Setiap modul berjalan pada server dengan redundansi primary/secondary. HA manager terus-menerus melakukan health check terhadap setiap server dan, ketika mendeteksi pengecualian, segera memindahkan beban kerja ke server yang sehat dengan latensi minimal. Untuk replikasi berkelanjutan—yaitu data synchronization dan change tracking—HA manager juga mendeteksi perubahan endpoint pada sumber data dan secara otomatis mengonfigurasi ulang koneksi.
- Primary/secondary redundancy
Setiap modul DTS diterapkan dalam arsitektur primary/secondary untuk redundansi. Sistem disaster recovery terus-menerus melakukan health check terhadap setiap server. Jika suatu server gagal, beban kerjanya dipindahkan ke server yang sehat dengan latensi minimal.
- Dynamic endpoint detection
Untuk tugas data synchronization dan change tracking, sistem disaster recovery mendeteksi perubahan pada endpoint sumber data. Jika terdeteksi perubahan endpoint, sistem disaster recovery mengonfigurasi ulang sumber data untuk memastikan koneksi tetap stabil.
Cara kerja DTS dalam mode migrasi data
Migrasi data lengkap berjalan melalui tiga fase berurutan: schema migration, full data migration, dan incremental data migration. Pilih ketiga fase tersebut saat mengonfigurasi tugas migrasi data—hal ini memungkinkan database sumber tetap beroperasi selama proses berlangsung.
Schema migration: DTS membuat ulang skema di database tujuan sebelum data dipindahkan. Untuk migrasi antar database heterogen, DTS mengurai DDL (Data Definition Language) dari database sumber, menerjemahkannya ke sintaksis database tujuan, lalu membuat ulang objek skema tersebut.
Full data migration: DTS memindahkan data historis dari sumber ke tujuan. Database sumber tetap online dan terus menerima operasi write selama fase ini. Untuk menangkap operasi write yang sedang berlangsung, DTS mengaktifkan incremental data reader pada awal full data migration. Data inkremental diurai, diformat ulang, dan disimpan secara lokal di server DTS selama migrasi penuh berjalan.
Incremental data migration: Setelah full data migration selesai, DTS mengambil data inkremental yang tersimpan secara lokal dan menerapkannya ke tujuan. Fase ini berlanjut hingga tujuan tersinkronisasi dengan sumber dan lag replikasi mencapai kondisi stabil.
Cara kerja DTS dalam mode sinkronisasi data
Mode sinkronisasi data mereplikasi perubahan data berkelanjutan antara dua penyimpanan data. Mode ini umum digunakan untuk replikasi OLTP-to-OLAP, di mana OLTP (online transaction processing) menangani beban kerja transaksional dan OLAP (online analytical processing) menangani kueri analitis.
Tugas sinkronisasi data menjalankan dua fase secara berurutan:
Initial data synchronization: DTS menyinkronkan data historis dari sumber ke tujuan.
Real-time data synchronization: DTS terus-menerus mereplikasi perubahan data berkelanjutan agar tujuan tetap tersinkronisasi dengan sumber.
Dua komponen menangani replikasi berkelanjutan tersebut:
Transaction log reader: Terhubung ke instans sumber melalui protokol yang sesuai—misalnya, melalui protokol binlog dump untuk instans ApsaraDB RDS for MySQL. Komponen ini membaca log inkremental, lalu mengurai, memfilter, dan mengonversi data sebelum menyimpannya secara lokal di server DTS.
Transaction log applier: Mengambil pembaruan dari transaction log reader, memfilter perubahan yang tidak terkait dengan objek yang direplikasi, lalu menerapkan perubahan yang tersisa ke database tujuan. Applier mempertahankan properti atomicity, consistency, isolation, dan durability (ACID) dari setiap transaksi.
Kedua komponen berjalan dalam mode redundansi. Jika terjadi pengecualian pada salah satu komponen, HA manager melanjutkan eksekusi log transaksi pada server yang sehat.
Cara kerja DTS dalam mode pelacakan perubahan
Mode change tracking memberikan akses real-time ke log data inkremental dari instans ApsaraDB RDS. Konsumsi log tersebut pada server change tracking menggunakan SDK DTS, dan Anda dapat menentukan aturan konsumsi data kustom sesuai kebutuhan.
Log processor terhubung ke instans sumber melalui protokol yang sesuai—misalnya, melalui protokol binlog dump untuk instans ApsaraDB RDS for MySQL. Komponen ini membaca log inkremental, lalu mengurai, memfilter, dan mengonversi sintaksis sebelum menyimpan data secara lokal di server DTS.
DTS menjamin high availability pada dua tingkat:
Log processor HA: Ketika HA manager mendeteksi pengecualian pada log processor, sistem me-restart log processor pada node layanan yang sehat.
SDK consumption HA: Jalankan beberapa proses konsumsi berbasis SDK untuk satu tugas change tracking. Server mendorong data inkremental melalui satu proses dalam satu waktu. Jika proses tersebut mengalami pengecualian, server secara otomatis beralih ke proses konsumsi lainnya.