Wesley et al, > -----Original Message----- > From: Wesley Craig [mailto:wes@xxxxxxxxx] > Sent: Thursday, 23 November 2006 1:17 PM > To: Sarah Walters > Cc: info-cyrus@xxxxxxxxxxxxxxxxxxxx > 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 ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
