Shards, Config Servers, dan mongos

Chapter Arsitektur Sharded Cluster memperkenalkan tiga komponen dalam satu diagram. Sekarang kita bedah masing-masing lebih dalam: apa sebenarnya yang disimpan sebuah shard, isi database config di config server, dan mengapa mongos boleh diperbanyak begitu bebas. Pemahaman ini penting karena hampir semua gejala troubleshooting sharding bermuara ke salah satu dari tiga komponen ini.

Shard: Replica Set dengan Subset Data #

Shard menyimpan subset data dari collection yang di-shard — seluruh shard bersama-sama memuat data lengkap cluster. Setiap shard wajib berupa replica set: ketahanan kegagalan di dalam shard ditangani mekanisme replikasi yang sudah kita kenal (election, oplog, failover), bukan oleh sharding.

Dua karakter penting shard:

• Primary shard per database. Setiap database di cluster punya satu shard utama; collection yang tidak di-shard dari database itu menumpang di sana. Istilah ini berbeda dari primary-nya replica set shard. Sejak MongoDB 8.0, collection tidak ter-shard dapat dipindahkan antar shard lewat perintah moveCollection.
• Bukan untuk disentuh aplikasi. Query langsung ke satu shard hanya melihat potongan data. Dokumentasi resmi memperingatkan operasi langsung ke shard berisiko merusak data; koneksi langsung hanya untuk administrasi lokal.

Dokumentasi juga menyarankan menghindari arbiter pada replica set shard karena banyak operasi internal sharded cluster memakai write concern "majority" — topologi PSA (primary-secondary-arbiter) membuat angka majority sulit dipenuhi saat maintenance.

Config Servers: Sumber Kebenaran Metadata #

Config server menyimpan metadata cluster: daftar shard, collection mana yang di-shard dengan shard key apa, dan chunk mana berada di shard mana. Seluruhnya hidup di database bernama config, dengan collection-collection berikut sebagai yang paling sering disebut:

Collection lain seperti config.settings (konfigurasi balancer) dan config.changelog melengkapi kumpulan itu. mongos membaca metadata ini dan menyimpannya di cache; setiap kali metadata berubah — chunk berpindah, shard ditambahkan — mongos memperbarui cache-nya. Shard pun membaca metadata chunk dari config server.

Config server harus berupa replica set (CSRS) tanpa arbiter, tanpa delayed member, dan seluruh anggotanya membangun index. Penulisan metadata memakai write concern "majority". Bila CSRS kehilangan primary dan tidak bisa melakukan election, metadata menjadi baca-saja: data tetap bisa dibaca dan ditulis di shard, tetapi migrasi dan split chunk berhenti sampai primary baru terpilih.

Kita bisa membuktikan bahwa koleksi metadata itu memang milik config server cluster, bukan milik mongod sembarangan. Di server latihan kita, database config juga ada — tetapi isinya hanya keperluan internal instance (sesi, transaksi, sampling query):

db.getSiblingDB("config").getCollectionNames()

Output yang Dihasilkan:

[
  'sampledQueries',
  'transactions',
  'image_collection',
  'queryShapeRepresentativeQueries',
  'sampledQueriesDiff',
  'analyzeShardKeySplitPoints',
  'system.indexBuilds',
  'system.preimages',
  'system.sessions'
]

Tidak ada shards, chunks, collections, maupun databases di daftar tersebut — metadata sharding itu hanya terbentuk di config server sebuah sharded cluster sungguhan. Ini juga alasan kuat untuk tidak sembarang menulis ke database config: dokumentasi resmi meminta kita menghindari menyunting isinya secara langsung.

mongos: Router Stateless #

mongos adalah satu-satunya pintu masuk aplikasi. Ia tidak menyimpan state persisten — matikan satu mongos dan nyalakan lagi, ia cukup menarik salinan metadata terbaru dari config server lalu siap merutekan. Konsumsi resource-nya kecil, sehingga praktik yang umum adalah menjalankan satu mongos di setiap mesin aplikasi.

Karena stateless, jumlah mongos mudah ditambah saat koneksi aplikasi tumbuh. Konsekuensinya: semua mongos harus melihat metadata dengan versi sama; bila cache salah satu mongos tertinggal, operasi bisa gagal dengan error StaleConfig lalu memicu refresh — gejala yang akan kita bahas di Chapter Troubleshooting Sharding.

Sebagai router, mongos juga membawa perintah administratif cluster. Contohnya listShards untuk mendaftar shard — di server biasa perintah ini tidak dikenal:

db.adminCommand({ listShards: 1 })

Output yang Dihasilkan:

Uncaught 
MongoServerError[CommandNotFound]: no such command: 'listShards'

Pesan no such command menegaskan bahwa listShards hanya disediakan mongos, bukan mongod — pola yang sama dengan sh.status() pada Chapter sebelumnya.

Menambah Shard ke Cluster #

Kapasitas cluster ditambah dengan mendaftarkan replica set baru sebagai shard, lewat mongos:

// mdtest: skip
// Dijalankan lewat mongos pada sharded cluster sungguhan:
sh.addShard( "rs1/mongodb0.example.net:27018" )

Argumennya berupa nama replica set dan salah satu anggotanya. Begitu shard baru terdaftar, balancer otomatis mulai memindahkan chunk ke shard yang masih kosong itu — detail mekanismenya dibedah di Chapter Balancing. Syarat praktisnya satu: mongos dan config server harus bisa menjangkau shard baru dengan hostname yang sama-sama dapat diselesaikan DNS.

Rangkuman #

• Shard adalah replica set penyimpan subset data; tiap database punya primary shard untuk collection yang tidak di-shard, dan aplikasi tidak boleh menyentuh shard secara langsung.
• Config server (CSRS) menyimpan metadata cluster di database config — shards, databases, collections, chunks — dan menjadi baca-saja bila primary-nya tidak terpilih.
• mongos stateless dan murah, boleh diperbanyak dan diletakkan di mesin aplikasi; perintah cluster seperti listShards hanya dikenal oleh mongos.
• Shard baru didaftarkan lewat sh.addShard(); balancer kemudian menyeimbangkan data secara otomatis.

Komponen sudah jelas. Chapter berikutnya masuk ke keputusan yang paling menentukan nasib cluster: pemilihan shard key.