ApsaraDB for MongoDB:Migrasi\\ data\\ dari\\ database\\ MongoDB\\ yang\\ dikelola\\ sendiri\\ \\(arsitektur\\ kluster\\ sharded\\)\\ ke\\ instans\\ ApsaraDB\\ for\\ MongoDB\\ \\(arsitektur\\ set\\ replika\\ atau\\ kluster\\ sharded\\)

Batasan database sumber

• Server harus memiliki bandwidth outbound yang mencukupi. Bandwidth yang tidak mencukupi akan memperlambat proses migrasi.

• Koleksi yang akan dimigrasikan harus memiliki PRIMARY KEY atau kendala UNIQUE, dengan semua bidang bernilai unik. Jika tidak, catatan duplikat dapat muncul di tujuan.

• DTS menggunakan sumber daya baca dan tulis pada database sumber dan tujuan selama migrasi data penuh, sehingga meningkatkan beban server. Jalankan migrasi pada jam sepi.

• Jika database sumber dan tujuan menggunakan versi MongoDB atau mesin penyimpanan yang berbeda, verifikasi kompatibilitas terlebih dahulu. Lihat Versi dan mesin penyimpanan MongoDB.

• Untuk migrasi data inkremental, aktifkan oplog pada database sumber dan simpan oplog minimal selama 7 hari. Jika oplog tidak diaktifkan, pesan error akan muncul saat pemeriksaan awal dan tugas migrasi data tidak dapat dimulai. Jika DTS tidak dapat memperoleh oplog, tugas akan gagal dan ketidakkonsistenan atau kehilangan data dapat terjadi. Persyaratan retensi ini berada di luar perjanjian tingkat layanan (SLA) DTS.

• Jika Anda memilih koleksi sebagai objek migrasi dan berencana mengeditnya di tujuan (misalnya mengganti nama), satu tugas mendukung maksimal 1.000 koleksi. Untuk lebih dari 1.000 koleksi, konfigurasikan beberapa tugas atau migrasikan seluruh database.

• Jangan gunakan database admin atau local sebagai sumber atau tujuan.

• Database MongoDB yang dikelola sendiri tidak boleh memiliki lebih dari 10 node mongos.

• Jangan migrasikan koleksi yang memiliki indeks time to live (TTL). Indeks TTL dapat menyebabkan ketidakkonsistenan data antara sumber dan tujuan setelah migrasi.

• Pastikan tidak ada dokumen yatim (orphaned documents) di database sumber atau instans kluster sharded tujuan. Dokumen yatim dapat menyebabkan ketidakkonsistenan data atau kegagalan tugas. Lihat dokumentasi MongoDB dan Bagaimana cara menghapus dokumen yatim dari database MongoDB yang diterapkan dalam arsitektur kluster sharded?.

Selama migrasi, jangan jalankan perintah berikut pada database sumber — perintah tersebut mengubah distribusi data dan menyebabkan ketidakkonsistenan:

• shardCollection, reshardCollection, unshardCollection, moveCollection, movePrimary

Selama migrasi skema dan migrasi data penuh:

• Jangan lakukan perubahan skema pada database atau koleksi, termasuk memperbarui tipe array. Perubahan skema menyebabkan kegagalan tugas atau ketidakkonsistenan data.

• Jangan menulis data ke database sumber jika Anda hanya menjalankan migrasi data penuh (tanpa inkremental). Untuk memastikan konsistensi data, pilih migrasi skema, migrasi data penuh, dan migrasi data inkremental secara bersamaan.

Jika balancer database sumber aktif selama migrasi, migrasi chunk dapat menyebabkan latensi.

Batasan lainnya

• Jika Anda membeli instans DTS sebelum mengonfigurasi tugas, tentukan jumlah shard pada saat pembelian.

• DTS tidak dapat terhubung ke database MongoDB melalui string koneksi SRV.

