java - Couchbase群集:一个节点关闭=>整个群集关闭？

Question

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

但是这个测试用例失败了:
Couchbase集群可提供40.000个操作，并且我在一台服务器上停止了长沙发服务=>向下一个节点。此后，整个集群的性能将严重下降。它只能在1.000 ops以下的服务器上运行。当我单击故障转移时，整个群集恢复正常。

我认为当一个节点关闭时，只有部分请求受到影响。那正确吗？

实际上，当一个节点出现故障时，会对整个集群产生很大影响吗？

更新:

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

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

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，有兴趣= 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，感兴趣= 1}，尝试0。
2014-04-16 16:22:20.406警告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 INFO 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，有兴趣= 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，感兴趣= 1}，尝试0。
2014-04-16 16:22:20.408警告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
取消

Answer 1

您应该发现6/7(即85％)的操作应继续以相同的性能进行。但是，针对现在已关闭的节点所拥有的vbuckets的15％的操作将永远不会完成，并且可能会超时，因此，根据您的应用程序如何处理这些超时，您可能会看到总体上性能下降得更多。

您如何衡量/衡量性能？

更新:OP的其他详细信息

我写了一个工具来使用spymemcached进行负载测试。该工具创建多线程以连接到Couchbase集群。每个线程设置一个键并获取该键以立即检查，如果成功则继续设置/获取另一个键。如果失败，则重试设置/获取，如果失败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％的 Activity 存储桶并重新启动。 -创建副本以确保任何进一步的节点故障不会导致数据丢失。