Sinkronisasi data satu arah dari instans kluster sharded ApsaraDB for MongoDB - ApsaraDB for MongoDB

Layanan Transmisi Data (DTS) memungkinkan Anda melakukan sinkronisasi data satu arah dari instans kluster sharded ApsaraDB for MongoDB ke instans set replika atau kluster sharded ApsaraDB for MongoDB. Topik ini memandu Anda melalui seluruh proses konfigurasi.

DTS hanya mendukung sinkronisasi data satu arah antara dua instans kluster sharded ApsaraDB for MongoDB. DTS tidak mendukung sinkronisasi data satu arah di antara beberapa instans ApsaraDB for MongoDB.

Cara kerja

DTS mendukung tiga jenis sinkronisasi untuk skenario ini: sinkronisasi skema, sinkronisasi data penuh, dan sinkronisasi data inkremental. Anda dapat menggabungkan jenis-jenis tersebut sesuai kebutuhan.

Sinkronisasi data penuh mencakup database dan koleksi.

Untuk data inkremental, DTS membaca perubahan dari database sumber menggunakan oplog atau change streams:

Oplog (disarankan): Menarik data log dari oplog MongoDB sumber. Latensi lebih rendah dan cakupan operasi lebih luas. Secara default, fitur oplog diaktifkan baik untuk database MongoDB yang dikelola sendiri maupun instans ApsaraDB for MongoDB.
Change streams: Berlangganan event perubahan dari sumber. Diperlukan untuk sumber Amazon DocumentDB. Tersedia pada MongoDB 4.0 dan versi lebih baru. Sinkronisasi dua arah tidak didukung dengan change streams.

Setelah DTS memulai tugas, data inkremental dari database yang dibuat setelah tugas dimulai tidak akan disinkronkan.

Operasi yang ditangkap melalui oplog:

CREATE COLLECTION, CREATE INDEX
DROP DATABASE, DROP COLLECTION, DROP INDEX
RENAME COLLECTION
Menyisipkan, memperbarui, dan menghapus dokumen

Untuk data inkremental berbasis file, hanya perintah $set yang dijalankan secara sinkron.

Operasi yang ditangkap melalui change streams:

DROP DATABASE, DROP COLLECTION
RENAME COLLECTION
Menyisipkan, memperbarui, dan menghapus dokumen

Untuk data inkremental berbasis file, hanya perintah $set yang dijalankan secara sinkron.

Penagihan

Jenis sinkronisasi	Biaya
Sinkronisasi skema dan sinkronisasi data penuh	Gratis
Sinkronisasi data inkremental	Dikenai biaya. Lihat Ikhtisar penagihan.

Batasan

Batasan database sumber dan tujuan

