This is an archived version of the documentation for SonarQube version 6.7 LTS.
See Documentation for current functionality
Start/Stop/Upgrade the Cluster
Start the Cluster
- Start the search nodes
- Start the application nodes
Stop the Cluster
- Stop the application nodes
- Stop the search nodes
- Stop the cluster
- Upgrade SonarQube on all nodes (app part, plugins, JDBC driver if required) following the usual Upgrade procedure but without triggering the /setup phase
- Once all nodes have the same binaries: start the cluster
- At this point only one of the application nodes is up. Try to access [node ip:port]/setup on each server, and trigger the setup operation on the one that responds.
Install/Upgrade a Plugin
- Stop the cluster
- Upgrade the plugin on all nodes
- Start the cluster
CPU and RAM usage on each node have to be monitored separately with an APM.
In addition, we provide a Web API api/system/health you can use to validate all of the nodes of your cluster are operation.
- GREEN: SonarQube is fully operational
- YELLOW: SonarQube is usable, but it needs attention in order to be fully operational
- RED: SonarQube is not operational
To call it from monitoring system without having to give admin credentials, it is possible to setup a System Passcode through the property sonar.web.systemPasscode. This has to be configured in the sonar.properties.
Manually Check the Status of your SQ Cluster from the UI
In the System Info page, you can check whether your cluster is running safely (green) or has some nodes with problems (orange or red).
Compute Engine Workers
If you change the number of Compute Engine workers in the UI, you must restart each application node to have it take this change into account.
When the Project Move feature, coming with the Governance Plugin, is used in a DC installation:
- Projects are exported on only one of the application nodes
- The archive of the exported projects must be copied to all the applications nodes in the target server