Data Transmission Service:Migrasi MongoDB (tanpa kunci shard) ke kluster sharded MongoDB

Perilaku kunci shard bergantung pada versi MongoDB tujuan

Cara DTS menangani nilai default kunci shard bergantung pada versi MongoDB tujuan:

• MongoDB tujuan sebelum versi 4.4: Nilai default kunci shard yang Anda tetapkan pada langkah Configure Database and Table Fields akan berlaku. DTS mengisi data asli dengan nilai default ini dan menuliskannya ke tujuan.

• MongoDB tujuan versi 4.4 atau lebih baru: Nilai default kunci shard tidak berlaku. DTS menulis data asli ke tujuan apa adanya.

Evaluasi perilaku mana yang berlaku untuk instans tujuan Anda sebelum melanjutkan.

Sharding data dan pre-sharding

Jika tujuan Anda memerlukan sharding, buat database dan koleksi yang perlu di-shard pada instans tujuan sebelum migrasi. Konfigurasikan sharding data, aktifkan balancer, dan lakukan pre-sharding. Hal ini mencegah seluruh data masuk ke satu shard saja dan menghindari kesenjangan data setelah migrasi.

Untuk detailnya, lihat Konfigurasikan sharding data untuk memaksimalkan performa shard dan Bagaimana menangani distribusi data yang tidak merata di kluster sharded MongoDB?.

Kompatibilitas versi

Pertahankan versi MongoDB sumber dan tujuan agar sama, atau migrasikan dari versi lama ke versi yang lebih baru. Migrasi dari versi yang lebih baru ke versi lama dapat menyebabkan masalah kompatibilitas.

Migrasi inkremental dengan oplog

DTS menangkap data inkremental melalui operasi berikut:

• CREATE COLLECTION, CREATE INDEX

• DROP DATABASE, DROP COLLECTION, DROP INDEX

• RENAME COLLECTION

• Operasi insert, update, dan delete pada dokumen

Untuk dokumen yang diperbarui, DTS hanya memigrasikan pembaruan dari $set. Migrasi inkremental tidak menangkap data dari database yang dibuat setelah tugas dimulai. Gunakan oplog untuk migrasi inkremental bila memungkinkan—metode ini memberikan penarikan log yang lebih cepat dan latensi lebih rendah dibanding change streams.

Migrasi inkremental dengan change streams

DTS menangkap data inkremental melalui operasi berikut:

• DROP DATABASE, DROP COLLECTION

• RENAME COLLECTION

• Operasi insert, update, dan delete pada dokumen

Untuk dokumen yang diperbarui, DTS hanya memigrasikan pembaruan dari $set.

Database sumber

• Bandwidth: Server sumber harus memiliki bandwidth keluar yang cukup. Bandwidth yang tidak mencukupi memperlambat migrasi.

• Diperlukan kunci primer atau kendala UNIK: Koleksi yang akan dimigrasikan harus memiliki kunci primer atau kendala UNIQUE dengan bidang unik. Jika tidak, data duplikat mungkin muncul di tujuan.

• Batas koleksi per tugas: Saat memigrasikan tingkat koleksi dengan pengeditan objek (seperti pemetaan nama), satu tugas mendukung hingga 1.000 koleksi. Jika melebihi batas ini, bagi koleksi ke beberapa tugas atau migrasikan seluruh database.

• Batas ukuran dokumen: Setiap dokumen di sumber harus berukuran 16 MB atau lebih kecil. Dokumen yang lebih besar menyebabkan tugas gagal.

• Batas node Mongos: Jika sumber adalah kluster sharded, jumlah node mongos-nya harus 10 atau kurang.

• Metode akses kluster sharded yang dikelola sendiri: Hanya Public IP Address, Express Connect, VPN Gateway, or Smart Access Gateway, dan Cloud Enterprise Network (CEN) yang didukung.

• MongoDB 8.0+ dengan oplog: Jika sumber adalah kluster sharded yang dikelola sendiri menjalankan MongoDB 8.0 atau lebih baru dan Migration Method adalah Oplog, berikan izin directShardOperations kepada akun shard: Ganti username dengan akun shard yang digunakan untuk tugas migrasi.

    db.adminCommand({ grantRolesToUser: "username", roles: [{ role: "directShardOperations", db: "admin"}]})

• Kluster elastis Azure Cosmos DB / Amazon DocumentDB: Hanya migrasi data penuh yang didukung.

• Retensi oplog untuk migrasi inkremental: Fitur oplog harus diaktifkan dengan penyimpanan log operasi minimal tujuh hari. Atau, aktifkan change streams dengan jendela langganan tujuh hari. Jika DTS tidak dapat mengakses log, tugas mungkin gagal, dan ketidakkonsistenan atau kehilangan data dapat terjadi. Masalah ini tidak dicakup oleh SLA DTS.

• Persyaratan versi change streams: Change streams memerlukan MongoDB V4.0 atau lebih baru.

