MongoDB replication issues

Ops and Admin Replication
1

Hello, I have configured my replica set with 2 nodes (our use case is not fail over case), So we have one primary and one non-voting secondary, and no arbiter. The idea is to have normal application traffic go to the primary and some analytics-related queries go to the secondary and also some data analytics team uses the secondary node for read-only purposes.

I have set the default global read and write concern in the following way.

db.adminCommand({
  "setDefaultRWConcern" : 1,
  "defaultWriteConcern" : {
    "w" : 2
  },
  "defaultReadConcern" : { "level" : "majority" }
})

And my connection details as follows :

await mongoose.connect(dbUrl,{replicaSet: 'replname', readPreference : 'primary'});

Here comes my issue :

on creating user like following

await User.create({ name: 'test-user'});'

and reading it immediately :

await User.findOne({name:'test-user'})

gives NULL results.

here we have 2 issues ==>

  1. My assumption is, as we have mentioned ‘primary’ as the default readPreference in connection URL, the query should fetch results always from the primary., looks like it’s trying to fetch from the secondary.

  2. as we have set writeConcern as ==>w:2, even from secondary data should come instead of returning NULL.

please let me know if am missing anything here.

thanks

3

Hey @Gangadhar_M,

Welcome to the MongoDB Community!

As per the documentation:

“After the write operation returns with a w: "majority" acknowledgment to the client, the client can read the result of that write with a "majority" readConcern.”

However, in your case, it depends on how you are executing the code and reading your own writes. Could you please share your workflow? Also, could you provide information about where you have deployed your MongoDB server?

Although, you have the option to read your own writes:

  • If you are using a read preference of “majority”, and write concern of “majority” you are ensured to achieve read-after-write consistency across all operations that utilize the same thread.

  • Also, in scenarios where multiple threads are in use and you are exclusively reading from primary nodes, you are guaranteed the achievement of read-after-write consistency, provided that you perform the read operation in the second thread only after the write operation has concluded in the first thread.

To learn more, please refer to the

In case of further assistance, share the code snippet you are trying to execute to test this out.

Regards,
Kushagra

4

Thanks Kushagra for response,
Will go through this and comeback.

thanks

5

@Gangadhar_M

Seems you have found the solution. Can you explain what is the root cause of your observed issue and what is the ultimate fix?

6

Hi ,

With following read and write concerns,

db.adminCommand({
  "setDefaultRWConcern" : 1,
  "defaultWriteConcern" : {
    "w" : 2
  },
  "defaultReadConcern" : { "level" : "majority" }
})

And knowing little more on readConcerns, we come to conclusion that why I faced these issues. I just mentioned them below with their cause.

Issue 1 :
As I have mentioned my writeConcern as ==> {w:2} data might not have been durable by the time am reading it through readConcern of ==> “majority”,
May be because of that I was not getting data even from primary node

Issue 2 :
Same thing applies to Secondary as well, with writeConcern as ==> {w:2} and read concern as ==>. “majority” you are trying to read durable data from secondary.
By the time that you are trying to read, it might not have been durable in the secondary.

With this , readConcern also plays a major role while reading the data. In our case, as we are not using any Transaction for storing data, and speed is main concern,
{readConcern: ‘local’} makes more sense for us. With this we get data faster as we are not looking at any fail over cases.

Hope this helps.

Thanks
Gangadhar M

7

Thx for the info. That makes sense.

8

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.