Server yang menghosting database sumber harus memiliki bandwidth keluar yang mencukupi. Jika tidak, kecepatan sinkronisasi terpengaruh.
Koleksi yang akan disinkronkan harus memiliki kendala PRIMARY KEY atau UNIQUE, dan semua bidangnya harus unik. Jika tidak, database tujuan mungkin berisi catatan duplikat.
Bidang _id di setiap koleksi yang disinkronkan harus unik. Jika tidak, ketidakkonsistenan data mungkin terjadi.
Jika Anda memilih koleksi sebagai objek untuk disinkronkan dan perlu mengganti namanya di tujuan, satu tugas mendukung hingga 1.000 koleksi. Untuk lebih dari 1.000 koleksi, konfigurasikan beberapa tugas secara batch, atau lakukan sinkronisasi di tingkat database.
Satu entri data yang akan disinkronkan tidak boleh melebihi 16 MB. Jika tidak, tugas gagal.
Database sumber tidak boleh berupa kluster Azure Cosmos DB for MongoDB atau kluster elastis Amazon DocumentDB.
Oplog harus diaktifkan pada database sumber dan harus menyimpan data selama minimal 7 hari. Atau, change streams harus diaktifkan untuk memastikan DTS dapat berlangganan perubahan dalam 7 hari terakhir. Jika tidak, DTS mungkin gagal membaca perubahan sumber, menyebabkan kegagalan sinkronisasi, ketidakkonsistenan data, atau kehilangan data. Masalah dalam kondisi seperti ini tidak dicakup oleh perjanjian tingkat layanan (SLA) DTS.
- Gunakan oplog untuk mencatat perubahan di database sumber.
- Hanya MongoDB 4.0 dan versi lebih baru yang mendukung penggunaan change streams untuk membaca perubahan sumber. Sinkronisasi dua arah tidak didukung dengan change streams.
- Jika sumber adalah kluster Amazon DocumentDB non-elastis, aktifkan change streams dan atur Migration Method ke ChangeStream dan Architecture ke Sharded Cluster.
Database kluster sharded MongoDB yang terlibat dalam tugas yang sedang berjalan tidak dapat diskalakan. Jika tidak, tugas gagal.
Jika sumber adalah database MongoDB yang dikelola sendiri dengan arsitektur kluster sharded, atur Access Method hanya ke Express Connect, VPN Gateway, atau Smart Access Gateway atau Cloud Enterprise Network (CEN).
Kluster sharded MongoDB sumber tidak boleh memiliki lebih dari 10 node mongos.
Koleksi dengan indeks time to live (TTL) tidak dapat disinkronkan. Jika sumber memiliki indeks TTL, ketidakkonsistenan data mungkin terjadi antara sumber dan tujuan.
Pastikan tidak ada dokumen orphaned di database sumber atau tujuan. Jika tidak, ketidakkonsistenan data atau kegagalan tugas mungkin terjadi. Lihat Glosarium MongoDB dan Bagaimana cara menghapus dokumen orphaned dari database MongoDB yang diterapkan dalam arsitektur kluster sharded?.
Selama sinkronisasi skema dan sinkronisasi data penuh, jangan mengubah skema database atau koleksi (termasuk pembaruan tipe array). Jika tidak, tugas gagal atau ketidakkonsistenan data mungkin terjadi.
Jika Anda hanya melakukan sinkronisasi data penuh, jangan menulis data ke database sumber selama sinkronisasi. Jika tidak, ketidakkonsistenan data terjadi.
Jika balancer database sumber diaktifkan untuk menyeimbangkan data, tugas DTS mungkin mengalami penundaan.

Batasan lainnya

