Database Migration Service (DMS) dan Schema Conversion Tool

AWS Database Migration Service (DMS) memigrasikan basis data ke AWS dengan waktu henti minimal. DMS mendukung migrasi homogen (misalnya, Oracle ke Oracle, MySQL ke MySQL) dan migrasi heterogen (misalnya, Oracle ke Aurora PostgreSQL, SQL Server ke MySQL). DMS menggunakan instans replikasi yang membaca dari sumber, secara opsional mengubah data, lalu menulisnya ke target. Anda hanya membayar waktu aktif instans replikasi.

DMS memiliki tiga komponen utama. Source Endpoints menentukan koneksi ke basis data sumber (URL JDBC, kredensial, TLS). Target Endpoints menentukan basis data tujuan. Replication Instance adalah server terkelola berbasis EC2 yang disediakan DMS di VPC Anda untuk menjalankan beban kerja migrasi. Pilih ukuran instans replikasi berdasarkan jumlah data yang perlu dimigrasikan dan apakah Anda ingin menggunakan multi-AZ untuk instans replikasi itu sendiri.

DMS mendukung dua mode migrasi. Full Load menyalin semua data yang ada dari sumber ke target—cocok jika Anda dapat menerima waktu henti atau sumber bersifat hanya-baca selama migrasi. Change Data Capture (CDC) menangkap perubahan berkelanjutan dari log transaksi sumber setelah Full Load selesai, sehingga sumber dan target tetap sinkron. Migrasi gabungan Full Load + CDC meminimalkan waktu henti: migrasikan data saat sumber tetap aktif, lalu lakukan peralihan ketika target sudah menyusul.

AWS Schema Conversion Tool (SCT) adalah aplikasi gratis yang dapat diunduh dan secara otomatis mengonversi skema basis data sumber (DDL) ke format yang kompatibel dengan mesin basis data target. SCT menangani definisi Table, View, prosedur tersimpan, fungsi, dan pemicu. Untuk migrasi heterogen (misalnya, Oracle ke PostgreSQL), SCT mengonversi sebagian besar objek secara otomatis dan menandai item yang memerlukan peninjauan manual karena perbedaan sintaks yang tidak didukung.

Untuk migrasi homogen (mesin yang sama, misalnya MySQL lokal ke RDS for MySQL), SCT biasanya tidak diperlukan karena skemanya kompatibel secara langsung. DMS dapat segera menjalankan Full Load + CDC. Untuk migrasi heterogen (mesin yang berbeda), SCT harus mengonversi skema terlebih dahulu, DMS menangani migrasi data, dan Anda mungkin perlu menulis ulang secara manual prosedur tersimpan serta pemicu yang tidak memiliki padanan pada mesin target.

DMS mendukung berbagai sumber: Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, SAP ASE, MongoDB, IBM Db2, dan S3. Target yang didukung mencakup semua layanan di atas serta Amazon Redshift, DynamoDB, Kinesis Data Streams, dan Kafka. Hal ini membuat DMS berguna bukan hanya untuk migrasi relasional, tetapi juga untuk mengalirkan peristiwa perubahan relasional ke data lake atau arsitektur berbasis peristiwa menggunakan CDC ke Kinesis.

DMS menggunakan aturan pemetaan Table (JSON) untuk mengontrol skema dan Table mana yang disertakan atau dikecualikan, serta untuk menerapkan transformasi data. Anda dapat mengganti nama skema atau Table, mengonversi nilai kolom (misalnya, mengubah semua String menjadi huruf besar), menambahkan kolom turunan, atau memfilter baris. Ini berguna saat melakukan migrasi ke target dengan konvensi penamaan yang berbeda atau saat Anda hanya ingin memigrasikan sebagian Table.

DMS memublikasikan metrik ke CloudWatch: FullLoadThroughputRowsSource (baris per detik yang dimuat), CDCLatencySource (kesenjangan antara log transaksi sumber dan saat DMS membacanya), serta CDCLatencyTarget (kesenjangan antara saat DMS membaca dan menulis ke target). Pantau CDCLatencyTarget dengan saksama selama fase sinkronisasi—ketika nilainya turun mendekati nol, target telah menyusul sumber dan Anda siap melakukan peralihan.

DMS Serverless secara otomatis menyediakan dan menskalakan kapasitas replikasi berdasarkan beban kerja migrasi, sehingga Anda tidak perlu memilih dan mengelola ukuran instans replikasi. Anda menentukan unit kapasitas DMS minimum dan maksimum (DCU), lalu DMS melakukan penskalaan otomatis dalam rentang tersebut. Fitur ini ideal untuk migrasi dengan beban yang berubah-ubah atau ketika Anda ingin menghindari risiko ukuran instans replikasi yang terlalu kecil saat beban migrasi mencapai puncaknya.

Setelah migrasi, validasi kelengkapan data menggunakan Data Validation DMS. Aktifkan fitur ini di pengaturan tugas, lalu DMS membandingkan jumlah baris dan checksum antara Table sumber dan target serta melaporkan ketidaksesuaian ke Table validasi terpisah. Untuk migrasi heterogen, jalankan juga pengujian awal pada tingkat aplikasi. Jangan pernah melakukan peralihan sebelum validasi menunjukkan tidak ada perbedaan—menyelaraskan data setelah peralihan yang bermasalah jauh lebih mahal daripada meluangkan waktu tambahan untuk melakukan validasi.

Dalam ujian SAA-C03, DMS muncul dalam skenario yang memerlukan migrasi basis data dengan waktu henti minimal. Petunjuk utamanya: 'migrasikan basis data dengan replikasi berkelanjutan' → DMS Full Load + CDC. 'perubahan mesin heterogen' → SCT terlebih dahulu, kemudian DMS. 'replikasi perubahan hampir secara waktu nyata ke data lake' → DMS CDC ke Kinesis atau S3. 'konsolidasikan beberapa basis data sumber ke satu target' → beberapa tugas DMS ke satu endpoint target. DMS secara khusus ditujukan untuk migrasi basis data—untuk migrasi server gunakan MGN, sedangkan untuk transfer data massal gunakan DataSync atau Snowball.

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari bahwa DMS mendukung migrasi basis data homogen dan heterogen menggunakan mode Full Load dan CDC, SCT mengotomatiskan konversi skema untuk migrasi yang mengubah mesin serta menandai item yang memerlukan peninjauan manual, dan DMS Serverless melakukan penskalaan otomatis kapasitas replikasi sehingga keputusan tentang ukuran instans tidak diperlukan. Selanjutnya, kita akan membahas Amazon EventBridge untuk perutean berbasis peristiwa dan arsitektur bus.