• Kluster Amazon DocumentDB non-elastis: Aktifkan change streams, atur Migration Method ke ChangeStream, dan atur Architecture ke Sharded Cluster.

• Indeks TTL: Indeks TTL di sumber dapat menyebabkan ketidakkonsistenan data antara sumber dan tujuan setelah migrasi.

• Dokumen yatim: Pastikan tidak ada dokumen yatim di kluster sharded sumber. Jika ada, ketidakkonsistenan data atau kegagalan tugas dapat terjadi. Lihat Dokumen Yatim dan Bagaimana membersihkan dokumen yatim di kluster sharded MongoDB?.

• Aktivitas balancer: Jika balancer kluster sharded sumber sedang aktif melakukan penyeimbangan ulang data, latensi instans dapat meningkat.

Pembatasan selama migrasi

• Migrasi skema dan migrasi data penuh: Jangan lakukan perubahan skema pada database atau koleksi, termasuk pembaruan pada tipe array. Perubahan skema dapat menyebabkan tugas gagal atau menghasilkan ketidakkonsistenan data.

• Sumber kluster sharded: Jangan jalankan shardCollection, reshardCollection, unshardCollection, moveCollection, atau movePrimary untuk mengubah distribusi data selama instans migrasi berjalan. Jika dilakukan, ketidakkonsistenan data dapat terjadi.

• Hanya migrasi penuh (tanpa inkremental): Jangan tulis data baru ke sumber. Untuk menjaga konsistensi real-time, pilih ketiga jenis migrasi: Schema Migration, Full Data Migration, dan Incremental Data Migration.

Batasan umum

• Koleksi baru selama migrasi: Nilai default kunci shard tidak dapat ditetapkan untuk koleksi yang ditambahkan ke sumber setelah tugas dimulai.

• Alamat SRV: DTS tidak mendukung koneksi ke MongoDB melalui alamat SRV.

• Sumber non-sharded ke tujuan sharded: Ketika sumber adalah kluster non-sharded dan tujuan adalah kluster sharded Alibaba Cloud, tugas akan melanjutkan ke langkah Configure Database and Table Fields.

• Database yang dikecualikan: DTS tidak dapat memigrasikan data dari database admin, config, atau local.

• Transaksi: Informasi transaksi tidak dipertahankan. Transaksi di sumber dikonversi menjadi catatan individual di tujuan.

• Konflik kunci primer / kunci unik: Saat terjadi konflik, DTS melewati penulisan yang bertentangan dan mempertahankan data yang sudah ada di tujuan.

• Urutan bidang (sumber < 3.6, tujuan >= 3.6): Jika sumber menjalankan MongoDB sebelum 3.6 dan tujuan menjalankan 3.6 atau lebih baru, urutan bidang mungkin tidak konsisten setelah migrasi karena perbedaan rencana eksekusi mesin database. Evaluasi dampaknya jika logika bisnis Anda melibatkan kueri pencocokan pada struktur bersarang.

• Overhead penyimpanan akibat penulisan konkuren: Migrasi penuh menjalankan operasi INSERT secara konkuren, yang menyebabkan fragmentasi koleksi. Tujuan menempati 5% hingga 10% lebih banyak ruang penyimpanan daripada sumber.

• Percobaan ulang tugas otomatis: DTS mencoba ulang tugas yang gagal dalam tujuh hari terakhir. Sebelum mengalihkan beban kerja ke tujuan, hentikan atau lepas tugas, atau cabut izin tulis pada akun tujuan. Hal ini mencegah pemulihan otomatis menimpa data tujuan.

• Koleksi dengan indeks unik atau atribut capped: Koleksi yang memiliki indeks unik atau atribut capped bernilai true hanya mendukung penulisan single-thread selama migrasi inkremental (tanpa replay konkuren), yang dapat meningkatkan latensi.

• Kueri jumlah dokumen: Untuk menanyakan jumlah dokumen di tujuan, gunakan: db.$table_name.aggregate([{ $count:"myCount"}]).

• Kunci primer duplikat (_id): Pastikan tujuan tidak memiliki dokumen dengan nilai _id yang sama dengan sumber. Nilai _id duplikat menyebabkan kehilangan data. Hapus dokumen yang bertentangan di tujuan sebelum migrasi jika hal tersebut tidak memengaruhi bisnis Anda.

• Pemulihan kegagalan tugas DTS: Jika tugas gagal, dukungan teknis DTS berupaya memulihkannya dalam waktu 8 jam. Selama pemulihan, tugas mungkin dimulai ulang dan parameter tugas DTS mungkin diubah. Parameter database tidak diubah. Parameter yang diubah mencakup, namun tidak terbatas pada, yang dijelaskan dalam Ubah parameter instans.

• Kepatuhan koleksi sharded: Setelah mengalihkan bisnis ke tujuan, semua operasi bisnis harus mematuhi persyaratan untuk koleksi sharded di database MongoDB tersebut.

