Putting an old indexer into manual detention is the correct procedure for planned maintenance, such as a hardware migration. When a peer node is in manual detention, the Cluster Manager is instructed not to initiate bucket-fixing activities for a configurable period (defaulting to 60 minutes). This directly prevents the cluster from starting unnecessary replication operations to create new copies of buckets from the peer being decommissioned. This allows the administrator to shut down the old indexer gracefully without causing a resource-intensive replication storm across the remaining peers in the cluster.

A. Disable the indexing ports on the old indexers.

This only stops new data from being indexed on the peer; it does not prevent the Cluster Manager from initiating bucket fixing for existing data if the peer goes offline.

B. Disable replication ports on the old indexers.

This would cause the Cluster Manager to see the peer as down or unresponsive, which would immediately trigger bucket-fixing activities, increasing replication operations.

D. Put the old indexers into automatic detention.

Automatic detention is a system-triggered state for unstable peers that restart too frequently. It is not a procedure initiated by an administrator for planned maintenance like a migration.

---

1. Splunk Enterprise Documentation, Managing Indexers and Clusters of Indexers, "Take a peer offline".

This section explicitly details the procedure for planned maintenance. It states, "To take a peer offline for a short time, for maintenance or a configuration change, you can put it in manual detention... When you put a peer in manual detention, the cluster manager does not engage in bucket fixing for that peer's buckets for 60 minutes (by default)... This prevents the cluster from performing unnecessary bucket-fixing activities." This directly supports using manual detention (Option C) to reduce replication.

2. Splunk Enterprise Documentation, Admin Manual, server.conf specification file.

Under the [clustering] stanza, the documentation describes autodetentiononrestartcount. It specifies: "If the peer restarts more than times within the autodetentiononrestartperiod, the cluster manager automatically puts the peer into detention." This confirms that automatic detention (Option D) is a reactive mechanism for unstable peers, not a proactive method for planned migration.