Jika tujuan adalah instans set replika:
- Jika terhubung melalui Express Connect, VPN Gateway, atau Smart Access Gateway, Public IP Address, atau Cloud Enterprise Network (CEN): Atur Domain Name or IP dan Port Number ke alamat IP dan port node primary, atau konfigurasikan titik akhir ketersediaan tinggi. Lihat Buat tugas DTS dengan database MongoDB ketersediaan tinggi sebagai sumber atau tujuan.
- Jika terhubung melalui Self-managed Database di ECS: Atur Port Number ke port node primary.
Tambahkan kunci shard ke data yang akan disinkronkan di database sumber sebelum memulai tugas. Selama sinkronisasi, operasi INSERT harus menyertakan kunci shard, dan operasi UPDATE tidak boleh mengubah kunci shard.
Versi MongoDB tujuan harus sama dengan atau lebih baru daripada versi sumber. Versi yang lebih lama mungkin menyebabkan masalah kompatibilitas.
DTS tidak dapat menyinkronkan data dari database admin atau local.
Informasi transaksi tidak dipertahankan. Transaksi yang disinkronkan ke tujuan dikonversi menjadi catatan tunggal.
Evaluasi dampak terhadap kinerja sumber dan tujuan sebelum menyinkronkan data. Jalankan sinkronisasi selama jam sepi. Selama sinkronisasi data penuh, DTS menggunakan sumber daya baca dan tulis di kedua instans, yang mungkin meningkatkan beban server.
Selama sinkronisasi data penuh, operasi INSERT konkuren menyebabkan fragmentasi koleksi di database tujuan. Setelah sinkronisasi penuh selesai, koleksi tujuan menempati ruang penyimpanan lebih besar daripada sumber.
Jika koleksi tujuan memiliki indeks unik atau atribut capped-nya bernilai true, koleksi tersebut hanya mendukung penulisan single-thread dan tidak mendukung replay konkuren selama sinkronisasi inkremental. Hal ini dapat meningkatkan latensi sinkronisasi.
Data ditulis secara konkuren ke tujuan, sehingga ruang penyimpanan tujuan 5%–10% lebih besar daripada ukuran data sumber.
Gunakan sintaksis db.$table_name.aggregate([{ $count:"myCount"}]) untuk menghitung jumlah di database MongoDB tujuan.
Pastikan database MongoDB tujuan tidak memiliki primary key yang sama dengan sumber. Primary key default adalah _id. Jika tujuan memiliki primary key yang cocok, hapus catatan tersebut dari tujuan tanpa mengganggu DTS. Misalnya, jika _id yang sama ada, hapus catatan tujuan dengan _id tersebut.
Nonaktifkan balancer MongoDB database sumber selama sinkronisasi data penuh. Jangan aktifkan kembali balancer hingga sinkronisasi penuh selesai dan sinkronisasi inkremental dimulai. Jika tidak, ketidakkonsistenan data mungkin terjadi. Lihat Mengelola balancer ApsaraDB for MongoDB.
Jika sharding data dikonfigurasi untuk tujuan dan Anda tidak memerlukan sinkronisasi skema, jangan pilih Schema Synchronization pada parameter Synchronization Types. Jika tidak, konflik shard dapat menyebabkan ketidakkonsistenan data atau kegagalan tugas.
Jika tugas DTS gagal, dukungan teknis DTS akan mencoba memulihkannya dalam waktu 8 jam. Selama pemulihan, tugas mungkin dimulai ulang dan parameternya mungkin dimodifikasi (parameter database tidak diubah). Parameter yang dimodifikasi mungkin termasuk yang ada di bagian Modifikasi parameter instans.

Prasyarat

Sebelum memulai, pastikan Anda telah:

Memiliki instans tujuan ApsaraDB for MongoDB berupa instans set replika atau kluster sharded. Lihat Buat instans set replika atau Buat instans kluster sharded.
Penting
Gunakan instans tujuan yang ruang penyimpanannya tersedia minimal 10% lebih besar daripada total ukuran data di instans sumber.
Untuk informasi tentang versi instans yang didukung, lihat Ikhtisar skenario sinkronisasi data.
Memiliki titik akhir yang ditetapkan untuk semua node shard di instans kluster sharded sumber, dengan semua node shard menggunakan akun dan kata sandi yang sama. Lihat Ajukan titik akhir untuk komponen shard atau ConfigServer.
(Untuk tujuan berupa kluster sharded) Database dan koleksi yang akan dishard telah dibuat di tujuan, sharding data telah dikonfigurasi, balancer diaktifkan, dan pre-sharding telah dilakukan. Lihat Konfigurasi sharding untuk memaksimalkan kinerja shard dan FAQ Apa yang harus saya lakukan jika data MongoDB dalam arsitektur kluster sharded tidak terdistribusi secara merata?.
Mengonfigurasi sharding sebelum tugas memastikan data yang disinkronkan terdistribusi di seluruh shard, memaksimalkan kinerja kluster sharded. Balancer dan pre-sharding juga mencegah kesenjangan data.
Dokumen orphaned telah dihapus dari database MongoDB sumber (lihat Hapus dokumen orphaned di bawah).

Hapus dokumen orphaned

Hapus dokumen orphaned dari database MongoDB sumber sebelum sinkronisasi. Jika dokumen orphaned tetap ada, kinerja sinkronisasi menurun dan dokumen mungkin memiliki nilai _id duplikat, menyebabkan data yang tidak diinginkan ikut disinkronkan.

