couchDB从2.0版本之后可以支持单独部署和集群部署， 下面详细介绍CouchDB集群背后的理论，关于节点、数据库和切分管理的具体操作说明。
在我们实践之前，需要掌握一些理论。
如etc/default.ini中所示，有一个名为“cluster”的部分
[cluster]
q=8
n=3- q 分片数量
- n 每个分片的副本数
以上是默认的配置， 在创建数据库时，可以使用request发送自己的值，从而覆盖default.ini中的默认值。
在集群操作中，在CouchDB返回fetch操作的200状态或write操作的201状态之前，必须达成法定数量。法定数量的定义是“相关副本”数量的一半加1。对于读写操作，“相关副本”的定义略有不同。
对于读取操作，相关副本的数量是当前可访问的请求数据的分片的数量，这意味着在故障或网络分区的情况下，相关副本的数量可能低于集群中的副本数量。可以使用r参数设置读取副本的数量。
对于写操作，相关副本的数量总是n，即集群中的副本总数量。对于写操作，可以使用w参数设置副本的数量。如果可用节点的数量少于此数量，则返回202。
分片和副本
分片是数据库的一部分。它可以被复制多次。分片的副本越多，就可以扩展得越多。如果您有4个副本，这意味着这个分片的4个副本将在最多4个节点上共存。对于一个副本，您只能有一个节点，就像CouchDB 1.x一样。任何节点都不能拥有每个碎片副本的多个副本。CouchDB的默认值(因为2.0.0)是q=8和n=3，这意味着每个数据库(和辅助索引)被分成8个分片，每个分片有3个副本，总共有24个分片副本文件。单数据库多分片多节点的集群模式，对于只承载具有这些默认值的单个数据库的CouchDB集群，最多可以使用24个节点进行水平伸缩。
副本增加了故障抗性，因为一些节点可以离线而不会崩溃。
- n=1 所有节点必须正常运行
- n=2 允许1个节点宕机
- n=3 允许2个节点宕机
- 等等
如上描述n<2就意味着停机。n值过高会增加服务器和复杂性，而不会带来任何实际好处。官方建议最佳点在n=3。
假设我们有一个包含3个副本和4个分片的数据库。这样就得到最多12个节点。每个分片有3个副本。 我们可以丢失任何2个节点，但仍然可以读写所有文档。
如果我们失去更多的节点会发生什么?这取决于我们有多幸运。只要每个分片在网上至少有一个副本，我们就可以读写所有文档。
如果幸运的话，最多可以损失8个结点。