ZCS 8.0.6 to 8.7.0 on Ubuntu 12.04 fails with MySQL error - Table 'mboxgroup22/#sql-ib6597-150967725' already exists

[6125amartin]

Hello,

I am upgrading Ubuntu 12.04 from ZCS 8.0.6 to ZCS 8.7.0. I've practiced this upgrade several times and have never encountered this error until now:
<pre>Sat Aug 27 02:45:45 2016: Migrating mboxgroup20. This can take a substantial amount of time...
Sat Aug 27 02:46:03 2016: done.

Sat Aug 27 02:46:03 2016: Migrating mboxgroup21. This can take a substantial amount of time...
Sat Aug 27 02:47:01 2016: done.

Sat Aug 27 02:47:01 2016: Migrating mboxgroup22. This can take a substantial amount of time...
ERROR 1050 (42S01) at line 1: Table 'mboxgroup22/#sql-ib6597-150967725' already exists
Sat Aug 27 02:48:15 2016: Error while running '/opt/zimbra/bin/mysql --user=zimbra --password=XXXXX --database=zimbra --batch --skip-column-names'.
Script failed with code 256: - exiting
UPGRADE FAILED - exiting.
</pre>

How can I bypass this error and keep going. Which script is this command found in? I see many results for "Error while running" while grepping through /opt/zimbra/libexec/scripts. I'd like to be able to restart the upgrade but skip installing the packages and go right to this script part.

[6125amartin]

I've narrowed down the problem script to /opt/zimbra/libexec/scripts/migrate20140319-MailItemPrevFolders.pl. I can't see any way around this other than to comment out these lines from the runSql functoin in /opt/zimbra/libexec/scripts/Migrate.pm:

Code: Select all

#    Migrate::myquit(1, "Error while running '$command'.")
#      if ($? != 0);

This will make it ignore MySQL errors and continue. I guess I'll just monitor the output for errors

[hillman]

I encountered the same error trying to upgrade our mailbox servers on RHEL6 from 8.0.7 to 8.7 this week. However, when we did a test upgrade to 8.6 last February, it worked fine. Since the step that's failing was introduced prior to 8.6, that suggests that it isn't the step itself that's the issue, but perhaps the difference between the version of MariaDB it's using in 8.7 and in 8.6 (vs MySQL in 8.0.6)

I am currently rerunning the upgrade on one of our mailbox servers, this time first upgrading to 8.6 and if that succeeds, doing an upgrade from 8.6 to 8.7. I'll let you know how it goes.

Note that I don't expect you'll just be able to comment out the error handling. Even though that may allow the script to run, you'd end up with broken schemas on some of your database tables.

Unfortunately it's also not possible to continue the upgrade from where it broke without extensively modifying the upgrade scripts. Since some of the tables have already had their schema modified, you'd have to rewrite it to only try and change the schema on tables that haven't been changed yet. I'd suggest you restore back to 8.0.6 and try again once the root cause has been identified.

[6125amartin]

Thanks for the reply - I'm glad to hear someone else has heard of this problem. What I ended up doing was commenting out those two lines I mentioned in Migrate.pm and then re-running zmsetup.pl. You're correct in that some of the databases already had their schema altered, and they correctly failed when they reached that same part of the upgrade (because the columns already existed now). However this was fine, and the upgrade then continued through performing the schema update on the rest of the databases successfully. I carefully reviewed the output for any other MySQL errors (the actual raw MySQL error still seems to be logged irrespective of the lines that I modified, so I could easily look for those).

After the upgrade, I manually compared the list of columns in mboxgroup22 with another database that had succeeded to verify that all of the correct columns were present. Moreover, I compared the Data Length, Index Length, and Row count with a mysqldump of mboxgroup22 that I had taken from before the upgrade. Something that was concerning is that the number of rows differed from before and after the upgrade (e.g. in mail_item), but when I went and checked another mbox that was not affected by this problem, it had a similar difference in number of rows as well. It seems like the upgrade may have moved some of that data around to other mboxes or purged out old entries?

[schachi-mdf]

I had the same issue on ubunut12.04 to update version 8.7.3
My solution was update as first to 8.6.0 (with last version mysql) and after successfully update to finally version. That works for me without mysql errors.
In 8.6.0 there is the same perl update script /opt/zimbra/libexec/scripts/migrate20140319-MailItemPrevFolders.pl

Migrating mboxgroup49. This can take a substantial amount of time...
ERROR 1060 (42S21) at line 1: Duplicate column name 'prev_folders'
Error while running '/opt/zimbra/bin/mysql --user=zimbra --password=xxx. --database=zimbra --batch --skip-column-names'.

[6125amartin]

I had the same issue on ubunut12.04 to update version 8.7.3
My solution was update as first to 8.6.0 (with last version mysql) and after successfully update to finally version. That works for me without mysql errors.
In 8.6.0 there is the same perl update script /opt/zimbra/libexec/scripts/migrate20140319-MailItemPrevFolders.pl

Migrating mboxgroup49. This can take a substantial amount of time...
ERROR 1060 (42S21) at line 1: Duplicate column name 'prev_folders'
Error while running '/opt/zimbra/bin/mysql --user=zimbra --password=xxx. --database=zimbra --batch --skip-column-names'.

Thanks for the additional feedback on this issue