0

I currently run a PSA (Primary, Secondary, Arbiter) deployment and thous only have two databearing nodes. In case of a databearing node going down, read concern majority prevented the change stream to be read out of.
In MongoDB 4.2 it is now possible to disable the read concern majority for the replicaset and still use the change stream (See https://docs.mongodb.com/manual/release-notes/4.2/#change-stream).

I disabled read concern majority in my deployment and the change stream works as expected.
If I shut down the secondary node the change stream can't be read out of again.

Is this the expected behaviour? I would have assumed that with 4.2 a majority is not necessary anymore to read the change stream.
If that is the case, is there any way to read the change stream in a PSA deployment with only a minority of data bearing nodes?

0

This is not the expected behavior. Since you have the majority members of the replica set online, it should work

Just wanted to confirm:

  1. Are you using version 4.2?
  2. After installing/upgrading the replica set, have you set the feature compatibility version to 4.2 by executing the below command?

    db.adminCommand( { setFeatureCompatibilityVersion: 4.2 } )

Thank you!

  • Using db.adminCommand ({getParameter: 1, featureCompatibilityVersion: 1}) I confirmed that I am actually running 4.2 as a compatibilityVersion. Upon connecting to my node it also tells me that the Server Version is 4.2.0. I also checked whether the read concern is truly disabled and according to MongoDB documentary it is. "storageEngine" : { "name" : "wiredTiger", "supportsCommittedReads" : false, – Franz Huebner Aug 19 at 6:06
  • Is there any error being logged at this time with regards to change stream? Also, does the same happen when Primary goes down? – Anban Aug 19 at 6:10
  • When I shut down my secondary this is getting written to my logfile, the same line is written to my secondary when Shutdown my primary: 2019-08-19T08:37:23.690+0200 W COMMAND [conn1074] Unable to gather storage statistics for a slow operation due to lock aquire timeout – Franz Huebner Aug 19 at 6:43
  • Please check if there is any long running query taking global lock which is impacting. Also refer JIRA jira.mongodb.org/browse/SERVER-41327 – Anban Aug 19 at 7:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.