Perancangan Konsistensi

Sejauh ini kita berdiskusi seolah semua baca dan tulis menyangkut satu server saja. Pada replica set, tulisan masuk ke primary lalu direplikasi ke secondary — dan pembaca bisa diarahkan ke anggota mana pun. Di titik ini muncul pertanyaan perancangan: seberapa kuat tulisan harus “menempel” sebelum dikonfirmasi, dan seberapa segar data yang boleh dibaca? Chapter penutup Section ini memadatkan pilihan itu: kombinasi write concern dan read concern, jaminan read your own writes, dan causal consistency session — lalu matriks keputusan untuk use case yang berbeda-beda. Detail mendalam tiap mekanisme menjadi milik Section Replication; di sini kita fokus pada cara memilihnya.

Tiga Tombol dan Default rs0 #

Tiga pengaturan mengatur dunia konsistensi, dan ketiganya pernah kita temui:

Kombinasi w: 1 + local cepat tetapi rawan: tulisan yang baru diakui primary bisa raib bila primary berhenti sebelum direplikasi. Kombinasi w: "majority" + majority lebih lambat tetapi kokoh — data yang sudah dibaca tidak akan berubah karena failover. Pada rs0 kita, default implisitnya { w: "majority" } untuk tulisan dan local untuk pembacaan — kita verifikasi angka ini lewat getDefaultRWConcern di Chapter Write Concern dan Write Results, dan mekanisme w/j/wtimeout juga sudah dibahas lengkap di sana.

Read Your Own Writes #

Masalah klasik konsistensi replication: pengguna menyimpan profil barunya, halaman dimuat ulang, dan perubahan itu tidak tampak. Urutannya: tulisan diakui oleh primary, tetapi halaman dibaca dari secondary yang replikasinya tertinggal beberapa ratus milidetik. Tiga penawarannya, dari yang paling sederhana:

1. Baca dari primary untuk semua permintaan yang mengikuti tulisan — read preference primary memastikan node yang sama yang barusan menulis.
2. w: "majority" + read concern majority — tulisan baru diakui setelah mayoritas memiliki, dan pembacaan majority tidak akan melompat lebih lawas dari itu.
3. Causal consistency session — solusi yang paling presisi, dan satu-satunya yang bekerja meski pembacaan berpindah anggota.

Sesi Causal Consistency #

Session yang kita pakai untuk transaksi bisa diberi mode causal consistency: setiap operasi membawa tanda waktu, dan server menjamin pembacaan berikutnya tidak lebih lawas dari tulisan yang sudah kita lakukan. Kombinasi wajibnya: tulisan dengan w: "majority", pembacaan dengan read concern majority. Kita amati jejak metadatanya langsung:

use latihan_relasi
db.pengaturan.drop()
var session = db.getMongo().startSession({ causalConsistency: true })
var dbSession = session.getDatabase("latihan_relasi")
dbSession.pengaturan.updateOne(
  { kunci: "biayaAdmin" },
  { $set: { nilai: 2500, diperbarui: ISODate("2026-01-06") } },
  { upsert: true, writeConcern: { w: "majority" } }
)
session.getOperationTime()
session.getClusterTime()

Output yang Dihasilkan:

switched to db latihan_relasi
true

{
  acknowledged: true,
  insertedId: ObjectId('6ad39c139d08d4e3fde1a3be'),
  matchedCount: 0,
  modifiedCount: 0,
  upsertedCount: 1
}
Timestamp({ t: 1792252947, i: 2 })
{
  clusterTime: Timestamp({ t: 1792252947, i: 2 }),
  signature: {
    hash: Binary.createFromBase64('AAAAAAAAAAAAAAAAAAAAAAAAAAA=', 0),
    keyId: 0
  }
}

[
  {
    _id: ObjectId('6ad39c139d08d4e3fde1a3be'),
    kunci: 'biayaAdmin',
    diperbarui: ISODate('2026-01-06T00:00:00.000Z'),
    nilai: 2500
  }
]

{ ok: 1, dropped: 'latihan_relasi' }

Rangkuman #

• Tiga tombol konsistensi: write concern (seberapa menempel tulisan), read concern (seberapa segar bacaan), read preference (baca dari anggota mana).
• Read your own writes diselesaikan bertingkat: baca dari primary, lalu majority+majority, lalu session kausal untuk jaminan paling presisi.
• Session kausal membawa operation time dan cluster time; jaminannya (read your writes, monotonic reads/writes) mensyaratkan majority di kedua arah.
• Pilih concern berdasarkan konsekuensi bisnis data basi atau hilang — matriks keputusan, bukan kebiasaan seragam.

Dengan itu, babak relasi dan konsistensi tuntas: referensi, join, atomicity, konkurensi optimis, transaksi, hingga perancangan konsistensi. Perjalanan berikutnya berpindah ke arsitektur penyebaran data — Section Replication membongkar replica set yang selama ini hanya kita pakai dari luar.