In the following cases, the Elasticsearch index can be desynchronized:
- Update of SonarQube that implies a DB migration
- Change DB from one vendor to another, for instance from H2 to Oracle
- Restore a previous DB backup
Currently, if a user follows the upgrade guide, the data directory is by definition empty. But if for any reason, this user would like to copy/paste the previous Elasticsearch data directory, we should detect such operation and drop/re-create all indices.
- Execution of DB migration
The DB version (ID of the last executed migration) is stored in Elasticsearch metadata. At startup it is compared with the effective version. If different, then all Elasticsearch indices are dropped, so that they will be automatically re-created and populated.
- Change DB vendor
The DB vendor (mysql, oracle, ...) is stored in Elasticsearch metadata. At startup is it compared with the effective DB vendor. If different, then all Elasticsearch indices are dropped, so that they will be automatically re-created and populated.
- Restore DB backup
Can't be technically implemented.
SonarCloud is frequently upgraded. Most of times it's not required to drop all Elastichsearch indices. The non-documented boolean property sonar.search.disableDropOnDbMigration should be implemented in order to decrease duration of service shutdown. By default value is false.
The development team should carefully notify SonarCloud ops team when a milestone requires to manually drop some indices.