Topik ini menjelaskan arsitektur Data Transmission Service (DTS) dan cara kerjanya dalam setiap mode replikasi.
Arstitektur DTS
Deskripsi Arsitektur
Redundansi Utama/Cadangan
Setiap modul DTS ditempatkan pada server dengan redundansi utama/cadangan. Manajer HA secara terus-menerus memeriksa kesehatan setiap server. Jika terjadi pengecualian pada sebuah server, beban kerja dari server tersebut dipindahkan ke server sehat dengan latensi minimal.
Pendeteksian Perubahan Titik Akhir
Untuk replikasi data kontinu, seperti sinkronisasi data dan pelacakan perubahan, manajer HA mendeteksi perubahan titik akhir sumber data. Jika titik akhir suatu instance berubah, manajer HA mengonfigurasi ulang sumber data untuk memastikan koneksi tetap stabil.
Cara kerja DTS dalam mode migrasi data
Proses migrasi data lengkap terdiri dari tiga fase: migrasi skema, migrasi data penuh, dan migrasi data tambahan. Untuk menjaga agar database sumber tetap beroperasi selama migrasi data, Anda harus memilih semua fase saat mengonfigurasi tugas migrasi data.
Migrasi Skema: Sebelum data dimigrasikan, DTS membuat ulang skema di database tujuan. Untuk migrasi data antar database heterogen, DTS menguraikan kode DDL dari database sumber dan menerjemahkannya ke dalam sintaks database tujuan. Kemudian, DTS membuat ulang objek skema di database tujuan.
Migrasi Data Penuh: DTS memigrasikan data historis dari database sumber ke database tujuan. Database sumber dapat tetap beroperasi, dan pembaruan data di database sumber tidak berhenti selama proses ini. DTS menggunakan pembaca data tambahan untuk menangkap pembaruan data yang sedang berlangsung selama fase migrasi data penuh. Pembacaan data tambahan diaktifkan ketika migrasi data penuh dimulai. Selama migrasi data penuh, data tambahan diuraikan, diformat ulang, dan disimpan secara lokal di server DTS.
Migrasi Data Tambahan: Setelah migrasi data penuh selesai, DTS mengambil data tambahan yang disimpan secara lokal di server DTS, memformat ulang, dan memigrasikannya ke database tujuan. Proses ini berlanjut hingga semua perubahan data yang sedang berlangsung direplikasi ke database tujuan dan database tujuan selaras dengan database sumber.
Cara kerja DTS dalam mode sinkronisasi data
Dalam mode sinkronisasi data, DTS mereplikasi perubahan data yang sedang berlangsung antara dua penyimpanan data. Mode ini biasanya digunakan untuk replikasi OLTP-ke-OLAP. OLTP adalah singkatan dari pemrosesan transaksi online, sedangkan OLAP adalah singkatan dari pemrosesan analitik online. Tugas sinkronisasi data terdiri dari fase-fase berikut:
Sinkronisasi Data Awal: DTS menyinkronkan data historis dari database sumber ke database tujuan.
Sinkronisasi Data Waktu Nyata: DTS menyinkronkan perubahan data yang sedang berlangsung dan menjaga agar database tujuan tetap selaras dengan database sumber.
Untuk menyinkronkan perubahan data yang sedang berlangsung, DTS menggunakan dua komponen yang bekerja dengan log transaksi:
Pembaca Log Transaksi: Pembaca log transaksi memperoleh data dari instance sumber. Setelah penguraian, penyaringan, dan konversi sintaks, data disimpan secara lokal di server DTS. Pembaca log transaksi terhubung ke instance sumber melalui protokol yang sesuai dan membaca log tentang data tambahan dari instance sumber. Misalnya, pembaca ini terhubung ke instance ApsaraDB RDS for MySQL melalui protokol binlog dump.
Penerapan Log Transaksi: Penerapan log transaksi mengambil pembaruan data dari pembaca log transaksi, menyaring pembaruan yang tidak terkait dengan objek yang direplikasi, dan menerapkan pembaruan yang telah disaring ke database tujuan. Dalam proses ini, penerapan log transaksi mempertahankan properti atomicity, consistency, isolation, dan durability (ACID) dari transaksi. Baik pembaca log transaksi maupun penerapan log transaksi ditempatkan dalam mode redundansi. Manajer HA memeriksa kondisi kesehatan setiap server. Jika terjadi pengecualian, eksekusi log transaksi dilanjutkan pada server sehat.
Cara kerja DTS dalam mode pelacakan perubahan
Mode pelacakan perubahan memungkinkan Anda memperoleh log tentang data tambahan dari instance ApsaraDB RDS secara real-time. Anda dapat melacak log pada server pelacakan perubahan menggunakan SDK DTS. Anda juga dapat menyesuaikan aturan konsumsi data berdasarkan kebutuhan Anda.
Prosesor log memperoleh data dari database sumber. Setelah penguraian, penyaringan, dan konversi sintaks, data disimpan secara lokal di server DTS.
Prosesor log terhubung ke instance sumber melalui protokol yang sesuai dan membaca log tentang data tambahan dari instance sumber. Misalnya, prosesor log ini terhubung ke instance ApsaraDB RDS for MySQL melalui protokol binlog dump.
DTS memastikan ketersediaan tinggi prosesor log dan proses konsumsi berbasis SDK.
Untuk memastikan ketersediaan tinggi prosesor log, manajer HA memulai ulang prosesor log pada node layanan sehat ketika terdeteksi adanya pengecualian pada prosesor log.
Untuk memastikan ketersediaan tinggi proses konsumsi berbasis SDK di server, DTS memungkinkan Anda memulai beberapa proses konsumsi berbasis SDK untuk satu tugas pelacakan perubahan. Server mendorong data tambahan menggunakan satu proses pada satu waktu. Jika terjadi pengecualian dalam suatu proses, server mendorong data tambahan menggunakan proses konsumsi lainnya.