首页 文章

Couchbase群集：一个节点向下=>整个群集向下？

提问于
浏览 次
3

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

但是我没遇到这个测试案例：Couchbase集群服务于40.000操作，我在一台服务器上停止了couchbase服务=>一个节点关闭 . 之后，整个集群的性能下降得很痛苦 . 它只能服务于1.000以下的服务器 . 当我单击故障转移时，整个群集恢复正常 .

我认为当节点向下时，只有部分请求受到影响 . 是对的吗？

实际上，当一个节点关闭时，它会对整个集群产生重大影响吗？

Updated:

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

This is log of a key when I Set/Get fail.

2014-04-16 16：22：20.405 INFO net.spy.memcached.MemcachedConnection：由于异常处理{QA sa = / 10.0.0.23：11234，＃Rops = 2，＃Wops = 0，＃上的memcached操作而重新连接iq = 0，topRop = Cmd：1不透明：2660829密钥：test_key_2681412 Cas：0 Exp：0标志：0数据长度：800，topWop = null，toWrite = 0，interest = 1} . 这可能是由于身份验证失败 . OperationException：SERVER：net.spy上net.spy.memcached.protocol.binary.OperationImpl.getStatusForErrorCode（OperationImpl.java:244）中net.spy.memcached.protocol.BaseOperationImpl.handleError（BaseOperationImpl.java:192）的内部错误.memcached.protocol.binary.OperationImpl.finishedPayload（OperationImpl.java:201）位于net.spy.memcached.protocol.binary.OperationImpl的net.spy.memcached.protocol.binary.OperationImpl.readPayloadFromBuffer（OperationImpl.java:196） .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 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上的memcached操作而重新连接，＃ 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} . 这可能是由于身份验证失败 . OperationException：SERVER：net.spy上net.spy.memcached.protocol.binary.OperationImpl.getStatusForErrorCode（OperationImpl.java:244）中net.spy.memcached.protocol.BaseOperationImpl.handleError（BaseOperationImpl.java:192）的内部错误.memcached.protocol.binary.OperationImpl.finishedPayload（OperationImpl.java:201）位于net.spy.memcached.protocol.binary.OperationImpl的net.spy.memcached.protocol.binary.OperationImpl.readPayloadFromBuffer（OperationImpl.java:196） .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-1616：22：20.407 WARN net.spy.memcached.MemcachedConnection：关闭，并重新打开{QA SA = / 10.0.0.24：11234，＃个Rops = 2，＃佬= 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经验：0标志：0数据长度：800 2014年4月16日16：22：20.408 WARN net.spy . memcached.protocol.binary.BinaryMemcachedNodeImpl：丢弃部分完成的操作：Cmd：0不透明：2660832密钥：test_key_2681412已取消

java couchbase

1 回答

  • 3

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

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

    更新：OP的额外细节

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

    Java SDK旨在利用异步操作实现最高性能，当群集性能下降且某些操作超时时尤其如此 . 我建议开始在单个线程中运行，但使用 Futures 来处理set之后的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％的最短停机时间 .

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

    回复于

相关问题