[SOLVED] Upgrade from 4.0.5

[digitaltendencies]

I'm going to be upgrading from 4.0.5 to the latest release tonight.

My plan involves going from 4.0.5 -> 4.5.11 -> 5.0.16

Any problems with doing it that way?
Any known issues I might run into?
Any helpful tips?

I do plan to backup and test it out after every upgrade to verify it is working and that I have a good backup to work from.

Thanks!

[phoenix]

Originally Posted by digitaltendencies

I'm going to be upgrading from 4.0.5 to the latest release tonight.

My plan involves going from 4.0.5 -> 4.5.11 -> 5.0.16

That would be the correct route and there shouldn't be any problems. Check the release notes for those versions and do a quick search of the forums for any problems that people may have encountered.

Originally Posted by digitaltendencies

I do plan to backup and test it out after every upgrade to verify it is working and that I have a good backup to work from.

That's sounds like a good plan. Good luck and let us know how you get on.

[digitaltendencies]

I was able to upgrade to 4.5.11 without any problems.
Unfortunately it took about 7 hours.
Any tips for speeding it up?
Server has 2x dual core Xeon's running at 3.0ghz and 8GB RAM.

Hopefully I can finish the upgrade to the latest version next weekend.

Current Version: Release 4.5.11_GA_1751.RHEL4_64_20080128132756 RHEL4_64 FOSS edition

Thanks!

[flums]

Did you do the database check, and was it that what took so long time? Did you pay attension for what kind of process that was timeconsuming? For myself, i notice that this is the only thing that can take some time, depending on the numbers of users you have, aswell as your hardware.

Sometimes i skip this test, between small releases, but the big upgrades you do, it migth be smart to have it.

[phoenix]

Originally Posted by digitaltendencies

I was able to upgrade to 4.5.11 without any problems.
Unfortunately it took about 7 hours.
Any tips for speeding it up?
Server has 2x dual core Xeon's running at 3.0ghz and 8GB RAM.

There isn't really much you can do if you run the integrity check and have a large db. Performance would also depend on the HD you have Zimbra installed on, RAID 10 is usually the best. As flums has hinted, I'd recommend you do the integrity check for such a large jump in version numbers.

Originally Posted by digitaltendencies

Hopefully I can finish the upgrade to the latest version next weekend.

Current Version: Release 4.5.11_GA_1751.RHEL4_64_20080128132756 RHEL4_64 FOSS edition

Thanks!

Glad the upgrade went OK.

[mmorse]

FYI for the future: The installer runs zmdbintegrityreport, which can be run without downtime before you start the upgrade.

[flums]

Nice tips mmorse!

[digitaltendencies]

The longest parts were making the DB Schema version changes.

There's about 1500 users setup on the system with about 85GB of email in the message store. Alot of our users use the web client to send/receive email.

I'm not too sure of the drive configuration as I did not originally set it up and have never had a chance to go into that part of the configuration.
Hopefully in a couple months I get to move it onto a brand new server that I have setup.

[mmorse]

There's a few other things you could do, like migratePreWidenSizeColumns.pl:

Originally Posted by old release notes

Schema version 50 introduced in 5.0.3 GA widens the column size of the revision table in the ZCS database. This script can take a significant amount of time on large systems.
If you do not run this script before you upgrade, the column size of the revision table is widened as part of the ZCS upgrade, but this can increase the time it takes to upgrade.

Run this script on all Zimbra mailbox servers.
1. Before you begin, stop all ZCS processes except mysql
2. Go to the directory where migratePreWidenSizeColumns.pl is located, /opt/zimbra/libexc/scripts/.
3. Run migratePreWidenSizeColumns.pl -g
If you run this without options, you will see how many mailbox groups need to be upgraded and you can set the number of accounts to be processed at a time.

Originally Posted by 5.0.16 release notes

If you are upgrading from 4.5.11 through 5.0.2 to 5.0.x the process to prepare and then upgrade would be as follows. Doing steps 2 before you upgrade will shorten the actual time it takes to upgrade.

1. Download 5.0.x.

2. Run the migratePreWidenSizeColumns.pl to shorten the time it takes to upgrade. (optional)

3. upgrade to 5.0.x. Note: If you do not run migratePreWidenSizeColumns.pl, the script is automatically run during the upgrade to 5.0.x.

(Incase someone in the future reads this thread, check if this applies to you: LDAP Replicas 4.5.x to 5.0.x - Zimbra :: Wiki)

Directions on how to get the widen script & details to running it:

Originally Posted by mlo in bug 33609

This is regarding the "Upgrading from 5.0.2 or earlier" section on p.36 of the 5.0.11 release notes.

1. We should explain that the file can be obtained from /opt/zimbra/libexec/scripts on a test 5.0.3+ install or extracted from the 5.0.3+ bits. For example, to extract from 5.0.11, the following commands can
be used:

# cd packages directory where you've expanded the 5.0.11 tarball
# rpm2cpio zimbra-core-5.0.11_GA_2696.RHEL4-20081117013729.i386.rpm | cpio -vid ./opt/zimbra/libexec/scripts/migratePreWidenSizeColumns.pl
# mv opt/zimbra/libexec/scripts/migratePreWidenSizeColumns.pl /opt/zimbra/libexec/scripts

2. The step about stopping all ZCS processes except mysql is correct.
# su - zimbra
$ zmcontrol stop
$ mysql.server start

3. As the zimbra user, go to the /opt/zimbra/libexec/scripts directory. For example,

# su - zimbra
$ cd /opt/zimbra/libexec/scripts

Note: There's a typo in the path in this section as well as the previous section about migrateLargeMetadata.pl. "libexc" should be "libexec".

4. Run the script with perl, i.e.

$ perl ./migratePreWidenSizeColumns.pl -g [all | N groups]

5. Remove the following comment:
"If you run this without options, you will see how many mailbox groups need to be upgraded and you can set the number of accounts to be processed at
a time."

Note: the -g parameter is not optional. You'll get an error if you don't specify -g. If you specify N groups to migrate, the script will update the first N groups it finds. It won't update a group that has already been updated.

---

Another interesting tip for later: Optimizing 50 to 60 LDAP upgrade - Zimbra :: Wiki

[digitaltendencies]

I finally finished updating to 5.0.16
This major update went quickly and only took about an hour and a half.

I had noticed the graphs were not updating since I upgraded to 5.0.16.
I went through all the tables from the Zimbra Logger mysql database.
The table 'mta' was showing this error when I checked it: Table 'mta' is marked as crashed and last (automatic?) repair failed
I attempted to repair it with 'repair table mta;' but that failed to fix it.
I checked this file mta.frm and noticed it had not been modified since December 2006

Here's how I fixed it.

1. Stopped zimbra logger service with: zmloggerctl stop
2. Ran /opt/zimbra/logger/mysql/bin/myisamchk /opt/zimbra/logger/db/data/zimbra_logger/mta.MYI
This recommended using the -r or the -o option to repair.
3. Ran /opt/zimbra/logger/mysql/bin/myisamchk -B -r /opt/zimbra/logger/db/data/zimbra_logger/mta.MYI
4. Started zimbra logger service with: zmloggerctl start
5. Ran: /opt/zimbra/bin/logmysql zimbra_logger
6. Ran: check table mta;
It still showed it needed to be repaired.
7. Ran: repair table mta;
8. Ran this again: check table mta;

After this it showed status of OK again.
Now it shows the mta.frm with a new modified date/time.

Waited until the next time zmgengraphs ran and than verified the statistic graphs were being created again.

It's working great, so glad to finally be running a recent version!
Thanks for all the help!