----- Janne Peltonen <janne.peltonen@xxxxxxxxxxx> wrote: > Hi! > > 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. And if you don't have multiple Cyrus instances accessing the same same message store, why use GFS? GFS adds a lot of inter-node locking overhead. > Now the workings of the replication code aren't completely clear to me. > It can do things like collapse multiple mailbox changes into one and so > on. But is it in some way dependent on there being just one cyrus-master > controlled group of imapd processes to ensure that all changes to the > spool (and meta) get replicated? Or does the replication code infer the > synchronization commands from changes it sees on the spool, independent > of the ongoing imap connections? That is, do I have to have n replica > nodes, one for each cluster node? Or don't I? The Cyrus master builds a replication log as changes are made by imapd, pop3d, and lmtpd. The log contents are pushed to the replica. The master and replica both have copies of all data, within independent message stores. So one replica per master. > Thanks for any answers Tom ---- 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
