Couchbase 集群：一个节点宕机 => 整个集群宕机？答案

【问题标题】：Couchbase Cluster: one node down => entire cluster down?Couchbase 集群：一个节点宕机 => 整个集群宕机？
【发布时间】：2014-04-16 10:05:01
【问题描述】：

我正在测试 Couchbase Server 2.5`。我有一个包含 7 个节点和 3 个副本的集群。在正常情况下，系统工作正常。

但是我在这个测试用例上失败了： Couchbase 集群提供 40.000 个操作，我在一台服务器上停止了 couchbase 服务 => 一个节点停机。在那之后，整个集群的性能就会痛苦地下降。它只能服务于 1.000 次以下的操作。当我点击故障转移时，整个集群恢复健康。

我认为当一个节点关闭时，只会影响部分请求。对吗？

而实际上，当一个节点宕机时，会对整个集群造成很大的影响？

更新：

我写了一个工具来负载测试使用 spymemcached。该工具创建多线程以连接到 Couchbase 集群。每个线程设置一个密钥并立即获取该密钥进行检查，如果成功则继续设置/获取另一个密钥。如果失败，则重试 Set/Get，如果失败 5 次则通过此密钥。

这是我设置/获取失败时的密钥日志。

2014-04-16 16:22:20.405 INFO net.spy.memcached.MemcachedConnection：由于在 {QA sa=/10.0.0.23:11234,#Rops=2, #Wops=0, #iq=0, topRop=Cmd: 1 Opaque: 2660829 Key: test_key_2681412 Cas: 0 Exp: 0 Flags: 0 Data Length: 800, topWop=null, toWrite=0, Interest=1}。这可能是由于身份验证失败。 OperationException：服务器：内部错误在 net.spy.memcached.protocol.BaseOperationImpl.handleError(BaseOperationImpl.java:192) 在 net.spy.memcached.protocol.binary.OperationImpl.getStatusForErrorCode(OperationImpl.java:244) 在 net.spy.memcached.protocol.binary.OperationImpl.finishedPayload(OperationImpl.java:201) 在 net.spy.memcached.protocol.binary.OperationImpl.readPayloadFromBuffer(OperationImpl.java:196) 在 net.spy.memcached.protocol.binary.OperationImpl.readFromBuffer(OperationImpl.java:139) 在 net.spy.memcached.MemcachedConnection.readBufferAndLogMetrics(MemcachedConnection.java:825) 在 net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:804) 在 net.spy.memcached.MemcachedConnection.handleReadsAndWrites(MemcachedConnection.java:684) 在 net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:647) 在 net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:418) 在 net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:1400) 2014-04-16 16:22:20.405 警告 net.spy.memcached.MemcachedConnection：关闭并重新打开 {QA sa=/10.0.0.23:11234，#Rops=2，#Wops=0，#iq=0，topRop =Cmd：1 不透明：2660829 密钥：test_key_2681412 Cas：0 Exp：0 标志：0 数据长度：800，topWop=null，toWrite=0，interested=1}，尝试 0。 2014-04-16 16:22:20.406 WARN net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl：丢弃部分完成的操作：Cmd：1 不透明：2660829 密钥：test_key_2681412 Cas：0 Exp：0 标志：0 数据长度：800 2014-04-16 16:22:20.406 警告 net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl：丢弃部分完成的操作：Cmd：0 不透明：2660830 密钥：test_key_2681412 取消 2014-04-16 16:22:20.407 错误 net.spy.memcached.protocol.binary.StoreOperationImpl：错误：内部错误 2014-04-16 16:22:20.407 信息 net.spy.memcached.MemcachedConnection：由于异常处理 {QA sa=/10.0.0.24:11234、#Rops=2、#Wops=0、# 上的 memcached 操作而重新连接iq=0, topRop=Cmd: 1 Opaque: 2660831 Key: test_key_2681412 Cas: 0 Exp: 0 Flags: 0 Data Length: 800, topWop=null, toWrite=0, Interest=1}。这可能是由于身份验证失败。 OperationException：服务器：内部错误在 net.spy.memcached.protocol.BaseOperationImpl.handleError(BaseOperationImpl.java:192) 在 net.spy.memcached.protocol.binary.OperationImpl.getStatusForErrorCode(OperationImpl.java:244) 在 net.spy.memcached.protocol.binary.OperationImpl.finishedPayload(OperationImpl.java:201) 在 net.spy.memcached.protocol.binary.OperationImpl.readPayloadFromBuffer(OperationImpl.java:196) 在 net.spy.memcached.protocol.binary.OperationImpl.readFromBuffer(OperationImpl.java:139) 在 net.spy.memcached.MemcachedConnection.readBufferAndLogMetrics(MemcachedConnection.java:825) 在 net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:804) 在 net.spy.memcached.MemcachedConnection.handleReadsAndWrites(MemcachedConnection.java:684) 在 net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:647) 在 net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:418) 在 net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:1400) 2014-04-16 16:22:20.407 警告 net.spy.memcached.MemcachedConnection：关闭并重新打开 {QA sa=/10.0.0.24:11234，#Rops=2，#Wops=0，#iq=0，topRop =Cmd：1 不透明：2660831 密钥：test_key_2681412 Cas：0 Exp：0 标志：0 数据长度：800，topWop=null，toWrite=0，interested=1}，尝试 0。 2014-04-16 16:22:20.408 WARN net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl：丢弃部分完成的操作：Cmd：1 不透明：2660831 密钥：test_key_2681412 Cas：0 Exp：0 标志：0 数据长度：800 2014-04-16 16:22:20.408 警告 net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl：丢弃部分完成的操作：Cmd：0 不透明：2660832 密钥：test_key_2681412 取消

【问题讨论】：

顺便说一句，7 节点集群上的 3 个副本可能是多余的，并且需要相对大量的资源来处理特定的工作负载。在 10 个节点以下，单个副本通常就足够了。

标签： java couchbase

【解决方案1】：

您应该会发现 6/7（即 85%）的操作应该继续以相同的性能运行。然而，15% 的针对现在停机节点拥有的 vbuckets 的操作将永远不会完成并且可能超时，因此根据您的应用程序如何处理这些超时，您可能会看到整体性能下降更大。

您如何对性能进行基准测试/衡量？

更新：OP 的额外细节

我写了一个工具来负载测试使用 spymemcached。该工具创建多线程以连接到 Couchbase 集群。每个线程设置一个密钥并立即获取此密钥进行检查，如果成功则继续设置/获取另一个密钥。如果失败，它会重试 Set/Get，如果失败 5 次则通过此密钥。

Java SDK 旨在利用异步操作来获得最佳性能，尤其是当集群降级并且某些操作将超时时尤其如此。我建议开始在单线程中运行，但使用Futures 处理设置后的获取。例如：

client.set("key", document).addListener(new OperationCompletionListener() {
    @Override
    public void onComplete(OperationFuture<?> future) throws Exception {
        System.out.println("I'm done!");    
    }
});

这是Java 开发人员指南Understanding and Using Asynchronous Operations 部分的摘录。

如果使用正确的代码，您在 85% 的节点上运行时的性能在短停机时间内不应接近最大值的 85%，这基本上没有理由。

请注意，如果一个节点长时间停机，那么其他节点上的复制队列将开始备份，这可能会影响性能，因此建议使用自动故障转移/重新平衡来恢复 100% 活动存储桶并重新创建副本，以确保任何进一步的节点故障都不会导致数据丢失。

【讨论】：