There appears to be conflicting statements about this feature.
First we find a potential warning in the docs about using/deploying the kv store:
The KV store files reside on search
heads.
In a search head cluster, if any node
receives a write, the KV store
delegates the write to the KV store
captain. The KV store keeps the reads
local, however.
From the Splunk dictionary:
KV store captain noun
The KV store captain is the single
instance in the app key value store
that receives write operations. Other
KV store instances replicate data from
the captain.
In a search head cluster, when a node
receives a write request, the KV store
delegates the write to the KV store
captain, while the KV store keeps read
requests local.
However, this page says:
Search head clustering and KV store KV
store can reside on a search head
cluster. However, the search head
cluster does not coordinate
replication of KV store data or
otherwise involve itself in the
operation of the KV store. For
information on KV store, see "About KV
store" in the Admin Manual.
I'm looking to keep state between search heads in a cluster with durability. The docs seem contradictory. Not sure if it's old docs which have failed to update or what. Also, the concept of using a captain seems a bit mysterious. Is this the SH Captain? What happens to durability during the timeframe when a new captain is being re-elected?
Is it maybe better to just use redis instead? With this app?
Anybody out there using the kv store in a SH cluster who might be able to chime in?
... View more