Sonar: The current batch process and the configured remote server do not share the same DB configuration

You might see this error message when starting the Sonar client, for example via Maven (mvn sonar:sonar):

The current batch process and the configured remote server do not share the same DB configuration
- Batch side: jdbc:...
- Server side: check the configuration at http://.../system

The message is a bit misleading. Sonar doesn’t actually compare the database URL, it compares the ID which you can find in the database table properties under prop_key = sonar.core.id and this isn’t an ID, it’s the start time of the Sonar web server:

select * from properties where prop_key = 'sonar.core.id'

There are two reasons why there could be a mismatch:

  1. The database URL on the batch and the server side don’t match (just check it via the URL which the Sonar client gives you)
  2. There are two Sonar servers using this database. This can happen, for example, when you migrated the service from one host to another and forgot to shut down the old version properly.

7 Responses to Sonar: The current batch process and the configured remote server do not share the same DB configuration

  1. Carlos Blanco says:

    Hello,

    I’m experiencing the same problem running Sonar plugin from Jenkins. I have checked the database URL on both sides and seems right.
    Do you know how to check property sonar.core.id?. It is the same value Sonar stores in Server ID?

    Regards, Carlos

    • digulla says:

      To check sonar.core.id, you need to run SQL against the Sonar database. The source code is pretty confusing in this area; the variable is called SERVER_ID but it’s not the same value that you can change in the “General Settings”

  2. Carlos Blanco says:

    Thx for your fast answer.

    I queried the table properties in sonar database and get the value of sonar.core.id. Then added next line

    sonar.core.id=XXX

    to my sonar plugin inside Jenkins. However, I still have the same problem. Maybe I did a mistake somewhere else.

  3. pards says:

    This was a great help. I had two Sonar WARs pointing at the same database (one was a sandbox, one was ‘production’).

    The trick was to shut them both down, then only restart the ‘production’ instance because Sonar resets the sonar.core.id on startup.

    FWIW you can get the server’s id via REST:

    http://server:port/sonar/api/server

    It has to match the one in the database for Sonar to work.

    • Thanks! In my case “select * from properties where prop_key = ‘sonar.core.id’ returned ID different from the one returned by “/api/server”. The solution was to restart Sonar, oh my God.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 339 other followers