Sumber MongoDB yang dikelola sendiri

• Failover selama migrasi: Jika terjadi failover primer/sekunder selama migrasi, tugas gagal.

• Perhitungan latensi: DTS menghitung latensi dengan membandingkan stempel waktu entri terakhir yang dimigrasikan dengan waktu saat ini. Jika sumber tidak diperbarui dalam waktu lama, latensi yang ditampilkan mungkin tidak akurat. Jalankan pembaruan pada sumber untuk memperbarui latensi.

• Heartbeat untuk migrasi seluruh database: Buat koleksi heartbeat yang secara berkala memperbarui atau menulis data (misalnya, setiap detik) untuk menjaga akurasi latensi.

Langkah 1: Buka halaman migrasi data

Gunakan salah satu metode berikut untuk membuka halaman Data Migration.

Konsol DTS:

1. Masuk 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:

Operasi aktual dapat berbeda tergantung pada mode dan tata letak konsol DMS. Untuk informasi lebih lanjut, lihat Mode simple dan Sesuaikan tata letak dan gaya konsol DMS.

1. Masuk ke Konsol DMS.

2. Di bilah navigasi atas, arahkan kursor ke Data + AI > DTS (DTS) > Data Migration.

3. Dari daftar drop-down di samping Data Migration Tasks, pilih wilayah tempat instans migrasi data berada.

Langkah 2: Buat tugas migrasi

Klik Create Task untuk membuka halaman konfigurasi tugas.

Langkah 3: Konfigurasikan database sumber dan tujuan

Konfigurasikan parameter berikut untuk database sumber dan tujuan.

Pengaturan tugas

Database sumber

Database tujuan

Langkah 4: Uji konektivitas

Klik Test Connectivity and Proceed di bagian bawah halaman.

Pastikan blok CIDR server DTS telah ditambahkan ke pengaturan keamanan database sumber dan tujuan. Untuk detailnya, lihat Tambahkan blok CIDR server DTS. Jika sumber atau tujuan adalah database yang dikelola sendiri dan Access Method-nya bukan Alibaba Cloud Instance, klik Test Connectivity di kotak dialog CIDR Blocks of DTS Servers.

Langkah 5: Konfigurasikan objek migrasi

Di halaman Configure Objects, atur pengaturan berikut.

Langkah 6: Konfigurasikan pengaturan lanjutan

Klik Next: Advanced Settings dan konfigurasikan parameter berikut.

Langkah 7: Konfigurasikan verifikasi data

Klik Next Step: Data Verification dan konfigurasikan tugas verifikasi data. Untuk detail selengkapnya, lihat Mengonfigurasi tugas verifikasi data.

Langkah 8: Tetapkan nilai default kunci shard

Klik Next: Configure Database and Table Fields untuk menetapkan nilai default kunci shard untuk koleksi tanpa kunci shard.

1. Di baris koleksi tujuan, klik Set Default Value.

   Jika Number of Shard Keys untuk suatu koleksi adalah 0, koleksi tersebut tidak memiliki kunci shard dan tidak memerlukan nilai default.

2. Pilih Shard key default value type.

   Hanya tipe string dan int yang didukung.

3. Masukkan Default Value untuk kunci shard.

Langkah 9: Jalankan pemeriksaan awal

Klik Next: Save Task Settings and Precheck.

Untuk melihat pratinjau parameter API untuk tugas ini, arahkan kursor ke tombol tersebut dan klik Preview OpenAPI parameters.

DTS menjalankan pemeriksaan awal sebelum memulai migrasi. Tugas hanya dimulai setelah pemeriksaan awal berhasil.

• Jika pemeriksaan awal gagal, klik View Details di samping setiap item yang gagal, perbaiki masalahnya, lalu jalankan kembali pemeriksaan awal.

• Jika item pemeriksaan awal memicu peringatan:

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

  • Jika peringatan dapat diabaikan, klik Confirm Alert Details > Ignore > OK, lalu klik Precheck Again. Mengabaikan peringatan dapat menyebabkan ketidakkonsistenan data.

Langkah 10: Beli instans dan mulai migrasi

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

2. Di halaman Purchase Instance, konfigurasikan instans:

   Parameter	Deskripsi
   Resource Group	Kelompok sumber daya untuk instans migrasi. Default: default resource group. Lihat Apa itu Manajemen Sumber Daya?.
   Instance Class	Pilih kelas berdasarkan kecepatan migrasi yang dibutuhkan. Lihat Kelas instans migrasi data.

3. Baca dan terima Data Transmission Service (Pay-as-you-go) Service Terms.

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

Tugas muncul di halaman Data Migration tempat Anda dapat memantau progresnya.

• Jika tugas tidak mencakup migrasi inkremental, tugas akan berhenti secara otomatis dan Status menunjukkan Completed.

• Jika tugas mencakup migrasi inkremental, tugas berjalan terus-menerus dan Status menunjukkan Running. Tugas tidak berhenti secara otomatis.