Cyrus IMAP and MySQL mailboxes (Building load-balancing cluster)

[Sarah Walters]

Wesley et al, 

> -----Original Message-----
> From: Wesley Craig [mailto:wes at umich.edu] 
> Sent: Thursday, 23 November 2006 1:17 PM
> To: Sarah Walters
> Cc: info-cyrus at lists.andrew.cmu.edu
> Subject: Re: Cyrus IMAP and MySQL mailboxes (Building 
> load-balancing cluster)
> 
> On 22 Nov 2006, at 19:10, Sarah Walters wrote:
> > Only a single machine can have write privileges to the mailboxes  
> > database at a time.
> 
> Actually, only a single process can be writing to a mailboxes  
> database at a time.

I think you misinterpreted me. I said write "privileges". All the
processes have that privilege, they just respect the locks.
 
> > Then, assuming the database is closed between changes (can a  
> > developer please confirm whether it is kept open by master 
> or not?)  
> > you should be able to run multiple IMAP servers over the same  
> > filesystem stored on a NAS (network-attached storage, as 
> opposed to  
> > SAN).
> 
> I'm not sure why closing the database between changes might be  
> important.  Multiple imapd processes on backends all access thesame  
> mailboxes database.  Writes are serialized with locks.  If a network  
> filesystem implements these locks correctly, there's no reason why  
> you couldn't run multiple "backends" against a single redundant  
> filesystem.  There are a number of examples of people doing this.

Because database locks are an operating system or program-dependant
feature and don't operate over NFS. It's built into the BDB library.
Filesystem locks are on *files*. Obviously it would be possible to
do exclusive write locks over NFS as required and otherwise just
have the file open. The issue then becomes one of operating system
caching. You would need to label the filesystem as volatile so that
there is no local caching of the disk, or you would risk database
changes made on one host being overwritten when the next host writes
to the database. You are also at risk of not seeing changes as they
are made. I haven't looked into this lately, so it may be the case
that no caching is the default for NFSv4. Closing and re-opening
the file is a reliable way to ensure that the file is re-read in its
entirety. Of course, there's a performance hit there. That is an
argument for a database server that can do entry-by-entry locking
of the mailboxes database as requested by networked clients. Which
takes us right back to the "MySQL" angle on this conversation! While
I wouldn't want to see the actual mail stored in MySQL, you could
make an argument for storing the mailboxes database in that way.
There are lighter-weight solutions that would carry all the needed
functionality so you wouldn't need MySQL. Of course, then you need
a cluster for the database server too!

This is an interesting discussion, I'm keen for comments on the
above.

Regards,
Sarah Walters