Instans ApsaraDB for MongoDB

Menjalankan skrip pembersihan pada instans ApsaraDB for MongoDB dengan versi utama sebelum 4.2, atau versi minor sebelum 4.0.6, akan mengembalikan error. Untuk memeriksa versi Anda, lihat Catatan rilis untuk versi minor ApsaraDB for MongoDB. Untuk upgrade, lihat Upgrade versi utama instans dan Perbarui versi minor instans.

Perintah cleanupOrphaned menghapus dokumen orphaned. Skrip bervariasi tergantung versi MongoDB.

MongoDB 4.4 dan versi lebih baru

Buat file JavaScript bernama cleanupOrphaned.js di server yang dapat terhubung ke instans kluster sharded.

Skrip ini menghapus dokumen orphaned dari semua koleksi di beberapa database di beberapa shard. Untuk menargetkan koleksi tertentu, modifikasi parameter skrip.

Parameter	Deskripsi
`shardNames`	ID shard yang akan dibersihkan. Temukan ID ini di bagian Shard List pada halaman Basic Information instans kluster sharded. Contoh: `d-bp15a3796d3a****`.
`databasesToProcess`	Nama database tempat dokumen orphaned akan dihapus.

// Nama-nama shard.
var shardNames = ["shardName1", "shardName2"];
// Database tempat Anda ingin menghapus dokumen orphaned.
var databasesToProcess = ["database1", "database2", "database3"];

shardNames.forEach(function(shardName) {
    // Telusuri database yang ditentukan.
    databasesToProcess.forEach(function(dbName) {
        var dbInstance = db.getSiblingDB(dbName);
        // Dapatkan nama semua koleksi dari database yang ditentukan.
        var collectionNames = dbInstance.getCollectionNames();

        // Telusuri semua koleksi.
        collectionNames.forEach(function(collectionName) {
            // Nama lengkap koleksi.
            var fullCollectionName = dbName + "." + collectionName;
            // Bangun perintah cleanupOrphaned.
            var command = {
                runCommandOnShard: shardName,
                command: { cleanupOrphaned: fullCollectionName }
            };

            // Jalankan perintah cleanupOrphaned.
            var result = db.adminCommand(command);
            if (result.ok) {
                print("Membersihkan dokumen orphaned untuk koleksi " + fullCollectionName + " di shard " + shardName);
                printjson(result);
            } else {
                print("Gagal membersihkan dokumen orphaned untuk koleksi " + fullCollectionName + " di shard " + shardName);
            }
        });
    });
});

Ganti parameter berikut:

Dari direktori yang berisi cleanupOrphaned.js, jalankan:

Parameter	Deskripsi
`<Mongoshost>`	Titik akhir node mongos. Format: `s-bp14423a2a51****.mongodb.rds.aliyuncs.com`.
`<Primaryport>`	Port node mongos. Default: `3717`.
`<database>`	Database otentikasi untuk akun.
`<username>`	Akun database.
`<password>`	Kata sandi akun.
`output.txt`	File tempat hasil eksekusi disimpan.

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

MongoDB 4.2 dan versi lebih lama

Buat file JavaScript bernama cleanupOrphaned.js di server yang dapat terhubung ke instans kluster sharded.

Skrip ini menghapus dokumen orphaned dari koleksi tertentu di database di beberapa shard. Untuk membersihkan beberapa koleksi, modifikasi parameter fullCollectionName dan jalankan skrip beberapa kali, atau perluas skrip untuk mengulangi semua koleksi.

Parameter	Deskripsi
`shardNames`	ID shard yang akan dibersihkan. Temukan ID ini di bagian Shard List pada halaman Basic Information instans kluster sharded. Contoh: `d-bp15a3796d3a****`.
`fullCollectionName`	Koleksi yang akan dibersihkan. Format: `nama database.nama koleksi`.

