On Wed, Oct 21, 2009 at 9:20 PM, Rob Mueller <robm@xxxxxxxxxxx> wrote: ... > The difference between "in theory this would work" and the practice of > actually doing it are huge. Basically it works only if you are 100% sure > that only one side is ever being accessed at a time. eg. IMAP/POP/LMTP/etc. ... > In other words, DON'T DO THIS. > > Rob What are the particular bits that could conflict and have undesirable results? Metadata, messages, entire mailboxes? In this hypothetical active/active configuration, what exactly what could an IMAP client potentially do to create undesirable results? Would it be a huge undertaking to timestamp data that is to be replicated to another Cyrus daemon for the receiving Cyrus daemon to know which conflicting pieces of data to drop in favor of newer data? Right now I have a client who needs 130 or so users on a private mail server and has two cheap 1U Dell servers to work with. Ideally they are to be put in physically distanced data-centers for redundancy to one another. Combined with the hypothetical replication of timestamped data describe above, wouldn't setting the fqdn imap.example.com to resolve two IP addresses so users' IMAP clients can fall back should an IMAP storage server be unavailable (with at least the most recent data replication of any kind is able to provide) make for a much simpler and more elegant solution than DRBD, clustered filesystems, or introducing more machines just for load balancing / resolving to an available IMAP daemon? Also, wouldn't timestamps also hypothetically resolve the inevitable split-brain situations clients would create? ---- 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
