A primary node is the replica set member that accepts writes. It executes database operations, records successful data-changing operations in its oplog, and streams them to secondary members. Secondaries apply those operations asynchronously, so their progress can lag behind the primary. section 9.1.1 section 9.1.3
To inspect the role in mongosh:
- Run `db.adminCommand("replSetGetStatus")` or `rs.status()` to see each member’s current state. `PRIMARY` identifies the write-accepting member; `SECONDARY` identifies a replicating member. section 9.1.1
- Run `db.adminCommand("replSetGetConfig")` or `rs.config()` to inspect member settings such as priority and votes. The configuration command requires an M10 or larger Atlas cluster. section 9.1.1
Listing 9.1 Output of the replSetGetStatus command
db.adminCommand("replSetGetStatus").members.map((m) =>
➥({ _id: m._id, name: m.name, state: m.state, stateStr: m.stateStr }))
[
{
_id: 0,
name: 'ac-5dhjxpf-shard-00-00.fpomkke.mongodb.net:27017'
state: 2,
stateStr: 'SECONDARY'
},
{
_id: 1,
name: 'ac-5dhjxpf-shard-00-01.fpomkke.mongodb.net:27017'
state: 1,
stateStr: 'PRIMARY'
},
{
_id: 2,
name: 'ac-5dhjxpf-shard-00-02.fpomkke.mongodb.net:27017'
state: 2,
stateStr: 'SECONDARY'
}
]
The status listing shows one member reporting `PRIMARY` and two reporting `SECONDARY`, making the write role easy to distinguish from the replication roles. section 9.1.1
Replication improves availability and can distribute reads, but every write in a replica set still passes through its primary. If that becomes a write bottleneck, sharding partitions data so writes to different shards can be handled by their respective primaries. Each shard still needs replication for availability. section 9.0
