Upgrade from 1.1.8 to 2.21

General discussion of Mantis.

Moderators: Developer, Contributor

Post Reply
mario.madera
Posts: 4
Joined: 01 Aug 2019, 15:50

Upgrade from 1.1.8 to 2.21

Post by mario.madera »

Hi all,

New to Mantis BT. I had inherited an Mantis installed with and old version (1.1.18).
I had to upgrade moving to a new application host, new database on a different host, etc.. Software requirements are met. Anayway I had concerns regarding this topics:
- old database use MyISAM engine on tables, I think InnoDB is the standard now.
- upgrading the database schema (and data) requires several upgrades going from 1.1.8 to intermediate versions till reaching 2.21?

Could anyone give me some hints about?

Regards,

Mario
mario.madera
Posts: 4
Joined: 01 Aug 2019, 15:50

Re: Upgrade from 1.1.8 to 2.21

Post by mario.madera »

Adding information,

Looking around the code with a fellow dba, it seems that the correct path for upgrade is moving

1.1.8 -> 1.2.0 -> 1.3.0 -> 2.21.1

Can anyone confirm?
atrol
Site Admin
Posts: 8366
Joined: 26 Mar 2008, 21:37
Location: Germany

Re: Upgrade from 1.1.8 to 2.21

Post by atrol »

There might occur problems when upgrading, but in general it's a single step from 1.1.8 to 2.21.1

At least one step can be avoided as 1.3.0 -and 2.21.1 use the same database schema.
Please use Search before posting and read the Manual
mario.madera
Posts: 4
Joined: 01 Aug 2019, 15:50

Re: Upgrade from 1.1.8 to 2.21

Post by mario.madera »

Thanks!! That's usefull. No we had encounter another concern! Reviewing the code we has seen that by default the schema is created using InnoDB and UTF-8 in modern versions.

Our 1.1.8 database uses MyISAM and Latin-1. Should we convert from one to another following manual procedures? Existing tables are not recreated, but modified, at the end, we would have a database with tables using different engines and collations.

Regards,
Mario
mario.madera
Posts: 4
Joined: 01 Aug 2019, 15:50

Re: Upgrade from 1.1.8 to 2.21

Post by mario.madera »

Hi all,

We had found a solution or workaround.
We decided to discard the database, and restore it again from our production version 1.1.8. Later we just display the sql sentences to be executed instead of actually running the upgrade process. Those senteces were analized by dba team and executed. They encounter that several sentences (in a range) were executed without problem.

We tray to map those sentences to admin/schema database and notice that the index in the array $g_upgrade is record in a table.
We also notice the correlation between "# Release marker: X.Y.Z" and the index in the array..

So we decide to execute the sql sentences that execute normally, set the value in the table to state the last executed sentence, and then run the upgrade process from the application /admin/install.php

That runs smmothly.

After that, we finished with a DB with tables in different store engines and collations. The DBA team correct that and now we are OK.

I hope this could help others.
Post Reply