Couchbase群集：一個節點向下=>整個群集向下？

Question

我正在測試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，＃上的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） net.spy.memcached.memcached.MemcachedConnection.handleReads（MemcachedConnection.java:804）net.spy.memcached的net.spy.memcached.MemcachedConnection.readBufferAndLogMetrics（MemcachedConnection.java:825）中的.readFromBuffer（OperationImpl.java:139）。 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） net.spy.memcached.memcached.MemcachedConnection.handleReads（MemcachedConnection.java:804）net.spy.memcached的net.spy.memcached.MemcachedConnection.readBufferAndLogMetrics（MemcachedConnection.java:825）中的.readFromBuffer（OperationImpl.java:139）。 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來處理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％的最短停機時間。

請注意，如果某個節點長時間處於關閉狀態，則其他節點上的復制隊列將開始備份，這會影響性能，因此建議使用自動故障轉移/重新平衡來恢復100％活動存儲桶並重新啟動 - 創建副本以確保任何進一步的節點故障不會導致數據丟失。