Migrasi set replika ke set replika atau kluster sharded - ApsaraDB for MongoDB

Topik ini menjelaskan cara menggunakan DTS untuk memigrasikan data dari instans set replika ApsaraDB for MongoDB ke instans set replika atau kluster sharded ApsaraDB for MongoDB.

Database sumber dan tujuan yang didukung

Database sumber (set replika)	Database tujuan (set replika 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 menjelaskan proses konfigurasi menggunakan contoh instans ApsaraDB for MongoDB (set replika) dan instans ApsaraDB for MongoDB (set replika atau kluster sharded). Proses konfigurasi serupa untuk sumber data lainnya.

Prasyarat

Instans set replika sumber ApsaraDB for MongoDB dan instans tujuan ApsaraDB for MongoDB (set replika atau kluster sharded) telah dibuat. Untuk informasi selengkapnya, lihat Buat instans set replika dan Buat instans kluster sharded.

Catatan
Untuk informasi versi yang didukung, lihat Ikhtisar solusi migrasi.
Ruang penyimpanan instans tujuan ApsaraDB for MongoDB harus 10% lebih besar daripada ruang penyimpanan yang digunakan oleh instans sumber ApsaraDB for MongoDB.
Jika instans tujuan ApsaraDB for MongoDB adalah kluster sharded, buat database dan koleksi yang memerlukan sharding, konfigurasikan sharding data, aktifkan balancer, dan lakukan pre-sharding di instans tujuan ApsaraDB for MongoDB sesuai kebutuhan. Untuk informasi selengkapnya, lihat Siapkan sharding data untuk memaksimalkan kinerja shard dan Cara menangani distribusi data tidak merata dalam kluster sharded MongoDB.

Catatan
Konfigurasi sharding data mencegah data dimigrasikan hanya ke satu shard, sehingga memastikan kinerja kluster optimal. Mengaktifkan balancer dan melakukan pre-sharding mencegah kesenjangan data.

Catatan penggunaan

Tipe	Deskripsi
Batasan database sumber	Persyaratan bandwidth: Server yang menghosting database sumber harus memiliki bandwidth keluar yang cukup. Jika tidak, kecepatan migrasi akan terpengaruh. Koleksi yang akan dimigrasikan harus memiliki primary key atau kendala UNIK, dan bidang tersebut harus unik. Jika tidak, data duplikat mungkin ada di database tujuan. Jika Anda memigrasikan data tingkat koleksi dan perlu mengedit koleksi, seperti memetakan nama koleksi, satu tugas migrasi data hanya dapat memigrasikan maksimal 1.000 koleksi. Jika melebihi batas ini, kesalahan akan dilaporkan setelah Anda mengirimkan tugas. Dalam hal ini, bagi koleksi menjadi beberapa tugas migrasi, atau konfigurasikan tugas untuk memigrasikan seluruh database. Satu data yang akan dimigrasikan dari database sumber tidak boleh melebihi 16 MB. Jika tidak, tugas akan gagal. Jika database sumber adalah Azure Cosmos DB for MongoDB atau kluster elastis Amazon DocumentDB, hanya migrasi penuh yang didukung. Untuk melakukan migrasi inkremental: Untuk migrasi inkremental, Anda harus mengaktifkan Oplog pada database sumber dan memastikan Oplog disimpan selama minimal tujuh hari. Atau, Anda dapat mengaktifkan Change Streams dan memastikan DTS dapat berlangganan perubahan data di database sumber dari tujuh hari terakhir melalui Change Streams. Jika tidak, tugas mungkin gagal karena tidak dapat memperoleh perubahan data dari sumber. Dalam kasus ekstrem, ketidakkonsistenan data atau kehilangan data dapat terjadi. Masalah yang disebabkan oleh hal ini tidak dicakup oleh Perjanjian Tingkat Layanan (SLA). Penting Peroleh perubahan data dari database sumber menggunakan Oplog. Hanya MongoDB 4.0 ke atas yang mendukung perolehan perubahan data melalui Change Streams. Jika database sumber adalah Amazon DocumentDB (kluster non-elastis), Anda harus mengaktifkan Change Streams secara manual, memilih Migration Method sebagai ChangeStream, dan memilih Architecture sebagai Sharded Cluster. Batasan operasi database sumber: Selama migrasi skema dan migrasi data penuh, jangan mengubah skema database atau koleksi. Ini termasuk memperbarui data tipe array. Jika tidak, tugas migrasi data mungkin gagal, atau ketidakkonsistenan data dapat terjadi antara database sumber dan tujuan. Jika Anda hanya melakukan migrasi data penuh, jangan menulis data baru ke instans sumber. Jika tidak, ketidakkonsistenan data akan terjadi antara database sumber dan tujuan. Untuk menjaga konsistensi data 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 atau latensi instans mungkin terjadi.
Batasan lainnya	Jika instans tujuan adalah kluster sharded: Bersihkan dokumen yatim (orphaned documents). Jika tidak, kinerja migrasi akan terpengaruh. Jika dokumen dengan nilai `_id` yang bertentangan ditemukan selama migrasi, ketidakkonsistenan data atau kegagalan tugas mungkin terjadi. Sebelum tugas dimulai, tambahkan kunci sharding ke data sumber yang sesuai dengan kunci sharding di tujuan. Jika Anda tidak dapat menambahkan kunci sharding ke sumber, lihat Migrasi data dari instans MongoDB tanpa kunci sharding ke kluster sharded MongoDB. Setelah tugas dimulai, data yang akan dimigrasikan harus menyertakan kunci sharding saat Anda menggunakan perintah INSERT. Anda tidak dapat mengubah kunci sharding saat menggunakan perintah UPDATE. Jika instans tujuan adalah set replika: Ketika Access Method adalah Express Connect, VPN Gateway, or Smart Access Gateway, Public IP Address, atau Cloud Enterprise Network (CEN), Anda harus memasukkan alamat dan port node primer di kolom Domain Name or IP dan Port Number, atau konfigurasikan titik akhir koneksi ketersediaan tinggi. Untuk informasi selengkapnya tentang titik akhir koneksi ketersediaan tinggi, lihat Buat Instans dengan Database Sumber atau Tujuan Berupa Instans MongoDB Ketersediaan Tinggi. Ketika Access Method adalah Self-managed Database on ECS, Anda harus memasukkan port node primer untuk Port Number. Menghubungkan ke database MongoDB menggunakan rekaman SRV tidak didukung. Pastikan versi database MongoDB sumber dan tujuan sama, atau migrasikan dari versi lebih lama ke versi lebih baru untuk memastikan kompatibilitas. Jika Anda memigrasikan dari versi lebih baru ke versi lebih lama, masalah kompatibilitas mungkin terjadi. Data di database admin, config, dan local tidak dapat dimigrasikan. Jika koleksi tujuan memiliki indeks unik atau properti `capped`-nya diatur ke `true`, replay konkuren tidak didukung untuk koleksi tersebut selama migrasi inkremental. Hanya penulisan single-threaded yang didukung. Hal ini dapat meningkatkan latensi tugas. Informasi transaksi tidak dipertahankan. Transaksi dari database sumber dikonversi menjadi catatan individual di database tujuan. Ketika Data Transmission Service (DTS) menulis data ke koleksi tujuan, jika terjadi konflik primary key atau unique key, DTS akan melewati pernyataan tulis yang bersangkutan dan mempertahankan data yang sudah ada di koleksi tujuan. Jika versi MongoDB sumber lebih awal dari 3.6 dan versi MongoDB tujuan 3.6 atau lebih baru, urutan bidang dalam data mungkin tidak konsisten sebelum dan sesudah migrasi. Hal ini disebabkan oleh perbedaan rencana eksekusi mesin database. Pasangan bidang-nilai tetap konsisten. Jika bisnis Anda melibatkan kueri pencocokan teks pada struktur bersarang, evaluasi potensi dampak ketidakkonsistenan urutan bidang terhadap bisnis Anda. Evaluasi kinerja database sumber dan tujuan sebelum migrasi. Migrasikan data selama jam sepi. Selama migrasi data penuh, DTS mengonsumsi sumber daya baca dan tulis di kedua database, yang dapat meningkatkan beban kerja database. Migrasi data penuh melibatkan operasi INSERT konkuren, yang menyebabkan fragmentasi di koleksi tujuan. Setelah migrasi penuh selesai, ruang penyimpanan yang digunakan oleh koleksi tujuan akan lebih besar daripada koleksi sumber. Konfirmasi apakah presisi migrasi yang disediakan DTS untuk kolom tipe data FLOAT atau DOUBLE memenuhi kebutuhan bisnis Anda. DTS membaca nilai kolom tersebut menggunakan `ROUND(COLUMN,PRECISION)`. Jika Anda tidak 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 Anda mengalihkan bisnis ke instans tujuan, Anda harus mengakhiri atau melepas tugas, atau menjalankan perintah `revoke` untuk mencabut izin tulis akun yang digunakan DTS untuk mengakses instans tujuan. Hal ini mencegah data sumber menimpa data di instans tujuan jika tugas dilanjutkan secara otomatis. Karena DTS menulis data secara konkuren, ruang penyimpanan yang digunakan oleh database tujuan 5% hingga 10% lebih besar daripada database sumber. Untuk menghitung jumlah dokumen di database MongoDB tujuan, gunakan sintaks `db.$table_name.aggregate([{ $count:"myCount"}])`. Pastikan database MongoDB tujuan tidak memiliki primary key yang sama (secara default, _id) dengan database sumber. Jika tidak, kehilangan data akan terjadi. Jika database tujuan memiliki primary key yang sama dengan sumber, bersihkan data terkait dari database tujuan tanpa memengaruhi bisnis Anda. Artinya, hapus dokumen di database tujuan yang memiliki `_id` yang sama dengan dokumen di sumber. 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 untuk koleksi sharded di database MongoDB. Anda tidak dapat memigrasikan `capped collection` jika database sumber adalah MongoDB 5.0 atau lebih baru dan database tujuan adalah versi sebelum 5.0. Hal ini dapat menyebabkan tugas migrasi gagal atau ketidakkonsistenan data antara database sumber dan tujuan. Hal ini karena perilaku `capped collection` berubah di MongoDB 5.0. Perilaku baru memungkinkan penghapusan eksplisit dan memungkinkan dokumen bertambah ukuran saat diperbarui. Versi kernel database sebelumnya tidak kompatibel dengan fitur-fitur baru ini. Koleksi time-series yang diperkenalkan di MongoDB 5.0 dan lebih baru tidak didukung untuk migrasi.
Kasus khusus	Jika database sumber adalah instans MongoDB yang dikelola sendiri: Alih bencana primer/sekunder di database sumber selama migrasi akan menyebabkan tugas migrasi gagal. Latensi yang dilaporkan oleh DTS dihitung dengan membandingkan timestamp catatan data terakhir yang dimigrasikan dengan timestamp saat ini. Jika database sumber belum diperbarui dalam waktu lama, informasi latensi mungkin tidak akurat. Jika tugas menunjukkan latensi tinggi, Anda dapat melakukan operasi pembaruan di database sumber untuk memperbarui informasi latensi. Catatan Jika Anda memilih untuk memigrasikan seluruh database, Anda juga dapat membuat tabel heartbeat. Tabel heartbeat diperbarui atau ditulis setiap detik.

Penagihan

Tipe migrasi	Biaya konfigurasi instans	Biaya lalu lintas Internet
Migrasi skema dan migrasi data penuh	Gratis.	Saat parameter Access Method 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 selengkapnya, lihat Ikhtisar penagihan.

Tipe migrasi

Tipe	Deskripsi
Migrasi skema	DTS memigrasikan skema objek yang dipilih dari instans sumber ApsaraDB for MongoDB ke instans tujuan ApsaraDB for MongoDB. Catatan DTS mendukung migrasi skema untuk database, koleksi, dan indeks.
Migrasi data penuh	DTS memigrasikan semua data yang ada untuk objek yang dipilih dari instans sumber ApsaraDB for MongoDB ke instans tujuan ApsaraDB for MongoDB. Catatan DTS mendukung migrasi data penuh untuk database dan koleksi.
Migrasi data inkremental	Setelah migrasi data penuh, DTS mereplikasi perubahan data berkelanjutan dari instans sumber ApsaraDB for MongoDB ke instans tujuan ApsaraDB for MongoDB. Gunakan oplog DTS tidak mereplikasi data dari database yang dibuat setelah tugas dimulai. Pembaruan inkremental berikut didukung: CREATE COLLECTION dan CREATE INDEX DROP DATABASE, DROP COLLECTION, dan DROP INDEX 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. Gunakan change streams 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	Schema migration	Full data migration	Incremental data migration
Instans sumber ApsaraDB for MongoDB	Izin baca pada database yang akan dimigrasikan dan database config.		Izin baca pada database yang akan dimigrasikan, database admin, dan database local.
Instans tujuan ApsaraDB for MongoDB	Izin dbAdminAnyDatabase, izin readWrite pada database tujuan, dan izin baca pada database local.

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

Prosedur

Buka halaman daftar tugas migrasi untuk wilayah tujuan menggunakan salah satu metode berikut.
Dari konsol DTS
1. Login 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 mungkin berbeda tergantung pada mode dan tata letak konsol DMS. Untuk informasi selengkapnya, lihat Konsol mode sederhana dan Sesuaikan tata letak dan gaya konsol DMS.
1. Login 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.
Klik Create Task untuk membuka halaman konfigurasi tugas.

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 mungkin 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 di bawah secara manual.
	Database Type	Pilih MongoDB.
	Connection Type	Pilih Cloud Instance.
	Instance Region	Pilih wilayah tempat instans sumber ApsaraDB for MongoDB 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 architecture. replica set architecture: Model penyebaran yang menggunakan beberapa node untuk memastikan ketersediaan tinggi dan mengaktifkan pemisahan baca/tulis. Untuk informasi selengkapnya, lihat replica set architecture. sharded cluster architecture: Model penyebaran yang terdiri dari komponen mongos, shard, dan ConfigServer. Anda dapat menyesuaikan jumlah dan konfigurasi node mongos dan shard. Untuk informasi selengkapnya, lihat sharded cluster architecture.
	Migration Method	Pilih metode untuk migrasi data inkremental berdasarkan kebutuhan Anda. Oplog (Direkomendasikan): Opsi ini tersedia jika Oplog diaktifkan untuk database sumber. Catatan Oplog diaktifkan secara default untuk database MongoDB yang dikelola sendiri dan instans ApsaraDB for MongoDB. Metode ini menawarkan latensi lebih rendah untuk migrasi data inkremental karena log ditarik lebih cepat. Oleh karena itu, kami sarankan Anda 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 sumber ApsaraDB for MongoDB.
	Authentication Database Name	Masukkan nama database tempat akun database instans sumber ApsaraDB for MongoDB berada. Nilai default-nya adalah admin.
	Database Account	Masukkan akun database instans sumber ApsaraDB for MongoDB. Untuk persyaratan izin, lihat Izin akun database.
	Database Password	Masukkan kata sandi untuk akun database.
	Encryption
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 di bawah secara manual.
	Database Type	Pilih MongoDB.
	Connection Type	Pilih Cloud Instance.
	Instance Region	Pilih wilayah tempat instans tujuan ApsaraDB for MongoDB 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 architecture: Model penyebaran yang menggunakan beberapa node untuk memastikan ketersediaan tinggi dan mengaktifkan pemisahan baca/tulis. Untuk informasi selengkapnya, lihat replica set architecture. sharded cluster architecture: Model penyebaran yang terdiri dari komponen mongos, shard, dan ConfigServer. Anda dapat menyesuaikan jumlah dan konfigurasi node mongos dan shard. Untuk informasi selengkapnya, lihat sharded cluster architecture.
	Instance ID	Pilih ID instans dari instans tujuan ApsaraDB for MongoDB.
	Authentication Database Name	Masukkan nama database tempat akun database instans tujuan ApsaraDB for MongoDB berada. Nilai default-nya adalah admin.
	Database Account	Masukkan akun database instans tujuan ApsaraDB for MongoDB. Untuk persyaratan izin, lihat Izin akun database.
	Database Password	Masukkan kata sandi untuk akun database.
	Encryption

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 selengkapnya, 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.

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 selengkapnya, lihat Tipe migrasi.
Processing Mode of Conflicting Tables
Capitalization of Object Names in Destination Instance	Anda dapat mengonfigurasi kebijakan huruf besar/kecil 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 selengkapnya, lihat Kebijakan huruf besar/kecil nama objek untuk tujuan.
Source Objects	Di kotak Source Objects, klik objek yang ingin dimigrasikan, lalu klik ikon untuk memindahkannya ke kotak Selected Objects. Catatan Anda dapat memilih objek tingkat DATABASE atau COLLECTION untuk migrasi.
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 selengkapnya, lihat Pemetaan nama objek. Untuk menghapus objek migrasi yang dipilih, klik objek di kotak Selected Objects, lalu klik 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 untuk memfilter data (didukung selama migrasi data penuh tetapi tidak 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.

Klik Next: Advanced Settings untuk mengonfigurasi parameter lanjutan.

Parameter	Deskripsi
Dedicated Cluster for Task Scheduling	Secara default, DTS menjadwalkan tugas pada 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 kesalahan dan segera mulai mencoba menghubungkan kembali. 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 kesalahan dan segera mulai mencoba mengulang operasi tersebut. 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 dan 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 tersedia hanya 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	Menentukan apakah tipe data primary key `_id` unik dalam satu koleksi yang akan dimigrasikan. Penting Pilih opsi berdasarkan kebutuhan Anda. Jika tidak, kehilangan data mungkin terjadi. Parameter ini tersedia hanya 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 database sumber. Dalam 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 database 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 Item konfigurasi ini tersedia hanya jika Anda memilih Incremental Data Migration untuk Migration Types. Anda juga dapat menyesuaikan kecepatan migrasi inkremental setelah instans migrasi berjalan.
Environment Tag	Anda dapat memilih tag lingkungan untuk mengidentifikasi instans. Dalam contoh ini, parameter ini opsional.
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 akan mengirimkan pemberitahuan peringatan.

Klik Next: Data Validation untuk mengonfigurasi tugas validasi data.

Untuk informasi selengkapnya tentang fitur validasi data, lihat Konfigurasi validasi data.

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 lulus pemeriksaan awal.
- Jika pemeriksaan awal gagal, klik View Details di sebelah item pemeriksaan yang gagal, perbaiki masalah berdasarkan prompt, 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 prompt, 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.

Beli instans.

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

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

Kategori	Parameter	Deskripsi
New Instance Class	Resource Group Settings	Pilih kelompok sumber daya tempat instans tersebut berada. Nilai default-nya adalah kelompok sumber daya default. Untuk informasi selengkapnya, lihat Apa itu Resource Management?
New Instance Class	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 selengkapnya, lihat Spesifikasi tautan migrasi data.

Setelah konfigurasi selesai, baca dan pilih Data Transmission Service (Pay-as-you-go) Service Terms.
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 terjadi latensi tugas dan ketidakkonsistenan data meskipun tidak ada data yang ditulis ke database?

Penyebab: Konflik antara mekanisme penghapusan otomatis indeks TTL di koleksi MongoDB dan mekanisme sinkronisasi data DTS dapat menyebabkan latensi dan ketidakkonsistenan data dalam tugas sinkronisasi atau migrasi.

Operasi DELETE yang terlewat selama penulisan inkremental mengurangi efisiensi: Ketika indeks TTL di instans sumber menghapus data yang kadaluarsa, ia menghasilkan catatan DELETE di Oplog. DTS kemudian menyinkronkan operasi DELETE ini. Jika indeks TTL di instans tujuan telah menghapus data yang sama, operasi DELETE dari DTS tidak akan menemukan data untuk dihapus. Mesin MongoDB kemudian mengembalikan jumlah baris yang terpengaruh yang tidak terduga. Hal ini memicu proses penanganan pengecualian dan mengurangi efisiensi migrasi.

Ketidakkonsistenan data akibat penghapusan data kadaluarsa secara asinkron: Indeks TTL tidak menghapus data secara real-time. Data kadaluarsa mungkin masih ada di instans sumber ketika sudah dihapus di instans tujuan. Hal ini menyebabkan ketidakkonsistenan data.

Contoh:

Oplog atau ChangeStream MongoDB hanya mencatat bidang yang diperbarui untuk operasi UPDATE. Tidak mencatat dokumen lengkap sebelum dan sesudah pembaruan. Oleh karena itu, jika operasi UPDATE tidak dapat 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 kadaluarsa 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: Anda perlu memodifikasi sementara waktu kedaluwarsa indeks TTL di tujuan selama sinkronisasi atau migrasi untuk memastikan efisiensi dan konsistensi. Untuk informasi selengkapnya, lihat Praktik terbaik untuk menyinkronkan/memigrasikan koleksi dengan indeks TTL saat MongoDB adalah sumber.

Database sumber dan tujuan yang didukung

Prasyarat

Catatan penggunaan

Penagihan

Tipe migrasi

Gunakan oplog

Gunakan change streams

Izin akun database

Prosedur

Dari konsol DTS

Dari konsol DMS

FAQ