Backup and restore using Azure PostgreSQL database server

SonarQube Server / Community Build
,
1

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
  • what are you trying to achieve
  • what have you tried so far to achieve this

*SonarQube version: 8.7.0-Developer running in a docker container on a Ubuntu host VM.

  • trying to achieve a viable upgrade/downgrade path with resources on Azure/postgresql database server
    *what have I tried so far: please continue reading

I’m new to SonarQube (SQ) so please bear with me for this long post.

We are planning to upgrade our current 8.7.0-developer version to the latest version and are currently exploring upgrade paths.

I wanted to be able to have a fallback path just in case the upgrade was unsuccessful. I’ve read past posts on backing up the postgresql database using pg_dump but since we run on Azure, I came up with the following upgrade path.

Could someone please advise on whether the proposed upgrade is viable and what, if any, consequences there may be.

Steps:

  1. back up postgresql database server to new server using Azure RESTORE
  2. modify host VM env variables to point to new server
  3. modify docker-compose.yml to pull required image version
  4. remove current docker container
  5. docker-compose up: to configure database on new server
  6. upgrade database as directed
  7. install plugins, if needed.

If necessary to downgrade, then just configure the env variables on the host VM to revert to the previous database server and repeat steps 3-7 above.

Questions:

  1. is this path viable?
  2. what about licensing issues since the database has been migrated to a new server?

Thank you for your time.
Dan Guerrero

2

Hi @dgu1usb ,

sorry for the delay in answering you :sweat_smile:

please note that you need to hop from 8.7.0 → 8.9.2 → latest as documented here.

there are some risks in your approach.
If you are using 3rd party plugins you need to make sure that they are compatible with the SQ version you are aiming for. They can be skipped for upgrade procedures but an incompatible plugins can cause SQ to not start up.
Changing the jdbc connection parameter will invalidate your license. SQ will still start up and you can view all of your data without a license, but you can not do any analysis on this system. in order to avoid this you should not modify your jdbc connection parameter and have you backup ready to restore if you need to role back. this is where we recommend using pg_dump to create the backup.

hope that helps :slight_smile:

3

Thank you for your response.

One question though about licensing:

If i were to use the new postgresql server, thereby changing the jdbc connection and invalidating the license, could I configure SQ to reuse the now invalidated license, on that new postgresql server?

in other words, is the SQ license nodelocked to a particular server/hostname or can it be migrated to a different azure postgresql server?

thanks,
dan

4

Hi @dgu1usb ,

we have documentation about actions that will invalidate your license here. in this document you will also find the answer that nearly every change to the database connection will invalidate your license. If that happens you need to reach out to your sales representative to get a new license generated for you.

In your particular case you could easily mitigate it if you backup or snapshot the database and roll back to a state before the upgrade if something goes south without creating a new database server that runs parallel.

hope that made things more clear