• Tambahkan shard key ke semua data di database sumber sebelum memulai migrasi. Selama migrasi, operasi INSERT harus menyertakan shard key, dan operasi UPDATE tidak boleh mengubah shard key.

• Nonaktifkan balancer untuk database MongoDB sumber selama migrasi data penuh. Biarkan nonaktif hingga setiap subtugas mencapai fase migrasi data inkremental. Mengaktifkannya kembali terlalu dini menyebabkan ketidakkonsistenan data. Lihat Kelola balancer ApsaraDB for MongoDB.

• Pastikan database tujuan tidak berisi dokumen yang memiliki primary key (_id) yang sama dengan sumber. Jika terdapat duplikat, hapus dokumen yang sesuai di tujuan sebelum memulai migrasi.

• Informasi transaksi tidak dipertahankan. Transaksi yang dimigrasikan diubah menjadi catatan individual.

• Jika terjadi konflik primary key atau unique key saat DTS menulis ke tujuan, DTS melewati penulisan yang konflik dan mempertahankan data yang sudah ada.

• Jangan melakukan scaling pada instans ApsaraDB for MongoDB kluster sharded selama tugas migrasi sedang berjalan. Scaling menyebabkan tugas gagal.

• Hitung jumlah hasil pada database ApsaraDB for MongoDB tujuan menggunakan db.$table_name.aggregate([{ $count:"myCount"}]).

• Karena DTS menulis data secara konkuren, ruang penyimpanan yang digunakan di tujuan 5–10% lebih besar daripada di sumber.

• Jika koleksi tujuan memiliki indeks unik atau atribut capped diatur ke true, koleksi tersebut hanya mendukung penulisan single-threaded dan tidak mendukung replay konkuren selama migrasi inkremental. Hal ini dapat meningkatkan latensi migrasi.

• Migrasi data penuh menggunakan sumber daya baca dan tulis pada kedua database, sehingga meningkatkan beban server. Jalankan migrasi pada jam sepi.

• Operasi INSERT konkuren selama migrasi data penuh menyebabkan fragmentasi tabel. Setelah migrasi data penuh, ruang tabel di tujuan lebih besar daripada di sumber.

• DTS mencoba melanjutkan tugas migrasi yang gagal hingga 7 hari. Sebelum beralih beban kerja ke instans tujuan, hentikan atau lepas tugas yang gagal, atau cabut izin tulis DTS pada tujuan. Jika tidak, data sumber akan menimpa data tujuan saat tugas yang gagal dilanjutkan kembali.

• Jika tugas DTS gagal, dukungan teknis DTS mencoba memulihkannya dalam waktu 8 jam. Selama pemulihan, tugas mungkin dimulai ulang dan parameter tugas mungkin dimodifikasi.

  Hanya parameter tugas yang mungkin dimodifikasi — parameter database tidak diubah. Parameter yang mungkin dimodifikasi tercantum di bagian Modifikasi parameter instans.

• Jika tujuannya adalah instans set replika:

  • Jika terhubung melalui Express Connect, VPN Gateway, Smart Access Gateway, alamat IP publik, atau Cloud Enterprise Network (CEN), atur Domain Name or IP dan Port Number.

    DTS memigrasikan seluruh kluster dengan memigrasikan setiap node shard satu per satu. Masukkan nama domain atau alamat IP node shard pertama di sini. Saat Anda membuat tugas migrasi kedua nanti, masukkan nama domain atau alamat IP node shard kedua. Ulangi proses ini hingga semua node shard dimigrasikan.

    Buat tugas DTS dengan database MongoDB berdaya tinggi sebagai sumber atau tujuan

  • Jika terhubung melalui Self-managed Database on ECS: atur Port Number ke port node primary.

• Jika tujuannya adalah instans kluster sharded, pastikan perilaku aplikasi Anda memenuhi persyaratan kluster sharded ApsaraDB for MongoDB.

Sebelum memulai

Selesaikan langkah-langkah berikut sebelum membuat tugas DTS.

