Clustering and replication

Simon Matter simon.matter at invoca.ch
Fri Jan 26 16:22:29 EST 2007


>
> ----- Wesley Craig <wes at umich.edu> wrote:
>> On Jan 26, 2007, at 3:07 AM, Tom Samplonius wrote:
>> > ----- Janne Peltonen <janne.peltonen at helsinki.fi> wrote:
>> >> As a part of our clustering Cyrus system, we are considering using
>> >> replication to prevent a catastrophe in case the volume used by the
>> >> cluster gets corrupted. (We'll have n nodes each accessing the
>> >> same GFS,
>> >> and yes, it can be done, see previous threads on the subject.)
>> >
>> >   I really doubt this.  Even if GFS works the way it says it does,
>>
>> > Cyrus does not expect to see other instances modifying the same
>> > message, and does not lock against itself.
>>
>> Yes it does.  How else do you suppose two users reading the same
>> shared mailbox might work?  They aren't all running through one
>> imapd.
>
>   Within a single server, this works, but Cyrus is not aware of other
> imapd's that are running on other servers.
>
>   It just isn't the imapd, but the sharing of the database files too.  Can
> you have writers to a BerkeleyDB database on different servers?  I don't
> think this works on NFS, let alone GFS.  Getting mmap() to over GFS is a
> hard problem, and would have to be very slow if it maintained the same
> semantics as a file on a local disk.

Believe it or not, it works and has been confirmed by several peoples on
the list using different shared filesystems (VeritasFS and Tru64 comes to
mind). In one thing you are right, it doesn't work with BerkeleyDB. Just
switch all your BDB's to skiplist and it works. This has really been
discussed on the list again and again and isn't it nice to know that
clustering cyrus that way works?

Simon


More information about the Info-cyrus mailing list