How indexer cluster nodes start up
This topic describes what happens when:
- the master node starts
- a peer node joins a new cluster
- a peer node joins an existing cluster
When the master node starts
When a master node comes online (either the first time or subsequently), it begins listening for cluster peers. Each online peer registers with the master, and the master adds it to the cluster. The master waits until the replication factor number of peers register, and then it starts performing its functions.
When you first deploy the cluster, you must enable the master before enabling the peer nodes, as described in "Indexer cluster deployment overview". The master blocks indexing on the peers until you enable and restart the full replication factor number of peers.
If you subsequently restart the master, it waits for a quiet period of 60 seconds, so that all peers have an opportunity to register with it. Once the quiet period ends and the replication factor number of peers register with it, the master can start performing its coordinating functions, such as rebalancing the primary bucket copies and telling peers where to stream copies of incoming data. Therefore, you must make sure that there are at least replication factor number of peers running when you restart the master.
After the 60 second quiet period is over, you can view the master dashboard for information on the status of the cluster.
For more information on what occurs when a master goes down and then restarts, see "What happens when the master node goes down".
When a peer joins a new cluster
When you initially deploy a cluster, you must first enable the master and then enable the peer nodes, as described in "Indexer cluster deployment overview". The master blocks indexing on the peers until you enable and restart the full replication factor number of peers.
Each peer registers with the master when it comes online, and the master automatically distributes the latest configuration bundle to it. The peer then validates the configuration bundle locally. The peer will only join the cluster if bundle validation succeeds.
The peer starts indexing data after the replication factor number of peers join the cluster.
When a peer joins an existing cluster
A peer can also come online at some later time, when the cluster is already up and running with a master and the replication factor number of peers. The peer registers with the master when it comes online, and the master distributes the latest configuration bundle to it. The peer validates the configuration bundle locally. The peer joins the cluster only if bundle validation succeeds.
Note: Adding a new peer to an existing cluster causes a rebalancing of primary bucket copies across the set of existing peer nodes, as described in "Rebalance the indexer cluster primary buckets". However, the new peer won't get any of those primary copies, because the master performs rebalancing only across the set of searchable copies, and a new peer has no searchable copies when it starts up. The peer can participate in future bucket replication, but the master does not automatically shift bucket copies or reassign primaries from existing peers to the new peer.
How indexer clusters handle report and data model acceleration summaries
What happens when a peer node goes down
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