Langkah 1: Buka halaman Migrasi Data

Gunakan salah satu metode berikut untuk membuka halaman Data Migration, lalu pilih Wilayah tempat instans migrasi berada.

Konsol DTS

1. Login ke Konsol DTS.

2. Di panel navigasi kiri, klik Data Migration.

3. Di pojok kiri atas, pilih wilayah tempat instans migrasi data berada.

Konsol DMS

Langkah-langkah tepatnya mungkin berbeda tergantung pada mode dan tata letak Konsol DMS. Lihat Mode sederhana dan Sesuaikan tata letak dan gaya Konsol DMS.

1. Login ke Konsol DMS.

2. Di bilah navigasi atas, buka Data + AI > DTS (DTS) > Data Migration.

3. Dari daftar tarik-turun di sebelah kanan Data Migration Tasks, pilih wilayah tempat instans migrasi berada.

Langkah 2: Buat tugas

Klik Create Task untuk membuka halaman konfigurasi tugas.

Langkah 3: Konfigurasikan database sumber dan tujuan

Konfigurasikan parameter berikut:

Umum

Database sumber

Database tujuan

Langkah 4: Uji konektivitas

Klik Test Connectivity and Proceed.

Pastikan blok CIDR server DTS telah ditambahkan ke pengaturan keamanan database sumber dan tujuan. Lihat Tambahkan blok CIDR server DTS. Jika sumber atau tujuannya adalah database yang dikelola sendiri dan tidak terhubung sebagai Alibaba Cloud Instance, klik Test Connectivity di kotak dialog CIDR Blocks of DTS Servers.

Langkah 5: Konfigurasikan objek migrasi

Di halaman Configure Objects, konfigurasikan parameter berikut:

Parameter	Deskripsi
Migration Types	Pilih jenis migrasi sesuai kebutuhan Anda. Untuk hanya melakukan migrasi data penuh, pilih Schema Migration dan Full data migration. Untuk menjaga layanan tetap berjalan selama migrasi, pilih Schema Migration, Full data migration, dan Incremental Data Migration. Jika Schema Migration tidak dipilih, buat database dan koleksi di tujuan sebelum memulai tugas, dan aktifkan fitur pemetaan nama objek di Selected Objects. Jika Incremental Data Migration tidak dipilih, jangan menulis data ke sumber selama migrasi.
Processing Mode of Conflicting Tables	Precheck and Report Errors: memeriksa apakah tujuan memiliki koleksi dengan nama yang sama seperti sumber. Pemeriksaan awal gagal jika terdapat duplikat. Untuk menyelesaikan konflik penamaan tanpa menghapus atau mengganti nama koleksi tujuan, gunakan fitur pemetaan nama objek. Lihat Pemetaan nama objek. Ignore Errors and Proceed: melewati pemeriksaan awal untuk nama koleksi duplikat. Selama migrasi data penuh, jika suatu catatan memiliki primary key yang sama dengan catatan yang sudah ada di tujuan, catatan yang sudah ada dipertahankan. Selama migrasi data inkremental, catatan yang sudah ada ditimpa. Jika skema sumber dan tujuan berbeda, kolom tertentu mungkin gagal dimigrasikan.
Capitalization of Object Names in Destination Instance	Mengontrol kapitalisasi nama database dan koleksi di tujuan. Default: DTS default policy. Lihat Tentukan kapitalisasi nama objek di instans tujuan.
Source Objects	Pilih satu atau beberapa objek (koleksi atau database), lalu klik ikon untuk menambahkannya ke Selected Objects.
Selected Objects	Klik kanan objek untuk mengganti namanya di tujuan atau memetakannya ke objek tujuan yang berbeda. Lihat Pemetaan nama objek. Klik kanan objek untuk mengatur mode migrasi inkremental untuk database dan koleksi. Klik kanan koleksi untuk menentukan kondisi filter WHERE untuk migrasi penuh. Lihat Tentukan kondisi filter. Untuk menghapus objek, klik objek tersebut lalu klik ikon . Jika pemetaan nama objek digunakan, objek lain yang bergantung pada objek yang dipetakan mungkin gagal dimigrasikan.

