Considerations for Deployments¶
Note
Only global administrators, promotion administrators and promotion users can deploy revisions. More information is available in the Authorization section.
Note
Solution Manager includes a new feature to perform promotions inside transactions. By doing this, Solution Manager deploys the revisions much faster and the rollbacks are almost instant. However, consider the following:
To start a promotion, there cannot be running queries on Virtual DataPort Server. If there are, the promotion will not start until all the previously running queries have finished.
During a promotion, if a Virtual DataPort server receives new queries, they will be queued until the promotion finishes on that node. If the cluster only has one node, all the queries received by the cluster will be queued.
With the previous promotion method, it was possible to execute queries in a server while a promotion was in progress. But notice that the server metadata could be in an inconsistent state while the promotion was not finished and, therefore, some queries could fail.
If you need the system to keep answering queries while promotions are performed, you can use multi-node clusters and configure the Solution Manager to remove the current node from the load balancer while the promotion process performs changes on each node (please review the Deployment Scripts and Load Balancing Variables documentation).
Cache¶
Consider the following aspects related with cache during Solution Manager deployments:
It is not possible to define Virtual DataPort properties at cluster level. In the case of cache data sources in multicluster environments, it is necessary to configure the cache manually. Due to this limitation, you should not include any cache data sources in CREATE revisions, otherwise during the deployment process the cache configuration of all clusters will be overwritten, leaving one of them in a possible inconsistent status. Solution Manager shows a warning message when deploying a revision with the features above:
Warning message when deploying revisions with cache data source a in multi-cluster environment.¶
If a revision includes Scheduler VDP Cache jobs, the Solution Manager might execute those jobs after the VQL changes are deployed in the first Virtual DataPort server of each cluster (if swap cache is configured or if a job is marked for execution). If the Virtual DataPort cluster does not use a shared cache, the Solution Manager may not update properly the cache of each Virtual DataPort server. Thus, in Virtual DataPort clusters without shared cache, you must update the cache using the Scheduler Web Tool or the Scheduler API and not the Solution Manager.
The cache swap process (in deployments in environments with a single cluster and cache swap enabled) only works with global cache (it does not work with caches defined for particular databases).
Summaries¶
If your revision includes a summary and that summary is either new or a modification of an existing one, remember to include the Scheduler job that loads the summary and select that job to be executed on the first Virtual DataPort server of the target environment. Otherwise the optimizer will not use the summary on the target environment because the table does not exist yet, or the definition has changed. For more information about summary promotions visit section Summary promotions.
Denodo Embedded MPP¶
Denodo includes embedded Massively Parallel Processing (MPP) capabilities to improve performance on environments containing data in an object storage. For this purpose Denodo now embeds a customized version of Presto, which is an open source parallel SQL query engine that excels in accessing data lake content. The Denodo Embedded MPP cluster can be deployed following the instructions in the Embedded MPP Guide.
This embedded MPP engine requires some special considerations during promotions that are described in section Promoting the Denodo Embedded MPP.