Index replication offers benefits such as data availability, data fidelity, data recovery, disaster recovery, and search affinity. It ensures that an indexer is always available to handle data, and the indexed data is searchable. It also guarantees data consistency and fault tolerance.
An indexer cluster consists of:
A single manager node to manage the cluster.
Several to many peer nodes to index data and maintain multiple copies, providing redundancy and data availability.
One or more search heads to coordinate searches across the set of peer nodes and provide a unified search experience
Here is a diagram of a basic, single-site indexer cluster, containing three peer nodes and supporting a replication factor of 3:
[default]
# maxHotSpanSecs sets the maximum age of data in the "hot" bucket to 90 days.
maxHotSpanSecs = 7776000
# frozenTimePeriodInSecs sets the maximum age of data in the "cold" bucket to 275 days.
frozenTimePeriodInSecs = 23760000
################################################################################
# index definitions
################################################################################
[main]
repFactor = 0
[history]
repFactor = 0
[summary]
repFactor = auto
[_internal]
repFactor = auto
[_audit]
repFactor = auto
[_thefishbucket]
repFactor = auto
[_telemetry]
homePath = $SPLUNK_DB/_telemetry/db
coldPath = $SPLUNK_DB/_telemetry/colddb
thawedPath = $SPLUNK_DB/_telemetry/thaweddb
repFactor = auto
[splunklogger]
repFactor = auto
[wineventlog]
homePath = $SPLUNK_DB/wineventlog/db
coldPath = $SPLUNK_DB/wineventlog/colddb
thawedPath = $SPLUNK_DB/wineventlog/thaweddb
maxTotalDataSizeMB = 1048576
repFactor = auto
[linux]
homePath = $SPLUNK_DB/linux/db
coldPath = $SPLUNK_DB/linux/colddb
thawedPath = $SPLUNK_DB/linux/thaweddb
maxTotalDataSizeMB = 512000
repFactor = auto
Enabling Phased Bundle Downloads
▶ This is recommended if a cluster master is pushing large bundles or even a smaller bundle but to a large cluster (20 or more indexers).
▶ To enable, set the following configuration within server.conf
Best practice: Forward manager node data to the indexer layer
Ensure necessary indexes exist on the indexers:
Check if indexes like _audit and _internal are present on both the manager node and the indexers.
If custom indexes exist only on the manager node, make sure to create the same indexes on the indexers to hold the corresponding manager data.
Configure the manager node as a forwarder:
Create an outputs.conf file on the manager node.
Configure load-balanced forwarding across the set of peer nodes.
Turn off indexing on the manager node to prevent it from retaining data locally and forwarding it to the peers.
Note: Ensure that the manager node is also set up as a search head in the indexer cluster. This allows it to perform searches and access the data it forwards to the peers.
Here is an example outputs.conf file:
# Turn off indexing
[indexAndForward]
index = false
[tcpout]
defaultGroup = my_peers_nodes
forwardedindex.filter.disable = true
indexAndForward = false
[tcpout:my_peers_nodes]
server=10.10.10.1:9997,10.10.10.2:9997,10.10.10.3:9997
This example assumes that each peer node's receiving port is set to 9997.
Configure the peers for index replication:
Ensure that all necessary indexes are available on the peers.
If you need to install apps or change configurations, apply the changes to all peers in a consistent manner, ensuring that they use a common set of indexes.
If you need to add indexes (including indexes defined by an app), configure the peers to use the same set of indexes.
Note: After configuring the peers, you can start replicating data between the manager node and the peers.