我在沙箱中创建了 3 节点 Riak-CS 集群，创建了存储桶，上传了一些文件，并在节点之间复制了它们（我希望智能算法主要将文件放在物理不同节点上的分区中）。v_node=2，其他副本配置默认。
现在我尝试三个节点之一失败的情况。我刚刚在一个节点上停止了 riak 和 riak-cs 服务，并从其余节点获取：
s3cmd la s3://
ERROR: S3 error: 403 (InvalidAccessKeyId): The AWS Access Key Id you provided does not exist in our records.
假设一个节点发生故障，集群仍然可以运行，不是吗？此外，我尝试将失败的节点标记为Down确保集群状态已收敛，但这无济于事。
如果您将 n_val 设置为 2，则每个密钥只有 2 个副本。当您关闭一个节点时，您的大部分密钥（大约 50%）的一个副本将变得不可用。
查看get_user_with_pbc 函数的源代码，它首先尝试使用strong_get_user_with_pbc 函数
获取用户记录的强选项是{pr,all}, {r,all}, {notfound_ok,false}。PR=all 表示除非两个主 vnode 都可用，否则 get 请求将提前失败。如果您的其中一个副本不可用，则使用pr_val_unsatisfied.
如果 strong 选项失败，它会使用weak_get_user_with_pbc 函数使用弱选项重试{r, quorum}, {pr, one}, {notfound_ok,false}。Quorum 表示(n_val/2 + 1)，在这种情况下为 2。
所以这仍然需要一个主 vnode 可用，但我们还必须从 vnode 的仲裁中获得响应，在这种情况下，主 vnode 和后备节点都是。如果节点刚刚失败，第一个请求会发现fallback是空的，所以get请求从fallback vnode收到一个notfound，从primary收到用户记录。由于选项包括notfound_ok=false，即 1 个有效响应，而 quorum 为 2，因此请求失败。
后续查询可能会成功完成，因为回退将在第一次请求后通过读取修复填充。
I think you will find a great many things in Riak and Riak CS that don't seem to work quite right if you reduce n_val below 3. For instance, if you had kept n_val at 3, since a quorum of 3 vnodes is 2, you could still have gotten a valid response to the weak options if one of the primaries was offline and the fallback had not yet been populated.