Zimbra: upgrade 6.0.10 to 7.0.0

Finally something has been done about the performance issues in the Zimbra collaberation suite. Now you don't have to have to disable scripts and adjust parameters to get a normal CPU performance. Take a look at the performance graphs of my zimbra virtual machine. The upgrade took place on the 7th of Februari 2011 (the releasedate) and no additional configuration changes concerning the performance have been made.

Graphs supplied by 360° Viewpoint (Nagios and Centreon).

MySQL table upgrades are not automatically run during the upgrade to 7.0. After the upgrade I executed the script /opt/zimbra/libexec/scripts/migrate20100913-Mysql51. It says so in the release notes, only I forgot to read it. So I did this becasue I received an automated e-mail from Zimbra after a scheduled database integrity check which failed:

Database errors found.
/opt/zimbra/mysql/bin/mysqlcheck –defaults-file=/opt/zimbra/conf/my.cnf -S /opt/zimbra/db/mysql.sock -A -C -s -u root –password=********************
mboxgroup1.appointment
 error    : Table upgrade required. Please do "REPAIR TABLE `appointment`" or dump/reload to fix it!
 mboxgroup1.data_source_item
 error    : Table upgrade required. Please do "REPAIR TABLE `data_source_item`" or dump/reload to fix it!
 mboxgroup1.imap_folder
….. and so on.

After running this script there are still some errors that are not solved yet:

Database errors found.
mysql.general_log
 Error    : You can't use locks with log tables.
 mysql.slow_log
 Error    : You can't use locks with log tables.

The new features come in many. Three examples:

• social networks like twitter and facebook are completely integrated
• the agenda offers more features like checking the availability of others when planning an appointment
• users can restore items that are deleted from the trashcan themselves

Everything runs smoothly in my FC11 64bit VM. Conclusion: do the upgrade!

Update 22 March 2011:
Memory usage is higher than with 6.x and as a result to prevent swapping I restart my zimbra server every day via the crontab. This saves me the costs of expanding the 2GB memory I committed to the Virtual Server.

Update 11 March 2011:
I upgraded to 7.0.1 and the process went smoothly.