Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-12370

Incorrect/unclear definition of majority write concern

      Description

      Hello,

      Under https://docs.mongodb.com/manual/reference/write-concern/index.html, we have the following text regarding write concern of majority:

      Requests acknowledgment that write operations have propagated to the majority of data-bearing voting members

      In my opinion (and particularly as an ESL speaker), this could be easily interpreted as "out of all data-bearing, voting members, the majority of them should acknowledge the write". In reality, write concern majority refers to something like "out of all voting members (data-bearing or not), a majority of them should acknowledge the write. But it so happens that only data-bearing members can acknowledge writes". This is more relevant in situations where arbiters are involved. For example, in a PSA replica set, with only one data-bearing node going down, majority can't be met (out of 3 members, only one can acknowledge the write because the other one is down and the arbiter is not data-bearing, so it can't acknowledge the write).

      More importantly, this distinction can be crucial for environments such as a PSSAA replica set (even though we don't recommend that, users can and do still configure replica sets like that). If we went by the alternative interpretation of "out of all data-bearing, voting members, the majority of them should acknowledge the write", then one data-bearing node going down should not affect majority because out of 3 data-bearing members, 2 can still ack writes. However, in practice, this is not correct: if one data-bearing node goes down, only the other two can acknowledge writes and with only 2 out of a total of 5 voting members being capable of acknowledging writes, a majority write concern can't be satisfied.

      I hope this makes clear the importance of the distinction that I think should be made in this documentation page. However, please let me know if you need any further clarification on this and I will be happy to elaborate.

      Scope of changes

      Impact to Other Docs

      MVP (Work and Date)

      Resources (Scope or Design Docs, Invision, etc.)

            Assignee:
            kay.kim@mongodb.com Kay Kim (Inactive)
            Reporter:
            francisco.alanis@mongodb.com Francisco Alanis
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved:
              5 years, 5 weeks ago