After browsing the community without finding any similar topics I decided to ask on my own.
I am planning to upgrade our SonarQube Enterprise Edition from 7.3.0.15553 (MySQL) to the latest one. Regarding the release notes the MySQL support was dropped some time ago so I have to migrate the database as well. That’s why I want to test this upgrade using a separate staging environment.
Although I made a quite detailed plan on how to do this some things are still unclear.
To get an idea of what I want to do, here a bullet list of my plan:
Setup two staging environments in version 7.3 using MySQL and PostgreSQL
Clone the production database to have comparable data
Request license for that new staging environment to test features like “pull request analysis”
Upgrade to the latest version (and test again)
I am asking myself the following:
Is it correct that I have to setup 2 SonarQube instances to use the migration tool?
Do I have to request a (temporary) license for the MySQL instance to fully migrate the database to PostgreSQL? Or does the migration tool work independently of the SonarQube edition?
The mysql-migrator will do the hard job of moving all your data from MySQL to whatever your new database engine is.
However, the mysql-migrator will not migrate the schema (tables, indices, etc.) from one database to another. As a result, you need to first start a SonarQube instance against your target database using the same version as your current SonarQube version. This will create the schema on your target database, which is then primed to have data transferred into it.
Whatever happens to that “second instance” is up to you (it would work just as well if you stopped your Production instance and started it against your target database, but by using a second instance, you can do that before you take your maintenance outage to actually migrate the data).
I think that most users shut it off and then update the sonar.jdbc.url of their primary instance, and start their primary instance (which might have important plugins or additional configuration).
The migration will work whether or not a valid license is applied, but any analyses submitted won’t work until a license is applied.
When you migrate your Production instance – your server ID will change because a new Database URL will be used. You will need a new license at that time (and you can talk to your account representative about a temporary license that will cover all Server IDs until you have your new Server ID in hand)
Before migrating the production instance I want to setup another (permanent) instance for staging/testing purpose. That newly created instance I would like to “fill” with a dump of the current production database.
I assume that should be possible by just dump the database and import it as another database?
The idea was to simulate the production upgrade (with all data) using that staging instance; I want to see if the concept works for our current analysis data, without interrupting my colleagues work by unnecessary long maintenance outage of the production instance.
After the migration test I will delete the unnecessary MySQL based staging instance.
After all that staging stuff I will directly migrate the production instance to a target database which was setup for production use.
I did not know that such a temporary license is available. Thanks for that hint. I will contact my account representative about that.
Alright. For now all my questions are answered. The request for such a temporary license is sent.
Took me quite a while to get your point. I had in mind that 2 completely independent instances have to be created. But you are absolutely right. Just switching the database url to create the schema is enough. After the schema is created the migration tool does everything else.
If there are any furher questions or problems during my road to the latest SonarQube version I will create another specific topic.
