Day to Day MongoDB scripts to help Automate tasks and track of improvements
Documentation for SetGuardRails Script with authentication.
Overview This mongosh script automates the process of: Connecting to all nodes in a replica set (excluding arbiters). Running the setGuardrails command on the primary with writeConcern to replicate to all members. Waiting until each node has persisted the guardrails oplog entry to disk (lastStableRecoveryTimestamp >= appliedOpTime). Running fsync on every node in every loop iteration to force a WiredTiger checkpoint — speeding up stable timestamp progression. Reporting when all nodes have caught up.
- Discover replica set members via rs.status().
- Execute setGuardrails on the primary with writeConcern: {w: }.
- Optional Delay – wait 65 seconds before monitoring for forcing a checkpoint
- Check per node:
- Run { replSetGetStatus: 1 } to get:
- appliedOpTime.ts (latest op applied in memory)
- lastStableRecoveryTimestamp (durable recovery point on disk)
- Run { fsync: 1 } to force persistence every iteration.
- Exit loop for node when lastStableRecoveryTimestamp >= appliedOpTime.
Finish when all nodes have persisted the change.
- MongoDB v4.4.s8+
- mongosh shell ( Not Legacy Mongo )
clusterAdmin or root Must be able to run replSetGetStatus and fsync. Replica set name and auth credentials available.
Edit the variables at the top of the script:
const username = "clusteradmin"; // cluster admin username
const password = "clusteradmin"; // password
const authDb = "admin"; // database to authenticate against
const rsName = "shard01"; // replica set nameSave the script as a js file like SetGuardRails_checkOpTime.js Or simply copy paste the code above in a mongosh session.
Run in mongosh while connected to the primary in an authenticated session
mongosh "mongodb://clusteradmin:clusteradmin@primaryHost:27017/admin?replicaSet=shard01" SetGuardRails_checkOpTime.js
Replica set members: ["primaryHost:27017", "secondary1:27017", "secondary2:27017"]
setGuardrails result: { ok: 1 }
⏳ Waiting 65 seconds before starting persistence checks...
🔍 Starting durability check loop for node: primaryHost:27017
appliedOpTime: Timestamp({ t: 1761912498, i: 1 })
lastStableRecoveryTimestamp: Timestamp({ t: 1761912498, i: 1 })
📌 Running fsync on primaryHost:27017 to force WiredTiger checkpoint...
fsync result: { ok: 1 }
✅ Node primaryHost:27017 has fully persisted the guardrails entry.
...
🎉 All nodes have run fsync and caught up with durability!