Nowadays, the main DBs SonarQube supports provides tools to allow backing up the data while the application is running.
The most common strategies to backup the DB consists in:
- performing daily full snapshot, as well as more frequent incremental snapshot depending on the level of safety expected
- replicating with the data in a master-salve approach
But, whatever the strategy, many SonarQube users that are using Oracle database faced issues with their database backup.
Indeed, if SonarQube is running when the backup is being performed, the backup might have a mismatch between database sequences and auto-generated ids of some table entries. As a result, the backup is corrupted and usually prevent the user to run new analyses.
As a workaround, Oracle users would currently have to stop the application before being able to take a snapshot. This requires to automate a daily downtime which can take quite some time depending on the size of the database.
The application should not required to be stopped to backup the data. And, this is even more important in the context of the DataCenter Edition which provides High Availability so that the development teams can keep working without interruption.
With this MMF, we want to make sure that our users, and more specifically the ones who use Oracle, can reliably backup and smoothly restore their database in case of problem, without having the constraint to stop SonarQube to perform the backup.
For this, we need get rid of database auto-generated ids everywhere in order to solve this hot backup issue with Oracle.
At the end, we want to document the process for our users to backup and restore, formalizing this way the ability for our users to restore a Database backup.
We need to replace all AUTO_INCREMENT column by generated UUID. See
SONAR-13221 for the exhaustive list.