Proses Server Database

Di mata sistem operasi, server MongoDB hanyalah sebuah proses biasa: bisa dinyalakan, dipantau dengan ps, dan dihentikan dengan sinyal. Yang membedakannya dari program biasa adalah cara berhentinya — proses database harus sempat menyiram data dari memori ke disk sebelum benar-benar tutup. Chapter ini membahas dua proses inti (mongod dan mongos), cara mengelolanya lewat systemd maupun manual, sinyal yang tepat untuk menghentikannya, dan batasan ulimit yang sering dilupakan.

Peta materi chapter ini:

Perbedaan mongod dan mongos.
Siklus hidup layanan lewat systemctl.
Menjalankan proses manual dengan --fork.
Sinyal SIGTERM vs SIGKILL.
ulimit dan file descriptor.

mongod dan mongos #

Dua nama proses ini muncul di hampir semua artikel MongoDB, jadi bedakan sejak awal:

Aspek	`mongod`	`mongos`
Peran	Daemon utama: menyimpan dan mengolah data	Router query untuk sharded cluster
Data	Punya `dbPath` sendiri	Tidak menyimpan data (stateless)
Port bawaan	27017	27017 (dikonfigurasi bebas)
Dipakai kapan	Standalone dan replica set — termasuk server latihan kita	Hanya ketika collection dipecah ke banyak shard

Sepanjang course ini kita hanya bekerja dengan mongod; mongos baru relevan di section Sharding. Semua perintah siklus hidup di bawah berlaku untuk keduanya karena keduanya adalah proses Linux yang sama-sama dikelola sistem operasi.

Mengelola Layanan dengan systemd #

Instalasi lewat paket (apt, yum, brew services) mendaftarkan mongod sebagai unit layanan, sehingga hidup-matinya dikelola systemd. Perintah yang perlu Anda hafal:

bash
systemctl status mongod      # apakah hidup, sejak kapan, baris log terakhir
systemctl start mongod       # menyalakan
systemctl stop mongod        # menghentikan dengan sopan (kirim SIGTERM lalu tunggu)
systemctl restart mongod     # stop lalu start — dipakai setelah mengubah mongod.conf
systemctl enable mongod      # otomatis menyala saat booting

Dua perintah pertama yang paling sering dipakai sehari-hari; restart menjadi wajib setiap kali mongod.conf diubah karena konfigurasi hanya dibaca saat proses menyala. Log layanan bisa diikuti tanpa membuka file log langsung:

bash

journalctl -u mongod -f      # mengikuti log layanan secara live

Unit systemd menjalankan mongod --config /etc/mongod.conf di foreground — tanpa --fork, karena systemd sendiri yang bertindak sebagai pengawas proses.

Menjalankan Proses Secara Manual #

Mode manual dipakai saat belajar, menguji konfigurasi kedua, atau diagnosis. Opsi --fork melepaskan proses ke latar belakang dan mewajibkan --logpath agar output tidak menempel di terminal:

bash
mkdir -p /tmp/latihan-mongod/data
mongod --dbpath /tmp/latihan-mongod/data --port 28018 --fork \
  --logpath /tmp/latihan-mongod/mongod.log

Output yang Dihasilkan:

text
about to fork child process, waiting until server is ready for connections.
forked process: 31866
child process started successfully, parent exiting

Baris kedua memberi tahu PID anak (31866) — catat angka ini karena dipakai untuk menghentikan proses. Kehadiran proses bisa dipastikan dari sisi sistem operasi:

bash

ps -o pid,rss,cmd -C mongod

Output yang Dihasilkan:

text

  PID    RSS CMD
31866 148764 mongod --dbpath /tmp/latihan-mongod/data --port 28018 --fork --logpath /tmp/latihan-mongod/mongod.log

Kolom RSS menunjukkan memori fisik proses dalam KB — sekitar 145 MB untuk instance baru, dan akan tumbuh seiring cache terisi. Contoh di atas memakai port 28018 agar tidak bentrok dengan server latihan utama di 27017.

Anatomi Proses dari Dalam #

Satu proses mongod sebenarnya adalah sekumpulan thread pekerja. Dari dalam mongosh, identitas proses yang kita sambangi terlihat lewat serverStatus:

