SonarQube staging instance gets new server ID when restoring database from production backup

[stumt (Sean Underhill)]

Must-share information (formatted with Markdown):

• which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
  SonarQube 10.5.1, postgresql database via Azure Database for PostgreSQL flexible server
• how is SonarQube deployed: zip, Docker, Helm
  Helm
• what are you trying to achieve
  Ultimately I’m trying to upgrade to the new version of SonarQube 10.6 but need to test this using our staging server first.
• what have you tried so far to achieve this

1. pg_dump backup of production database
2. shut down staging instance
3. purged elasticsearch index es8 directory
4. pg_restore the production database backup into the staging database
5. start up staging instance

I’ve tried several variations of #4 above, including:

• plain restore
• –clean restore
• dropping and creating the staging database before restoring

No matter what I try, the staging instance comes up with a new server ID every time, even though I’m not changing the JDBC string (it remains pointed at the staging database).

I haven’t even gotten to switching to 10.6 yet because I can’t get the staging database sync’d up with the production database without invalidating my staging license.

Please advise, thanks.

[Colin]

Hey there.

If this is your first time restoring your Prod database to staging, this is pretty normal that a new Server ID gets generated.

docs: actions that will invalidate your license key

Certain actions will regenerate your server ID and invalidate your license key. The following are some of the most common of these actions:
…

• Restoring the database content from another SonarQube instance (except for production/staging synchronization).

So I would go ahead and move forward after requesting a new staging license from contact@sonarsource.com.

[stumt (Sean Underhill)]

Hi Colin, thank you for the prompt reply. Can you confirm the correct method of restoring the production database into the staging database for postgresql databases? Should I drop and recreate the staging database each time? Basically how do I ensure that I can sync production to staging without having to go through this request a new license process again?

Thanks,
Sean

[Colin]

A basic pg_dump and pg_restore should do just fine.

You just need to have synced your staging database at least once with production to get the server ID in a place where it won’t change on future dumps (assuming the JDBC URL won’t change). After that, you can do whatever you like with your staging database as long as the JDBC URL doesn’t change, and you always copy data from the same production instance.