Sharded cluster bukan sekadar “banyak mongod”. Cluster yang berfungsi terdiri dari tiga jenis komponen dengan tanggung jawab yang tegas terpisah: shard yang menyimpan data, config server yang menyimpan metadata, dan mongos yang merutekan permintaan. Memahami siapa mengerjakan apa adalah bekal untuk seluruh chapter section ini — dari pemilihan shard key sampai troubleshooting. Kita mulai dari gambar besar, lalu periksa bentuk deployment minimumnya.

Gambar Besar #

Tiga jenis komponen pada diagram di atas:

KomponenBentukTanggung jawab
ShardReplica setMenyimpan subset data collection yang di-shard
Config serversReplica set khusus (CSRS)Menyimpan metadata: shard apa punya chunk apa
mongosProses router, satu atau banyakMenerima query aplikasi dan meneruskannya ke shard yang tepat

Aplikasi hanya bicara ke mongos — tidak pernah langsung ke shard. mongos membaca metadata dari config servers untuk tahu data berada di shard mana, lalu meneruskan query ke sana dan menggabungkan hasilnya. mongos tidak menyimpan data aplikasi sama sekali; ia hanya proses perutean yang bisa dimatikan dan dinyalakan tanpa kehilangan apa pun.

Alur satu query find({ userId: 42 }) pada collection yang di-shard menurut userId:

  1. Aplikasi mengirim query ke salah satu mongos pada connection string-nya.
  2. mongos memeriksa cache metadata-nya: nilai userId: 42 jatuh pada chunk milik shard 2.
  3. mongos meneruskan query ke primary shard 2, menerima hasilnya, lalu mengembalikan hasil ke aplikasi.

Connection string aplikasi memuat daftar mongos, bukan daftar shard:

text 
mongodb://mongos1.example.net:27017,mongos2.example.net:27017/toko

Daftar mongos membuat driver otomatis mencoba mongos lain bila salah satu tidak terjangkau — perilaku failover yang sudah kita bahas pada Chapter Connection String. Perhatikan bahwa parameter replicaSet tidak dipakai di sini: mongos bukan anggota replica set aplikasi. Shard tidak pernah muncul di connection string aplikasi.

Bentuk Deployment Minimum dan Produksi #

Untuk pengembangan dan pengujian, dokumentasi resmi menyebut konfigurasi minimum: satu mongos, satu shard (replica set), dan satu config server (replica set satu anggota). Bentuk ini cukup untuk mencicipi perilaku sharding, tetapi tidak menawarkan ketahanan kegagalan.

Deployment produksi menuntut lebih:

  • Config servers sebagai replica set tiga anggota, tanpa arbiter dan tanpa delayed member.
  • Setiap shard sebagai replica set tiga anggota.
  • Satu atau lebih mongos; sebarkan di mesin aplikasi atau mesin shard.
  • Distribusikan config server dan shard ke minimal tiga data center bila memungkinkan.

Perlu diingat juga: sharding membutuhkan minimal dua shard agar data benar-benar terbagi. Cluster satu shard sah-sah saja — dokumentasi resmi menyebutnya berguna bila kita berencana mengaktifkan sharding dalam waktu dekat tetapi belum membutuhkannya saat deployment.

Perintah Cluster Hanya Lewat mongos #

Kita buktikan bahwa perintah khusus sharding tidak berlaku di server biasa. Status cluster biasanya diperiksa dengan sh.status() lewat mongos — kita coba langsung di replica set latihan:

js 
sh.status()

Output yang Dihasilkan:

text 
Warning: MongoshWarning: [SHAPI-10003] You are not connected to a mongos. This command may not work as expected.
Uncaught 
MongoshInvalidInputError: [SHAPI-10003] This db does not have sharding enabled. Be sure you are connecting to a mongos from the shell and not to a mongod.

Dua lapis pesan muncul. Warning dari mongosh memberi tahu bahwa klien sadar kita tidak terhubung ke mongos; error berikutnya menegaskan bahwa perintah status sharding memang ditolak oleh mongod biasa. Perilaku ini bukan kegagalan — perintah seperti sh.status() memang dirancang dijalankan lewat mongos pada sharded cluster sungguhan, dan di seluruh section ini kita tampilkan outputnya sebagai contoh berlabel ilustratif.

Rangkuman #

  • Sharded cluster terdiri dari shard (replica set penyimpan data), config servers (replica set CSRS penyimpan metadata), dan mongos (router stateless).
  • Aplikasi hanya terhubung ke mongos; connection string memuat daftar mongos, bukan shard.
  • Deployment minimum untuk pengembangan: satu mongos, satu shard, satu config server; produksi menuntut replica set tiga anggota untuk config server dan setiap shard.
  • Perintah sharding seperti sh.status() hanya berjalan lewat mongos — terbukti ditolak dengan pesan eksplisit saat dijalankan pada mongod biasa.

Chapter berikutnya membedah tiga komponen ini satu per satu lebih dalam, termasuk isi database config yang menjadi sumber kebenaran seluruh cluster.