Klik Next: Advanced Settings untuk mengonfigurasi hal berikut:

Klik Next Step: Data Verification untuk mengonfigurasi verifikasi data. Lihat Konfigurasikan tugas verifikasi data.

Langkah 6: Jalankan pemeriksaan awal

Klik Next: Save Task Settings and Precheck.

Untuk melihat pratinjau parameter API untuk konfigurasi tugas ini, arahkan kursor ke Next: Save Task Settings and Precheck dan klik Preview OpenAPI parameters.

DTS menjalankan pemeriksaan awal sebelum migrasi dimulai. Tugas tidak dapat dimulai hingga pemeriksaan awal berhasil.

• Jika item pemeriksaan awal gagal, klik View Details di sebelahnya, selesaikan masalahnya, lalu jalankan pemeriksaan awal lagi.

• Jika item pemeriksaan awal memicu peringatan:

  • Jika peringatan tidak dapat diabaikan, klik View Details, selesaikan masalahnya, lalu jalankan ulang pemeriksaan awal.

  • Jika peringatan dapat diabaikan, klik Confirm Alert Details, lalu klik Ignore di kotak dialog, dan klik OK. Klik Precheck Again untuk melanjutkan. Mengabaikan peringatan dapat menyebabkan ketidakkonsistenan data.

Langkah 7: Beli instans

1. Tunggu hingga Success Rate mencapai 100%, lalu klik Next: Purchase Instance.

2. Di halaman Purchase Instance, konfigurasikan hal berikut:

   Bagian	Parameter	Deskripsi
   New Instance Class	Resource Group	Kelompok sumber daya untuk instans migrasi. Default: default resource group. Lihat Apa itu Resource Management?
   	Instance Class	Kelas instans menentukan kecepatan migrasi. Pilih sesuai kebutuhan Anda. Lihat Kelas instans untuk instans migrasi data.

3. Baca dan setujui Ketentuan Layanan Data Transmission Service (Pay-as-you-go) dengan mencentang kotak yang tersedia.

4. Klik Buy and Start, lalu klik OK di dialog konfirmasi.

Tugas ditampilkan di halaman Data Migration.

• Hanya migrasi data penuh: tugas berhenti secara otomatis. Status menunjukkan Completed.

• Migrasi data inkremental: tugas berjalan terus-menerus dan tidak pernah berhenti secara otomatis. Status menunjukkan Running.

Langkah 8: Buat tugas untuk shard yang tersisa (jika berlaku)

Jika Access Method untuk sumber adalah Self-managed Database on ECS atau Database Gateway, ulangi Langkah 1–7 untuk setiap shard yang tersisa.

Langkah 9: Hentikan tugas migrasi

Full data migration

Jangan hentikan tugas migrasi data penuh secara manual — data yang dimigrasikan mungkin tidak lengkap. Tunggu hingga tugas berhenti secara otomatis.

Incremental Data Migration

Migrasi data inkremental tidak berhenti secara otomatis. Hentikan secara manual pada waktu yang tepat, misalnya pada jam sepi atau sebelum beralih beban kerja ke instans tujuan.

1. Tunggu hingga Incremental Data Migration muncul di bilah kemajuan Running dan Undelayed muncul di Operation Info. Lalu hentikan penulisan data ke database sumber selama beberapa menit.

2. Setelah status Incremental Data Migration kembali menjadi Undelayed, hentikan secara manual tugas migrasi untuk semua shard.

Langkah 10: Alihkan beban kerja ke instans tujuan

Setelah migrasi selesai dan Anda telah memverifikasi data, alihkan beban kerja Anda ke instans ApsaraDB for MongoDB tujuan.