History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: QB-3980
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Robin Shen
Reporter: Alexey Kuznetsov
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Data version mismatch

Created: 06/Jun/23 08:54 AM   Updated: 08/Jun/23 10:58 AM
Component/s: None
Affects Version/s: 13.0.21
Fix Version/s: None

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown

 Description  « Hide
We had Aurora MySQL database version on Amazon. And QB fine worked on it.
But Amazon forcibly updated the database up to version
We have version 5.7.42 of MySQL on QB server's Amazon instance.
But QuickBuild server cannot start on the database with version and fails with error "com.pmease.quickbuild.QuickbuildException: Data version mismatch (database data version:117, application data version:120)".

 All   Comments   Work Log   Change History      Sort Order:
Robin Shen [06/Jun/23 09:15 AM]
This happens as data version in your new database is not the same as QB application version. I guess you want to use same data as in MySQL If so, you need to export data from it and import into with MySQL dump tool.

Alexey Kuznetsov [06/Jun/23 09:23 AM]
I guess that Amazon converted data into when updated the database. Otherwise there is no point in update.

Robin Shen [06/Jun/23 09:26 AM]
I mean data version specific to QB application. This data version will remain unchanged even if you upgrade MySQL itself.

Alexey Kuznetsov [06/Jun/23 09:38 AM]
So, here is what i have to do:
1) Get backup of Database (before Amazon update).
2) Export data from it by MySQL dump tool.
3) Create a new Database
4) Import exported data into new DB by MySQL dump tool.
5) Start QB server on exported Database
All right?

Alexey Kuznetsov [06/Jun/23 09:40 AM]
Can I use QB tool (https://wiki.pmease.com/display/QB13/Data+Management) instead of MySQL dump tool?

Robin Shen [06/Jun/23 11:10 AM]
Yes, correct. Please make sure you also run same QB app version as the one you are running against MySQL 5.6

You can also use QB backup and restore tool, but it is a lot slower than MySQL dump tool, and is normally used in cases when you are switching to a different database, or migrate data between different QB versions.

Alexey Kuznetsov [07/Jun/23 08:24 AM]
I have the same error ("Data version mismatch (database data version:117, application data version:120)") even after Database export from version and import to version with MySQL dump tool.

Alexey Kuznetsov [07/Jun/23 10:38 AM]
I've upgraded right now QB to version 13.0.22 and got in upgrade logs:
2023-06-07 10:31:13,691 INFO Db version: 120
2023-06-07 10:31:18,831 INFO App version: 120

But there is still error "Data version mismatch (database data version:117, application data version:120)" on QB start with 5.7 MySQL Database.

Robin Shen [07/Jun/23 12:02 PM]
You mentioned that QB is able to connect to MySQL 5.6. Now data is exported from MySQL 5.6 and imported into MySQL 5.7. Then what QB app version are you using? I guess you are still using the QB app version connecting to MySQL 5.6 ealier, and simply modify database connection in conf/hibernate.properties?

If so, I can not think of any reason this error happens, unless QB is actually poining to the wrong databbase.

Alexey Kuznetsov [07/Jun/23 01:35 PM]
I'm using QB version 13.0.21.
I have 2 Databases:
1) version 5.6 which fine works with QB
2) version 5.7 on which QB cannot start
DB vesrion 5.7 doesn't work with QB even export data from 5.6 and inport to 5.7 via MySQL dump tool.
And yes, I switch between these Databases via conf/hibernate.properties.
Why do QB write on starting "database data version:117, application data version:120" if on QB updating I find in logs: "Db version: 120, App version: 120"? How is database data version determined in QB on starting?

Robin Shen [07/Jun/23 01:48 PM]
Data version in database is recorded in table QB_SETTING, but you can not read directly as it is in binary form. When you finished QB app upgrade, are you starting QB from the folder where you initiated the upgrade, or from the directory being upgraded (the directory you specified as param of upgrade.sh)?

Alexey Kuznetsov [07/Jun/23 01:53 PM]
From the directory being upgraded, of course.

Robin Shen [07/Jun/23 02:00 PM]
This is really odd. The only reason I can think of is that QB is not connecting to the correct database. You may schedule an online session and I can join to check what might be wrong. I am at timezone of GMT+8 and is normally available from 8:00AM to 22:00PM.

Alexey Kuznetsov [07/Jun/23 02:06 PM]
When does value of QB_SETTING (which is responsible for db version) should be changed? On export to MySQL 5.7 Database?

Alexey Kuznetsov [07/Jun/23 02:09 PM]
Seems they are the same (in 5.6 and 5.7).

Robin Shen [07/Jun/23 02:11 PM]
When export/import between MySQL 5.6/5.7, no any value will be changed, and data version will remain unchanged. However when perform upgrade from one QB version to another, data will be changed and data version will change.

Robin Shen [07/Jun/23 02:13 PM]
Are you still able to start QB with MySQL 5.6?

Alexey Kuznetsov [07/Jun/23 02:15 PM]
But I first upgraded QB and then switched to 5.7 DB. Is it wrong?

Alexey Kuznetsov [07/Jun/23 02:16 PM]
Yes, QB starts and work with 5.6 now. If I switch to 5.7 then QB cannot start.

Robin Shen [07/Jun/23 02:21 PM]
Seems to me that the 5.7 database does not contain data exported by 5.6. Any possibility of using wrong data for import/export?

Alexey Kuznetsov [07/Jun/23 02:23 PM]
No, it's excluded.

Alexey Kuznetsov [07/Jun/23 02:25 PM]
Plus, QB failed right after Amazon forcibly upgraded DB from 5.6 to 5.7 (see Description).

Alexey Kuznetsov [07/Jun/23 02:27 PM]
And QB could start only when I restore 5.6 DB from pre-upgrade snapshot.

Alexey Kuznetsov [07/Jun/23 02:29 PM]
We are talking about *Aurora* MySQL (if it matters).

Robin Shen [07/Jun/23 02:36 PM]
This should not do any difference. Since you already have the exported dataset, let's re-create 5.7 database to get an empty database, and then point QB to it to see what happens.

Alexey Kuznetsov [08/Jun/23 09:19 AM]
Then I get the error: "java.sql.SQLException: Index column size too large. The maximum column size is 767 bytes."

Alexey Kuznetsov [08/Jun/23 09:25 AM]
Sorry, this error was on MySQL 8.0.
On empty 5.7 DB QB starts successfully.

Robin Shen [08/Jun/23 09:48 AM]
Then please import data from 5.6 again into the empty 5.7 database and start QB to see if it works.

Alexey Kuznetsov [08/Jun/23 10:08 AM]
Yes, I've already done it. And it's incredible, but works. :)

Alexey Kuznetsov [08/Jun/23 10:47 AM]
I was able to switch even to MySQL 8.0.
Robin thank you very much for your help!

Robin Shen [08/Jun/23 10:58 AM]
No problem at all, :)

Let me know if there is any other issues.