Best practice for restoring a dashboard on a Search Head Cluster

[pkeller]

I recently had to pull a dashboard raw XML file off of an archive. What is the process for actually putting it back in? I copied the file to the original directory ... $SPLUNK_HOME/etc/users/username/search/local/data/ui/views ... Then I executed a debug/refresh which did make the dashboard visible to the UI on the cluster member, but it didn't result in that dashboard being replicated on the other cluster members. Then I used the UI to edit the dashboard, made a trivial change, and at that point, it was pushed.

I'm looking really for the best practice to actually restore something in an SHC ... be it a dashboard or a lookup table.

[rphillips_splk · Accepted solution]

The recommended approach is to place your configurations within an app on your SHC deployer and deploy the configuration bundle to one of the SHC members. It will then get replicated to all other members.

http://docs.splunk.com/Documentation/Splunk/6.3.0/DistSearch/PropagateSHCconfigurationchanges

make sure to set the preserve-lookups flag when pushing the bundle so your lookups living on the SHC members don't get overwritten.

Maintain lookup files across app upgrades[edit]
Any app that uses lookup tables typically ships with stubs for the table files. Once the app is in use on the search head, the tables get populated as an effect of runtime processes, such as searches. When you later upgrade the app, by default the populated lookup tables get overwritten by the stub files from the latest version of the app, causing you to lose the data in the tables.

To avoid this problem, you can stipulate that the stub files in upgraded apps not overwrite any table files of the same name already on the cluster members. Run the splunk apply shcluster-bundle command on the deployer, setting the -preserve-lookups flag to "true":

splunk apply shcluster-bundle -target : -preserve-lookups true -auth :
Note the following:

The default for -preserve-lookups is "false". In other words, by default, the populated lookup tables are overwritten on upgrade.
Note: To ensure that a stub persists on members only if there is no existing table file of the same name already on the members, this feature can temporarily rename a table file with a .default extension. (So, for example, lookup1.csv becomes lookup1.csv.default.) Therefore, if you have been manually renaming table files with a .default extension, you might run into problems when using this feature. You should contact Support before proceeding.

[pkeller]

Thanks for the detailed response. The Lookup table process makes sense ... With regards to the first part, restoring a dashboard ... Since this is a dashboard created by a user via the UI, it wouldn't be something we'd typically bundle in an app ... I'm thinking that maybe the best way to handle this would be:

1. Pick a cluster member, login and shutdown the UI
2. Restore the file to its original directory
3. Restart Splunk
4. Check to see if the dashboard is now visible on that cluster member
5. Check another cluster member ... if the dashboard isn't visible, then edit and save the dashboard on the member where you restored it, and then check the other cluster members ... my guess would be that it'll now have been replicated to them.

( That probably sounds convoluted )

Anyway, thanks so much for your help.