js
const ss = db.serverStatus()
ss.process
ss.pid
Math.floor(ss.uptime / 3600)

Output yang Dihasilkan:

text
mongod
Long('3067')
6

Nilai pid di sini adalah PID yang sama dengan yang dilaporkan ps — cara cepat memastikan mongosh terhubung ke proses yang Anda kira. Sedangkan uptime dalam jam menunjukkan proses sudah hidup selama itu; angka yang tiba-tiba kecil berarti proses baru saja restart. Daftar thread internalnya bisa diintip lewat currentOp:

js
db.adminCommand({ currentOp: 1, active: true }).inprog.map(op => op.desc)

Output yang Dihasilkan:

text
[
  'conn8538',
  'NoopWriter',
  'OplogApplier-0',
  'Checkpointer',
  'JournalFlusher'
]

Nama conn diawali nomor koneksi yang berubah setiap sesi mongosh — sisanya adalah thread tetap server.

Nama-nama itu bukan proses acak: Checkpointer menjalankan checkpoint WiredTiger secara berkala, JournalFlusher menyiram write-ahead journal, dan OplogApplier memutar operasi replikasi. Chapter Monitoring Server membahas currentOp jauh lebih dalam; di sini cukup pahami bahwa kesehatan mongod adalah kesehatan kumpulan thread ini.

Menghentikan Proses dengan Benar #

Ada tiga cara sopan menghentikan mongod: systemctl stop mongod, kill -TERM <pid>, atau perintah khusus dari mongosh:

js
// mdtest: skip
use admin
db.shutdownServer()

Ketiganya bermuara ke jalur yang sama: proses diberi kesempatan menyelesaikan operasi berjalan, menyiram data ke disk, lalu menutup file dengan rapi. Jejaknya terlihat di log saat kita mengirim SIGTERM ke instance latihan tadi:

bash
kill -TERM 31866

Output yang Dihasilkan (cuplikan log mongod.log):

text
{"t":{"$date":"2026-10-17T20:01:16.919+00:00"},"s":"I",  "c":"CONTROL",  "id":23377,   "ctx":"SignalHandler","msg":"Received signal","attr":{"signal":15,"error":"Terminated"}}
{"t":{"$date":"2026-10-17T20:01:16.919+00:00"},"s":"I",  "c":"-",        "id":23411,   "ctx":"SignalHandler","msg":"Signal was sent by kill(2)"}
{"t":{"$date":"2026-10-17T20:01:16.919+00:00"},"s":"I",  "c":"-",        "id":23412,   "ctx":"SignalHandler","msg":"will terminate after current cmd ends"}

Konteks SignalHandler membuktikan proses menangkap sinyal dan mematikan dirinya secara terkontrol, bukan dipaksa putus di tengah jalan. Setelah rangkaian pembersihan (menutup koneksi, checkpoint terakhir, melepas file lock), log diakhiri pesan mongod shutdown complete.

ulimit dan File Descriptor #

Setiap koneksi klien dan setiap berkas WiredTiger memakan satu file descriptor. Batas bawaan sistem sering kali terlalu kecil untuk database. Periksa nilai saat ini:

bash

ulimit -n

Output yang Dihasilkan:

text

Angka 1024 cukup untuk latihan, tetapi produksi bisa menemui batas ini begitu jumlah koneksi dan collection bertambah. MongoDB merekomendasikan nilai 64000 untuk nofile (file descriptor) dan nproc (jumlah proses/thread). Naikkan melalui /etc/security/limits.conf untuk sesi login, atau LimitNOFILE=64000 pada unit systemd agar berlaku khusus untuk mongod.

Rangkuman #

mongod adalah daemon penyimpan data; mongos hanya router untuk sharded cluster.
Produksi: kelola lewat systemctl (start/stop/restart/status); restart wajib setelah mengubah mongod.conf.
Mode manual memakai --fork + --logpath; PID dicetak saat proses menyala dan dipakai untuk menghentikan proses.
Hentikan hanya lewat jalur sopan: systemctl stop, SIGTERM, atau db.shutdownServer(); SIGKILL memotong pembersihan dan memicu recovery.
Pastikan ulimit -n cukup besar (rekomendasi 64000) sebelum server menerima beban nyata.