Tableau Server Dynamic Topology Changes
With the introduction of TSM, Tableau Server also introduced the ability to make certain topology changes or updates without restarting the server. These are known as dynamic topology changes, and are possible with the Backgrounder and VizQL Server processes.
You can increase or decrease the number of backgrounder or VizQL Server instances on a node without requiring a Tableau Server restart if the node already has at least one instance of the process running. You must be only changing the number of instances of Backgrounder or VizQL Server. If you also add or remove another process, or if you are adding the first instance of Backgrounder or VizQL Server to a node or removing the last instance of either from the node, Tableau Server will require a restart.
Dynamic configuration changes
Beginning with version 2020.2.0 of Tableau Server, certain configuration changes can also be made dynamically using configuration keys. You can make dynamic topology changes at the same time you make dynamic configuration changes, without needing to restart Tableau server. For more information about dynamic configuration changes, see Tableau Server Release Notes in What's New and Changed for 2020.2 in Tableau Server.
Example Scenarios
To better understand why this might be useful, consider these examples:
- Backgrounder – At the end of a sales quarter your sales team is using Tableau Server to keep track of their numbers. Dashboards that depend on extracts are showing sales people how they are doing. Any delay in extract refreshes means your team is not seeing the most up-to-date numbers. You can add additional backgrounders to any node that already has at least one backgrounder or VizQL Server, and increase the throughput of extract refreshes, helping to guarantee the numbers are up-to-date as your team finished up their quarter. Later, after the quarterly push, you can reduce the backgrounder instances again to return Tableau Server to its original configuration.
- VizQL Server –Similarly, if Tableau Server is unable to keep up with view refreshes, you can quickly add additional VizQL Server instances to any node that already has at least one instance of either VizQL Server or backgrounder configured. In the above backgrounder example, you might want to remove VizQL Servers temporarily, to accommodate additional backgrounders, and then re-add them back before your users arrive in the morning.
Making dynamic topology changes
You can make dynamic topology changes using the TSM Web UI, or on the command line. To use the Web UI, sign in to TSM using a browser, and on the Configuration tab, update the number of backgrounder or VizQL Server instances for the node you are updating. For details, see Configure Nodes. To make your changes using the TSM CLI, at a command prompt, run the tsm topology set-process command. For details, see Changing the number of processes on a node.
Impact of dynamic topology changes
When making dynamic topology changes that remove existing instances of VizQL Server or backgrounder, the instances are removed immediately. Be aware of the following potential impacts to users and currently running jobs:
Backgrounder – Any currently running jobs are terminated. The normal Tableau Server retry logic will restart these jobs, using another backgrounder instance.
VizQL Server – Any currently active sessions are terminated. Users may see an error message. Refreshing the browser should clear the error.
Best practices
Tableau recommends you test any dynamic topology changes you plan on using, before implementing them in your production environment. This will help you fully understand potential impacts to your users and scheduled refreshes and subscriptions, and allow you to most efficiently take advantage of the flexibility offered by dynamic topology.
Automating dynamic topology changes
You can automate dynamic topology changes. For example, if you have most of your extract refreshes scheduled overnight, and know your server has extra capacity because users are not signed in, you can use a script or other automated deployment tool to add backgrounder instances when they can be most efficiently used, and then remove them before the start of the work day.
To automatically get the status of processes, use the tsm status -v command and parse the output in your script. Alternately, you can use the TSM REST API get server status. The API is currently in alpha. For more details, see Get server status(Link opens in a new window).
A sample script to set four instances of backgrounder on node2 might look like this:
echo Adding/Removing Processes tsm topology set-process -pr backgrounder -n node2 -c 4 tsm pending-changes apply echo Done!