Configure indexing and replication separation

Enable Indexing and Replication Separation on your indexer cluster by configuring per-index settings in indexes.conf and pushing the cluster bundle.

  • Splunk Enterprise 10.4 or higher
  • Ingest-Tier Scaling already enabled and stable
  • SmartStore configured for each index that you want to use with this feature

You enable this feature per index through indexes.conf and push the configuration through the indexer cluster bundle.

Important: After Indexing and Replication Separation is enabled for an index, disabling it is not supported. Treat enablement as a one-way configuration change and validate the rollout path before applying it to production indexes.
Important: Deploy this feature in a test or low-stakes environment before you enable it broadly in production. Validate at least one representative SmartStore-enabled index and confirm that the cluster is healthy before you expand to additional indexes.
CAUTION: Do not treat this configuration as a replacement for a tested disaster recovery plan. Confirm your SmartStore, replication factor, search factor, site, and restore procedures before you rely on this behavior during a recovery event.
Setting Description
remotePath Points the index to SmartStore-backed remote storage. This must already be valid and working.
hotBucketStreaming.sendSlices = true Enables hot bucket slice streaming for the index. This is the core feature flag.
hotBucketStreaming.removeRemoteSlicesOnFreeze = true Removes remote slices when the bucket freezes. If you do not enable this cleanup behavior, you must manually clean the slice folders.
hotBucketStreaming.removeRemoteSlicesOnRoll = true Removes remote slices when the bucket rolls. If you do not enable this cleanup behavior, you must manually clean the slice folders.
  1. Identify the indexes that should participate and confirm that SmartStore is already enabled for those indexes.
  2. Add the hot bucket streaming settings to each index stanza in the cluster manager bundle.

    For clustered deployments, place the configuration in the following file:

    CODE 
    $SPLUNK_HOME/etc/manager-apps/_cluster/local/indexes.conf

    Add the core enablement setting and the recommended cleanup settings to each index stanza:

    CODE 
    [_internal]
remotePath = volume:remote/$_index_name
hotBucketStreaming.sendSlices = true
hotBucketStreaming.removeRemoteSlicesOnFreeze = true
hotBucketStreaming.removeRemoteSlicesOnRoll = true

    You can configure these settings in an individual index stanza or in the [default] stanza if all SmartStore-enabled indexes should use the same behavior. Use the [default] stanza only when you have confirmed that the setting should apply consistently across the affected indexes.

  3. Push the updated cluster bundle.
  4. Allow peers to receive the new configuration and wait for any required rolling restart or convergence activity to complete.
    Note: Validate only after the cluster has stabilized. If you inspect the logs while the cluster is still converging, you might misread normal transitional behavior as a configuration issue.
  5. Verify that the cluster is healthy before you proceed to validation.

After the bundle push completes and the cluster is stable, Splunk Enterprise uses Indexing and Replication Separation for the configured indexes. Verify the feature through Splunk logs.

Confirming indexing and replication separation

Verify that Indexing and Replication Separation is enabled

Successful verification requires expected behavior on the source indexer, the cluster manager, and the target indexers. You can also inspect the bucket from the cluster manager REST API:

CODE 
GET /services/cluster/manager/buckets/{name}

Source indexer verification

On the source indexer, confirm all of the following:

  • Splunk creates a new hot bucket for the configured index.
  • The bucket is marked as a streaming source.
  • The legacy hot bucket replication path no longer returns normal replication targets for that bucket.
