How/where do you set the # of replicas/copies of data in a sharded replica? I want high write performance and less redundancy.
I don’t believe the documentation is clear here as I couldn’t figure this out for weeks (doing other things along the way too of course.)
The answer is to create additional shards over additional replicasets. Each replicaset can then be assigned as a shard. So the # of copies you’re holding is defined in the replicaset. There is no automated “hey, we lost this shard and it held the second copy of record 10. Now there’s only one record 10, so copy it to another shard.” So the # of shards represent the number of possible buckets the record can go into. Additionally, the # of copies of that shard is handled by the underlying replicaset configuration of the shard.
Hi Matthew,
Thank you for the feedback, I will pass that onto the documentation team.
Documents in a sharded collection are distributed based on a user-defined shard key index where each document is associated with a single shard. You are correct that the replication factor is determined by the replication set configuration (there is no separate configuration for this).
The minimum replica set size is a single member (typically only for development or testing), with 3 or more replica set members for a production deployment.
Regards,
Stennie