Before we move on, we need some theory.
As you see in etc/default.ini there is a section called [cluster]
[cluster]
q=8
r=2
w=2
n=3
When creating a database or doing a read or write you can send your own values with request and thereby overriding the defaults in default.ini.
We will focus on the shards and replicas for now.
A shard is a part of a database. The more shards, the more you can scale out. If you have 4 shards, that means that you can have at most 4 nodes. With one shard you can have only one node, just the way CouchDB 1.x is.
Replicas adds fail resistance, as some nodes can be offline without everything comes crashing down.
Computers goes down and sysadmins pull out network cables in a furious rage from time to time, so using n<2 is asking for downtime. Having a to high value of n is adding servers and complexity without any real benefit. The sweetspot is at n=3.
Say that we have a database with 3 replicas and 4 shards. That would give us a maximum of 12 nodes. 4*3=12 Every shard have 3 copies.
We can lose any 2 nodes and still read and write all documents.
What happens if we lose more nodes? It depends on how lucky we are. As long as there is at least one copy of every shard online, we can read and write all documents.
So, if we are very lucky then we can lose 8 nodes at maximum.