Upgrade MongoDB

Upgrade server database bukan apt-get upgrade yang dijalankan begitu notifikasi muncul — satu perbedaan perilaku antar versi bisa menghentikan aplikasi yang semalam sehat. Karena itu MongoDB merancang proses upgrade bertahap yang bisa dihentikan di tengah jalan tanpa kehilangan layanan. Chapter ini membahas siklus rilis MongoDB, prasyarat yang harus dipenuhi, urutan resmi upgrade replica set, peran featureCompatibilityVersion sebagai sabuk pengaman, dan pertimbangan rollback.

Peta materi chapter ini:

Siklus rilis: major, rapid, dan patch.
Prasyarat: release notes, driver, backup, jalur upgrade.
Prosedur replica set: secondary dulu, primary terakhir.
featureCompatibilityVersion dan jendela rollback.

Siklus Rilis MongoDB #

Nomor versi 9.0.2 yang kita pakai sebenarnya tiga angka dengan tiga makna berbeda:

Jenis	Contoh	Perilaku	Dukungan
Major	`8.0`, `9.0`	Bisa membawa perubahan tidak kompatibel	Panjang — 9.0 (Sept 2026) hingga Okt 2031; 8.0 hingga Okt 2029
Rapid/minor	`9.1`, `9.2`, `9.3`	Fitur baru, dirilis kira-kira kuartalan	Singkat — hanya sampai rapid berikutnya
Patch	`9.0.2`	Perbaikan galat dan keamanan, tanpa fitur baru	Mengikuti major-nya

Untuk produksi, aturan praktisnya: tetap di rilis major terkini dan ambil patch segera (terutama patch keamanan); rilis rapid hanya bila Anda membutuhkan fiturnya lebih dulu. Patch seperti 9.0.1 → 9.0.2 aman diambil hampir kapan saja, sedangkan pindah major seperti 8.0 → 9.0 memerlukan prosedur penuh di bawah.

Prasyarat Sebelum Menyentuh Binary #

Empat kotak yang wajib dicentang sebelum upgrade major:

Baca release notes versi tujuan — terutama bagian compatibility changes; MongoDB 9.0 misalnya menghapus fitur yang sudah lama ditandai deprecated.
Periksa kompatibilitas driver — driver versi lama sering tidak mengenali server baru; naikkan driver aplikasi lebih dulu bila perlu (matrix resmi ada di halaman MongoDB Drivers).
Backup teruji pemulihannya — backup yang belum pernah direstorasi bukan backup; section Backup dan Recovery membahas uji pemulihannya.
Pastikan jalur upgrade sekuensial — lompatan major tidak didukung: dari 7.0 harus melewati 8.0 sebelum 9.0. Di setiap pemberhentian, featureCompatibilityVersion harus sudah naik sebelum melanjutkan.

Kapasitas disk juga ikut bermain: binary baru, proses penyalinan data saat index dibangun ulang, dan backup sementara semuanya butuh ruang.

Prosedur Replica Set: Secondary Dulu #

Urutan resminya dirancang agar selalu ada anggota siap melayani. Prinsipnya satu kalimat: naikkan secondary satu per satu, turunkan primary lewat stepDown, baru naikkan primary — dan simpan perintah setFeatureCompatibilityVersion paling akhir:

flowchart TD A[Backup + release notes + driver] --> B[Upgrade secondary 1] B --> C[Sehat?] C -- tidak --> R[Rollback binary anggota itu] C -- ya --> D[Upgrade secondary berikutnya] D --> E[rs.stepDown pada primary] E --> F[Upgrade mantan primary] F --> G[Soak period: amati 1-2 minggu] G --> H[setFeatureCompatibilityVersion 9.0]

Langkah stepDown memaksa election sehingga mantan primary turun menjadi secondary dan bisa di-upgrade tanpa jendela layanan kosong:

js
// mdtest: skip
rs.stepDown()

Setelah anggota terakhir naik versi, seluruh set berjalan dengan binary 9.0 — tetapi masih menjalankan perilaku versi lawas. Di sinilah sabuk pengaman berperan.

featureCompatibilityVersion #

Setiap replica set menyimpan satu pengaturan bernama featureCompatibilityVersion (fCV). Dua angka yang wajib dibandingkan saat upgrade adalah versi binary dan fCV — keduanya bisa dibaca tanpa risiko:

js
db.version()

Output yang Dihasilkan:

text

9.0.2

Itu versi binary yang terpasang. Sekarang fCV-nya:

js
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

Output yang Dihasilkan:

text
{
  featureCompatibilityVersion: { version: '9.0' },
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1792268233, i: 1 }),
    signature: {
      hash: Binary.createFromBase64('AAAAAAAAAAAAAAAAAAAAAAAAAAA=', 0),
      keyId: Long('0')
    }
  },
  operationTime: Timestamp({ t: 1792268233, i: 1 })
}

Server latihan kita memperlihatkan version: '9.0' — fCV mengikuti major yang terpasang. Pada cluster yang baru saja di-upgrade dari 8.0, nilai ini masih '8.0': server 9.0 sengaja menahan fitur dan format data baru sampai fCV dinaikkan secara eksplisit:

js
// mdtest: skip
db.adminCommand({ setFeatureCompatibilityVersion: "9.0" })

Perintah ini tidak bisa dibalik dengan santai — itulah gunanya soak period: biarkan cluster berjalan beberapa waktu (praktik umum satu hingga dua minggu) untuk memastikan versi baru stabil di beban nyata, baru naikkan fCV. Selama fCV belum naik, binary bisa diturunkan kembali ke versi major sebelumnya.

Upgrade Standalone dan Patch #

Untuk standalone (tanpa replica set), prosedurnya versi sederhana tanpa election: hentikan mongod dengan sopan, ganti binary dengan versi baru, nyalakan kembali, lalu naikkan fCV setelah yakin. Jendela layanan kosong tidak terhindarkan karena tidak ada anggota lain — jadwalkan di jam sepi. Patch (9.0.1 → 9.0.2) cukup mengikuti alur yang sama tetapi tanpa perubahan fCV; inilah alasan patch aman diambil cepat sementara major tidak.

Rangkuman #

Rilis major didukung ±5 tahun (9.0 hingga 2031), rapid kuartalan, patch aman segera; jalur major wajib sekuensial.
Prasyarat: release notes, kompatibilitas driver, backup teruji, dan ruang disk memadai.
Urutan replica set: secondary satu per satu → rs.stepDown() → upgrade primary → setFeatureCompatibilityVersion paling akhir setelah soak period.
fCV menahan perilaku versi baru; selama belum dinaikkan, rollback binary masih terbuka — sesudahnya, pemulihan backup satu-satunya jalan.