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 产生的过程。

有具体案例可以私信我。