A few days ago, our clients had problems with their on-premise mail server deployment. Their Zimbra services are down and mailbox service could not restart. After a quick check, it turns out that one of the disk partitions is full because there is an incorrect mounting disk. As it uses incorrect folder/disk, backup process filling up primary partition instead of external disk.
To deal with this problem, I move some unimportant data from primary partition and release quite enough free space and trying to restart services. LDAP, mta and others services are up but mailbox services won’t. More detailed checking on log shows that the MariaDB database services cannot run. Inspecting /opt/zimbra/log/mysql_error.log log file, there is an error message: “Can’t init tc log”.
181022 22:35:42 mysqld_safe mysqld from pid file /opt/zimbra/log/mysql.pid ended
201-10-10 22:35:42 140144607115136 [Note] InnoDB: 128 rollback segment (s) are active.
201-10-10 22:35:42 140144607115136 [Note] InnoDB: Waiting for purge to start
201-10-10 22:35:43 140144607115136 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.36-82.0 started; log sequence number 6803622123
201-10-10 22:35:43 140141100709632 [Note] InnoDB: Dumping buffer pool (s) not yet started
2018-10-22 22:35:43 140144607115136 [Note] The plugin ‘FEEDBACK’ is disabled.
2018-10-22 22:35:43 140144607115136 [Note] Recovering after a crash using tc.log
2018-10-22 22:35:43 140144607115136 [ERROR] Can’t init tc log
2018-10-22 22:35:43 140144607115136 [ERROR] Aborting
181022 22:35:45 mysqld_safe mysqld from pid file /opt/zimbra/log/mysql.pid ended
As the problem related to tc.log, some reference on Google search recommends an easy resolution. Simply delete or move (I would rather choose the moving process for the sake of precaution) the file /opt/zimbra/db/data/tc.log to a different location and then restart the database services. Database services turn out OK and the next process is to restarting Zimbra services.
One more important step is to ensure the preventive checks run even better, in the sense that an early warning of an almost full disk should be escalated earlier.
