First,
i have upgraded to the Last Version 7.2.2 before i have started the upgrade to 8.0.2
I don't know exactly but i think i started on this machine with Version 6 of Zimbra and did continously upgrade to actual Version.
I did the changes in /etc/profile, checked the manual and did the needed steps.
After starting and waiting a while, the setup for 8.0.2 stops and gave an error:
Code:
Tue Jan 8 18:21:06 2013: Updating DB schema version from 65 to 90.
Running /opt/zimbra/libexec/scripts/migrate20120410-BlobLocator.pl
Tue Jan 8 18:21:08 2013: Verified schema version 90.
ERROR 1025 (HY000) at line 2: Error on rename of './mboxgroup1/mail_item' to './mboxgroup1/#sql2-2649-7a' (errno: 152)
Tue Jan 8 18:21:15 2013: Error while running '/opt/zimbra/bin/mysql --user=zimbra --password=X4qvkfAkKlJ1Pu2XmGmVPitbDb --database=zimbra --batch --skip-column-names'.
Script failed with code 256: - exiting
UPGRADE FAILED - exiting.
I searched for a while and detected that i missed something from my manual. I thought i had not to do the db Update because im using Version 7, but then i read we have to do it when your basic installation has began before Version 7. So i started the DB Udate, that tooks a little bit and then I tried to run the setup again, but this results in the next error:
Code:
Schema upgrade required from version 90 to 92.
Running /opt/zimbra/libexec/scripts/migrate20120410-BlobLocator.pl
Tue Jan 8 18:59:08 2013: Verified schema version 90.
ERROR 1091 (42000) at line 1: Can't DROP 'i_volume_id'; check that column/key exists
Tue Jan 8 18:59:15 2013: Error while running '/opt/zimbra/bin/mysql --user=zimbra --password=X4qvkfAkKlJ1Pu2XmGmVPitbDb --database=zimbra --batch --skip-column-names'.
Script failed with code 256: - exiting
UPGRADE FAILED - exiting.
I changed the table, altered it to add the index that the script wants to delete, run the setup again but this doesn't helps because i get the error before.
After some hours i found where the problem is related and analyse some parts from the database upgrade script where all tables should be altered.
A long research later, i found no actual hint or similar problem that was solved, i have seen that something is "wrong" in my first database mboxgroup1. Because in the other databases are everything ok. The needed Index, Table etc exists. That is not so in mboxgroup1.
I make a try to start setup with a new install log on /opt/zimbra/.install_history - but this should be never done when DB Errors occurs. Because they don't fix it and believe in an working installation. I reverted it back - thats the wrong hint.
I do following modifications on mboxgroup1 before i start the Upgrade script manualy. I know that i reverting back some changes that are already made but this is the only way for my to run the script again.
Code:
ALTER TABLE mboxgroup1.mail_item ADD INDEX i_volume_id (id, mailbox_id);
ALTER TABLE mboxgroup1.mail_item ADD INDEX fk_mail_item_volume_id (id, mailbox_id);
ALTER TABLE mboxgroup1.mail_item_dumpster ADD INDEX i_volume_id (id, mailbox_id);
ALTER TABLE mboxgroup1.mail_item_dumpster ADD INDEX fk_mail_item_dumpster_volume_id (id, mailbox_id);
ALTER TABLE mboxgroup1.mail_item_dumpster ADD CONSTRAINT fk_mail_item_dumpster_volume_id FOREIGN KEY (mailbox_id) references tombstone (mailbox_id);
ALTER TABLE mboxgroup1.mail_item CHANGE locator volume_id INT(200);
ALTER TABLE mboxgroup1.mail_item_dumpster CHANGE locator volume_id INT(200);
ALTER TABLE mboxgroup1.revision CHANGE locator volume_id INT(102);
ALTER TABLE mboxgroup1.revision_dumpster CHANGE locator volume_id INT(102);
After that i started to change the script, because it doesn't work actually. Its very easy i uncommented the procedure that runs to start the failover procedure that seems to be more stable because of checking the table first before deleting something that does not exists:
(we can find some DB Update Logging here /opt/zimbra/log/myslow.log)
/opt/zimbra/libexec/scripts/migrate20120410-BlobLocator.pl
Code:
sub doIt() {
foreach my $group (Migrate::getMailboxGroups()) {
my $volumeIdInt = (Migrate::runSql("show columns from $group.mail_item where Field = 'volume_id' and Type like '%int%';"))[0];
# if (length $volumeIdInt == 0) {
#existing install using external store; volume_id was manually altered
Migrate::logSql("$group.mail_item.volume_id is not currently an int; this installation probably altered it for older StoreManager implementation");
fixVolumeId($group);
# } else {
# #standard migration
# Migrate::logSql("Adding blob locator columns in $group");
# alterVolumeId($group);
# }
}
}
After i have done these modifications, i do the following steps:
cd /opt/zimbra/libexec/scripts
perl migrate20120410-BlobLocator.pl
this gave the following without any errors
Tue Jan 8 21:51:44 2013: Verified schema version 90.
Tue Jan 8 21:51:44 2013: Updating DB schema version from 90 to 91.
After that i ran the setup again with success, except
> ERROR 1133 (42000) at line 3: Can't find any matching row in the user table
but i think this should be no issue at all. Or does someone knows more about this line?
Code:
Restoring existing configuration file from /opt/zimbra/.saveconfig/localconfig.xml...done
Operations logged to /tmp/zmsetup.01082013-221337.log
Upgrading from 7.2.2_GA_2852 to 8.0.2_GA_5569
Stopping zimbra services...done.
Starting mysql...done.
This appears to be 7.2.2_GA
Checking ldap status...not running.
Running zmldapapplyldif...done.
Checking ldap status...not running.
Starting ldap...done.
Checking ldap status...already running.
Running mysql_upgrade...done.
Schema upgrade required from version 91 to 92.
Running /opt/zimbra/libexec/scripts/migrate20121009-VolumeBlobs.pl
Tue Jan 8 22:14:08 2013: Verified schema version 91.
Tue Jan 8 22:14:11 2013: Verified schema version 91.
Tue Jan 8 22:14:11 2013: Updating DB schema version from 91 to 92.
Stopping mysql...done.
Updating from 8.0.0_BETA1
Adding dynamic group configuration
Stopping ldap...done.
Checking ldap status...not running.
Running zmldapapplyldif...done.
Checking ldap status...not running.
Starting ldap...done.
Stopping ldap...done.
Checking ldap status...not running.
Running zmldapapplyldif...done.
Checking ldap status...not running.
Starting ldap...done.
Updating from 8.0.0_BETA2
Starting mysql...done.
ERROR 1133 (42000) at line 3: Can't find any matching row in the user table
Stopping mysql...done.
Updating from 8.0.0_BETA3
Updating from 8.0.0_BETA4
Stopping ldap...done.
Checking ldap status...not running.
Running zmldapapplyldif...done.
Checking ldap status...not running.
Starting ldap...done.
Stopping ldap...done.
Checking ldap status...not running.
Running zmldapapplyldif...done.
Checking ldap status...not running.
Starting ldap...done.
Stopping ldap...done.
Checking ldap status...not running.
Running zmldapapplyldif...done.
Checking ldap status...not running.
Starting ldap...done.
Stopping ldap...done.
Checking ldap status...not running.
Running zmldapapplyldif...done.
Checking ldap status...not running.
Starting ldap...done.
Updating from 8.0.0_BETA5
Updating from 8.0.0_GA
Updating from 8.0.1_GA
Updating from 8.0.2_GA
Updating global config and COS's with attributes introduced after 7.2.2_GA...done.
Stopping ldap...done.
Upgrade complete.
Running zmldapapplyldif...done.
Checking ldap status....not running.
Starting ldap...done.
Setting defaults.../opt/zimbra/postfix/sbin/postconf: warning: inet_protocols: disabling IPv6 name/address support: Address family not supported by protocol
done.
Setting defaults from existing config...done.
Checking for port conflicts
Setting defaults from ldap...done.
Saving config in /opt/zimbra/config.26679...done.
Operations logged to /tmp/zmsetup.01082013-221337.log
Setting local config values...done.
Initializing core config...Setting up CA...done.
Deploying CA to /opt/zimbra/conf/ca ...done.
Setting replication password...done.
Setting Postfix password...done.
Setting amavis password...done.
Setting nginx password...done.
.
.
.
Configuration complete - press return
This upgrade takes 12 hours with fixing. I thought zimbra will be more stable since the Version 4 and 5 gave a lot of errors for every update, but now im not sure ....
I have never changed something on my db or installation, so this problem must be reproducable with old Installation and continously Updates. But i think the zimbra team are not testing installations that is going to update each version since the latest three Releases. Otherwise i can't imagine why a database has the wrong settings.
I hope someone could need this and maybe someone from zimbra could confirm that there is no missing update on my DB.