function cleanupOrphanedOnShard(shardName, fullCollectionName) {
    var nextKey = { };
    var result;

    while ( nextKey != null ) {
        var command = {
            runCommandOnShard: shardName,
            command: { cleanupOrphaned: fullCollectionName, startingFromKey: nextKey }
        };

        result = db.adminCommand(command);
        printjson(result);

        if (result.ok != 1 || !(result.results.hasOwnProperty(shardName)) || result.results[shardName].ok != 1 ) {
            print("Tidak dapat menyelesaikan saat ini: kegagalan atau timeout.")
            break
        }

        nextKey = result.results[shardName].stoppedAtKey;
    }

    print("cleanupOrphaned selesai untuk koleksi: " + fullCollectionName + " di shard: " + shardName)
}

var shardNames = ["shardName1", "shardName2", "shardName3"]
var fullCollectionName = "database.collection"

shardNames.forEach(function(shardName) {
    cleanupOrphanedOnShard(shardName, fullCollectionName);
});

Ganti parameter berikut:

Dari direktori yang berisi cleanupOrphaned.js, jalankan:

Parameter	Deskripsi
`<Mongoshost>`	Titik akhir node mongos. Format: `s-bp14423a2a51****.mongodb.rds.aliyuncs.com`.
`<Primaryport>`	Port node mongos. Default: `3717`.
`<database>`	Database otentikasi untuk akun.
`<username>`	Akun database.
`<password>`	Kata sandi akun.
`output.txt`	File tempat hasil eksekusi disimpan.

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

Database MongoDB yang dikelola sendiri

Unduh skrip cleanupOrphaned.js di server yang dapat terhubung ke database MongoDB yang dikelola sendiri.

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

Ganti test dalam skrip dengan nama database tempat dokumen orphaned akan dihapus.
Penting
Untuk membersihkan beberapa database, ulangi langkah 2 dan 3 untuk setiap database.

Di setiap shard, jalankan perintah berikut untuk menghapus dokumen orphaned dari semua koleksi di database yang ditentukan.

Ulangi langkah ini untuk setiap shard.

Parameter	Deskripsi
`<Shardhost>`	Alamat IP shard.
`<Primaryport>`	Port layanan node primary di shard.
`<database>`	Database otentikasi untuk akun.
`<username>`	Akun untuk database MongoDB yang dikelola sendiri.
`<password>`	Kata sandi untuk akun.

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

Contoh: Database MongoDB yang dikelola sendiri 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

Konfigurasi tugas sinkronisasi

Penting

Dalam contoh ini, tugas DTS dikonfigurasi sebelum membeli instans DTS. Anda tidak perlu menentukan jumlah shard di instans kluster sharded sumber. Jika Anda membeli instans DTS sebelum mengonfigurasi tugas, tentukan jumlah shard saat pembelian.

Buka halaman Data Synchronization dan pilih wilayah tempat instans berada. Konsol DTS Konsol DMS
1. Login ke Konsol DMS.
2. Di bilah navigasi atas, arahkan kursor ke Data + AI lalu pilih DTS (DTS) > Data Synchronization.
3. Dari daftar drop-down di sebelah kanan Data Synchronization Tasks, pilih wilayah tempat instans berada.
Operasi aktual mungkin berbeda tergantung mode dan tata letak Konsol DMS. Lihat Mode sederhana dan Sesuaikan tata letak dan gaya Konsol DMS.
Klik Create Task.
(Opsional) Klik New Configuration Page di pojok kanan atas.
Lewati langkah ini jika tombol Back to Previous Version sudah ditampilkan. Gunakan halaman konfigurasi baru jika tersedia.

Konfigurasi database sumber dan tujuan.

