I am trying to check my understanding after reading docs and some older questions, so my question is quite loaded:
- In a sharded cluster, each shard should (and as of 3.6 must?) reside on its own replica set. 2) Each replica set has its own master.
So suppose I wanted to deploy a Mongo cluster in 2 availability zones. So I set up a 6-node cluster with 2 shards on 2 separate replica sets, such that master for each set is in different datacenter. Slave nodes are distributed such that at least one slave from each replica set is in each datacenter, so:
- If I use "majority" read concern, would my mongod instances within same replica set have to communicate between my datacenters to verify that data is available on at least 2 instances? It sounds a little silly. Or would replication take longer, as each instance needs to confirm to other instances that its write is complete?
- If I use "available" read concern, can I guarantee that my application reads from closest instance? Can I make my application (say Mongo CLI) prefer a certain slave?
- If I wanted to guarantee each write happens to the closest master, I could use region as shard key.
Now suppose I wanted to do same exercise with 4 shards, 2 on each replica set.
- Is it possible to have more than one shard in one replica set? Ie each node would duplicate 2 sets of data?
- If so, and I wanted to still make sure each write happens to the closest master, I would use a compound shard key, with region and some other attribute. Can I somehow configure ranges of my shard key hash results to each master? Ie I'd like to achieve something like:
Shard 1 and 2 reside in US-West datacenter and shard 3 and 4 reside in US-East datacenter
Then for my compound shard key of (region, foo) I would want to guarantee that:
| region = US-West | region = US-East | | foo < 0 | foo >=0| foo < 0 | foo >=0| | shard 1 | shard 2| shard 3 | shard 4|