CODE 
01-24-2026 07:58:44.347 +0000 INFO IndexWriter [82840 indexerPipe] -
Creating hot bucket=hot_v1_252, idx=_internal, bid=_internal~252~1A8D0D80-
DB99-45D5-BDEF-DA7802BECC7C, path_crc32=3763587448, event
timestamp=1769241516, reason=suitable bucket not found, hot_buckets=1, max=3,
closest bucket localid=251, earliest=1766470581, latest=1766503940,
sourcetype=splunkd
01-24-2026 07:58:44.348 +0000 INFO CMSlave [82840 indexerPipe] -
event=addBucket bid=_internal~252~1A8D0D80-DB99-45D5-BDEF-DA7802BECC7C
status=StreamingSource ss=Searchable mask=18446744073709551615 earliest=0
latest=0 standalone=0
01-24-2026 07:59:01.360 +0000 WARN BucketReplicator [83371 journal-compress]
- Skipping replication of bucket bid=_internal~252~1A8D0D80-DB99-45D5-BDEF-
DA7802BECC7C. No replication targets were returned

These messages indicate that the bucket is handled as a streaming source rather than through the normal hot bucket replication path.

Cluster manager verification

On the cluster manager, confirm all of the following:

  • The cluster manager updates the source bucket mask for streaming behavior.
  • The cluster manager creates HotSlicePollingStreamingTargetJob jobs.
  • The cluster manager adds target peers as streaming target peers.
CODE 
01-24-2026 07:59:02.536 +0000 INFO CMPeer [81111 CMMasterServiceThread] -
peer=1A8D0D80-DB99-45D5-BDEF-DA7802BECC7C peer_name=idx2
bid=_internal~252~1A8D0D80-DB99-45D5-BDEF-DA7802BECC7C transitioning
from=Searchable to=Searchable oldmask=0x2 newmask=0x5 reason="set
StreamingSource mask"
01-24-2026 07:59:02.536 +0000 INFO CMMaster [81111 CMMasterServiceThread] -
sendHotSlicePollingStreamingTargetJob created a
HotSlicePollingStreamingTargetJob for peer=1CE6CE85-95D0-47D1-93FE-
C5CF28CB8BBB, serverName=idx1, bid=_internal~252~1A8D0D80-DB99-45D5-BDEF-
DA7802BECC7C, mask=2, searchable=1
01-24-2026 07:59:02.657 +0000 INFO CMMaster [81407 TcpChannelThread] -
event=addTarget bid=_internal~252~1A8D0D80-DB99-45D5-BDEF-DA7802BECC7
peer=0A24A328-D9A7-4C76-808C-EE90C54AC953 peer_name=idx3
status=StreamingTarget searchable=yes mask=0

These messages indicate that the cluster manager is assigning and tracking streaming targets for the bucket.

Target indexer verification

On each target indexer, confirm all of the following:

  • The cluster manager adds the peer as a hot slice polling streaming target.
  • The bucket is marked as a streaming target.
  • The add-target workflow completes successfully.
CODE 
01-24-2026 07:59:02.540 +0000 INFO CMSlave [86824 TcpChannelThread] -
event=addHotSlicePollingStreamingTarget bid=_internal~252~1A8D0D80-DB99-45D5-
BDEF-DA7802BECC7C srcGuid=1A8D0D80-DB99-45D5-BDEF-DA7802BECC7C mask=0
searchable=1
01-24-2026 07:59:02.540 +0000 INFO CMSlave [86824 TcpChannelThread] -
event=addBucket bid=_internal~252~1A8D0D80-DB99-45D5-BDEF-DA7802BECC7C
status=StreamingTarget ss=Searchable mask=0 earliest=0 latest=0 standalone=0
01-24-2026 07:59:02.543 +0000 INFO CMSlave [89323 CMExecutorWorker-0] -
addTargetDone bid=_internal~252~1A8D0D80-DB99-45D5-BDEF-DA7802BECC7C
status=success addTargetInProgress=false

These messages indicate that the target peer accepted the bucket as a streaming target and completed setup successfully.

Minimum success criteria

  • The source peer shows streaming source behavior.
  • The cluster manager creates HotSlicePollingStreamingTargetJob jobs.
  • The cluster manager adds peers as streaming targets.
  • Target peers show streaming target behavior.
  • Target peers report addTargetDone ... status=success.
  • The cluster remains healthy after you apply the configuration.