Impact of enableMajorityReadConcern

[Eric Sedor]

Hello,

I have some questions about the enableMajorityReadConcern command option that supports Read Concern (https://docs.mongodb.com/manual/reference/read-concern/).

The documentation does not suggest that enabling this has a negative impact, but that this is an option seems to imply there are trade-offs. Other than exposing clusters to enableMajorityReadConcern-specific bugs like https://jira.mongodb.org/browse/SERVER-26592, what is the impact of enabling this option, especially with respect to performance? Can anyone provide specific insight into how the cluster behaves differently?

Additionally, is this ticket to enable the option by default (https://jira.mongodb.org/browse/SERVER-22629) something that's going to be considered soon?

Gratefully,

Eric

[Stephen Steneker]

On Tuesday, 18 October 2016 06:18:46 UTC+11, Eric Sedor wrote:

I have some questions about the enableMajorityReadConcern command option that supports Read Concern (https://docs.mongodb.com/manual/reference/read-concern/).

The documentation does not suggest that enabling this has a negative impact, but that this is an option seems to imply there are trade-offs. Other than exposing clusters to enableMajorityReadConcern-specific bugs like https://jira.mongodb.org/browse/SERVER-26592, what is the impact of enabling this option, especially with respect to performance? Can anyone provide specific insight into how the cluster behaves differently?

Hi Eric,

The enableMajorityReadConcern option is only supported by WiredTiger and MongoDB 3.2+ with the v1 replication protocol configured.

When this option is enabled the WiredTiger storage engine uses snapshots to keep available all versions of data between the oldest accessible and the most recent. Snapshots will first use space in the cache and eventually overflow to the WiredTigerLAS.wt file. Old snapshots will be freed once a majority of replica members have advanced past that point.

SERVER-26592 is the result of a configuration error where majority read concern was enabled on a mixed-version replica set (3.0 and 3.2): MongoDB 3.0 does not support majority write concern so the old snapshots would never be freed.

 

Additionally, is this ticket to enable the option by default (https://jira.mongodb.org/browse/SERVER-22629) something that's going to be considered soon?

The current status of this issue is "planned but not scheduled", so it's certainly on a farther horizon than MongoDB 3.4. You can watch the issue for updates.

Regards,

Stephen

[Eric Sedor]

Thanks kindly, Stephen,

This is a big help in reasoning about the memory/disk/CPU that might be used with this feature enabled. We are trying to determine if we should only enable it when we plan to use it or whether it is reasonable to enable by default with no real negative impact.

Would it be safe to say that, in its current form, enabling the feature if you don’t plan on using it introduces an un-needed performance / resource drag? Or would you say the impact of enabling the feature is already minimal?

Is part of the work to enable it by default in a later version related to optimizing how the feature uses resources (such as WT Cache or space in the WiredTigerLAS file?

Gratefully,

Eric

[Stephen Steneker]

On Tuesday, 25 October 2016 04:58:30 UTC+11, Eric Sedor wrote:

This is a big help in reasoning about the memory/disk/CPU that might be used with this feature enabled. We are trying to determine if we should only enable it when we plan to use it or whether it is reasonable to enable by default with no real negative impact.

Would it be safe to say that, in its current form, enabling the feature if you don’t plan on using it introduces an un-needed performance / resource drag? Or would you say the impact of enabling the feature is already minimal?

Hi Eric,

For a production environment I would generally only enable extra features if required so that your configuration reflects the most commonly used & tested defaults.

For majority read concern there is some overhead of cache maintenance for snapshots, so this definitely falls in the category of unnecessary resource utilization if you don't have a use case. The impact is going to be specific to your workload and environment, so the best way to measure would be for you to test with & without this feature enabled in comparable situations.

I would also consider other potentially problematic scenarios based on your replica set configuration. For example, arbiters and delayed secondaries maintain availability for a replica set but may affect how soon old read concern snapshots can be freed. A pathological example is the server bug you pointed out where read concern was accidentally enabled with a mixed 3.0/3.2 replica set: a majority of servers in this deployment didn't support majority read concern so the old snapshots were never freed. Secondary lag is also a factor in how long snapshots need to be kept available.

A specific use case where majority read concern does make sense (and is enabled by default) is for the Config Server Replica Set (CSRS) servers in MongoDB 3.2. However, it is worth noting that CSRS servers have specific configuration restrictions (no arbiters, no delayed members, ...) to avoid obvious problematic scenarios.

Is part of the work to enable it by default in a later version related to optimizing how the feature uses resources (such as WT Cache or space in the WiredTigerLAS file?

It's not certain that this option should be enabled by default, and as I mentioned the current "planned but not scheduled" horizon is somewhere past MongoDB 3.4 in terms of planning consideration. The specific changes would have to be assessed given the codebase and related features scheduled as part of the same planning round.

I think the backlog server issue you noted needs some clarity of title & description as it is currently very terse. The intent of the issue looks to be more about running the full test suite to try to identify the impact of majority read concern rather than a suggestion this option should generally default to true.

Regards,

Stephen 

[Eric Sedor]

Thank you kindly for the thorough response, Stephen. Be well!