Important: Although the site_replication_factor effectively replaces the single-site replication_factor, and the site_search_factor replaces single-site search_factor, those single-site attributes continue to exist in the master's configuration, with their default values of 3 and 2, respectively. This can cause problems on start-up if any site has fewer peer nodes than either of those values; that is, if any site has only one or two peer nodes. The symptom will be a message that the multisite cluster does not meet its replication or search factor. For example, if one of your sites has only two peers, the default single-site replication factor of 3 will cause the error to occur. To avoid or fix this problem, you must set the single-site replication and search factors to values that are less than or equal to the smallest number of peers on any site. In the case where one site has only two peers, you must therefore explicitly set the replication_factor attribute to a value of 2. See "Multisite cluster does not meet its replication or search factors."

If you are migrating a cluster from single-site to multisite, you must keep the existing replication_factor and search_factor attributes for the existing single-site buckets, while also adding the new multisite site_replication_factor and site_search_factor attributes for the new multisite buckets. See "Migrate an indexer cluster from single-site to multisite".

Configure multisite cluster nodes

To configure a multisite cluster, you configure the nodes for each site, editing each node's server.conf file. For details on the clustering attributes, read the server.conf specification.

Site values

Site values identify the site on which a node resides. You assign a site value to each node in a multisite cluster. To do this, you set the site attribute in the node's [general] stanza.

Site values have the syntax:

site<n>

where <n> is an integer in the range of 0 to 63: site1, site2, site3, ....

For example:

site=site1

The special value "site0" can be set only on search heads or on forwarders that are participating in indexer discovery:

The cluster label is optional. It is useful for identifying the cluster in the monitoring console. See Set cluster labels in Monitoring Splunk Enterprise.

Important: When the master starts up for the first time, it blocks indexing on the peers until you enable and restart the full replication factor number of peers. For example, given a three-site cluster with "site_replication_factor = origin:2, site1:1, site2:2, site3:3, total:8", the master blocks indexing until there are at least eight peers in total across all sites, including at least one in site1, two in site2, and three in site3.

Do not restart the master while it is waiting for the peers to join the cluster. If you do, you will need to restart the peers a second time.

Configure the peer nodes

To configure a peer node in a multisite cluster, you set a site attribute in the [general] stanza. All other configuration settings are identical to a peer in a single-site cluster.

the instance is located in site1. A peer can belong to only a single site.

the peer will use port 9887 to listen for replicated data streamed from the other peers. You can specify any available, unused port as the replication port. Do not re-use the management or receiving ports.

the peer's cluster master is located at 10.152.31.202:8089.

the instance is a cluster peer ("slave") node.

the security key is "whatever".

Configure the search heads

To configure a search head in a multisite cluster, you set a site attribute in the [general] stanza and a multisite attribute in the [clustering] stanza. All other configuration settings are identical to a search head in a single-site cluster.
Here is an example configuration for a multisite search head node:

the instance is located in site1. A search head can belong to only a single site per master.

the search head is a member of a multisite cluster.

the search head's cluster master is located at 10.152.31.202:8089.

the instance is a cluster search head.

the security key is "whatever".

Note: You can also use server.conf to enable multi-cluster search, in which the search head searches across multiple clusters, multisite or single-site. For searching across multiple multisite clusters, you can configure the search head to be a member of a different site on each cluster. For details, see "Configure multi-cluster search for multisite clusters".

When reconfiguring a search head that is up-and-running, Splunk recommends that you use the CLI command described in "Configure multisite indexer clusters with the CLI", rather than editing server.conf directly. If you use the CLI, you do not need to restart the search head.

Restart the cluster nodes

After initial configuration

After configuring instances as multisite cluster nodes, you need to restart all of them (master, peers, and search head) for the changes to take effect. You can do this by invoking the CLI restart command on each node:

$SPLUNK_HOME/bin/splunk restart

Important: When the master starts up for the first time, it blocks indexing on the peers until you enable and restart the full replication factor number of peers. For example, given a three-site cluster with "site_replication_factor = origin:2, site1:1, site2:2, site3:3, total:8", the master blocks indexing until there are at least eight peers in total across all sites, including at least one in site1, two in site2, and three in site3.

Do not restart the master while it is waiting for the peers to join the cluster. If you do, you will need to restart the peers a second time.

After changing the configuration

On the master

You must restart the master after you change any of the following attributes:

multisite

available_sites

site_replication_factor

site_search_factor

After you restart the master, you must also initiate a rolling-restart of the cluster peers. If you don't, the cluster will be in an indeterminate state. For information on the splunk rolling-restart command, see "Use rolling restart".

You do not need to restart if you change the site value on a master.

On the peers

If you change the site value on a peer, you must restart it for the change to take effect.

Important: Although you can use the CLI restart command when you initially enable an instance as a cluster peer node, you should not use it for subsequent restarts. The restart command is not compatible with index replication once replication has begun. For more information, including a discussion of safe restart methods, see "Restart a single peer".

On the search head

You do not need to restart if you change the site value on a search head.

Enter your email address, and someone from the documentation team will respond to you:

Send me a copy of this feedback

Please provide your comments here. Ask a question or make a suggestion.

Feedback submitted, thanks!

You must be logged into splunk.com in order to post comments.
Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic.
If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk,
consider posting a question to Splunkbase Answers.

0
out of 1000 Characters

Your Comment Has Been Posted Above

We use our own and third-party cookies to provide you with a great online experience. We also use these cookies to improve our products and services, support our marketing campaigns, and advertise to you on our website and other websites. Some cookies may continue to collect information after you have left our website.
Learn more (including how to update your settings) here »