| << Back to previous view |
|
[QB-3980] Data version mismatch
|
|
| Status: | Closed |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | 13.0.21 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Alexey Kuznetsov | Assigned To: | Robin Shen |
| Resolution: | Fixed | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Description |
|
We had Aurora MySQL database version 5.6.1.22.3 on Amazon. And QB fine worked on it.
But Amazon forcibly updated the database up to version 5.7.2.08.3. We have version 5.7.42 of MySQL on QB server's Amazon instance. But QuickBuild server cannot start on the database with version 5.7.2.08.3 and fails with error "com.pmease.quickbuild.QuickbuildException: Data version mismatch (database data version:117, application data version:120)". |
| Comments |
| Comment by 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 5.6.1.22.3? If so, you need to export data from it and import into 5.7.2.08.3 with MySQL dump tool. |
| Comment by Alexey Kuznetsov [ 06/Jun/23 09:23 AM ] |
| I guess that Amazon converted data into 5.7.2.08.3 when updated the database. Otherwise there is no point in update. |
| Comment by 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. |
| Comment by Alexey Kuznetsov [ 06/Jun/23 09:38 AM ] |
|
So, here is what i have to do:
1) Get backup of Database 5.6.1.22.3 (before Amazon update). 2) Export data from it by MySQL dump tool. 3) Create a new Database 5.7.2.08.3. 4) Import exported data into new DB by MySQL dump tool. 5) Start QB server on exported Database 5.7.2.08.3. All right? |
| Comment by 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? |
| Comment by 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. |
| Comment by 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 5.6.1.22.3 and import to version 5.7.2.08.3 with MySQL dump tool. |
| Comment by 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. |
| Comment by 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. |
| Comment by 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? |
| Comment by 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)? |
| Comment by Alexey Kuznetsov [ 07/Jun/23 01:53 PM ] |
| From the directory being upgraded, of course. |
| Comment by 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. |
| Comment by 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? |
| Comment by Alexey Kuznetsov [ 07/Jun/23 02:09 PM ] |
| Seems they are the same (in 5.6 and 5.7). |
| Comment by 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. |
| Comment by Robin Shen [ 07/Jun/23 02:13 PM ] |
| Are you still able to start QB with MySQL 5.6? |
| Comment by Alexey Kuznetsov [ 07/Jun/23 02:15 PM ] |
| But I first upgraded QB and then switched to 5.7 DB. Is it wrong? |
| Comment by 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. |
| Comment by 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? |
| Comment by Alexey Kuznetsov [ 07/Jun/23 02:23 PM ] |
| No, it's excluded. |
| Comment by 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). |
| Comment by Alexey Kuznetsov [ 07/Jun/23 02:27 PM ] |
| And QB could start only when I restore 5.6 DB from pre-upgrade snapshot. |
| Comment by Alexey Kuznetsov [ 07/Jun/23 02:29 PM ] |
| We are talking about *Aurora* MySQL (if it matters). |
| Comment by 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. |
| Comment by 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." |
| Comment by Alexey Kuznetsov [ 08/Jun/23 09:25 AM ] |
|
Sorry, this error was on MySQL 8.0.
On empty 5.7 DB QB starts successfully. |
| Comment by 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. |
| Comment by Alexey Kuznetsov [ 08/Jun/23 10:08 AM ] |
| Yes, I've already done it. And it's incredible, but works. :) |
| Comment by 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! |
| Comment by Robin Shen [ 08/Jun/23 10:58 AM ] |
|
No problem at all, :)
Let me know if there is any other issues. |