Question

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

但是我没遇到这个测试用例： Couchbase集群提供40.000操作，我在一台服务器上停止了couchbase服务=＆gt;一个节点向下。之后，整个集群的性能都会下降。它只能服务器低于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的memcached操作而重新连接#Wops = 0，＃iq = 0，topRop = Cmd：1不透明：2660829密钥：test_key_2681412 Cas：0 Exp：0标志：0数据长度：800，topWop = null，toWrite = 0，interest = 1}。这可能是由于身份验证失败。 OperationException：SERVER：内部错误 at net.spy.memcached.protocol.BaseOperationImpl.handleError（BaseOperationImpl.java:192） at net.spy.memcached.protocol.binary.OperationImpl.getStatusForErrorCode（OperationImpl.java:244） at net.spy.memcached.protocol.binary.OperationImpl.finishedPayload（OperationImpl.java:201） at net.spy.memcached.protocol.binary.OperationImpl.readPayloadFromBuffer（OperationImpl.java:196） at net.spy.memcached.protocol.binary.OperationImpl.readFromBuffer（OperationImpl.java:139） at net.spy.memcached.MemcachedConnection.readBufferAndLogMetrics（MemcachedConnection.java:825） at net.spy.memcached.MemcachedConnection.handleReads（MemcachedConnection.java:804） at 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 WARN 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，interest = 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 WARN 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，＃上的memcached操作而重新连接iq = 0，topRop = Cmd：1不透明：2660831密钥：test_key_2681412 Cas：0 Exp：0标志：0数据长度：800，topWop = null，toWrite = 0，interest = 1}。这可能是由于身份验证失败。 OperationException：SERVER：内部错误 at net.spy.memcached.protocol.BaseOperationImpl.handleError（BaseOperationImpl.java:192） at net.spy.memcached.protocol.binary.OperationImpl.getStatusForErrorCode（OperationImpl.java:244） at net.spy.memcached.protocol.binary.OperationImpl.finishedPayload（OperationImpl.java:201） at net.spy.memcached.protocol.binary.OperationImpl.readPayloadFromBuffer（OperationImpl.java:196） at net.spy.memcached.protocol.binary.OperationImpl.readFromBuffer（OperationImpl.java:139） at net.spy.memcached.MemcachedConnection.readBufferAndLogMetrics（MemcachedConnection.java:825） at net.spy.memcached.MemcachedConnection.handleReads（MemcachedConnection.java:804） at 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 WARN 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，interest = 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 WARN net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl：丢弃部分完成的操作：Cmd：0不透明：2660832密钥：test_key_2681412 取消

Answer 1

您应该会发现6/7（即85％）的操作应该继续以相同的性能运行。但是，针对现在被击落的节点所拥有的vbuckets的15％的操作将永远不会完成并且可能会超时，因此根据应用程序处理这些超时的方式，您可能会看到整体性能下降。

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

更新：OP的额外详情

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

Java SDK旨在利用异步操作实现最高性能，当群集性能下降且某些操作超时时尤其如此。我建议开始在单个线程中运行，但使用Futures来处理集合之后的get。例如：

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

这是Java Developer指南的Understanding and Using Asynchronous Operations部分的摘录。

基本上没有理由为什么在给定正确的代码的情况下，85％的节点的性能不应该接近最大85％的最短停机时间。

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

Couchbase Cluster：一个节点down =＆gt;整个集群下来？

1 个答案: