Splunk® Enterprise

Managing Indexers and Clusters of Indexers

Download manual as PDF

Download topic as PDF

Indexer cluster states

An indexer cluster in good working order is both valid and complete:

  • A valid cluster has exactly one primary copy of each bucket. In the case of a multisite cluster, a valid cluster has one full set of primary copies for each site that supports search affinity.
  • A complete cluster has replication factor number of copies of each bucket and search factor number of searchable copies of each bucket. In the case of a multisite cluster, the number of bucket copies must also fulfill the site-specific requirements for the replication and search factors.

Note these points:

  • A valid cluster is able to handle search requests across the entire set of data. A valid multisite cluster also meets any inherent search affinity goals.
  • A complete cluster meets the designated requirements for failure tolerance.
  • A complete cluster is also a valid cluster, but a valid cluster is not necessarily complete.

In addition, to ensure robust data availability, a cluster must not only be complete, but its search factor must be set to at least 2. This guarantees that a search head can continue to search across the cluster without interruption, if a peer goes down.

When a peer node goes down, the master directs the cluster in activities designed to recover both its valid and complete states. In some cases, the cluster might be able to return to a valid state but not to a complete state. (For example, consider a cluster containing three peers, with a replication factor of 3. If one peer goes down, the cluster cannot recover its complete state as long as the peer remains down, but it should be able to recover its valid state.) See "What happens when a peer node goes down" for details on how the cluster recovers from a downed node.

PREVIOUS
Buckets and indexer clusters
  NEXT
How clustered indexing works

This documentation applies to the following versions of Splunk® Enterprise: 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.1.10, 6.1.11, 6.1.12, 6.1.13, 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.2.14, 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.2.0, 7.2.1


Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters