I am facing the below error.
org.sonar.api.utils.MessageException: Database relates to a more recent version of sonar. Please check your settings.
i have 2 different servers. one for sonar and another for database.
1. I have taken snapshot of sonar server, but i didnot take snapshot for database(forgot to take it).
2. I have upgraded sonar from sonar 4.0 to sonarqube4.5.1 after taking backup of database(postgresql) using pg_dump command... but as i have faced some loss of data after upgrading sonar and database i have reverted back to previous snapshot (sonar server)
3. now we have done restoring the database using pg_restore command successfully but the sonar 4.0 is not getting started and gives the above error
could anyone help me with this
Message is quite obvious. You are starting your SQ 4.0 instance connected to a DB which is recognized as more recent.
Options are limited:
either the DB is really your original SQ 4.0 DB and you are not running the exact same SQ 4.0 software you used to
or you are running the same SQ 4.0 software and the DB is not your original SQ 4.0 DB
My guess is that you did not successfully restore your DB to its SQ 4.0 state, or only partially.
Under the hood, SQ uses table schema_migrations to know which version of the DB it is connected to.
Each db migration "script" (lets use that name for simplicity sake) has a unique number (number is strictly increasing) and each SQ version knows the number of the last migration script it bundles. When a script is successfully executed, a row is added to table schema_migrations.
SQ checks at startup its last script's number against the highest number in schema_migrations:
same number, everything is ok
lower number, DB needs an upgrade
higher number, the error message you got
Related
Can we take base backup from postgresql old version db to new version db.
For Example I have two DB servers. One server is having old version Postgres 9.x and another one is running Postgres 13.
If I want to take base backup from postgres 9.x for Postgres 13, can we do that directly using the pg_basebackup command in Postgres 13 DB server.
Is there any other way to complete the above task in Postgres.
I have a plan below to complete the above task if the base backup does not work for lower to higher versions. But it is a slow process.
DB A has a lower version and DB B has a higher version.
So to take base backup, updating the A DB version same as B DB is the only option.
Once the DB A updated successfully, Then start the base backup from A DB with updated Postgres version to the B DB.
We can refer to the below site for the DB update process.
https://www.migops.com/blog/upgrading-postgresql-9-6-to-postgresql-13/
The DB update process will take time to complete. In that time the write process will not work on the primary DB. All the write process will be affected because of this. If any issue happens in the update process, almost everything will be a mess.
I will suggest the old version DB to the new version db base backup process to complete this activity.
Do you guys have any suggestions?
You are mixing up physical file-system level backup (pg_basebackup) and logical backup, also known as dump or export (pg_dump). You can only use the latter for upgrading. A pg_basebackup can only be restored to the same major PostgreSQL version.
I have a Postgres database instance in GCP running on version 9.6.
I want to upgrade the Postgres version to a newer version, and I use GCPs "Database migration" for that purpose.
I have 2 databases in the instance and they fill around 800 GB in total.
The problem is that the migration gets in stuck. There are no errors in the migration log.
Copy of monitoring
In short, my question is:
How can I check in what phase is the migration and what is the issue?
Thanks.
Background:
In one of our projects there is a Jenkins build step which generates a Postgres SQL script based on provided EF Core DbContext. The script generating step looks like
dotnet-ef migrations script -c MyDbContext
Since there is a requirement to generate a script for different versions of Postgres, the following steps are taken:
Postgres version is being set in C# code via SetPostgresVersion extension method
Version which is being set in step 1 is being passed as Environment variable.
These version-setting steps are working because I've got an error while trying to pass version '12' instead of required '12.0', the scripts are also generated without issues.
Question:
I need to come up with the first (lowest) Postgres version for which the generated script will be different from the baseline 9.6.
I have generated SQL scripts for Postgres 9.6, 10.0, 11.0, 12.0, 13.0, 13.1 and they all are identical.
This might be a correct result, but how do I verify it? What differences should I expect between, let's say, 9.6 and higher versions of Postgres (if indeed such differences exist)?
The actions performed in the migration script are following:
If a table does not exist then create it
If an index does not exist then create it
Insert records into MigrationHistory
Alter some tables, drop some columns and indexes, etc.
It is possible that the actions performed by the script are indeed the same for different Postgres versions, but is there any way to verify it?
I'm finding references in the 9.5 manual to phraseto_tsquery
https://postgrespro.com/docs/postgrespro/9.5/textsearch-controls
But if I use it in my query it gives me this error:
No function matches the given name and argument types.
SELECT phraseto_tsquery('english', 'The Fat Rats');
Was this function not added with 9.5 as intended or is it likely there's some other problem on my side. Running 9.5.4 of the database currently. Anyone that can confirm?
For anyone looking; took the step to install postgresql 9.6beta4 and I'm no longer receiving the error message. In other words phraseto_tsquery seems to only be fully supporting in the current 9.6 beta and upcoming full release.
Trying to install MobileFirst 6.3 (Using DB2 v 10.5, Windows Server 2012 R2 std) - and during the creation of the DB2 APPCNTR database stage, I get the error:
Creating database APPCNTR (this may take 5 minutes) ...failed:
Cannot connect to database 'APPCNTR' with user 'db2admin' after it was created: com.ibm.db2.jcc.am.SqlException: DB2 SQL Error: SQLCODE=-1035, SQLSTATE=57019, SQLERRMC=null, DRIVER=4.17.29
This is a clean installation of DB2, with no other programs using it (that I know of). The db2admin user is a member of my windows security group 'DB2ADMS' as well as 'DB2USERS' just in case
If I go back in the installer, then press next again, it says the database is already created (not sure if it's fully successful or partial)....
I believe that the database has been created successfully but for some reason, it is not possible to connect to the database via JDBC.
The explanation for the error message can be found here -- it can be many reasons: http://www-01.ibm.com/support/knowledgecenter/SSEPGG_9.5.0/com.ibm.db2.luw.messages.sql.doc/doc/msql01035n.html
When that happens to me the issue is often resolved by waiting a bit and retarting Installation Manager. Restarting the DB2 instance helps also. (If you don't restart Installation Manager, it believes it needs to create the database and fails because the database was created).
If the problem is not resolved by waiting a bit, you can also create the database manually prior running install Manager using that procedure (use a different database name than the one that is considered busy):
https://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.installconfig.doc/admin/t_creating_the_db2_database_for_App_Center.html
Then use that database name when running Installation Manager,