Splunk Bucket 背後的秘密

最近剛好一個運維case 來看splunk 移除peer node 數據不會丟失：

1: 由於性能問題，要移除index node, 通常我們說這是一個peer:

可以參考我的blog:Splunk 移除index 節點 + 注意點_shenghuiping2001的博客-CSDN博客

先在CM. server 上執行remove 的命令後：

 發現node peer : 15 -> 14, 少了一個，但是searchable 的變少了：

2: 但是不用擔心：看上面的replicated Data copies: 2 個，還是綠色的：

檢查一下上面bucket status 的： 點一下 Butcket Status:

可以看到 Fixup Tasks : pending 的數量在不斷减少，稍微等一會，再看上面的searchable 的:

3: 下面再看一下process 的進程：

可以看到pendingd 的數量在不斷减少，而且新的bucket 是在不同的兩個新的peer 上面的copy.

4: 所以，當有兩個node 同時移除的時候，而且這兩個noe 都是含有同一個bucket 的話那這個bucket 就沒有地方copy.

5: 最後完全OK：

6: 關於上圖的: indexer with exces Buckets: (下圖可以解釋)

RF: 2
		peer3
peer1	peer2
bkt1	bkt1(excess)
	bkt2	bkt2(excess)
bkt2	bkt1	bkt1(excess)

Case1:

Peer1: bkt1 / bkt2

Peer2: bkt2

Peer3: bkt1

Case2:   when peer2 offline / maintenance:

Peer1: bkt1 / bkt2

Peer2: ---

Peer3: bkt1 / bkt2 (copy from peer2).

Case3: when peer2 recovery:

Peer1: bkt1 / bkt2

Peer2: bkt2

Peer3: bkt1 / bkt2

從上面的case 3 的時候，bkt2 就顯示excess. 如果出現如下case4 的時候：

Case4: when peer3 offline / maintenance:

Peer1: bkt1 / bkt2

Peer2: bkt2 / ( bkt1 / bkt2) excess

Peer3: ---

上面的解釋說明excess buket 產生的過程。

有具體案例可以私信我。