Error
Error Code:
95
MongoDB Error 95: Not Secondary Member Write
Description
Error 95, 'Not Secondary', indicates that a write operation was attempted on a replica set member that is not the current primary. MongoDB replica sets only allow write operations to be performed on the primary member. This error prevents data modification on non-primary nodes.
Error Message
Not Secondary
Known Causes
3 known causesApplication Targeting Secondary
The client application or driver is configured to send write operations directly to a secondary replica set member instead of the primary.
Primary Step Down/Failover
The previous primary member stepped down or failed, and the application attempted a write before a new primary was elected or the driver updated its view of the replica set.
Manual Write on Secondary
A user manually attempted to perform a write operation via the MongoDB shell or a client tool directly connected to a secondary replica set member.
Solutions
4 solutions available1. Direct Writes to Primary easy
Ensure your application is attempting writes to the replica set primary.
1
Identify the current primary member of your replica set. You can do this by connecting to any member and running the `rs.status()` command.
rs.status()2
Verify your application's MongoDB connection string. It should be configured to connect to the replica set and allow failover. If your application is explicitly configured to connect to a secondary, update the connection string to point to the primary or the replica set name.
mongodb://primary_host:27017,secondary_host:27017/?replicaSet=myReplicaSet3
If you are using a driver, check its documentation for how to ensure write operations are routed to the primary. Most drivers handle this automatically when connected to a replica set.
N/A (Driver specific)2. Check Replica Set Health and Election Status medium
Investigate if a primary is unavailable or if an election is in progress.
1
Connect to any member of the replica set and run `rs.status()` to check the overall health of the replica set. Look for any members that are in an unhealthy state (e.g., `DOWN`, `STARTUP2`, `RECOVERING`).
rs.status()2
Examine the `members` array in the `rs.status()` output. The member with `stateStr: 'PRIMARY'` is the current primary. If no primary is listed, an election is likely in progress or the replica set is not configured correctly.
N/A (Analyze rs.status() output)3
If an election is in progress, wait for it to complete. During an election, there is no primary, and writes will fail. Once a new primary is elected, writes should resume.
N/A (Wait for election)4
If a member is consistently unhealthy, investigate the logs of that member for specific errors. Address any underlying network, disk, or configuration issues.
N/A (Check member logs)3. Configure Write Concern medium
Adjust write concern settings to ensure writes are acknowledged by a sufficient number of nodes.
1
Understand write concern. It specifies the number of members that must acknowledge a write operation before it is considered successful. If your write concern is too high for the available secondaries, you might encounter this error during failover or network partitions.
N/A (Conceptual)2
When performing write operations, set an appropriate `w` value. For example, `w: 1` (default) means the write is acknowledged by the primary. `w: 'majority'` means the write is acknowledged by a majority of the replica set members.
db.collection.insertOne({ item: 'book', qty: 20, tags: ['electronics'] }, { writeConcern: { w: 1 } })3
If you are experiencing this error frequently, especially during network interruptions, consider reducing the write concern to `w: 1` for less critical operations or ensure your replica set has sufficient members to satisfy higher write concerns.
db.collection.insertOne({ item: 'book', qty: 20, tags: ['electronics'] }, { writeConcern: { w: 'majority' } })4
You can also set a default write concern for a database or collection using `db.settings.setOption()` or `db.setWriteConcern()`.
db.settings.setOption( 'writeConcernDefault', { w: 1 } );4. Review Application Read Preference easy
Ensure reads are not inadvertently directed to secondaries when writes are expected.
1
Check your application's MongoDB connection string or driver configuration for `readPreference`. If `readPreference` is set to `secondary`, `secondaryPreferred`, or `nearest` and your application expects to perform writes, this could lead to issues if the client attempts a write to a secondary.
mongodb://host1:27017,host2:27017/?replicaSet=myReplicaSet&readPreference=secondary2
For operations that should always go to the primary (like writes), ensure the `readPreference` is not set to a secondary-only option. If you need to read from secondaries, use separate connections or carefully manage read preferences per operation.
N/A (Application configuration)3
The default `readPreference` is `primary`, which is generally what you want for write operations and consistent reads.
N/A (Default behavior)