Question 1. Is my understanding of the concepts correct?
local- returns data from any single instance, and thus may return outdated state, or state that will be rolled back.
majority- returns data from single instance that has been majority acknowledged, and thus may return outdated state, but never state that will be rolled back.
linearizable- returns data from primary that has been majority acknowledged and waits for any concurrent operations on the same document to complete, and thus will never return outdated state or state that will be rolled back. When applied to an operation that may return multiple documents, only provides same guarantees as
snapshot- provides same guarantees as
majority, but eliminates anomalies that may arise from sharding (?). Not sure I really understand this one.
primary- reads from primary, and thus will never return outdated state, but may return state that will be rolled back if primary is reelected before the write propagates to secondaries.
- any non-
primaryoption - may read data from a secondary, and thus may return outdated state or state that may be rolled back, unless
ReadConcernof choice implies stronger guarantees.
Question 2. How do the concepts interact?
So for instance if I use
linearizable read concern and a non-
primary read preference, will my request be rerouted to primary, ignoring the preference, to uphold guarantees of linearizability? If my read concern is
local but read preference is
primary, does it mean that I will never get outdated state, but may get state that will be rolled back? Is read concern
majority combined with read preference
primary essentially the same as read concern
Question 3. What does it mean in practice for an app developer?
As an app developer, is it enough to use a non-
primary read preference in all operations, and use appropriate read concerns depending on the situation? Are there any situations when I should use
primary read preference? What are some examples of combinations that make sense in certain cases?