View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0024658 | mantisbt | upgrade | public | 2018-08-09 02:50 | 2018-08-30 11:29 |
Reporter | girtsb | Assigned To | dregad | ||
Priority | normal | Severity | block | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Product Version | 2.16.0 | ||||
Summary | 0024658: Upgrade 1.1.1 to 2.16 | ||||
Description | Hello! I did everything in documentation states i needed to do, but cant get rid of this one error. So first of all. Im using the newest MySQL server (8.0 smth) on Windows Server 2016. As our application cant run on newest PHP, Im using 5.5.38 version.
Did some checking and:
| ||||
Tags | No tags attached. | ||||
Might be a problem of underlying ADOdb library when using Mysql 8.0. |
|
Okey I will try on that version of MySQL |
|
Thanks for trying. |
|
Tried with 5.7.9 MySQL. No success (using its versions connectors). Perhaps I need to go real hardcore, and make 2 new virtual machines one for web server and other for MySQL to imitate this setup, but on fresh installations? (huge sigh) |
|
That would imply some kind of failure between schema steps 64 and 80 (excluded). What is the schema version after you get the error ? ( The query you are referring to is executed by the plugin API when registering installed plugins (line 905); this is normally called when initializing MantisBT core, but should be skipped when done within the installer. To have some context, it would be interesting to have the full stack trace for the error. |
|
I don't think that would help. |
|
value is 70. As i remember seeing this in forums (about checking DB version) the start one before upgrading dump was 63. Yep. Redid dump, checked version its 63. (mantis 1.1.1), went into website and it showed login screen, but sayed that DB needs upgraded, then run intall.php (mantis 2.16) and after while it goes with the same error and DB version is 70. |
|
@dregad IMO this is the strange thing
|
|
That would imply that upgrade stopped (failed) at step 71 when migrating categories - did the installer report any other errors ? Anything in the PHP logs ? You did not provide the error's stack trace as requested in 0024658:0060395
That creates a discrepancy between the actual schema, and the state in which the installer expects to find it. So in any case some error would occur later on (i.e at step 80) |
|
Here are PHP error yesterday: Weirdly it goes into default Asia/Muscat instead of Europe/Riga. Installer doesn't report any errors untill the mantis_plugin_table one. I'm sorry, but how can I obtain error's stack trace? Edit: Got PHP 5.6 instead of 5.5 and now check index.php shows different stuff. Some tables weren't in UTF-8, but i guess that's not related to this strange error. Edit2: redid this process again to catch right PHP errors and they didn't show up so I guess these are unrelated to upgrade, but just me messing with dropping and recreating scheme/dump. After upgrade and getting the error, rechecking it shows plenty of warnings, but those are just security things and some options that are obsolete. |
|
Are there any news on this? Should I try upgrade incremently by going 1.1.1 -> 1.1.2 -> 1.1.3 or something like that? And tell on which it throws this error? |
|
Will not help as database schema of all 1.1.x versions is the same. @xxxxx to summarize the findings, please confirm and double check if it's right: After import of the database dump
After running install.php of version 2.16.0
If you confirm, we are again at 0024658:0060399
Maybe there are warnings / errors in it that memory limit exceeded or a CPU timeout. |
|
Did upgrade to 1.2.20 and got this error: Database query failed. Error received from database was #/1062: Duplicate entry '1-Meklesana' for key 'idx_category_project_name' for the query: INSERT INTO mantis_category_table ( name, project_id ) VALUES ( ?, ? ). If I enter mantis page again it shows the error I had when tried to upgrade 2.16. DB version value: 70 and unfortunately plugin_table still has 2 columns. To me it seems this 1.2.20 install error is the real one and somehow doesn't show up in 2.16 upgrade. Also 1-Meklesana is in that category_table. So why would it throw that insert error? Perhaps as it should be UTF-8 and in Latvian its Meklēšana and thats how actually in rows it shows up rightly. I'm bit confused. |
|
Might be the same issues 0014826, maybe the described workaround works also for you 0014826:0033198. |
|
Is our mantis DB cursed or what? Tried that workaround. Once I comment the line on schema.php out and run install on clean dump, it goes into FastCGI timeout. DB versions shows now 113 and there is no php errors. If i try to login (of course it shows under login screen that i need to upgrade it) this error: Database query failed. Error received from database was #1292: Incorrect datetime value: '1534250598' for column 'expiry' at row 1 for the query: DELETE FROM mantis_tokens_table WHERE ? > expiry. Can they be related or its simply because install didn't upgrade till the end. fun fact: plugin table is all right. |
|
That's most likely it. If you have a large number of records, it is quite possible that you're running into a timeout as the script is converting all the date/time fields. |
|
Been running that install script for 2 days now, reaching timeouts and starting it again. Question is: how to improve this speed? mantis_bug_history_table is 546382 rows long, avg row length 46 and data length 24,5 MB. As I see in MySQL connections it updates these rows all the time. When I would need to do migration of production, it would mean downtime for so many days? That's very unreasonable! |
|
This seems strange, it should not take such a long time to update 500K records... Alternatively (and at your own risk), you may try to perform the data conversion manually via SQL. In 1.x there is a date_modified column in Timestamp format, which gets converted to a date_modified_int column integer format (unix timestamp). See install_date_migrate() function in core/install_helper_functions_api.php for details. |
|
Thank you for advice! Putting PHP timeout values way more helped. Took around 1 hour for DB upgrade. For a side note. In original DB there is no category with 'Meklesana' just 'Meklēšana' within project id 1. It seems that upgrade script creates another category in that project and then cant create index, cuz of 2 same named categories. Gonna try to upgrade 1.2.20 -> 2.16 shouldnt be problems anymore. |
|
As of now, everything is ok. Version 2.16 is successfully upgraded. Thank you for helping so much! |
|
Thanks for the feedback, glad to hear you completed the upgrade successfully. |
|