All Products
Search

This Product

    ApsaraDB for MongoDB:Migrasi kluster sharded MongoDB yang dikelola sendiri dengan DTS

    Document Center

    ApsaraDB for MongoDB:Migrasi kluster sharded MongoDB yang dikelola sendiri dengan DTS

    Last Updated:Aug 26, 2026

    Migrasikan kluster sharded MongoDB yang dikelola sendiri ke ApsaraDB for MongoDB satu shard dalam satu waktu menggunakan Data Transmission Service (DTS). Migrasi inkremental DTS menjaga aplikasi Anda tetap berjalan selama proses migrasi.

    Untuk opsi lainnya, lihat Ikhtisar solusi migrasi dan sinkronisasi data MongoDB.

    Prasyarat

    • Verifikasi bahwa versi MongoDB sumber dan tujuan Anda didukung. Periksa kombinasi versi yang didukung di Solusi migrasi.

      Solusi migrasi.

    • Pastikan setiap shard pada instans kluster sharded tujuan memiliki ruang penyimpanan yang cukup.

      Catatan

      Contoh: Jika shard terbesar di database sumber Anda menggunakan 500 GB, setiap shard pada instance tujuan harus memiliki kapasitas penyimpanan lebih dari 500 GB.

      Jika database sumber Anda berukuran 500 GB, setiap shard pada instans tujuan harus memiliki ruang penyimpanan lebih dari 500 GB.

    Cara kerja

    DTS melakukan migrasi kluster sharded satu shard dalam satu waktu. Buat tugas migrasi terpisah untuk setiap shard.

    Catatan

    Distribusi data bergantung pada kunci shard yang Anda konfigurasikan. Konfigurasi sharding data untuk memaksimalkan kinerja shard.

    Migration architecture

    Catatan penggunaan

    • Migrasi data penuh memberikan beban tambahan pada database sumber dan tujuan. Lakukan migrasi selama jam sepi untuk menghindari gangguan layanan.

      menghindari gangguan layanan.

    • Saat melakukan migrasi lintas versi atau mesin penyimpanan, verifikasi kompatibilitas terlebih dahulu di Versi dan mesin penyimpanan.

      Versi dan mesin penyimpanan terlebih dahulu.

    • DTS menulis data secara konkuren, sehingga database tujuan mungkin memerlukan ruang penyimpanan 5% hingga 10% lebih banyak dibandingkan sumber.

      Database mungkin menggunakan penyimpanan 5% hingga 10% lebih besar daripada sumbernya.

    • Pastikan tujuan tidak memiliki dokumen dengan kunci primary (_id secara default) yang sama dengan sumber. Jika terjadi konflik dan penghapusannya tidak memengaruhi bisnis Anda, hapus dokumen yang bertentangan dari tujuan sebelum migrasi.

      Pastikan tujuan tidak memiliki dokumen dengan kunci primary (_id secara default) yang sama dengan sumber. Jika terjadi konflik dan penghapusan tidak memengaruhi bisnis Anda, hapus dokumen yang bertentangan dari tujuan sebelum migrasi.

    • Database admin dan local tidak dapat digunakan sebagai sumber atau tujuan.

      tidak dapat digunakan sebagai sumber atau tujuan.

    • Kluster sharded MongoDB sumber dapat memiliki hingga 10 node mongos.

      Mendukung hingga 10 node Mongos (Proxy Layanan).

    Penagihan

    Jenis migrasi

    Biaya konfigurasi tugas

    Biaya traffic Internet

    Migrasi data penuh

    Gratis.

    Data yang dimigrasikan keluar dari Alibaba Cloud melalui Internet publik dikenai biaya. Harga DTS.

    Migrasi data inkremental

    Dikenai biaya. .Harga DTS

    Jenis migrasi

    • Migrasi data penuh: Menyalin semua data yang ada dari objek sumber yang dipilih ke tujuan.

      Catatan

      Mencakup database, koleksi, dan indeks.

      n1y_f19">

      Mencakup database, koleksi, dan indeks.

    • Migrasi data inkremental: Setelah migrasi penuh selesai, DTS terus menyinkronkan perubahan data dari sumber ke tujuan.

      Catatan

      • DTS menyinkronkan operasi pembuatan dan penghapusan database, koleksi, dan indeks.

      • DTS menyinkronkan operasi pembuatan, pembaruan, dan penghapusan dokumen.

      dan operasi penghapusan untuk database, koleksi, dan indeks.

    • DTS menyinkronkan operasi pembuatan, pembaruan, dan penghapusan dokumen.

      te, serta operasi pembaruan dokumen.

    Izin akun database

    Database

    Migrasi data penuh

    Migrasi data inkremental

    Database MongoDB yang dikelola sendiri

    read izin pada database yang akan dimigrasikan.

    read izin pada database yang akan dimigrasikan, serta pada database admin dan local.

    Instans ApsaraDB for MongoDB

    readWrite izin pada database tujuan.

    readWrite izin pada database tujuan.

    Untuk membuat akun database dan memberikan izin:

    Sebelum memulai

    1. Wajib: Nonaktifkan balancer selama migrasi untuk mencegah ketidakkonsistenan data. Kelola balancer instans MongoDB.

      Peringatan

      Jika balancer tidak dinonaktifkan, migrasi chunk dapat memengaruhi konsistensi data yang dibaca oleh Data Transmission Service (DTS).

      Jika balancer tidak dinonaktifkan, migrasi chunk dapat memengaruhi konsistensi data yang dibaca oleh Data Transmission Service (DTS).

    2. Hapus dokumen yatim yang dihasilkan oleh migrasi chunk gagal dari database sumber.

      Catatan

      Dokumen yatim dapat menurunkan kinerja migrasi dan menyebabkan konflik _id yang mengakibatkan error.

      1. Unduh skrip cleanupOrphaned.js.

        wget "https://docs-aliyun.cn-hangzhou.oss.aliyun-inc.com/assets/attach/120562/cn_zh/1564451237979/cleanupOrphaned.js"

      2. Pada skrip cleanupOrphaned.js, ganti test dengan nama database yang akan dibersihkan.

        Catatan

        Jika Anda memiliki beberapa database, ulangi langkah ini dan langkah c.

        function cleanupOrphaned(coll) {
  var nextKey = { };
  var result;
  while ( nextKey != null ) {
    result = db.adminCommand( { cleanupOrphaned: coll, startingFromKey: nextKey } );
    if (result.ok != 1)
      print("Unable to complete at this time: failure or timeout.")
    printjson(result);
    nextKey = result.stoppedAtKey;
  }
}
var dbName = 'test'
db = db.getSiblingDB(dbName)
db.getCollectionNames().forEach(function(collName) {
        cleanupOrphaned(dbName + "." + collName);
});

      3. Jalankan perintah ini pada setiap shard untuk menghapus dokumen yatim dari semua koleksi dalam database tersebut.

        Catatan

        Jalankan pada setiap shard.

        mongo --host <Shardhost> --port <Primaryport>  --authenticationDatabase <database> -u <username> -p <password> cleanupOrphaned.js
        Catatan

        • <Shardhost>: Alamat IP shard.

        • <Primaryport>: Port layanan node primary dalam shard.

        • <database>: Database otentikasi untuk akun tersebut.

        • <username>: Akun database.

        • <password>: Kata sandi akun.

        Contoh dengan tiga shard:

        mongo --host 172.16.1.10 --port 27018  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
        mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
        mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

      d826nfg"><password>: Kata sandi akun.

    3. Contoh dengan tiga shard:

      5. mongo --host 172.16.1.10 --port 27018  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
      mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
      mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

    5. >mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

      6. mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

    Buat database dan koleksi yang memerlukan sharding pada instans tujuan, lalu konfigurasikan sharding data. Konfigurasi sharding data untuk memaksimalkan kinerja shard.

    Catatan

    Mengonfigurasi sharding sebelum migrasi mencegah seluruh data masuk ke satu shard dan melebihi kapasitas penyimpanannya.

    ote" id="note_keh_seo_9uz">>

    Mengonfigurasi sharding sebelum migrasi mencegah seluruh data masuk ke satu shard dan melebihi kapasitas penyimpanannya.

    Batasan

    Batasan database sumber

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

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

    • DTS menggunakan sumber daya baca dan tulis pada database sumber dan tujuan selama migrasi data penuh, yang meningkatkan beban server. Jalankan migrasi selama 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 setidaknya selama 7 hari. Jika oplog tidak diaktifkan, pesan error dikembalikan selama pemeriksaan awal dan tugas migrasi data tidak dapat dimulai. Jika DTS tidak dapat memperoleh oplog, tugas gagal dan ketidakkonsistenan atau kehilangan data mungkin terjadi. Persyaratan retensi ini berada di luar perjanjian tingkat layanan (SLA) DTS.

    • Jika Anda memilih koleksi sebagai objek migrasi dan berencana mengeditnya di tujuan (seperti mengganti nama), satu tugas mendukung hingga 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 dengan indeks time to live (TTL). Indeks TTL dapat menyebabkan ketidakkonsistenan data antara sumber dan tujuan setelah migrasi.

    • Pastikan tidak ada dokumen yatim 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 ini 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 memperkenalkan 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 kunci shard ke semua data di database sumber sebelum memulai migrasi. Selama migrasi, operasi INSERT harus menyertakan kunci shard, dan operasi UPDATE tidak boleh memodifikasi kunci shard.

    • 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 sudah berisi dokumen dengan kunci primary (_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 kunci primary atau kunci unik saat DTS menulis ke tujuan, DTS melewati penulisan yang bertentangan dan mempertahankan data yang ada.

    • Jangan melakukan scaling instans kluster sharded ApsaraDB for MongoDB saat 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, meningkatkan beban server. Jalankan migrasi selama 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 lepaskan tugas yang gagal, atau cabut izin tulis DTS pada tujuan. Jika tidak, data sumber akan menimpa data tujuan saat tugas yang gagal dilanjutkan.

    • 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 tujuan 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.

        ke alamat IP dan port node primary, atau konfigurasikan titik akhir high-availability. Lihat Buat tugas DTS dengan database sumber atau tujuan berupa database MongoDB high-availability.

      • Jika terhubung melalui Database yang Dikelola Sendiri di ECS: atur Port Number ke port node primary.

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

    Migrasi data

    Sebelum memulai

    Selesaikan langkah-langkah berikut sebelum membuat tugas DTS.

    Langkah 1: Nonaktifkan balancer database sumber

    Nonaktifkan balancer pada database MongoDB yang dikelola sendiri untuk mencegah migrasi chunk memengaruhi konsistensi data selama tugas DTS.

    Peringatan

    Jika balancer aktif selama migrasi, migrasi chunk menyebabkan DTS membaca data yang tidak konsisten.

    Untuk petunjuknya, lihat Kelola balancer ApsaraDB for MongoDB.

    Langkah 2: Hapus dokumen yatim dari database sumber

    Dokumen yatim yang tersisa dari migrasi chunk gagal mengganggu kinerja migrasi, dapat membuat nilai _id duplikat, dan dapat menyebabkan data yang tidak diinginkan ikut dimigrasikan.

    1. Unduh file cleanupOrphaned.js:

      wget "https://docs-aliyun.cn-hangzhou.oss.aliyun-inc.com/assets/attach/120562/cn_zh/1564451237979/cleanupOrphaned.js"

    2. Pada file cleanupOrphaned.js, ganti test dengan nama database tempat Anda ingin menghapus dokumen yatim.

      Untuk menghapus dokumen yatim dari beberapa database, ulangi langkah ini dan langkah berikutnya untuk setiap database.

      Replace the database name in cleanupOrphaned.js

    3. Jalankan perintah berikut pada setiap shard untuk menghapus dokumen yatim dari semua koleksi dalam database yang ditentukan:

      Jalankan perintah ini pada setiap shard.

      Placeholder

      Deskripsi

      <Shardhost>

      Alamat IP shard

      <Primaryport>

      Port layanan node primary dalam shard

      <database>

      Nama database tempat akun tersebut berada

      <username>

      Akun yang digunakan untuk login ke database MongoDB yang dikelola sendiri

      <password>

      Kata sandi yang digunakan untuk login ke database MongoDB yang dikelola sendiri

      mongo --host <Shardhost> --port <Primaryport> --authenticationDatabase <database> -u <username> -p <password> cleanupOrphaned.js

      Contoh: Untuk database sumber dengan tiga shard:

      mongo --host 172.16.1.10 --port 27018  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

    Langkah 3: Konfigurasi sharding pada instans tujuan (hanya untuk kluster sharded)

    Jika tujuan adalah instans kluster sharded, buat database dan koleksi yang akan di-shard serta konfigurasi sharding data sebelum memulai migrasi. Hal ini mendistribusikan data yang dimigrasikan secara merata di seluruh shard dan mencegah satu shard kelebihan beban.

    Lihat Konfigurasi sharding untuk memaksimalkan kinerja shard.

    Langkah 1: Buka halaman Migrasi Data

    Gunakan salah satu metode berikut untuk membuka halaman Data Migration dan 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 drop-down 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: Konfigurasi database sumber dan tujuan

    Peringatan

    Setelah mengonfigurasi database sumber dan tujuan, baca Batasan yang ditampilkan di bagian atas halaman. Melewatkan langkah ini dapat menyebabkan tugas gagal atau menghasilkan ketidakkonsistenan data.

    Konfigurasikan parameter berikut:

    Umum

    Parameter

    Deskripsi

    Task Name

    DTS menghasilkan nama tugas secara otomatis. Tentukan nama deskriptif agar tugas mudah diidentifikasi. Nama unik tidak diperlukan.

    Database sumber

    Parameter

    Deskripsi

    Select Existing Connection

    Jika instans telah terdaftar di DTS, pilih dari daftar drop-down — DTS akan mengisi parameter lainnya secara otomatis. Jika tidak, konfigurasikan parameter di bawah ini. Di Konsol DMS, pilih dari daftar Select a DMS database instance.

    Database Type

    Pilih MongoDB.

    Access Method

    Pilih metode koneksi. Contoh ini menggunakan Alamat IP Publik. Untuk metode lain, siapkan lingkungan jaringan terlebih dahulu. Lihat Ikhtisar persiapan.

    Instance Region

    Wilayah tempat database sumber berada. Jika wilayah tidak tercantum, pilih yang paling dekat secara geografis.

    Architecture

    Pilih Sharded Cluster. Opsi ini hanya muncul untuk metode akses Express Connect, VPN Gateway, Smart Access Gateway, Alamat IP Publik, atau Cloud Enterprise Network (CEN).

    Migration Method

    Pilih metode untuk migrasi data inkremental: Oplog (direkomendasikan) atau ChangeStream. Oplog tersedia saat oplog diaktifkan di sumber (diaktifkan secara default baik di database yang dikelola sendiri maupun instans ApsaraDB for MongoDB) dan menyediakan migrasi inkremental dengan latensi rendah. ChangeStream tersedia saat change streams diaktifkan. Lihat Change Streams. Jika sumber adalah kluster Amazon DocumentDB yang tidak elastis, pilih hanya ChangeStream. Jika Architecture diatur ke Sharded Cluster, parameter Shard account dan Shard password tidak diperlukan.

    Endpoint Type

    Pilih Standalone atau Multi-node berdasarkan pengaturan Anda. Parameter ini hanya muncul untuk metode akses Express Connect, VPN Gateway, Smart Access Gateway, Alamat IP Publik, atau Cloud Enterprise Network (CEN).

    Mongos Domain Name or IP Address

    Titik akhir atau alamat IP node mongos mana pun. Muncul hanya saat Endpoint Type adalah Standalone. Atur Domain Name or IP ke alamat node mongos mana pun dan Port Number ke port-nya.

    Port Number

    Port layanan node mongos. Muncul hanya saat Endpoint Type adalah Standalone. Port harus dapat diakses melalui Internet.

    Mongos endpoint

    Titik akhir database sumber dalam format <IP>:<Port>. Muncul hanya saat Endpoint Type adalah Multi-node. Pisahkan beberapa titik akhir dengan line feed. Gunakan nama domain yang dapat diakses publik jika memungkinkan.

    Authentication Database

    Database otentikasi untuk sumber. Default: admin.

    Database Account

    Akun untuk mengakses node Mongos. Jika Access Method adalah Self-managed Database on ECS atau Database Gateway, masukkan akun akses shard sebagai gantinya.

    Database Password

    Kata sandi untuk akun database.

    Access to Multiple Shard Nodes

    Informasi akses untuk node shard. Tersedia hanya saat arsitektur sumber adalah Sharded Cluster, Migration Method adalah Oplog, dan Endpoint Type adalah Multi-node. Klik Add, masukkan setiap titik akhir node shard dalam format <IP>:<Port> (satu per baris), dan ulangi untuk semua shard.

    Shard access information (IP:Port)

    Alamat IP dan port setiap shard, dalam format IP:Port. Muncul hanya saat Endpoint Type adalah Standalone. Pisahkan beberapa shard dengan koma.

    Shard account

    Akun untuk mengakses shard di database sumber.

    Shard password

    Kata sandi untuk akun shard.

    Encryption

    Metode enkripsi koneksi: Tidak terenkripsi, SSL-terenkripsi, atau Mongo Atlas SSL. Opsi yang tersedia bergantung pada pengaturan Access Method dan Architecture. Jika Architecture adalah Sharded Cluster dan Migration Method adalah Oplog, SSL-terenkripsi tidak tersedia untuk ApsaraDB for MongoDB. Jika sumber menggunakan arsitektur Set Replika, Access Method bukan Alibaba Cloud Instance, dan Encryption adalah SSL-terenkripsi, unggah sertifikat CA untuk memverifikasi koneksi.

    Database tujuan

    Parameter

    Deskripsi

    Select Existing Connection

    Jika instans telah terdaftar di DTS, pilih dari daftar drop-down. Jika tidak, konfigurasikan parameter di bawah ini.

    Database Type

    Pilih MongoDB.

    Access Method

    Pilih Alibaba Cloud Instance.

    Instance Region

    Wilayah tempat instans ApsaraDB for MongoDB tujuan berada.

    Replicate Data Across Alibaba Cloud Accounts

    Pilih No untuk menggunakan instans di akun saat ini.

    Architecture

    Arsitektur instans tujuan.

    Instance ID

    ID instans ApsaraDB for MongoDB tujuan.

    Authentication Database

    Database otentikasi untuk tujuan. Default: admin.

    Database Name

    Nama database tujuan yang menerima objek yang dimigrasikan.

    Database Account

    Akun database untuk instans tujuan.

    Database Password

    Kata sandi untuk akun database tujuan.

    Encryption

    Metode enkripsi koneksi. Opsi yang tersedia bergantung pada pengaturan Access Method dan Architecture. Jika tujuan adalah instans ApsaraDB for MongoDB dengan arsitektur Sharded Cluster, SSL-terenkripsi tidak tersedia.

    Langkah 4: Uji konektivitas

    Klik Test Connectivity and Proceed.

    Pastikan blok CIDR server DTS telah ditambahkan ke pengaturan keamanan database sumber dan tujuan. Untuk informasi selengkapnya, lihat Menambahkan blok CIDR server DTS. Jika sumber atau tujuan merupakan database yang dikelola sendiri dan tidak terhubung sebagai Alibaba Cloud Instance, klik Test Connectivity pada kotak dialog CIDR Blocks of DTS Servers.

    Langkah 5: Konfigurasi objek migrasi

    Di halaman Configure Objects, konfigurasikan parameter berikut:

    Parameter

    Deskripsi

    Migration Types

    Pilih jenis migrasi berdasarkan 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

    Periksa Awal dan Laporkan Error: memeriksa apakah tujuan memiliki koleksi dengan nama yang sama dengan 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. Abaikan Error dan Lanjutkan: melewati pemeriksaan awal untuk nama koleksi duplikat. Selama migrasi data penuh, jika suatu catatan memiliki kunci primary yang sama dengan catatan yang ada di tujuan, catatan yang ada dipertahankan. Selama migrasi data inkremental, catatan yang 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: Kebijakan default DTS. 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 image. Jika pemetaan nama objek digunakan, objek lain yang bergantung pada objek yang dipetakan mungkin gagal dimigrasikan.

    Klik Next: Advanced Settings untuk mengonfigurasi hal berikut:

    Parameter

    Deskripsi

    Dedicated Cluster for Task Scheduling

    DTS menjadwalkan tugas ke kluster bersama secara default. Untuk stabilitas yang lebih tinggi, beli kluster khusus. Lihat Apa itu kluster khusus DTS.

    Retry Time for Failed Connections

    Jendela coba ulang untuk kegagalan koneksi setelah tugas dimulai. Nilai valid: 10–1.440 menit. Default: 720 menit. Atur minimal 30 menit. Jika DTS terhubung kembali dalam jendela ini, tugas dilanjutkan. Jika tidak, tugas gagal. Saat beberapa tugas berbagi database yang sama, waktu coba ulang yang paling baru diatur berlaku. DTS mengenakan biaya untuk instans selama coba ulang.

    Retry Time for Other Issues

    Jendela coba ulang untuk kegagalan operasi DDL atau DML. Nilai valid: 1–1.440 menit. Default: 10 menit. Atur lebih dari 10 menit. Harus kurang dari Retry Time for Failed Connections.

    Enable Throttling for Full Data Migration

    Membatasi penggunaan sumber daya DTS selama migrasi data penuh. Konfigurasikan Queries per second (QPS) to the source database, RPS of Full Data Migration, dan Kecepatan migrasi data untuk migrasi penuh (MB/s). Tersedia hanya saat Full Data Migration dipilih.

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

    Menentukan apakah kunci primary _id memiliki tipe data unik dalam setiap koleksi. Yes: DTS melewati pemindaian tipe data kunci primary dan memigrasikan satu tipe per koleksi. No: DTS memindai dan memigrasikan semua tipe data kunci primary. Aktifkan berdasarkan data Anda. Konfigurasi yang salah dapat menyebabkan kehilangan data. Tersedia hanya saat Full Data Migration dipilih.

    Enable Throttling for Incremental Data Migration

    Membatasi penggunaan sumber daya DTS selama migrasi data inkremental. Konfigurasikan RPS of Incremental Data Migration dan Kecepatan migrasi data untuk migrasi inkremental (MB/s). Tersedia hanya saat Incremental Data Migration dipilih.

    Environment Tag

    Tag untuk mengidentifikasi instans DTS. Opsional.

    Configure ETL

    Mengaktifkan fitur ekstrak, transformasi, dan muat (ETL). Pilih Yes untuk memasukkan pernyataan pemrosesan data di editor kode. Lihat Konfigurasi ETL dalam tugas migrasi data atau sinkronisasi data. Pilih No untuk melewati ETL.

    Monitoring and Alerting

    Mengonfigurasi peringatan untuk tugas. Pilih Yes untuk mengatur ambang batas peringatan dan kontak notifikasi. Lihat Konfigurasi pemantauan dan peringatan saat membuat tugas DTS.

    Klik Next Step: Data Verification untuk mengonfigurasi verifikasi data. Lihat Konfigurasi 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 lalu 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 Tingkat Keberhasilan 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: kelompok sumber daya default. Lihat Apa itu Manajemen Sumber Daya?

      Instance Class

      Kelas instans menentukan kecepatan migrasi. Pilih berdasarkan kebutuhan Anda. Lihat Kelas instans untuk instans migrasi data.

    3. Baca dan setujui Ketentuan Layanan Data Transmission Service (Bayar Sesuai Pemakaian) dengan mencentang kotak centang tersebut.

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

    Tugas muncul di halaman Data Migration.

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

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

    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 menghentikan 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, seperti selama jam sepi atau sebelum beralih beban kerja ke instans tujuan.

    1. Tunggu hingga Incremental Data Migration muncul di bilah kemajuan Berjalan dan Tidak Tertunda muncul di Info Operasi. Lalu hentikan penulisan data ke database sumber selama beberapa menit.

    2. Setelah status Incremental Data Migration kembali ke Tidak Tertunda, hentikan secara manual tugas migrasi untuk semua shard.

    Langkah 10: Alihkan beban kerja ke instans tujuan

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