MicroStrategy ONE
Maintain Result Caches and History Lists in a Clustered Environment
Proper maintenance of result caches and History Lists is important in any MicroStrategy system. For detailed information on caches and cache management, including recommended best practices, see Result Caches. For detailed information on History Lists, including best practices, see Saving Report Results: History List.
When maintaining result caches and History Lists in a clustered environment, be aware of the following:
- You can manage the caches on a node only if that node is active and joined to the cluster and if the project containing the caches is loaded on that node.
- Whenever a cache on one node of the cluster is created or updated, any copies of the old cache for that report, on the same node or on other nodes, are automatically invalidated. This means that only one valid copy of a cache exists at any time for a report on all nodes in the cluster. For more information about invalidating caches, see Managing Result Caches.
- The Cache Monitor's hit count number on a machine reflects only the number of cache hits that machine initiated on any cache in the cluster. If a different machine in the cluster hits a cache on the local machine, that hit is not be counted on the local machine's hit count. For more information about the Cache Monitor, see Monitoring Result Caches.
For example, ServerA and ServerB are clustered, and the cluster is configured to use local caching (see Synchronizing Cached Information Across Nodes in a Cluster). A report is executed on ServerA, creating a cache there. When the report is executed on ServerB, it hits the report cache on ServerA. The cache monitor on ServerA does not record this cache hit, because ServerA's cache monitor displays activity initiated by ServerA only.
- To ensure that History List messages are synchronized correctly between nodes and to reduce system overhead, either enable user affinity clustering or set the cache backup frequency to 0 (zero). For a discussion of these settings, including instructions, see Configure Caches in a Cluster.
Maintaining History Lists in a Clustered Environment
User affinity clustering causes Intelligence Server to connect all sessions for a user to the same node of the cluster. This enables Intelligence Server to keep the user's History List on one node of the cluster. Resource use is minimized because the History List is not stored on multiple machines, and the History List is never out of sync across multiple nodes of the cluster.
MicroStrategy recommends that you enable user affinity clustering in any clustered system. If you are not using user affinity clustering, MicroStrategy recommends that you set the cache backup frequency to 0 (zero) to ensure that History List messages are synchronized correctly among nodes. For more information about this setting, see Configuring Result Cache Settings.
To Configure the History List Governing Settings for a Clustered Environment
- In Developer, log in to a project source. You must log in as a user with administrative privileges.
- From the Administration menu, point to Server and then select Configure MicroStrategy Intelligence Server.
- Expand the Server Definition category, and then select Advanced.
- Do one of the following:
- To enable user affinity clustering, select the User Affinity Cluster check box.
- If you do not want to enable user affinity clustering, in the Backup frequency (minutes) field, enter 0 (zero).
- Click OK.
- Restart Intelligence Server.