mongod is actual mongodb daemon what "is" the database. mongo is just client program what connects to mongod process (in this case; with sharded cluster it connects to mongos -process).
So, mongod process must be running before mongo can connect it.
You wrote that sudo systemctl enable mongod.service don't work anymore? Check if that service has (some how) changed its name. Just give command sudo systemctl|grep -i mongo and you can see if it is there and it is enabled. IF still your mongod process don't start automatically after reboot, check /var/log/mongodb/mongodb.log (you can check that lock file name with sudo grep path /etc/mongod.conf -command) says. What is the error? Fix that error (maybe chown of directory and files?) and try again with sudo systemctl restart mongod.service (or what ever is services name)
Given your current replica set configuration, this behaviour is expected.
In order to be elected (and remain) primary, a replica set member must have connectivity with a majority of voting replica set members.
Your configuration has two members which have priority 0 and cannot be elected as primary, so there is only one candidate for primary (the member _id:0 ). However, all of the members in your replica set are voting so the required majority to elect a primary is 2/3 configured replica set members.
Based on the log information you have provided from the member you prefer as primary, the replica set member state timeline looks like:
- Member with
_id: 0 is started and performs WiredTiger consistency checks for the data files. The mongod transitions from replica set STARTUP (reading configuration) to STARTUP2 (enabling replication threads).
- STARTUP2 completes and the member briefly transitions to RECOVERING and then SECONDARY state, where it is now ready to connect to other members of the replica set based on the last saved replica set configuration.
- Network connectivity to the other members is not available (
Connection refused), so the member transitions into a SECONDARY state and marks the other members of the replica set as unreachable: Member mongo2:27017 is now in state RS_DOWN. Since there is only 1 voting member available out of the 3 configured, a primary cannot be elected so this member will remain SECONDARY and will not propose an election.
- When network connectivity issues are resolved, the status of other members of the replica set can now be determined:
Member mongo2:27017 is now in state SECONDARY.
- The replica set now has connectivity between enough members to start an election. The reason for the election is also noted:
Starting an election, since we've seen no PRIMARY in the past 10000ms.
- The election succeeds (
election succeeded, assuming primary role in term 42) and this member transitions from SECONDARY to PRIMARY state.
I need primary to be write to access at all times - I can't have it switch to secondary in case one of the secondary fails and has to reconnect.
The default configuration for a replica set is designed for automatic failover: if the current primary becomes isolated from a majority of replica set members, a new primary can be elected to continue write availability.
If you do not want automatic failover, set the votes for your secondaries to 0:
var conf=rs.conf()
conf.members[1].votes = 0
conf.members[2].votes = 0
rs.reconfig(conf)
With only one voting member in the replica set configuration, the primary is now able to elect itself irrespective of the connectivity or health of the other replica set members.
There are a few obvious caveats with this configuration:
Since you only have a single voting node, a w:majority write concern is equivalent to w:1 and will only request acknowledgement from the primary.
If the primary remains disconnected from the other replica set members for any significant duration, the secondaries may become stale and require a full resync. You can mitigate this by increasing the size of the replication oplog for each of your replica set members in order to provide an appropriate buffer.
Best Answer
As per your it seems like that your mongod server has not started.
As per MongoDB documentation here All read preference modes except primary may return stale data because secondaries replicate operations from the primary with some delay. [1] Ensure that your application can tolerate stale data if you choose to use a non-primary mode.
MongoDB drivers support five read preference modes.
As MongoDB documented setSlaveOk() This allows the current connection to allow read operations to run on secondary members. See the readPref() method for more fine-grained control over read preference in the mongo shell.
For further your ref here, here and here