4.1. 理论

在我们继续之前,我们需要一些理论。

如你所见 etc/default.ini 有一个部分叫做 [cluster]

[cluster]
q=2
n=3
  • q -碎片的数量。

  • n -每份文件的份数。复制品。

创建数据库时,您可以通过请求发送自己的值,从而覆盖中的默认值 default.ini .

在集群操作中,在CouchDB返回a之前必须达到仲裁 200 为了一个机会,或者 201 对于写操作。法定人数是指“相关副本”数量的一加二“相关副本”对于读写操作的定义略有不同。

对于读操作,相关副本数是当前可访问的保存请求数据的碎片数,这意味着在发生故障或网络分区的情况下,相关副本的数量可能低于群集中的副本数。可使用设置已读副本的数量 r 参数。

对于写入操作,相关副本的数量始终为 n ,群集中的副本数。对于写操作,可以使用w参数设置副本数。如果可用节点数少于此数量,则 202 将被退回。

我们现在将重点放在碎片和副本上。

碎片是数据库的一部分。它可以复制多次。一个碎片的拷贝越多,就越能扩展。如果您有4个副本,这意味着该特定碎片的所有4个副本最多将驻留在4个节点上。对于一个副本,您只能有一个节点,就像couchdb1.x一样。自3.0.0以来,CouchDB的默认值是 q=2n=3 ,这意味着每个数据库(和辅助索引)被分成2个碎片,每个碎片有3个副本,总共有6个碎片副本文件。对于仅承载具有这些默认值的单个数据库的CouchDB集群,最多可以使用6个节点来水平扩展。

副本增加了抗故障能力,因为有些节点可以离线,而不会发生任何故障。

  • n=1 所有节点都必须启动。

  • n=2 任何一个节点都可以关闭。

  • n=3 任何2个节点都可以关闭。

电脑坏了,系统管理员时不时愤怒地拔掉网线,所以 n<2 要求停工。价值太高的 n 增加了服务器和复杂性,但没有任何实际好处。最佳位置在 n=3 .

假设我们有一个包含3个副本和4个碎片的数据库。这将给我们最多12个节点:4*3=12。

我们可以丢失任何2个节点,但仍然可以读写所有文档。

如果丢失更多节点会怎么样?这要看我们有多幸运。只要每个碎片至少有一个拷贝在网上,我们就可以读写所有的文档。

所以,如果我们很幸运的话,我们最多可以失去8个节点。