- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have recently created a field extraction on one search head that I have assigned all apps and users to read and write and was wondering how long is would take for a change done in one search head to get replicated to other search heads?
Also from what I know is that changes done via the GUI are always replicated to other SHs, is this true? If so what CAN and CANNOT be replicated across other search heads via gui.
Thanks,
Regards,
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
![Azeemering Azeemering](https://community.splunk.com/legacyfs/online/avatars/407394.jpg)
These are the main types of configuration changes that the cluster replicates:
- Runtime changes or additions to knowledge objects, such as saved searches, lookup table and dashboardss.
For example, when a user in Splunk Web defines a field extraction, the cluster replicates that field extraction to all search heads in the cluster. - Runtime changes to users and roles.
Replication operates under these constraints:
- The cluster only replicates changes made at runtime, through specific configuration methods.
- A whitelist determines the specific types of changes that the cluster replicates.
Configuration methods that trigger replication
The cluster replicates changes made through these methods:
- Splunk Web
- The Splunk CLI
- The REST API
The cluster does not replicate any configuration changes that you make manually, such as direct edits to configuration files.
The cluster uses a whitelist to determine what changes to replicate. This whitelist is configured through the set of conf_replication_include attributes in the default version of server.conf, located in $SPLUNK_HOME/etc/system/default.
You can add or remove items from that list by editing the members' server.conf files under $SPLUNK_HOME/etc/system/local. If you change the whitelist, you must make the same changes on all cluster members.
For a comprehensive list of items in the whitelist, consult the default version of server.conf. This is the approximate set of whitelisted items:
alert_actions authentication authorize datamodels event_renderers eventtypes fields html literals lookups macros manager models multikv nav panels passwd passwords props quickstart savedsearches searchbnf searchscripts segmenters tags times transforms transactiontypes ui-prefs user-prefs views viewstates workflow_actions
The cluster replicates changes to all files underlying the whitelist items. In addition to configuration files themselves, this includes dashboard and nav XML, lookup table files, data model JSON files, and so on. The cluster also replicates permissions stored in *.meta files.
These are examples of the types of files replicated for various whitelist items:
# escape-hatch HTML views conf_replication_include.html = true # lookup table files conf_replication_include.lookups = true # manager XML conf_replication_include.manager = true # datamodel JSON files conf_replication_include.models = true # nav XML conf_replication_include.nav = true # view XML conf_replication_include.views = true
Note: The cluster does not replicate user search history
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you very much for the detailed explanation.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
![Azeemering Azeemering](https://community.splunk.com/legacyfs/online/avatars/407394.jpg)
These are the main types of configuration changes that the cluster replicates:
- Runtime changes or additions to knowledge objects, such as saved searches, lookup table and dashboardss.
For example, when a user in Splunk Web defines a field extraction, the cluster replicates that field extraction to all search heads in the cluster. - Runtime changes to users and roles.
Replication operates under these constraints:
- The cluster only replicates changes made at runtime, through specific configuration methods.
- A whitelist determines the specific types of changes that the cluster replicates.
Configuration methods that trigger replication
The cluster replicates changes made through these methods:
- Splunk Web
- The Splunk CLI
- The REST API
The cluster does not replicate any configuration changes that you make manually, such as direct edits to configuration files.
The cluster uses a whitelist to determine what changes to replicate. This whitelist is configured through the set of conf_replication_include attributes in the default version of server.conf, located in $SPLUNK_HOME/etc/system/default.
You can add or remove items from that list by editing the members' server.conf files under $SPLUNK_HOME/etc/system/local. If you change the whitelist, you must make the same changes on all cluster members.
For a comprehensive list of items in the whitelist, consult the default version of server.conf. This is the approximate set of whitelisted items:
alert_actions authentication authorize datamodels event_renderers eventtypes fields html literals lookups macros manager models multikv nav panels passwd passwords props quickstart savedsearches searchbnf searchscripts segmenters tags times transforms transactiontypes ui-prefs user-prefs views viewstates workflow_actions
The cluster replicates changes to all files underlying the whitelist items. In addition to configuration files themselves, this includes dashboard and nav XML, lookup table files, data model JSON files, and so on. The cluster also replicates permissions stored in *.meta files.
These are examples of the types of files replicated for various whitelist items:
# escape-hatch HTML views conf_replication_include.html = true # lookup table files conf_replication_include.lookups = true # manager XML conf_replication_include.manager = true # datamodel JSON files conf_replication_include.models = true # nav XML conf_replication_include.nav = true # view XML conf_replication_include.views = true
Note: The cluster does not replicate user search history
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
![SplunkTrust SplunkTrust](/html/@E48BE65924041B382F8C3220FF058B38/rank_icons/splunk-trust-16.png)
Ehhh. "The cluster doesn't replicate user search history". It's true. It's also confusing because there is an option for it set by default to false but setting it to true doesn't do anything. 😆
![](/skins/images/FE4825B2128CA5F641629E007E333890/responsive_peak/images/icon_anonymous_message.png)