Allow to connect to Mongo without readConcern: majority

[ST-eugenekrivdyuk]

Hello there!

I stumbled upon inability to mirror our MongoDB database due to the following error:

[qrep] failed to pull records: failed to query for records: (ReadConcernMajorityNotEnabled) Majority read concern is not enabled.

While I agree that it's a good default, it basically makes it impossible to work for certain MongoDB installations. In our case it's PSA (Primary, Secondayr, Arbiter) where setting read concern to majority is not always good.

Hence I propose to add an option to allow disabling majority read concern.

I am very new to the project - so it's likely that I've missed some things - apologies if that's the case 🙏

[CLAassistant]

All committers have signed the CLA.

[ST-eugenekrivdyuk]

Oops, I should put the new one at the end.

[serprex]

option should also be made so false will maintain existing behavior in order to be backwards compatible

[jgao54]

@ST-eugenekrivdyuk Thanks for the PR. Understand the need to want to support a different readConcern.

The config proposed makes readConcern == Majority a binary decision, which means it will be a bit trickier to extend if another readConcern level is preferred.

Instead of using config, a simpler option I would recommend is passing in readConcern overrides via the URI as a param option, for example:

mongodb://<host>/?readConcernLevel=<your_level_of_choice> // `local` should be Mongo's default read concern if not supplied 

Then the only change you need to make in the code would be:

if connStr.ReadConcernLevel == "" {
    clientOptions.SetReadConcern(readconcern.Majority())
}

[ST-eugenekrivdyuk]

@jgao54 Great idea! Makes everything a lot simpler 👍 I've updated the PR.

[ST-eugenekrivdyuk]

Hmm, it's still not working on initial sync:

slot error: failed to start change stream for storing initial resume token: (InvalidOptions) Command aggregate does not support { readConcern: { level: "available" } } :: caused by :: Aggregation stage $changeStream cannot run with a readConcern other than 'majority'. Current readConcern: available

Even though in Mongo docs it says:

Read Concern "majority" Enablement.

Starting in MongoDB 4.2, [change streams](https://www.mongodb.com/docs/v4.4/changeStreams/) are available regardless of the ["majority"](https://www.mongodb.com/docs/v4.4/reference/read-concern-majority/#mongodb-readconcern-readconcern.-majority-) read concern support; that is, read concern majority support can be either enabled (default) or [disabled](https://www.mongodb.com/docs/v4.4/reference/read-concern-majority/#std-label-disable-read-concern-majority) to use change streams.

In MongoDB 4.0 and earlier, [change streams](https://www.mongodb.com/docs/v4.4/changeStreams/) are available only if ["majority"](https://www.mongodb.com/docs/v4.4/reference/read-concern-majority/#mongodb-readconcern-readconcern.-majority-) read concern support is enabled (default).

[jgao54]

Dug into this a bit, the mongodb doc regarding to Read Concern "majority" Enablement. is a bit confusing.

TL;DR: there are two separate things here:

1. $changestream only works if readConcern is majority. This likely has to do with the design of change stream api which replicates majority-committed data to guarantee correctness.

2. The original error you encountered:

(ReadConcernMajorityNotEnabled) Majority read concern is not enabled.

Is not referring to this client-side readConcernLevel option, but is referring to the server-side configuration replication.enableMajorityReadConcern.

According to Mongo docs:

Starting in MongoDB 5.0, enableMajorityReadConcern and --enableMajorityReadConcern cannot be changed and are always set to true due to storage engine improvements.

Given your original error, seems like you are on a version older than 5.0, which had enableMajorityReadConcern set to false (which sounds like an intentional decision). It's very confusing that MongoDB claims:

Starting in MongoDB 4.2, change streams are available regardless of the "majority" read concern support; that is, read concern majority support can be either enabled (default) or disabled to use change streams.

Which when I tested on my end, anything other than majority fails.

So i think in order for this connector to work for your PSA setup, this server-side config must be set to true.

[jgao54]

Just found the source code here that guards readConcern to majority .

Could you test out if the connector works for you without the line clientOptions.SetReadConcern(readconcern.Majority()). Curious if the error here is just because we explicitly set global read concern.

My current understanding is that you would still hit the error (ReadConcernMajorityNotEnabled) Majority read concern is not enabled. due to the server-side config setting and "internally upconvert the readConcern to majority" would only work if your server actually supports it.

[ST-eugenekrivdyuk]

@jgao54 I've tried it w/o setting clientOptions.SetReadConcern(readconcern.Majority()) and it didn't work and failed with the same error:

slot error: failed to start change stream for storing initial resume token: (InvalidOptions) Command aggregate does not
support { readConcern: { level: "available" } } :: caused by :: Aggregation stage $changeStream cannot run with a
readConcern other than 'majority'. Current readConcern: available

[jgao54]

Thanks for the update @ST-eugenekrivdyuk. Seems like this is a MongoDB changestream limitation unfortunately. Will require enabling the server side config replication.enableMajorityReadconcern in order to be supported.