View Issue Details

IDProjectCategoryView StatusLast Update
0024658mantisbtupgradepublic2018-08-30 11:29
Reportergirtsb Assigned Todregad  
PrioritynormalSeverityblockReproducibilityalways
Status closedResolutionno change required 
Product Version2.16.0 
Summary0024658: 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.
Then IIS web server that is on Windows Server 2008 R2

As our application cant run on newest PHP, Im using 5.5.38 version.

  1. I put mantis 2.16 version files and then old cofig_inc.php in configuration map.
  2. Import the .sql dump of the production DB into new MySQL server.
  3. Run from that 2.16 version folder admin/install.php on web. Everything checks out.
  4. installing ends with this error: "Database query failed. Error received from database was #1054: Unknown column 'priority' in 'field list' for the query: SELECT basename, priority, protected FROM mantis_plugin_table WHERE enabled=? ORDER BY priority DESC."

Did some checking and:

  1. Created empty scheme and installed it on that scheme as clean mantis installation. Everything was ok.
  2. On that clean instalation mantis_plugin_table is with all columns. "basename, enabled, priority, field list"
  3. Comparing it to upgraded scheme, it has only "basename" and "enabled" columns.
  4. Removed that table and created it as from the "fresh installation" scheme. But still the error shows up. I have searched forums on every possible thing and nothing has helped. And yes i tried to upgrade to 1.3 or 2.15 and same thing happened. I don't get why it cant query sql showing it lacks those columns, but in scheme they are there.
TagsNo tags attached.

Activities

atrol

atrol

2018-08-09 03:33

developer   ~0060388

Might be a problem of underlying ADOdb library when using Mysql 8.0.
Could you try if the issue occurs when using latest MySQL 5.7?

girtsb

girtsb

2018-08-09 03:40

reporter   ~0060389

Okey I will try on that version of MySQL

atrol

atrol

2018-08-09 03:47

developer   ~0060390

Thanks for trying.
Waiting for your feedback.

girtsb

girtsb

2018-08-09 08:54

reporter   ~0060394

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)

dregad

dregad

2018-08-09 09:05

developer   ~0060395

That would imply some kind of failure between schema steps 64 and 80 (excluded). What is the schema version after you get the error ? (SELECT value FROM mantis_config_table WHERE config_id = 'database_version') ?

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.

dregad

dregad

2018-08-09 09:10

developer   ~0060396

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?

I don't think that would help.

girtsb

girtsb

2018-08-09 09:17

reporter   ~0060397

Last edited: 2018-08-09 09:34

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.

atrol

atrol

2018-08-09 09:22

developer   ~0060398

@dregad IMO this is the strange thing

Removed that table and created it as from the "fresh installation" scheme. But still the error shows up.

dregad

dregad

2018-08-09 09:35

developer   ~0060399

Last edited: 2018-08-09 09:36

value is 70

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

this is the strange thing

Removed that table and created it as from the "fresh installation" scheme. But still the error shows up.

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)
But you're right, it should not report non-existing columns in this case.

girtsb

girtsb

2018-08-09 10:00

reporter   ~0060401

Last edited: 2018-08-09 10:40

Here are PHP error yesterday:
[08-Aug-2018 10:38:11 Asia/Muscat] PHP Fatal error: Call to undefined function require_api() in C:\inetpub\MANTIS\admin\schema.php on line 48
[08-Aug-2018 11:21:06 Asia/Muscat] PHP Fatal error: Call to undefined function require_api() in C:\inetpub\MANTIS\admin\schema.php on line 48
[08-Aug-2018 12:00:38 Asia/Muscat] PHP Fatal error: Call to a member function MoveNext() on a non-object in C:\inetpub\MANTIS\core\database_api.php on line 538
[08-Aug-2018 12:02:41 Asia/Muscat] PHP Fatal error: Call to a member function MoveNext() on a non-object in C:\inetpub\MANTIS\core\database_api.php on line 538
[08-Aug-2018 12:02:49 Asia/Muscat] PHP Fatal error: Call to a member function MoveNext() on a non-object in C:\inetpub\MANTIS\core\database_api.php on line 538
[08-Aug-2018 12:19:25 Asia/Muscat] PHP Fatal error: Call to a member function MoveNext() on a non-object in C:\inetpub\MANTIS\core\database_api.php on line 427
[08-Aug-2018 12:22:21 Asia/Muscat] PHP Fatal error: Call to a member function MoveNext() on a non-object in C:\inetpub\MANTIS\core\database_api.php on line 427

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.

girtsb

girtsb

2018-08-13 09:51

reporter   ~0060415

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?

atrol

atrol

2018-08-14 02:34

developer   ~0060423

Should I try upgrade incremently by going 1.1.1 -> 1.1.2 -> 1.1.3 or something like that?

Will not help as database schema of all 1.1.x versions is the same.
Migration in two steps from 1.1.1 to 1.2.20 to 2.16.0 could be worth a try.

@xxxxx to summarize the findings, please confirm and double check if it's right:

After import of the database dump

  • value of database_version in mantis_config_table is 63
  • there is no table mantis_plugin_table

After running install.php of version 2.16.0

  • database_version in config_table is 70
  • there is a table mantis_plugin_table
  • there are just two columns in mantis_plugin_table (basename and enabled)

If you confirm, we are again at 0024658:0060399

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 ?

Maybe there are warnings / errors in it that memory limit exceeded or a CPU timeout.

girtsb

girtsb

2018-08-14 05:19

reporter   ~0060427

Last edited: 2018-08-14 05:24

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.

atrol

atrol

2018-08-14 05:38

developer   ~0060428

Might be the same issues 0014826, maybe the described workaround works also for you 0014826:0033198.

girtsb

girtsb

2018-08-14 08:19

reporter   ~0060430

Last edited: 2018-08-14 08:46

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.

dregad

dregad

2018-08-14 09:09

developer   ~0060431

its simply because install didn't upgrade till the end.

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.
Just run the upgrade again, it will pick up where it left off.

girtsb

girtsb

2018-08-17 07:21

reporter   ~0060448

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!

dregad

dregad

2018-08-17 11:22

developer   ~0060449

This seems strange, it should not take such a long time to update 500K records...
How many rows does the installer process before timing out ? Count the number of 1 values in the xxx_int column being converted.
Did you try increasing the PHP timeout ?

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.

girtsb

girtsb

2018-08-20 07:31

reporter   ~0060459

Last edited: 2018-08-20 07:32

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.

girtsb

girtsb

2018-08-20 10:27

reporter   ~0060462

As of now, everything is ok. Version 2.16 is successfully upgraded. Thank you for helping so much!

dregad

dregad

2018-08-20 10:58

developer   ~0060463

Thanks for the feedback, glad to hear you completed the upgrade successfully.