Replica-Set Roles, Primary/Secondary Members, Oplog Replication, and Majority Commit Point

Learning objectives

1. AtlasMart problem: what happened after checkout returned success?

A replica set is a group of mongod processes maintaining copies of the same logical data set. One data-bearing member normally acts as primary and accepts application writes; secondary members copy and apply history asynchronously. The replication record is the oplog, a special capped collection at local.oplog.rs. An optime combines an operation timestamp and election term. The majority commit point is the newest operation known written to a majority of voting data-bearing members—not simply the newest local operation.

2. Observe member state and commit progress before writing

Start from the server’s current view instead of assuming container A is primary forever. rs.status() includes heartbeat-derived state, so it is a current observation rather than a permanent assignment.

const s=rs.status();printjson({set:s.set,myState:s.myState,term:s.term});printjson(s.members.map(m=>({name:m.name,stateStr:m.stateStr,optime:m.optime,optimeDate:m.optimeDate,health:m.health})));printjson(s.optimes);printjson(rs.conf().members.map(m=>({_id:m._id,host:m.host,votes:m.votes,priority:m.priority})));

3. Write with majority acknowledgment and find the oplog entry

The fixture requests w:"majority". The exact oplog document is implementation-facing/version-sensitive evidence; the stable mechanism is that secondaries reproduce primary history by copying and applying oplog entries.

const shop=db.getSiblingDB("atlasmart");const orders=shop.orders_ch14_l1;orders.drop();const r=orders.insertOne({_id:"ORD-1401",tenantId:"tenant-a",status:"placed",totalCents:12900,createdAt:new Date()},{writeConcern:{w:"majority",wtimeout:10000}});printjson({acknowledged:r.acknowledged,insertedId:r.insertedId});const s=rs.status();printjson({term:s.term,lastCommittedOpTime:s.optimes.lastCommittedOpTime,appliedOpTime:s.optimes.appliedOpTime,durableOpTime:s.optimes.durableOpTime});const oplog=db.getSiblingDB("local").getCollection("oplog.rs");printjson(oplog.find({ns:"atlasmart.orders_ch14_l1"}).sort({$natural:-1}).limit(3).toArray());

4. Inspect the same logical history from a secondary

Direct diagnostic connections avoid replica-set discovery through Docker-only hostnames. This is an inspection path, not the application connection architecture.

mongosh "mongodb://127.0.0.1:27085/admin?directConnection=true" --quiet --eval 'const h=db.hello(); printjson({host:h.me,secondary:h.secondary,primary:h.primary});const s=rs.status(); printjson({term:s.term,optimes:s.optimes});const o=db.getSiblingDB("local").getCollection("oplog.rs");printjson(o.find({ns:"atlasmart.orders_ch14_l1"}).sort({$natural:-1}).limit(3).toArray());printjson(db.getSiblingDB("atlasmart").orders_ch14_l1.findOne({_id:"ORD-1401"}));' 

If the secondary has applied the write, both the document and matching history are visible. That proves local replication/application at that moment; it does not prove all members are forever caught up.

5. Deliberately wrong: “three copies means backup”

Replication propagates current history, including destructive history. The following disposable delete shows why replicas are not independent restore points.

const orders=db.getSiblingDB("atlasmart").orders_ch14_l1;const before=orders.findOne({_id:"ORD-1401"});const d=orders.deleteOne({_id:"ORD-1401"},{writeConcern:{w:"majority",wtimeout:10000}});printjson({before,deletedCount:d.deletedCount,after:orders.findOne({_id:"ORD-1401"})});printjson(db.getSiblingDB("local").getCollection("oplog.rs").find({ns:"atlasmart.orders_ch14_l1"}).sort({$natural:-1}).limit(3).toArray());

Production judgment. Replica sets add redundancy and failover but consume storage, network, CPU/cache, and operational/security budget. Monitor member state, optime lag, majority commit lag, flow control, disk, and oplog window. A three-member set on one laptop demonstrates protocol mechanisms, not independent failure domains.

Bridge. Lesson 2 builds the topology incrementally so configuration revision and member readiness become observable.

docker rm -f atlasmart-mongo-ch14-l1-a atlasmart-mongo-ch14-l1-b atlasmart-mongo-ch14-l1-c atlasmart-mongo-ch14-l1-d 2>/dev/null || truedocker volume rm atlasmart-mongo-ch14-l1-a-data atlasmart-mongo-ch14-l1-b-data atlasmart-mongo-ch14-l1-c-data atlasmart-mongo-ch14-l1-d-data 2>/dev/null || truedocker network rm atlasmart-ch14-l1-net 2>/dev/null || true