I am trying to find an authoritative answer to the following question: Is a single member replica set a supported deployment setup?
While this question may seems weird or silly, my specific use case follows:
A team wants to upgrade from Mongo 2 to Mongo 4 and they foresee that transactions might be useful to them. They currently run a single mongod instance. MongoDB documentation leads them to believe that to use transactions they must activate replica sets and deploy at least 3 mongod instances. Interesting documentation bits are:
https://docs.mongodb.com/manual/core/transactions/#transactions-and-replica-sets
Multi-document transactions are available for replica sets only. Transactions for sharded clusters are scheduled for MongoDB 4.2 [1].
https://docs.mongodb.com/manual/core/replica-set-members/
The minimum recommended configuration for a replica set is a three member replica set with three data-bearing members: one primary and two secondary members. You may alternatively deploy a three member replica set with two data-bearing members: a primary, a secondary, and an arbiter, but replica sets with at least three data-bearing members offer better redundancy.
My point of view is that:
- Replica sets aim to increase redundancy and availability through a typical primary - secondaries design
- Replica set documentation focuses on what make sense for its initial orginal purpose. It documents traditional and sane deployment setups fo HA (>= 3 and odd number of voter, separate machines, how to deal with multiple DC etc.)
- Team is not interested in HA but must switch to replica sets in order to use TX (alternative path being to forgo TX and deploy a single mongod)
- According to replica set documentation and my distributed systems background, I don't see why a single member replica set would be an issue if you don't care about HA. With a single member a primary can be elected, replication is NOOP and default and majority write concern are just
w: 1.
Am I right?