Bagian	Parameter	Deskripsi
N/A	Task Name	Nama untuk tugas DTS. DTS menghasilkan nama default. Tentukan nama deskriptif agar tugas lebih mudah diidentifikasi. Nama tidak perlu unik.
Source Database	Select Existing Connection	Pilih database terdaftar yang ada untuk mengisi parameter secara otomatis, atau biarkan kosong untuk mengonfigurasi secara manual. Untuk mendaftarkan database: di konsol DTS, gunakan halaman Database Connections (lihat Mengelola koneksi database); di konsol DMS, pilih dari daftar Select a DMS database instance. atau klik Add DMS Database Instance (lihat Mendaftarkan instans database Alibaba Cloud dan Mendaftarkan database yang di-hosting di layanan cloud pihak ketiga atau database yang dikelola sendiri).
	Database Type	Pilih MongoDB.
	Access Method	Pilih Alibaba Cloud Instance.
	Instance Region	Wilayah instans ApsaraDB for MongoDB sumber.
	Replicate Data Across Alibaba Cloud Accounts	Pilih No untuk contoh ini (akun yang sama).
	Architecture	Pilih Sharded Cluster.
	Migration Method	Metode yang digunakan untuk menyinkronkan data inkremental. Oplog (disarankan): secara default, fitur oplog diaktifkan baik untuk database MongoDB yang dikelola sendiri maupun instans ApsaraDB for MongoDB. Memungkinkan sinkronisasi latensi rendah karena penarikan log cepat. ChangeStream: tersedia saat change streams diaktifkan. Lihat Change Streams. Diperlukan untuk kluster Amazon DocumentDB non-elastis. Jika Sharded Cluster dipilih untuk Architecture, parameter Shard account dan Shard password tidak diperlukan.
	Instance ID	ID instans ApsaraDB for MongoDB sumber.
	Authentication Database	Nama database otentikasi. Default: `admin`.
	Database Account	Akun database sumber. Harus memiliki izin baca pada database sumber, database `config`, database `admin`, dan database `local`.
	Database Password	Kata sandi akun.
	Shard account	Akun untuk mengakses node shard. Diperlukan jika sumber adalah database MongoDB yang dikelola sendiri.
	Shard password	Kata sandi untuk mengakses node shard.
Destination Database	Encryption	Apakah koneksi database sumber dienkripsi. Pilih Non-encrypted, SSL-encrypted, atau Mongo Atlas SSL. Opsi yang tersedia tergantung pada nilai Access Method dan Architecture. Jika Architecture adalah Sharded Cluster dan Migration Method adalah Oplog, SSL-encrypted tidak tersedia. Jika sumber adalah database MongoDB yang dikelola sendiri dengan arsitektur Replica Set dan Access Method bukan Alibaba Cloud Instance, Anda dapat mengunggah sertifikat CA saat memilih SSL-encrypted.
	Select Existing Connection	Pilih database terdaftar yang sudah ada untuk mengisi parameter secara otomatis, atau biarkan kosong untuk mengonfigurasi secara manual.
	Database Type	Pilih MongoDB.
	Access Method	Pilih Alibaba Cloud Instance.
	Instance Region	Wilayah instans ApsaraDB for MongoDB tujuan.
	Replicate Data Across Alibaba Cloud Accounts	Pilih No untuk contoh ini (akun yang sama).
	Architecture	Arsitektur instans tujuan.
	Instance ID	ID instans ApsaraDB for MongoDB tujuan.
	Authentication Database	Nama database otentikasi. Default: `admin`.
	Database Account	Akun database tujuan. Harus memiliki izin `dbAdminAnyDatabase`, izin baca dan tulis pada database tujuan, dan izin baca pada database `local`.
	Database Password	Kata sandi akun.
	Encryption	Apakah koneksi database tujuan dienkripsi. Pilih Non-encrypted, SSL-encrypted, atau Mongo Atlas SSL. Jika tujuan adalah instans ApsaraDB for MongoDB dengan arsitektur Sharded Cluster, SSL-encrypted tidak tersedia. Jika tujuan adalah database MongoDB yang dikelola sendiri dengan arsitektur Replica Set dan Access Method bukan Alibaba Cloud Instance, Anda dapat mengunggah sertifikat CA saat memilih SSL-encrypted.

