Unexpected database recovery

[Rob Siemborski]

On Wed, 19 Nov 2003, Richard Gilbert wrote:

> 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[9697]: [...] process started
> Nov 19 05:00:11 impala ctl_cyrusdb[9698]: [...] recovering cyrus databases
> Nov 19 05:05:10 impala ctl_mboxlist[10854]: [...] skiplist: recovered
> 	/var/imap/mailboxes.db (61786 records, 4909724 bytes) in 9 seconds
> Nov 19 08:38:54 impala ctl_cyrusdb[9698]: [...] done recovering cyrus databases
> Nov 19 08:38:54 impala master[9697]: [...] ready for work
> Nov 19 08:38:54 impala ctl_cyrusdb[22419]: [...] 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.

The lock_flock patch has serious performance implications (namely, if you
don't get a lock on the first try, you have to wait an entire second to
try again), and given that this happened just after you changed the
locking mechanism, it seems suspicious.

However, I can't think what would be causing the recovery process to lose
at getting the locks it needs, so (nothing else should be running at
that time)....

FWIW, database recovery is necessary every time you restart cyrus to
ensure that the databases are in a consistant state before data is served.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper