Migrate settings from a standalone search head to a search head cluster
You can migrate settings from an existing standalone search head to all members in a search head cluster.
You cannot migrate the search head instance itself, only its settings. You can only add clean, new Splunk Enterprise instances to a search head cluster.
Types of objects to migrate
There are two types of objects to migrate:
- Custom app configurations. These originate under
etc/appson the standalone search head.
- Private user configurations. These originate under
etc/userson the standalone search head.
In both cases, you copy the relevant directories from the search head to the search head cluster's deployer. You then use the deployer to propagate these directories to the cluster.
The deployer pushes the configurations to the cluster, using a different method for each type. Post-migration, the app configurations obey different rules from the user configurations.
For information on where deployed settings reside on the cluster members, see "Where deployed configurations live on the cluster members."
Custom app configurations
When it migrates an app's custom settings, the deployer places them in default directories on the cluster members. This includes any runtime changes that were made while the apps were running on the standalone search head.
Because users cannot change settings in default directories, this means that users cannot perform certain runtime operations on these migrated entities:
- Delete. Users cannot delete any migrated entities.
- Move. Users cannot move these settings from one app to another.
- Change sharing level. Users cannot change sharing levels. For example, a user cannot change sharing from app-level to private.
Cluster users can override existing attributes by editing entities in place. Runtime changes get put in the local directories on the cluster members. Local directories override default directories, so the changes override the default settings.
Private user configurations
The deployer copies user configurations to the captain only. The captain then replicates the settings to all the cluster members through its normal method for replicating configurations, as described in "Configuration updates that the cluster replicates."
Unlike custom app configurations, the user configurations reside in the normal user locations on the cluster members and can later be deleted, moved, and so on. They behave just like any runtime settings created by cluster users through Splunk Web.
When you migrate user configurations to an existing search head cluster, the deployer respects attributes that already exist on the cluster. It does not overwrite any existing attributes within existing stanzas.
For example, say the cluster members have an existing file
$SPLUNK_HOME/etc/users/admin/search/local/savedsearches.conf containing this stanza:
[my search] search = index=_internal | head 1
and on the deployer, there's the file
$SPLUNK_HOME/etc/shcluster/users/admin/search/local/savedsearches.conf with these stanzas:
[my search] search = index=_internal | head 10 enableSched = 1 [my other search] search = FOOBAR
This will result in a final merged configuration on the members:
[my search] search = index=_internal | head 1 enableSched = 1 [my other search] search = FOOBAR
[my search] stanza, which already existed on the members, keeps the existing setting for its
search attribute, but adds the migrated setting for the
enableSched attribute, because that attribute did not already exist in the stanza. The
[my other search] stanza, which did not already exist on the members, gets added to the file, along with its
Note: Splunk does not support migration of per-user search history files.
Do not migrate default apps
When you migrate apps to the search head cluster, do not migrate any default apps, that is, apps that ship with Splunk Enterprise, such as the search app. If you push default apps to cluster members, you overwrite the version of those apps residing on the members, and you do not want to do this.
You can, however, migrate custom settings from a default app:
- You can migrate any private objects associated with default apps. Private objects are located under the
etc/usersdirectory, not under
- You can migrate custom settings in the app itself by moving them to a new app and exporting them globally. The migration procedure in this topic includes a step for this.
Migrate settings to a search head cluster
Note: This procedure assumes that you have already deployed the search head cluster. See "Deploy a search head cluster."
To migrate settings:
1. Copy the
$SPLUNK_HOME/etc/users directories on the standalone search head to a temporary directory on the deployer where you can edit them.
2. If you want to migrate custom settings from a default app, you can move them to a new app and export them globally. For example, to migrate settings from the search app :
- a. Copy the
.../search/localdirectory in the temporary directory to a new app directory, such as
search_migration_app, in the temporary directory. Do not name this new app "search."
- b. Export the settings globally to make them available to all apps, including the search app. To do this, create a
.../search_migration_app/metadata/local.metafile and populate it with the following content:
- See the default.meta specification file for details.
3. In the temporary directory, delete these subdirectories:
- Any default apps, such as the search app. Do not push default apps to the cluster members. If you do, they will overwrite the versions of those apps already on the members.
- Any apps already existing in the deployer's distribution directory. Otherwise, the versions from the standalone search head will overwrite the versions already on the members.
4. Copy all the remaining subdirectories from the temporary location to the distribution directory on the deployer, located at
$SPLUNK_HOME/etc/shcluster. Leave any subdirectories already in the distribution directory unchanged.
For details on the distribution directory file structure, see "Where to place the configuration bundle on the deployer."
5. If you need to add new cluster members, you must deploy clean instances. You cannot reuse the existing search head. For information on adding cluster members, see "Add a cluster member."
6. Run the
splunk apply shcluster-bundle command on the deployer to push the configuration bundle, including the migrated settings, to the cluster. See "Push the configuration bundle."
The deployer pushes
etc/apps directly to the cluster members. It pushes
etc/users to the captain, which asynchronously replicates the settings to the other cluster members.
Note: If you point the cluster members at the same set of search peers previously used by the standalone search head, the cluster will need to rebuild any report acceleration summaries or data model summaries resident on the search peers. It does this automatically. It does not, however, automatically remove the old set of summaries.
Migrate from a search head pool to a search head cluster
Upgrade a search head cluster
This documentation applies to the following versions of Splunk® Enterprise: 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6