Zimbra: место на диске и протухшие сообщения

Я уже упоминал о проблемах с зимброй: в каталогах хранилища скапливаются древние файлы сообщений, которые давным давно удалены. До поры до времени я чистил их вручную, не зная, не аукнется ли это мне проблемами с доступом к п/я и т.п.
Оказалось, не всё так плохо. Хотя и не очень хорошо. Совершенно случайно выяснил, что это задокументированный баг, который нельзя устранить, но с последствиями которого можно бороться штатными средствами.
Итак, информация в зимбре хранится в более чем сотне БД MySQL. То есть, есть 100 штук баз mailboxgroupXXX, где XXX от 1 до 100, и несколько вспомогательных. Блобы, то есть, файлы почтовых сообщений, хранятся отдельно в "кластеризованном хранилище", и они-то и вызывают головную боль: движок MySQL не освобождает место, занятое ими.
В статье рассмотрено несколько вариантов, надо будет попробовать, а то совсем уже тоскливо.

Под катом текст статьи.

Теперь по месту на диске.
Обнаружил, что пропала или очень неактуальна статистика по использованию дискового пространства. Оказалось, что сам виноват: раньше она обновлялась с интервалом в 10 минут и заваливала меня сообщениями об исчерпании места, после чего я увеличил интервал до 5.5 часов. За что и поплатился.
В рабочем порядке уменьшил тот интервал до 3600 секунд, посмотрим, не полегчает ли сборщику статистики

Purpose

After deleting data on the Zimbra DB (MySQL/MariaDB) through account deletion or moving accounts to a different mailbox server using zmmboxmove (or older zmmailboxmove with purge), we're not seeing disk space being released at /opt/zimbra/db/data. This could be a problem on servers with a very high number of accounts that were deleted or moved.

Resolution

If we delete data from MySQL/MariaDB, there is no way to release disk space unless we use InnoDB's innodb_file_per_table feature which is enabled by default with Zimbra. What is important to notice is that MySQL/MariaDB does not release disk space automatically, so we will always need to run the command "OPTIMIZE TABLE" for every table. This should not cause any problems with Zimbra, but we have to be careful about a few things:

• MySQL/MariaDB locks the table during the time "OPTIMIZE TABLE" is running so we recommend you perform this operation on a scheduled downtime (stop mailboxd process and manually start the DB for running this operation). Do one table at a time. This may take a considerable time for big databases on busy environments. We don't want mailboxd running when you do this operation.
• For InnoDB tables, "OPTIMIZE TABLE" is mapped to "ALTER TABLE", which rebuilds the table to update index statistics and free unused space in the clustered index. So the message "Table does not support optimize, doing recreate + analyze instead" is normal.
• During this process, MariaDB might need to create a temporary file that will require additional temporary disk space on the partition, so you can end up in the situation where you were have no available space left and the process will abort. This can be an issue since we are trying to release space. A possible solution is to perform a db dump/reload instead.
• Please run this command using screen or any other tool that will not abort the operation if your terminal connection suddenly closes due to some error or network timeout.

Additional Content

• http://dev.mysql.com/doc/refman/5.5/en/optimize-table.html (OPTIMIZE TABLE Syntax)
• http://stackoverflow.com/questions/1270944/mysql-innodb-not-releasing-disk-space-after-deleting-data-rows-from-table (MySQL innodb not releasing disk space after deleting data rows from table)