Klik Test Connectivity and Proceed.
Pastikan blok CIDR server DTS dapat mengakses database sumber dan tujuan. Blok CIDR ini ditambahkan secara otomatis saat Anda menggunakan instans Alibaba Cloud, atau Anda dapat menambahkannya secara manual. Lihat Tambahkan blok CIDR server DTS. Jika sumber atau tujuan adalah database yang dikelola sendiri yang tidak terhubung melalui Alibaba Cloud Instance, klik Test Connectivity di kotak dialog CIDR Blocks of DTS Servers.

Konfigurasi objek yang akan disinkronkan.

Pada langkah Configure Objects, atur parameter berikut.

Parameter	Deskripsi
Synchronization Types	Jenis sinkronisasi yang akan dilakukan. Incremental Data Synchronization dipilih secara default. Pilih juga Schema Synchronization dan Full Data Synchronization untuk menyinkronkan data historis sebagai dasar sinkronisasi inkremental berikutnya. Lihat Cara kerja untuk detail jenis sinkronisasi.
Processing Mode of Conflicting Tables	Precheck and Report Errors (default): memeriksa konflik nama koleksi antara sumber dan tujuan sebelum memulai. Tugas gagal dalam pemeriksaan awal jika ditemukan nama identik. Untuk menyinkronkan ke koleksi tujuan yang tidak dapat dihapus atau diganti namanya, gunakan pemetaan nama objek. Lihat Ganti nama objek yang akan disinkronkan. Ignore Errors and Proceed: melewati pemeriksaan konflik. > Warning: Jika Anda memilih opsi ini, ketidakkonsistenan data mungkin terjadi. Catatan di tujuan dengan primary key atau unique key yang sama dengan sumber tidak ditimpa; catatan tujuan yang ada dipertahankan. Hal ini juga dapat menyebabkan kegagalan inisialisasi atau sinkronisasi kolom parsial.
Synchronization Topology	Pilih One-way Synchronization.
Capitalization of Object Names in Destination Instance	Kebijakan kapitalisasi untuk nama database dan koleksi di tujuan. Default: DTS default policy. Lihat Tentukan kapitalisasi nama objek di instans tujuan.
Source Objects	Pilih database atau koleksi dari Source Objects lalu klik ikon untuk memindahkannya ke Selected Objects.
Selected Objects	Untuk mengganti nama objek di tujuan, klik kanan objek tersebut. Lihat Pemetaan nama objek. Untuk menghapus objek, klik objek tersebut lalu klik ikon . Untuk mengatur cakupan sinkronisasi inkremental berdasarkan database atau koleksi, klik kanan Selected Objects. Untuk memfilter data selama sinkronisasi penuh, klik kanan tabel di Selected Objects dan konfigurasikan kondisi filter. Perhatikan bahwa filter tidak berlaku selama sinkronisasi inkremental. Lihat Tentukan kondisi filter. Mengganti nama database atau koleksi menggunakan pemetaan nama objek mungkin menyebabkan objek dependen gagal disinkronkan.

Klik Next: Advanced Settings dan konfigurasikan parameter berikut.

