mongodb write concern: all replica members dynamically?

Question

Is it possible to set the WriteConcern to something like all which means the insert/update will only return when all "currently functional" (at time of the operation) replica members acknowledges the operation?

As

1. the 'majority' setting leave some members unaccounted for.
2. if we specify a numeric value, the insert/update may suspend indefinitely if we set the WriteConcern as "total number of members" and any replica members go down for any reason.
3. if we use tag set, as outlined in official docs, we still need to supply a numeric value to each tag and if we specify the numeric value as the total members count and any member goes down, the result would be same as 2nd point.

What we have in mind is if there is a setting forWriteConcern which is, dynamically, the total number of replica members at the time of insert/update.

Thanks in advance!

Answer 1

Is it possible to set the WriteConcern to something like all which means the insert/update will only return when all "currently functional" (at time of the operation) replica members acknowledges the operation?

There is a logical contradiction in suggesting your use case requires strong consistency except when that isn't possible. There are expected scenarios such as replication lag, maintenance, or failure (and subsequent recovery) where one or more of your replica set secondaries may be online but lagging behind the current primary.

If your use case requires strong consistency then you should always read from the primary instead of secondaries, and use a write concern of majority / replica_safe to ensure data has replicated sufficiently for high availability in the event of failover.

The default read preference is to direct reads to the primary for consistency. Secondaries in MongoDB replica sets are generally intended to support high availability rather than read scaling (with a few exceptions such as distribution across multiple data centres). For a lengthier explanation see: Can I use more replica nodes to scale?.

the 'majority' setting leave some members unaccounted for.

The majority write concern matches up with the majority required to elect a primary in the event of a replica set election. The replica set election mechanics include ensuring that a new primary is up-to-date with the most recent operation available in the replica set (of the nodes that are participating in the election).

if we specify a numeric value, the insert/update may suspend indefinitely if we set the WriteConcern as "total number of members" and any replica members go down for any reason.

That is the expected default behaviour, however there is a wtimeout write concern option which sets a time limit (in milliseconds) so a write will not block indefinitely waiting for an acknowledgement to be satisfied.

The caveats on using timeouts are very important, and provide even less certainty of outcome:

wtimeout causes write operations to return with an error after the specified limit, even if the required write concern will eventually succeed. When these write operations return, MongoDB does not undo successful data modifications performed before the write concern exceeded the wtimeout time limit.

The write concern timeout is not directly related to the current health of the replica set members (i.e. whether they online or offline and might be able to acknowledge a write concern) or the eventual outcome -- it's just a hard stop on how long your application will wait for a response before returning.

if we use tag set, as outlined in official docs, we still need to supply a numeric value to each tag and if we specify the numeric value as the total members count and any member goes down, the result would be same as 2nd point.

Correct.