All Products
Search

This Product

    Data Transmission Service:Migrasi replica set MongoDB ke replica set atau kluster sharded

    Document Center

    Data Transmission Service:Migrasi replica set MongoDB ke replica set atau kluster sharded

    Last Updated:Jul 08, 2026

    Topik ini menjelaskan cara memigrasikan data dari instans replica set ApsaraDB for MongoDB ke instans replica set atau kluster sharded ApsaraDB for MongoDB menggunakan Data Transmission Service (DTS).

    Database sumber dan tujuan yang didukung

    Database sumber (replica set)

    Database tujuan (replica set atau kluster sharded)

    ApsaraDB for MongoDB

    ApsaraDB for MongoDB

    Database yang dikelola sendiri pada instance ECS

    Database yang dikelola sendiri pada instance ECS

    Database yang dikelola sendiri yang terhubung menggunakan Express Connect, VPN Gateway, atau Smart Access Gateway

    Database yang dikelola sendiri yang terhubung menggunakan Express Connect, VPN Gateway, atau Smart Access Gateway

    Database yang dikelola sendiri dengan alamat IP publik

    Database yang dikelola sendiri dengan alamat IP publik

    Topik ini memberikan contoh konfigurasi untuk sumber ApsaraDB for MongoDB replica set dan instans tujuan ApsaraDB for MongoDB (replica set atau kluster sharded). Proses konfigurasi untuk sumber data lainnya serupa.

    Prasyarat

    • Anda telah membuat instans replica set ApsaraDB for MongoDB sebagai sumber dan instans replica set atau kluster sharded ApsaraDB for MongoDB sebagai tujuan. Untuk informasi lebih lanjut, lihat Buat instans replica set dan Buat instans kluster sharded.

      Catatan

      Untuk informasi tentang versi yang didukung, lihat Ikhtisar solusi migrasi.

    • Instans ApsaraDB for MongoDB tujuan harus memiliki ruang penyimpanan minimal 10% lebih besar daripada instans ApsaraDB for MongoDB sumber.

    • Jika instans ApsaraDB for MongoDB tujuan adalah kluster sharded, Anda harus membuat database dan koleksi yang memerlukan sharding, mengonfigurasi sharding data, mengaktifkan balancer, dan melakukan pre-sharding di instans ApsaraDB for MongoDB tujuan sesuai kebutuhan bisnis Anda. Untuk informasi lebih lanjut, lihat Siapkan sharding data untuk memaksimalkan kinerja shard dan Cara menangani distribusi data tidak merata di kluster sharded MongoDB.

      Catatan

      Mengonfigurasi sharding data mencegah semua data dimigrasikan ke satu shard saja, sehingga memastikan kinerja kluster optimal; mengaktifkan balancer dan melakukan pre-sharding mencegah kesenjangan data.

    Catatan

    Jenis

    Deskripsi

    Batasan database sumber

    • Kebutuhan bandwidth: Server database sumber harus memiliki bandwidth egress yang cukup. Jika tidak, kecepatan migrasi data akan terpengaruh.

    • Koleksi yang akan dimigrasikan harus memiliki primary key atau unique constraint, dan bidang yang dibatasi tersebut harus berisi nilai unik. Jika tidak, data duplikat dapat tercipta di database tujuan.

    • Nama bidang dalam data tidak boleh mengandung karakter "." (titik); jika tidak, ketidakkonsistenan data dapat terjadi.

    • Jika Anda melakukan migrasi data tingkat koleksi dan perlu mengedit koleksi tersebut, misalnya dengan memetakan nama koleksi, satu tugas migrasi hanya dapat memigrasikan maksimal 1.000 koleksi. Jika melebihi batas ini, tugas akan melaporkan error saat dikirim. Dalam kasus ini, Anda harus membagi koleksi menjadi beberapa batch dan mengonfigurasi tugas terpisah untuk setiap batch, atau mengonfigurasi satu tugas untuk memigrasikan seluruh database.

    • Satu dokumen di database sumber tidak boleh melebihi 16 MB. Jika melebihi, tugas migrasi akan gagal.

    • Jika database sumber adalah Azure Cosmos DB for MongoDB atau kluster elastis Amazon DocumentDB, hanya migrasi data penuh yang didukung.

    • Untuk melakukan migrasi data inkremental:

      Database sumber harus memiliki oplog yang diaktifkan dengan retensi minimal tujuh hari. Atau, change streams harus diaktifkan, dan DTS harus dapat berlangganan perubahan data dari database sumber dalam tujuh hari terakhir melalui change streams. Jika persyaratan ini tidak terpenuhi, tugas migrasi dapat gagal karena tidak dapat memperoleh perubahan data dari sumber. Dalam kasus ekstrem, hal ini dapat menyebabkan ketidakkonsistenan atau kehilangan data. Masalah yang timbul akibat hal ini tidak dicakup oleh Perjanjian Tingkat Layanan (SLA) DTS.

      Penting

      • Kami merekomendasikan menggunakan oplog untuk memperoleh perubahan data dari database sumber.

      • Hanya MongoDB versi 4.0 dan yang lebih baru yang mendukung perolehan perubahan data melalui change streams.

      • Jika database sumber adalah kluster Amazon DocumentDB (non-elastis), Anda harus mengaktifkan change streams secara manual. Saat mengonfigurasi tugas, atur Migration Method ke ChangeStream dan Architecture ke Sharded Cluster.

    • Batasan operasional pada database sumber:

      • Selama fase migrasi skema dan migrasi data penuh, jangan lakukan perubahan skema pada database atau koleksi, termasuk memperbarui data dalam array. Perubahan semacam itu dapat menyebabkan migrasi gagal atau mengakibatkan ketidakkonsistenan data antara database sumber dan tujuan.

      • Jika Anda hanya melakukan migrasi data penuh, jangan menulis data baru ke instans sumber. Jika tidak, database sumber dan tujuan akan menjadi tidak konsisten. Untuk menjaga konsistensi data secara real-time, pilih Schema Migration, Full Data Migration, dan Incremental Data Migration.

    • Jika koleksi yang akan dimigrasikan berisi indeks Time-to-Live (TTL), ketidakkonsistenan data dapat terjadi atau latensi instans dapat meningkat.

    Batasan lainnya

    • Jika instans tujuan memiliki arsitektur kluster sharded:

      • Anda harus membersihkan dokumen orphaned karena dapat memengaruhi kinerja migrasi. Jika dokumen dengan konflik _id ditemukan selama migrasi, ketidakkonsistenan data atau kegagalan tugas dapat terjadi.

      • Sebelum memulai tugas, Anda harus menambahkan shard key ke data sumber untuk setiap koleksi sharded di tujuan. Jika Anda tidak dapat menambahkan shard key ke data sumber, lihat Migrasi data dari instans MongoDB tanpa shard key ke instans kluster sharded MongoDB.

      • Setelah tugas dimulai, perintah INSERT harus menyertakan shard key. Perintah UPDATE tidak boleh mengubah shard key.

    • Jika instans tujuan memiliki arsitektur replica set:

      • Saat Access Method adalah Express Connect, VPN Gateway, or Smart Access Gateway, Public IP Address, atau Cloud Enterprise Network (CEN), Anda harus mengatur Domain Name or IP dan Port Number ke alamat dan port node primer, atau mengonfigurasi alamat koneksi ketersediaan tinggi. Untuk informasi lebih lanjut tentang alamat koneksi ketersediaan tinggi, lihat Buat Instans Sumber atau Tujuan untuk Database MongoDB Ketersediaan Tinggi.

      • Saat Access Method adalah Self-managed Database on ECS, Anda harus mengatur Port Number ke port node primer.

    • DTS tidak mendukung koneksi ke database MongoDB menggunakan rekaman SRV.

    • Pertahankan versi MongoDB database sumber dan tujuan agar konsisten, atau migrasikan dari versi yang lebih lama ke versi yang lebih baru untuk memastikan kompatibilitas. Migrasi dari versi yang lebih baru ke versi yang lebih lama dapat menyebabkan masalah kompatibilitas.

    • DTS tidak mendukung migrasi data dari database admin, config, atau local.

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

    • DTS tidak menyimpan informasi transaksi. DTS mengonversi transaksi dari database sumber menjadi pernyataan individual di database tujuan.

    • Saat DTS menulis data ke koleksi tujuan, jika terjadi konflik primary key atau unique key, DTS akan melewati pernyataan penulisan data yang bertentangan dan mempertahankan data yang sudah ada di koleksi tujuan.

    • Jika database sumber adalah MongoDB versi sebelum 3.6 dan database tujuan adalah MongoDB 3.6 atau yang lebih baru, urutan bidang dalam data yang dimigrasikan mungkin berbeda dari sumber. Pasangan nilai-bidang tetap benar. Hal ini disebabkan oleh perbedaan rencana eksekusi mesin database. Jika logika aplikasi Anda melibatkan pencocokan teks pada struktur bersarang, evaluasi potensi dampak dari perubahan urutan bidang ini.

    • Sebelum melakukan migrasi data, evaluasi kinerja database sumber dan tujuan serta lakukan migrasi selama jam sepi. Selama migrasi data penuh, DTS mengonsumsi sumber daya baca/tulis, yang dapat meningkatkan beban database.

    • Selama migrasi data penuh, DTS melakukan operasi INSERT konkuren, yang dapat menyebabkan fragmentasi di koleksi tujuan. Akibatnya, koleksi tujuan mungkin menempati ruang penyimpanan lebih besar daripada di instans sumber.

    • Verifikasi bahwa presisi migrasi yang digunakan DTS untuk kolom FLOAT atau DOUBLE memenuhi kebutuhan bisnis Anda. DTS membaca nilai tipe ini menggunakan ROUND(COLUMN,PRECISION). Jika Anda tidak secara eksplisit menentukan presisi, DTS memigrasikan nilai FLOAT dengan presisi 38 digit dan nilai DOUBLE dengan presisi 308 digit.

    • DTS mencoba melanjutkan tugas migrasi yang gagal dalam waktu tujuh hari. Sebelum alih bencana layanan ke instans target, Anda harus mengakhiri atau melepas tugas tersebut, atau menggunakan perintah revoke untuk mencabut izin tulis akun yang digunakan DTS untuk mengakses instans target. Hal ini mencegah data sumber menimpa data di instans target jika tugas dilanjutkan secara otomatis.

    • Karena DTS menulis data secara konkuren, database tujuan menggunakan ruang penyimpanan 5% hingga 10% lebih banyak daripada database sumber.

    • Gunakan sintaks db.$table_name.aggregate([{ $count:"myCount"}]) untuk menghitung jumlah dokumen di MongoDB tujuan.

    • Pastikan database MongoDB tujuan tidak memiliki dokumen dengan primary key yang sama (bidang _id secara default) dengan database sumber. Jika tidak, kehilangan data dapat terjadi. Jika dokumen tersebut ada, hapus dokumen dengan nilai _id yang bertentangan dari database tujuan sebelum migrasi, asalkan tidak memengaruhi operasi bisnis Anda.

    • Jika tugas gagal, staf dukungan DTS akan mencoba memulihkannya dalam waktu delapan jam. Selama pemulihan, mereka mungkin me-restart tugas atau menyesuaikan parameternya.

      Catatan

      Hanya parameter tugas DTS yang dimodifikasi—bukan parameter database. Parameter yang mungkin disesuaikan termasuk yang tercantum di Modifikasi parameter instans.

    • Jika database tujuan adalah kluster sharded MongoDB, setelah Anda mengalihkan bisnis ke database ini, pastikan operasi bisnis Anda mematuhi persyaratan kluster sharded untuk koleksi yang di-shard.

    • Anda tidak dapat memigrasikan capped collections ketika database sumber adalah MongoDB 5.0 atau yang lebih baru dan database tujuan adalah versi sebelumnya. Hal ini dapat menyebabkan tugas gagal atau ketidakkonsistenan data. Ini karena perilaku capped collections berubah di MongoDB 5.0, yang memungkinkan penghapusan eksplisit dan peningkatan ukuran dokumen saat pembaruan. Kernel database versi sebelumnya tidak kompatibel dengan fitur-fitur ini.

    • Koleksi time series, yang diperkenalkan di MongoDB 5.0, tidak didukung untuk migrasi.

    Kasus khusus

    Jika database sumber adalah database MongoDB yang dikelola sendiri:

    • Alih bencana primer/sekunder di database sumber selama migrasi menyebabkan tugas gagal.

    • DTS menghitung latensi dengan membandingkan timestamp catatan terakhir yang dimigrasikan ke tujuan dengan timestamp saat ini. Jika database sumber tidak diperbarui dalam waktu lama, latensi yang dilaporkan mungkin tidak akurat. Jika tugas menunjukkan latensi berlebihan, lakukan pembaruan kecil di database sumber untuk memperbarui nilai latensi.

    Catatan

    Jika Anda memigrasikan seluruh database, Anda juga dapat membuat tabel heartbeat yang diperbarui secara berkala, misalnya setiap detik.

    Penagihan

    Jenis migrasi

    Biaya konfigurasi instans

    Biaya lalu lintas internet

    Migrasi skema dan migrasi data penuh

    Gratis.

    Saat parameter Access Method untuk database tujuan diatur ke Public IP Address, Anda akan dikenai biaya untuk lalu lintas internet. Untuk informasi selengkapnya, lihat Ringkasan penagihan.

    Migrasi data inkremental

    Dikenai biaya. Untuk informasi lebih lanjut, lihat Ikhtisar penagihan.

    Jenis migrasi

    Jenis

    Deskripsi

    migrasi skema

    Migrasikan skema objek migrasi dari ApsaraDB for MongoDB sumber ke ApsaraDB for MongoDB tujuan.

    Catatan

    Migrasi skema didukung untuk database, koleksi, dan indeks.

    migrasi data penuh

    Migrasikan semua data yang ada dari objek migrasi di ApsaraDB for MongoDB sumber ke ApsaraDB for MongoDB tujuan.

    Catatan

    Migrasi data penuh didukung untuk data dalam database dan koleksi.

    migrasi data inkremental

    Selain migrasi penuh, Anda dapat memigrasikan pembaruan inkremental dari ApsaraDB for MongoDB sumber ke ApsaraDB for MongoDB tujuan.

    Oplog

    Migrasi inkremental tidak mendukung database yang dibuat setelah tugas dimulai. Pembaruan inkremental berikut didukung:

    • CREATE COLLECTION dan CREATE INDEX

    • DROP DATABASE, DROP COLLECTION, dan DROP INDEX

      Catatan

      Operasi RENAME COLLECTION yang menyertakan opsi dropTarget diatur ke true tidak didukung.

    • RENAME COLLECTION

    • Menyisipkan, memperbarui, dan menghapus dokumen dalam koleksi.

      Catatan

      Untuk pembaruan dokumen inkremental, hanya perubahan yang dibuat menggunakan perintah $set yang direplikasi.

    Change stream

    Pembaruan inkremental berikut didukung:

    • DROP DATABASE dan DROP COLLECTION

    • RENAME COLLECTION

      Catatan

      Operasi RENAME COLLECTION yang menyertakan opsi dropTarget diatur ke true tidak didukung.

    • Menyisipkan, memperbarui, dan menghapus dokumen dalam koleksi.

      Catatan

      Untuk pembaruan dokumen inkremental, hanya perubahan yang dibuat menggunakan perintah $set yang direplikasi.

    Izin akun database

    Database

    Migrasi skema

    Migrasi data penuh

    Migrasi data inkremental

    Instans ApsaraDB for MongoDB sumber

    Izin baca pada database yang akan dimigrasikan dan database config.

    Izin baca pada database yang akan dimigrasikan, database admin, dan database local.

    Instans ApsaraDB for MongoDB tujuan

    dbAdminAnyDatabase, readWrite pada database tujuan, dan read pada database local.

    Untuk membuat akun database dan memberikan izin untuk instans ApsaraDB for MongoDB sumber dan tujuan, lihat Kelola pengguna database MongoDB dengan DMS.

    Prosedur

    1. Buka halaman daftar tugas migrasi untuk wilayah tujuan menggunakan salah satu metode berikut.

      Dari Konsol DTS

      1. Masuk ke Konsol Data Transmission Service (DTS).

      2. Di panel navigasi kiri, klik Data Migration.

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

      Dari Konsol DMS

      Catatan

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

      1. Masuk ke Konsol Data Management (DMS).

      2. Di bilah menu atas, pilih Data + AI > Data Transmission (DTS) > Data Migration.

      3. Di sebelah kanan Data Migration Tasks, pilih wilayah tempat instans migrasi berada.

    2. Klik Create Task untuk membuka halaman konfigurasi tugas.

    3. Konfigurasikan database sumber dan tujuan.

      Peringatan

      Setelah memilih instans sumber dan tujuan, kami sarankan Anda membaca dengan cermat batasan yang ditampilkan di bagian atas halaman. Jika tidak, tugas dapat gagal atau terjadi ketidakkonsistenan data.

      Kategori

      Parameter

      Deskripsi

      N/A

      Task Name

      DTS secara otomatis menghasilkan nama tugas. Kami sarankan Anda menentukan nama deskriptif agar mudah diidentifikasi. Nama tidak perlu unik.

      Source Database

      Select Existing Connection

      • Untuk menggunakan instans database yang telah ditambahkan ke sistem (dibuat atau disimpan), pilih instans database yang diinginkan dari daftar drop-down. Informasi database di bawah akan dikonfigurasi secara otomatis.

        Catatan

        Di konsol DMS, parameter ini bernama Select a DMS database instance..

      • Jika Anda belum mendaftarkan instans database ke sistem, atau tidak perlu menggunakan instans terdaftar, konfigurasikan informasi database secara manual di bawah.

      Database Type

      Pilih MongoDB.

      Connection Type

      Pilih Cloud instance.

      Instance Region

      Pilih wilayah tempat instans ApsaraDB for MongoDB sumber berada.

      Replicate Data Across Alibaba Cloud Accounts

      Dalam contoh ini, instans database di bawah Akun Alibaba Cloud saat ini digunakan. Pilih No.

      Architecture

      Pilih Replica Set.

      • Replica Set: Arsitektur ini menggunakan beberapa node untuk memastikan ketersediaan tinggi dan mengaktifkan pemisahan baca/tulis. Untuk informasi lebih lanjut, lihat Arsitektur replica set.

      • Sharded Cluster: Arsitektur ini terdiri dari komponen mongos, shard, dan ConfigServer. Anda dapat menyesuaikan jumlah dan konfigurasi node mongos dan shard. Untuk informasi lebih lanjut, lihat Arsitektur kluster sharded.

      Migration Method

      Pilih metode untuk migrasi data inkremental sesuai kebutuhan Anda.

      • Oplog (Direkomendasikan):

        Opsi ini tersedia jika oplog diaktifkan untuk database sumber.

        Catatan

        Oplog diaktifkan secara default baik untuk database MongoDB yang dikelola sendiri maupun instans ApsaraDB for MongoDB. Metode ini menawarkan latensi lebih rendah untuk migrasi data inkremental karena penarikan log lebih cepat. Oleh karena itu, kami merekomendasikan memilih Oplog.

      • ChangeStream: Opsi ini tersedia jika Change Streams diaktifkan untuk database sumber.

        Catatan

        • Jika database sumber adalah instans Amazon DocumentDB (kluster non-elastis), Anda hanya dapat memilih ChangeStream.

        • Jika Anda mengatur Architecture ke Sharded Cluster untuk database sumber, Anda tidak perlu memasukkan Shard account atau Shard password.

      Instance ID

      Pilih ID instans dari instans ApsaraDB for MongoDB sumber.

      Authentication Database

      Masukkan nama database tempat akun database instans ApsaraDB for MongoDB sumber berada. Nilai default adalah admin.

      Database Account

      Masukkan akun database instans ApsaraDB for MongoDB sumber. Untuk informasi tentang persyaratan izin, lihat Izin akun database.

      Database Password

      Masukkan kata sandi untuk akun database.

      Encryption

      DTS mendukung tiga metode koneksi: Non-encrypted, SSL-encrypted, dan Mongo Atlas SSL. Opsi untuk Encryption bervariasi berdasarkan Access Method dan Architecture yang dipilih. Opsi yang ditampilkan di konsol berlaku.

      Catatan

      • Database MongoDB dengan Architecture Sharded Cluster dan Migration Method Oplog tidak mendukung SSL-encrypted.

      • Jika sumber adalah database MongoDB yang dikelola sendiri (Access Method bukan Alibaba Cloud Instance) dengan arsitektur Replica Set, dan Anda memilih SSL-encrypted, DTS juga memungkinkan Anda mengunggah sertifikat CA untuk memverifikasi koneksi.

      Destination Database

      Select Existing Connection

      • Untuk menggunakan instans database yang telah ditambahkan ke sistem (dibuat atau disimpan), pilih instans database yang diinginkan dari daftar drop-down. Informasi database di bawah akan dikonfigurasi secara otomatis.

        Catatan

        Di konsol DMS, parameter ini bernama Select a DMS database instance..

      • Jika Anda belum mendaftarkan instans database ke sistem, atau tidak perlu menggunakan instans terdaftar, konfigurasikan informasi database secara manual di bawah.

      Database Type

      Pilih MongoDB.

      Connection Type

      Pilih Cloud instance.

      Instance Region

      Pilih wilayah tempat instans ApsaraDB for MongoDB tujuan berada.

      Replicate Data Across Alibaba Cloud Accounts

      Dalam contoh ini, instans database di bawah Akun Alibaba Cloud saat ini digunakan. Pilih No.

      Architecture

      Pilih arsitektur berdasarkan kebutuhan bisnis Anda. Nilai yang valid:

      • Replica Set: Arsitektur ini menggunakan beberapa node untuk memastikan ketersediaan tinggi dan mengaktifkan pemisahan baca/tulis. Untuk informasi lebih lanjut, lihat Arsitektur replica set.

      • Sharded Cluster: Arsitektur ini terdiri dari komponen mongos, shard, dan ConfigServer. Anda dapat menyesuaikan jumlah dan konfigurasi node mongos dan shard. Untuk informasi lebih lanjut, lihat Arsitektur kluster sharded.

      Instance ID

      Pilih ID instans dari instans ApsaraDB for MongoDB tujuan.

      Authentication Database

      Masukkan nama database tempat akun database instans ApsaraDB for MongoDB tujuan berada. Nilai default adalah admin.

      Database Account

      Masukkan akun database instans ApsaraDB for MongoDB tujuan. Untuk informasi tentang persyaratan izin, lihat Izin akun database.

      Database Password

      Masukkan kata sandi untuk akun database.

      Encryption

      DTS mendukung tiga metode koneksi: Non-encrypted, SSL-encrypted, dan Mongo Atlas SSL. Opsi untuk Encryption bervariasi berdasarkan Access Method dan Architecture yang dipilih. Opsi yang ditampilkan di konsol berlaku.

      Catatan

      • Database MongoDB dengan Architecture Sharded Cluster tidak mendukung SSL-encrypted.

      • Jika tujuan adalah database MongoDB yang dikelola sendiri (Access Method bukan Alibaba Cloud Instance) dengan Replica Set, dan Anda memilih SSL-encrypted, DTS juga memungkinkan Anda mengunggah sertifikat CA untuk memverifikasi koneksi.

    4. Setelah menyelesaikan konfigurasi, klik Test Connectivity and Proceed di bagian bawah halaman.

      Catatan

      • Pastikan blok CIDR alamat IP server DTS telah ditambahkan ke pengaturan keamanan database sumber dan tujuan untuk mengizinkan akses dari server DTS. Hal ini dapat dilakukan secara otomatis atau manual. Untuk informasi lebih lanjut, lihat Tambahkan blok CIDR alamat IP server DTS ke daftar putih.

      • Jika database sumber atau tujuan adalah database yang dikelola sendiri (di mana Access Method bukan Alibaba Cloud Instance), Anda juga harus mengklik Test Connectivity di kotak dialog CIDR Blocks of DTS Servers.

    5. Konfigurasikan objek tugas.

      Di halaman Configure Objects, konfigurasikan objek yang ingin Anda migrasikan.

      Parameter

      Deskripsi

      Migration Types

      • Jika Anda hanya perlu melakukan migrasi penuh, pilih Schema Migration dan Full Data Migration.

      • Untuk melakukan migrasi tanpa downtime, pilih Schema Migration, Full Data Migration, dan Incremental Data Migration.

      Catatan

      • Jika Anda tidak memilih Schema Migration, Anda harus memastikan bahwa database dan tabel untuk menerima data sudah ada di database tujuan. Anda juga dapat menggunakan fitur pemetaan nama objek di kotak Selected Objects sesuai kebutuhan.

      • Jika Anda tidak memilih Incremental Data Migration, jangan menulis data baru ke instans sumber selama migrasi data untuk memastikan konsistensi data.

      Untuk informasi lebih lanjut, lihat Jenis migrasi.

      Processing Mode of Conflicting Tables

      • Precheck and Report Errors: Memeriksa apakah koleksi dengan nama yang sama ada di database tujuan. Jika tidak ada koleksi dengan nama yang sama, pemeriksaan awal lolos. Jika ada koleksi dengan nama yang sama, error dilaporkan selama pemeriksaan awal, dan tugas migrasi data tidak dimulai.

        Catatan

        Jika koleksi di database tujuan memiliki nama yang sama tetapi tidak dapat dengan mudah dihapus atau diganti namanya, Anda dapat mengubah nama koleksi di database tujuan. Untuk informasi lebih lanjut, lihat Pemetaan nama objek.

      • Ignore Errors and Proceed: Melewati pemeriksaan koleksi dengan nama yang sama.

        Peringatan

        Memilih Ignore Errors and Proceed dapat menyebabkan ketidakkonsistenan data dan risiko bisnis. Misalnya:

        • Jika catatan di database tujuan memiliki nilai primary key yang sama dengan catatan di database sumber, catatan di database tujuan dipertahankan. Catatan dari database sumber tidak dimigrasikan ke database tujuan.

        • Inisialisasi data dapat gagal, hanya sebagian data yang dimigrasikan, atau migrasi gagal.

      Capitalization of Object Names in Destination Instance

      Anda dapat mengonfigurasi kebijakan kapitalisasi untuk nama database dan koleksi yang dimigrasikan di instans tujuan. Secara default, DTS default policy dipilih. Anda juga dapat memilih untuk menyelaraskan dengan kebijakan default database sumber atau tujuan. Untuk informasi lebih lanjut, lihat Kebijakan kapitalisasi nama objek untuk tujuan.

      Source Objects

      Di kotak Source Objects, klik objek yang ingin Anda migrasikan, lalu klik 向右小箭头 untuk memindahkannya ke kotak Selected Objects.

      Catatan

      Anda dapat memilih objek tingkat DATABASE atau COLLECTION.

      Selected Objects

      • Untuk mengatur nama objek migrasi di instans tujuan, atau menentukan objek yang menerima data di instans tujuan, klik kanan objek migrasi di kotak Selected Objects untuk melakukan perubahan. Untuk informasi lebih lanjut, lihat Pemetaan nama objek.

      • Untuk menghapus objek migrasi yang dipilih, klik objek di kotak Selected Objects, lalu klik image untuk memindahkannya ke kotak Source Objects.

      Catatan

      • Untuk memilih operasi migrasi inkremental tingkat database atau koleksi, klik kanan objek migrasi di kotak Selected Objects dan buat pilihan Anda di kotak dialog yang muncul.

      • Untuk mengatur kondisi penyaringan data (didukung selama migrasi data penuh tetapi tidak untuk migrasi data inkremental), klik kanan koleksi di kotak Selected Objects dan konfigurasikan pengaturan di kotak dialog yang muncul. Untuk petunjuk, lihat Atur kondisi filter.

      • Jika Anda menggunakan fitur pemetaan nama objek untuk menentukan database atau koleksi yang menerima data, migrasi objek lain yang bergantung pada objek ini mungkin gagal.

      1. Klik Next: Advanced Settings untuk mengonfigurasi parameter lanjutan.

        Parameter

        Deskripsi

        Dedicated Cluster for Task Scheduling

        Secara default, DTS menjadwalkan tugas di kluster bersama. Anda tidak perlu memilih satu. Jika Anda menginginkan tugas yang lebih stabil, Anda dapat membeli kluster khusus untuk menjalankan tugas migrasi DTS.

        Retry Time for Failed Connections

        Setelah tugas migrasi dimulai, jika koneksi ke database sumber atau tujuan gagal, DTS melaporkan error dan segera mulai mencoba koneksi ulang. Durasi percobaan ulang default adalah 720 menit. Anda dapat menyesuaikan waktu percobaan ulang ke nilai antara 10 hingga 1.440 menit. Kami sarankan Anda mengatur durasi lebih dari 30 menit. Jika DTS terhubung kembali ke database sumber dan tujuan dalam durasi yang ditentukan, tugas migrasi akan dilanjutkan secara otomatis. Jika tidak, tugas gagal.

        Catatan

        • Untuk beberapa instans DTS yang berbagi sumber atau tujuan yang sama, waktu percobaan ulang jaringan ditentukan oleh pengaturan tugas yang terakhir dibuat.

        • Karena Anda dikenai biaya untuk tugas selama periode percobaan ulang koneksi, kami sarankan Anda menyesuaikan waktu percobaan ulang berdasarkan kebutuhan bisnis Anda, atau melepas instans DTS sesegera mungkin setelah instans database sumber dan tujuan dilepas.

        Retry Time for Other Issues

        Setelah tugas migrasi dimulai, jika terjadi masalah non-konektivitas, seperti pengecualian eksekusi DDL atau DML, di database sumber atau tujuan, DTS melaporkan error dan segera mulai mencoba operasi ulang. Durasi percobaan ulang default adalah 10 menit. Anda dapat menyesuaikan waktu percobaan ulang ke nilai antara 1 hingga 1.440 menit. Kami sarankan Anda mengatur durasi lebih dari 10 menit. Jika operasi terkait berhasil dalam durasi percobaan ulang yang ditentukan, tugas migrasi akan dilanjutkan secara otomatis. Jika tidak, tugas gagal.

        Penting

        Nilai Retry Time for Other Issues harus kurang dari nilai Retry Time for Failed Connections.

        Enable Throttling for Full Data Migration

        Selama migrasi penuh, DTS mengonsumsi sumber daya baca/tulis di database sumber dan tujuan, yang dapat meningkatkan beban database. Jika diperlukan, Anda dapat mengaktifkan pembatasan kecepatan untuk tugas migrasi penuh. Anda dapat mengatur Queries per second (QPS) to the source database, RPS of Full Data Migration, dan Data migration speed for full migration (MB/s) untuk mengurangi beban di database tujuan.

        Catatan

        • Item konfigurasi ini hanya tersedia jika Anda memilih Full Data Migration untuk Migration Types.

        • Anda juga dapat menyesuaikan kecepatan migrasi penuh setelah instans migrasi berjalan.

        Only one data type for primary key _id in a table of the data to be synchronized

        Dalam data yang akan dimigrasikan, apakah tipe data primary key _id seragam dalam satu koleksi?

        Penting

        • Pilih opsi berdasarkan kebutuhan Anda. Jika tidak, kehilangan data dapat terjadi.

        • Parameter ini hanya tersedia jika Anda memilih Full Data Migration untuk Migration Types.

        • Yes: Tipe data unik. Selama migrasi data penuh, DTS tidak memindai tipe data primary key di data sumber. Untuk satu koleksi, DTS hanya memigrasikan data yang sesuai dengan satu tipe data primary key.

        • No: Tipe data tidak unik. Selama migrasi data penuh, DTS memindai tipe data primary key di data sumber dan memigrasikan semua data.

        Enable Throttling for Incremental Data Migration

        Jika diperlukan, Anda juga dapat memilih untuk mengatur batas kecepatan untuk tugas migrasi inkremental. Anda dapat mengatur RPS of Incremental Data Migration dan Data migration speed for incremental migration (MB/s) untuk mengurangi beban di database tujuan.

        Catatan

        Environment Tag

        Anda dapat memilih tag lingkungan untuk mengidentifikasi instans. Ini opsional untuk contoh ini.

        Configure ETL

        Berdasarkan kebutuhan bisnis Anda, pilih apakah akan mengonfigurasi fitur ETL untuk memproses data.

        • Yes: Mengonfigurasi fitur ETL. Anda juga harus memasukkan pernyataan pemrosesan data di kotak teks.

        • No: Tidak mengonfigurasi fitur ETL.

        Monitoring and Alerting

        Pilih apakah akan mengatur peringatan dan menerima pemberitahuan peringatan berdasarkan kebutuhan bisnis Anda.

        • No: Tidak mengatur peringatan.

        • Yes: Konfigurasikan peringatan dengan mengatur ambang batas peringatan dan pemberitahuan peringatan. Jika migrasi gagal atau latensi melebihi ambang batas, sistem mengirim pemberitahuan peringatan.

      2. Klik Next: Data Validation untuk mengonfigurasi tugas validasi data.

        Untuk informasi lebih lanjut tentang fitur validasi data, lihat Konfigurasi validasi data.

    6. Simpan tugas dan jalankan pemeriksaan awal.

      • Untuk melihat parameter konfigurasi instans ini saat memanggil operasi API, arahkan pointer ke tombol Next: Save Task Settings and Precheck dan klik Preview OpenAPI parameters di gelembung yang muncul.

      • Jika Anda tidak perlu melihat atau telah selesai melihat parameter API, klik Next: Save Task Settings and Precheck di bagian bawah halaman.

      Catatan

      • Sebelum tugas migrasi dimulai, DTS melakukan pemeriksaan awal. Tugas hanya dimulai setelah lolos pemeriksaan awal.

      • Jika pemeriksaan awal gagal, klik View Details di sebelah item pemeriksaan yang gagal, perbaiki masalah berdasarkan petunjuk, lalu jalankan pemeriksaan awal lagi.

      • Jika peringatan dilaporkan selama pemeriksaan awal:

        • Untuk item pemeriksaan yang tidak dapat diabaikan, klik View Details di sebelah item yang gagal, perbaiki masalah berdasarkan petunjuk, lalu jalankan pemeriksaan awal lagi.

        • Untuk item pemeriksaan yang dapat diabaikan, Anda dapat mengklik Confirm Alert Details, Ignore, OK, dan Precheck Again untuk melewati item peringatan dan menjalankan pemeriksaan awal lagi. Jika Anda memilih untuk mengabaikan peringatan, hal ini dapat menyebabkan masalah seperti ketidakkonsistenan data dan menimbulkan risiko bagi bisnis Anda.

    7. Beli instans.

      1. Saat Success Rate mencapai 100%, klik Next: Purchase Instance.

      2. Di halaman Purchase, pilih spesifikasi tautan untuk instans migrasi data. Untuk informasi lebih lanjut, lihat tabel berikut.

        Kategori

        Parameter

        Deskripsi

        New Instance Class

        Resource Group Settings

        Pilih kelompok sumber daya tempat instans berada. Nilai default adalah kelompok sumber daya default. Untuk informasi lebih lanjut, lihat Apa itu Resource Management?

        Instance Class

        DTS menyediakan spesifikasi migrasi dengan tingkat kinerja berbeda. Spesifikasi tautan memengaruhi kecepatan migrasi. Anda dapat memilih spesifikasi berdasarkan skenario bisnis Anda. Untuk informasi lebih lanjut, lihat Spesifikasi tautan migrasi data.

      3. Setelah konfigurasi selesai, baca dan pilih Data Transmission Service (Pay-as-you-go) Service Terms.

      4. Klik Buy and Start. Di kotak dialog OK yang muncul, klik OK.

        Anda dapat melihat progres tugas migrasi di halaman daftar Data Migration Tasks.

        Catatan

        • Jika tugas migrasi tidak mencakup migrasi inkremental, tugas akan berhenti secara otomatis setelah migrasi penuh selesai. Setelah tugas berhenti, Status-nya berubah menjadi Completed.

        • Jika tugas migrasi mencakup migrasi inkremental, tugas tidak berhenti secara otomatis. Tugas migrasi inkremental terus berjalan. Selama tugas migrasi inkremental berjalan, Status tugas adalah Running.

    FAQ

    Mengapa saya mengalami latensi tugas dan ketidakkonsistenan data meskipun tidak ada penulisan aplikasi?

    • Penyebab: Masalah ini terjadi karena konflik antara mekanisme penghapusan otomatis indeks TTL pada koleksi MongoDB dan mekanisme sinkronisasi data DTS. Konflik ini dapat menyebabkan latensi tugas dan ketidakkonsistenan data dalam tugas sinkronisasi/migrasi Anda.

      • DELETE berlebihan mengurangi efisiensi: Saat indeks TTL sumber menghapus data yang kedaluwarsa, ia menulis catatan DELETE ke Oplog. DTS memainkan ulang DELETE ini di tujuan. Jika indeks TTL tujuan sudah menghapus data yang sama, MongoDB mengembalikan jumlah baris yang terpengaruh yang tidak sesuai, memicu penanganan pengecualian dan memperlambat migrasi.

      • Ketidakkonsistenan data akibat penghapusan TTL asinkron: Indeks TTL tidak menghapus data secara real-time. Data yang kedaluwarsa mungkin masih ada di sumber sementara tujuan sudah menghapusnya, menyebabkan ketidakkonsistenan.

        Contoh:

        Oplog atau ChangeStream MongoDB hanya mencatat bidang yang diperbarui untuk operasi UPDATE, bukan dokumen lengkap. Jika UPDATE tidak menemukan data target di tujuan, DTS mengabaikan operasi tersebut.

        Waktu

        Instans sumber

        Instans tujuan

        1

        Layanan menyisipkan data

        2

        DTS menyinkronkan operasi INSERT

        3

        Data telah kedaluwarsa tetapi belum dihapus oleh indeks TTL

        4

        Layanan memperbarui data (misalnya, memperbarui bidang indeks TTL untuk mengubah waktu kedaluwarsa)

        5

        Indeks TTL menghapus data

        6

        DTS menyinkronkan UPDATE, tetapi data tidak ditemukan. Operasi diabaikan.

        Akibatnya, dokumen ini hilang dari instans MongoDB tujuan.

    • Solusi: Untuk mengatasi hal ini, ubah sementara waktu kedaluwarsa indeks TTL di tujuan selama tugas sinkronisasi/migrasi. Hal ini memastikan efisiensi sinkronisasi dan konsistensi data. Untuk langkah-langkah detail, lihat Praktik terbaik untuk menyinkronkan atau memigrasikan koleksi dengan indeks TTL dari sumber MongoDB.