Replace the master node on the indexer cluster

You might need to replace the master node for either of these reasons:

• The node fails.
• You must move the master to a different machine or site.

Although there is currently no master failover capability, you can prepare the indexer cluster for master failure by configuring a stand-by master that you can immediately bring up if the primary master goes down. You can use the same method to replace the master intentionally.

This topic describes the key steps in replacing the master:

1. Back up the files that the replacement master needs.

   This is a preparatory step. You must do this before the master fails or otherwise leaves the system.

2. Ensure that the peer and search head nodes can find the new master.
3. Replace the master.

In the case of a multisite cluster, you must also prepare for the possible failure of the site that houses the master. See Handle master site failure.

Back up the files that the replacement master needs

There are several files and directories that you must backup so that you can later copy them to the replacement master:

• The master's server.conf file, which is where the master cluster settings are stored. You must back up this file whenever you change the master's cluster configuration.

• The plain text version of the security key, pass4SymmKey. You should already have a backup copy available. See Configure the security key.

• The master's $SPLUNK_HOME/etc/master-apps directory, which is where common peer configurations are stored, as described in Update cluster peer configurations. You must back up this directory whenever you update the set of content that you push to the peer nodes.

• The master's $SPLUNK_HOME/var/run/splunk/cluster/remote-bundle/ directory, which contains the actual configuration bundles pushed to the peer nodes. You must back up this directory whenever you push new content to the peer nodes.

If the $SPLUNK_HOME/var/run/splunk/cluster/remote-bundle/ directory contains a large number of old bundles, you can optionally back up only the files associated with the active and previously active bundles. Look for the two files ending with .bundle_active and .bundle_previousActive. Each of those files has has an associated directory and a file that are each identified by the bundle id. You must back up all six files/directories in total.

For example, If the directory contains the file 42af6d880c6a1d43e935e8d8a0062089-1571637961.bundle_active, it will also contain the file 42af6d880c6a1d43e935e8d8a0062089-1571637961.bundle and the directory 42af6d880c6a1d43e935e8d8a0062089-1571637961. To back up the active bundle, you must back up the two files and the directory. Similarly, to back up the previously active bundle, you must back up the file that ends with .bundle_previousActive, as well as the directory and other file with the same id.

In addition to the above files and directories, back up any other configuration files that you have customized on the master, such as inputs.conf, web.conf, and so on.

In preparing a replacement master, you must copy over only these files and directories. You do not copy or otherwise deal with the dynamic state of the cluster. The cluster peers as a group hold all information about the dynamic state of a cluster, such as the status of all bucket copies. They communicate this information to the master node as necessary, for example, when a downed master returns to the cluster or when a stand-by master replaces a downed master. The master then uses that information to rebuild its map of the cluster's dynamic state.

Ensure that the peer and search head nodes can find the new master

You can choose between two approaches for ensuring that the peer nodes and search head can locate the replacement instance and recognize it as the master:

• The replacement uses the same IP address and management port as the primary master. To ensure that the replacement uses the same IP address, you must employ DNS-based failover, a load balancer, or some other technique. The management port is set during installation, but you can change it by editing web.conf.

• The replacement does not use the same IP address or management port as the primary master. In this case, after you bring up the new master, you must update the master_uri setting on all the peers and search heads to point to the new master's IP address and management port.

Neither approach requires a restart of the peer or search head nodes.

Replace the master

Prerequisite

You must have up-to-date backups of the set of files and directories described in Back up the files that the replacement master needs.

Steps

If you want to skip steps 3 and 5, you can replace the [general] and [clustering] stanzas on the replacement master in step 4, instead of copying the entire server.conf file.

1. Stop the old master, if this is a planned replacement. If the replacement is due to a failed master, then this step has already been accomplished for you.
2. Install, start, and stop a new Splunk Enterprise instance. Alternatively, you can reuse an existing instance that is not needed for another purpose. This will be the replacement master.
3. Copy the sslPassword setting from the replacement master's server.conf file to a temporary location.

   In release 6.5, the sslKeysfilePassword attribute was deprecated and replaced by the sslPassword attribute. If the server.conf file is using sslKeysfilePassword, then copy that setting instead.

4. Copy the backup of the old master's server.conf file to the replacement master.
5. Delete the sslPassword setting in the copied server.conf, and replace it with the version of the setting that you saved in step 3.
6. Delete the encrypted value for pass4symmkey in the copied server.conf, and replace it with the plain text value. See Configure the security key.
7. Copy the backup of the old master's $SPLUNK_HOME/etc/master-apps directory to the replacement master.
8. Copy the backup of the old master's $SPLUNK_HOME/var/run/splunk/cluster/remote-bundle/ directory to the new master.
9. Start the replacement master.
10. Make sure that the peer and search head nodes are pointing to the new master through one of the methods described in Ensure that the peer and search head nodes can find the new master.

For information on the consequences of a master failing, see What happens when the master node goes down.