Unexpected database recovery
R.Gilbert at sheffield.ac.uk
Wed Nov 19 10:11:52 EST 2003
Yesterday I applied John Wade's lock_flock patch to the version of Cyrus
impad we were already running, i.e. 2.1.14 and rebuilt and reinstalled.
cyrus-imapd was restarted at 5 am this morning to minimise inconvenience
to users. I was surprised to find that the system was unavailable until
about 08:39 because of database recovery.
Nov 19 05:00:11 impala master: [...] process started
Nov 19 05:00:11 impala ctl_cyrusdb: [...] recovering cyrus databases
Nov 19 05:05:10 impala ctl_mboxlist: [...] skiplist: recovered
/var/imap/mailboxes.db (61786 records, 4909724 bytes) in 9 seconds
Nov 19 08:38:54 impala ctl_cyrusdb: [...] done recovering cyrus databases
Nov 19 08:38:54 impala master: [...] ready for work
Nov 19 08:38:54 impala ctl_cyrusdb: [...] checkpointing cyrus databases
My question is: was this database recovery caused by the system realising
that the software had changed, or was it a complete coincidence? We
restart the system three times a week at 5am and this has not happenned
before, as far as I know.
It's a bit early to say, but the number of lockers in the "DBERROR db3: N
lockers" is staying very low today -- rarely anything other than 2. I'm
touching wood and crossing my fingers even as I type!
Corporate Information and Computing Services
University of Sheffield, Sheffield, S10 2TN, UK
Phone: +44 114 222 3028 Fax: +44 114 222 3040
More information about the Info-cyrus