Error
Error Code:
10107
MongoDB Error 10107: Not Writable Primary
Description
This error indicates that a write operation was attempted on a MongoDB replica set member that is not currently the primary. Only the primary member can accept write operations in a replica set.
Error Message
Not Writable Primary
Known Causes
3 known causesApplication Targeting Secondary
The application's connection string or logic directed a write operation to a secondary replica set member.
Primary Unavailable or Stepped Down
The replica set primary member has stepped down, become unavailable, or is not reachable by the application.
Replica Set Election in Progress
The replica set is actively undergoing an election process to choose a new primary, during which writes are temporarily paused.
Solutions
4 solutions available1. Verify Replica Set Primary Status easy
Ensure the correct node is acting as the primary and is available for writes.
1
Connect to any member of your MongoDB replica set using the `mongosh` shell.
mongosh2
Run the `rs.status()` command to get the replica set status.
rs.status()3
Examine the output for the `stateStr` field of each member. Look for the member with `stateStr: "PRIMARY"`. Ensure this node is reachable and healthy.
rs.status()4
If the primary is not the expected node or is unhealthy, investigate the cause of the failover or the primary's unresponsiveness. This might involve checking logs, network connectivity, or resource utilization on the primary.
text2. Check for Network Issues or Firewall Restrictions medium
Confirm that your application can communicate with the current primary node on the MongoDB port.
1
Identify the hostname and port of the current primary node from `rs.status()`.
rs.status()2
From the machine where your application is running, attempt to connect to the primary node using `mongosh` or a network utility like `telnet`.
telnet <primary_hostname> <mongodb_port>3
If the connection fails, check for any firewall rules on the application server, the MongoDB server, or any intermediate network devices that might be blocking traffic on the MongoDB port.
text4
Ensure that DNS resolution is working correctly if you are using hostnames.
text3. Review Write Concern Settings medium
Verify that the write concern configured for your operations is achievable by the replica set.
1
Examine the `writeConcern` settings for your database or collection. Common values include `w: 1` (majority writes) or `w: 'majority'`.
db.getWriteConcern()2
If your write concern requires acknowledgement from a majority of nodes (`w: 'majority'` or `w: 2` for a 3-node replica set), ensure that a sufficient number of nodes are healthy and reachable.
text3
If you are experiencing transient network issues or a temporary node unavailability, temporarily reducing the write concern (e.g., to `w: 1`) might allow writes to proceed, but this should be done with caution as it reduces durability guarantees.
db.setWriteConcern({ w: 1 })4
Alternatively, if your application is consistently sending operations with a high write concern to a replica set that cannot satisfy it, consider adjusting your application's write concern or increasing the replica set size.
text4. Address Replica Set Member Health and Configuration advanced
Ensure all members of the replica set are running, healthy, and have consistent configurations.
1
Connect to the primary node and run `rs.status()` to check the health of all members. Look for any members that are `DOWN`, `STARTUP`, or in an `UNHEALTHY` state.
rs.status()2
Check the MongoDB logs on all replica set members for errors related to replication, network connectivity, or disk I/O. The log file location can typically be found in the MongoDB configuration file (`mongod.conf`).
text3
Verify that the `replication.replSetName` parameter is correctly configured and identical on all `mongod` instances belonging to the same replica set.
text4
Ensure that all members have a valid `net.bindIp` and `net.port` configuration that allows them to communicate with each other. For inter-node communication, `bindIp` should typically include the IP addresses of other members or be set to `0.0.0.0` (with appropriate security measures).
text5
Restart any unhealthy or non-responsive replica set members after addressing any identified issues. If a member has been down for an extended period, it might require a resync.
sudo systemctl restart mongod