Parameter	Deskripsi
Dedicated Cluster for Task Scheduling	Secara default, DTS menggunakan kluster bersama. Untuk stabilitas yang lebih baik, beli kluster khusus. Lihat Apa itu kluster khusus DTS.
Retry Time for Failed Connections	Berapa lama DTS mencoba koneksi ulang jika database sumber atau tujuan tidak dapat dijangkau. Nilai valid: 10–1440 menit. Default: 720 menit. Atur nilai ini lebih dari 30 menit. Jika DTS terhubung kembali dalam jendela percobaan ulang, tugas dilanjutkan; jika tidak, tugas gagal. Jika beberapa tugas berbagi sumber atau tujuan yang sama, jendela percobaan ulang terpendek yang berlaku. DTS terus menagih selama percobaan ulang.
Retry Time for Other Issues	Berapa lama DTS mencoba ulang jika operasi DDL atau DML gagal. Nilai valid: 1–1440 menit. Default: 10 menit. Atur nilai ini lebih dari 10 menit. Nilai ini harus kurang dari Retry Time for Failed Connections.
Enable Throttling for Full Data Migration	Membatasi laju baca/tulis DTS selama sinkronisasi penuh untuk mengurangi beban pada server database. Konfigurasikan Queries per second (QPS) to the source database, RPS of Full Data Migration, dan Data migration speed for full migration (MB/s). Ditampilkan hanya saat Full Data Synchronization dipilih.
Only one data type for primary key _id in a single table	Apakah bidang `_id` memiliki satu tipe data di semua catatan dalam koleksi. Yes: DTS melewati pemindaian tipe data `_id` selama sinkronisasi penuh. No: DTS memindai tipe data `_id`. Ditampilkan hanya saat Full Data Synchronization dipilih.
Enable Throttling for Incremental Data Synchronization	Membatasi laju DTS selama sinkronisasi inkremental. Konfigurasikan RPS of Incremental Data Synchronization dan Data synchronization speed for incremental synchronization (MB/s).
Environment Tag	Tag untuk mengidentifikasi instans DTS. Opsional.
Configure ETL	Apakah fitur ekstrak, transformasi, dan muat (ETL) diaktifkan. Yes: konfigurasikan ETL dengan pernyataan pemrosesan data. Lihat Konfigurasi ETL dalam tugas migrasi data atau sinkronisasi data. No: lewati konfigurasi ETL.
Monitoring and Alerting	Apakah peringatan untuk tugas diaktifkan. Yes: konfigurasikan ambang batas peringatan dan kontak. Lihat Konfigurasi pemantauan dan peringatan saat membuat tugas DTS. No: nonaktifkan peringatan.

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

Simpan pengaturan tugas dan jalankan pemeriksaan awal.
- Untuk melihat pratinjau parameter API untuk konfigurasi ini, arahkan kursor ke Next: Save Task Settings and Precheck lalu klik Preview OpenAPI parameters.
- Klik Next: Save Task Settings and Precheck.
DTS menjalankan pemeriksaan awal sebelum tugas dapat dimulai. Jika pemeriksaan awal gagal, klik View Details di sebelah setiap item yang gagal untuk mendiagnosis dan menyelesaikan masalah, lalu jalankan kembali pemeriksaan awal. Jika peringatan dipicu untuk suatu item: jika peringatan tidak dapat diabaikan, selesaikan masalah dan periksa ulang; jika dapat diabaikan, klik Confirm Alert Details, lalu Ignore, lalu OK, lalu Precheck Again.

Beli instans.

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

Di halaman buy, konfigurasikan parameter berikut.

Bagian	Parameter	Deskripsi
New Instance Class	Billing Method	Subscription: bayar di muka untuk durasi tertentu. Lebih hemat biaya untuk penggunaan jangka panjang. Pay-as-you-go: ditagih per jam. Cocok untuk penggunaan jangka pendek. Rilis instans saat tidak lagi diperlukan untuk menghentikan tagihan.
	Resource Group Settings	Kelompok sumber daya untuk instans. Default: default resource group. Lihat Apa itu Resource Management?.
	Instance Class	Pilih kelas berdasarkan kebutuhan kecepatan sinkronisasi Anda. Lihat Kelas instans untuk instansi sinkronisasi data.
	Subscription Duration	Tersedia hanya untuk metode penagihan Subscription. Opsi: 1–9 bulan, 1 tahun, 2 tahun, 3 tahun, atau 5 tahun.

Baca dan pilih Data Transmission Service (Pay-as-you-go) Service Terms.
Klik Buy and Start, lalu klik OK di kotak dialog.

Lihat progres tugas di daftar tugas.