I believe that documentation for migration of SonarQube from one server to another would be very helpful and possibly save some users a lot of aggravation.
I am very familar with:
However, none of these resources seem to touch on migration between servers, nor restoration of a database from backup.
My aim was to move from inhouse SQ to SQ in the cloud, and starting with:
- SQ v5.6.7 (on CentOS 5, so cannot be upgraded to LTS)
- MySQL v5.6.35
- No proxy (ie, HTTP access to SQ)
- LDAP configured without groups
…and moving to:
- SQ v5.6.7
- MySQL v5.7.23
- nginx reverse proxy (HTTPS access to SQ)
- LDAP configured with groups
…with a non-negotiable requirement to test that access is both secure and authenticated (eg proxy and LDAP working) before restoring the database from the old system.
Based on the existing documentation, I followed the following steps:
- Install MySQL (empty schema, sonar user, etc)
- Install SQ (configured, plugins deployed, etc)
- Start SQ
- Succesfully tested that everything the system is accessible and things are working… including analysis of one project performed via Jenkins.
- Stop SQ
- Restore database backup from old SQ and run mysql_upgrade, etc.
- Start SQ
At this point, SQ was ostensibly working. For instance, the authentication token from the old SQ server was now valid on the new. All our projects from the old SQ were displaying on the new dashboard.
However, inspection revealed that everything was actually in a mess. For instance:
- Quality profiles (including sonarway) were reporting that 0 rules were active
- Quality Gates appear to be unassigned
- Clicking on a dashboard link that reported (say) 100 major issues would then list 0 issues
- The technical user that “owned” the authentication token was not displaying in users
Here’s the thing… after a LOT of head-scratching and research, the solution turned out to be really very simple. Using a clue from Sonar DB Copy Tool:
- Stop SQ instance
- Delete the ElasticSearch index
- Start SQ
The logs showed lots of interesting index rebuild events and zero errors. Once this was complete (and it did not take long) the SQ instance was now in rude heath. No problems at all.
Obviously, our ElasticSearch index had been “poisoned” by the initial access tests (steps 3 and 4 above)
It’s this that I suggest needs to be explicitly documented.
I really would not like anyone else to have the same problem that I had!