I have a problem in mongodb replication .
Whenever my replica server is down (which is secondary node). Then I can't read from master db (and I guess it should not happen, because master database is up and running ).
I have two micro services ....one is calling only the master db in node js like ----
Mongo.connect(masterurl)
If I hit any api in backend that is querying the database, I get the error
not master or slave=false
And on the master db it shows ..connection refused to ip:port
But when the replica db is up then there is no error .
Master and replica are on different ip .
Thanks
If you have a two-node replica set, and one of the nodes is unavailable, the replica set does not have a primary. In order for a primary to exist in the RS, the majority of nodes must be available and communicating (so that they can elect the primary).
Then I can't read from master db (and i guess it should not happen , bacause master db is up and running ).
The "master db" is not a MongoDB concept, so this statement is meaningless in the context of MongoDB.
If you wish to run MongoDB in resource constrained environments, consider a PSA setup which comes with reduced redundancy and fault tolerance compared to PSS.
Related
I am using nodejs driver to write to MongoDB cluster. The cluster is on kubernetes with 2 mongos replicas, 4 shards with PSS setup each and config server with PSS setup as well.
My application (nodejs) connects to mongos (mongos replicas are behind kubernetes service) which then writes/reads from shards. All works fine until I simulate a failover i.e. shutdown the primary pod in one of the shard replica (which is also the primary shard for the database). When primary fails, one of the secondary steps up as primary and the failed pod is restarted by kubernetes, as expected. But then what I observe is that none of the writes are actually reflecting into the collection even though the results show as success from nodejs app (with acknowledged: true and inserted ids in the result).
I could also confirm from mongod logs on new primary that it received the writes and resulted in nInserted: <some-number> and no error. But when I query the collection itself then there are no entries after new primary was elected.
However, if I shutdown the newly elected primary of shard replica so that the old pod becomes the new primary once again, then all writes start to reflect in the collection correctly. Strange behaviour I am trying to get my head around, appreciate your suggestions.
MongoDB version: 5.0.2
NodeJs driver version: 4.9
Write concern used: majority
Read preference: primary (default)
Shards and config servers are statefulSets.
Mongos is a replicaSet of 2 pods.
NodeJS app connects to mongos via k8s service.
All shards (primary and secondaries headless service DNS names) are added to mongos.
Update:
From further troubleshooting, I found that the writes are lost only when the primary shard of a database loses its primary member of replica set and another member is elected as primary (everything works if other non-primary shards of the database lose their primary member).
My NodeJS app is working with ReplicaSet of mongo. I want to client read data from secondary, so I set readPreference=secondary, but If secondary is down, NodeJS app cannot read data from mongo. With option secondaryPreferred, if no secondary is available, NodeJS can read data from primary instance. But if have no primary available, have only secondary available, I cannot start NodeJS app. It throw error failed to connect to server [xxxx] on first connect [Error: connect ECONNREFUSED xxx.xx.xx.xx:27017
How I can config mix between secondary and secondaryPreferred. I expect my NodeJS can start even have only one instance available, no care it's primary or secondary. When NodeJS running, if have one mongo instance down, it's auto read from other instance
"if have no primary available" is not normal state of the replica. Let the election to happen, then start your app.
Primary is a mandatory member of a replica set. All writes are going to primary. When you connect to the replica-set the driver should know where to write to, even if you don't intend to write on application level.
Once connected, your application can survive temporary loss of primary and read from secondaries.
As a side note - consider adding an arbiter. 2 nodes replica set is a recipe for disaster.
I have a Redis replication group where I have 1 master and 2 slave nodes. Slave nodes are read only. I am using node_redis to connect to Redis endpoint.
Now I want my application to connect to only slave nodes for any read query and only write query should go to master node. Do I have to make any changes in my application to connect or I can connect to master node and elastic cache will automatically redirect read queries to slave nodes?
Point the 'read queries' to the 'endpoint' of the slave node if used for non-critical purposes.
Another point to note is that data in Slave node 'may' be stale
Keep in mind that primary node can also be used for 'read'
Elasticcache does the load balancing of read queries
All node have run with the same config.
When I send high write load to my replica set I found one of my secondary node have high Replication Lag.
In Mongodb client(nodejs mongodb v2.0.42) I connect to replica set with readPreference=secondaryPreferred
It should have the same behaviour in both secondary.
I find out that one of my server doesn't have same Read Ahead as others.
So I follow this instruction
Problem solve!
I have a nodejs app that connects to mongodb.
Mongodb allows replicaset client connection to provide a level of resilience.
e.g "mongodb://localhost:50000,localhost:50001/myproject?replicaSet=foo", the client first connects to localhost#50000 and if that dies it switches to localhost#50001.
This is fine but if when the application starts and if one of the two mongo is dead then the application dies - with can't connect error.
The only solution I can think is to reformat the url so it excludes the inactive instance, but would like to avoid this ...
Any ideas?
Thanks
Replicaset works fine when do you have an odd number of servers, because MongoDB ReplicaSet work using election between nodes for define what server will be the "primary".
You can to add a new node in your ReplicaSet just for voting. It's called "ARBITER".
You can understand more about ReplicaSet Elections on this page https://docs.mongodb.com/manual/core/replica-set-elections/#replica-set-elections.
As Rafael mentioned, a replica set needs an odd number of members to be able to function properly when some of the members are offline. There are more details in the Replica Set Elections docs page, but the most relevant is:
If a majority of the replica set is inaccessible or unavailable to the current primary, the primary will step down and become a secondary. The replica set cannot accept writes after this occurs, but remaining members can continue to serve read queries if such queries are configured to run on secondaries.
The node driver by default requires a Primary to be online to be able to connect to the replica set, and will output an error you observed when you try to connect to a replica set without a Primary.
This default behaviour can be changed by setting connectWithNoPrimary to true. However, to be able to do queries, you also should set the proper readPreference setting (which also defaults to Primary). For example:
var MongoClient = require('mongodb').MongoClient
conn = MongoClient.connect('mongodb://localhost:27017,localhost:27018,localhost:27019/test',
{
replicaSet: 'replset',
connectWithNoPrimary: true,
readPreference: 'primaryPreferred'
}).catch(console.log)
More information about the connection options can be found in the Node Driver URI Connection Settings page