Cyrus murder ( IMAP Aggregator )
richard at softwaredev.nl
Fri Feb 12 05:56:50 EST 2010
Thank you for your info.
It gives me a clearer idea how it works.
The multiple front-ends with the imap aggregator would give a huge
advantage for expanding when more resources are needed, so this is an
option i would like to use.
The only issue i can think of is backups of the mailboxes.
The planning is to have all the mailbox storage on a SAN.
My idea is to have 1 replication slave which does the replication of all
the other backend nodes.
This replication slave uses an other SAN as storage.
This way it should be easy to handle if the SAN dies or the filesystem
gets corrupted from one of the backends.
Each backend will replicate it's data to the replication slave on an own
So that if the 'disk' on the main SAN is dead i can connect the backend to
the other SAN.
I hope this still makes any sense :-)
Is this even a good idea?
Thanks for your time.
On Thu, 11 Feb 2010 10:25:26 -0500, Wesley Craig <wes at umich.edu> wrote:
> On 10 Feb 2010, at 16:54, Richard Pijnenburg wrote:
>> How do the backends deceide who services which mailbox?
> The admin decides, more or less, as you provision mailboxes.
>> And what happens if one of those backends dies?
> The mailboxes on that backend are inaccessible. The rest of the
> cluster continues to operate as normal, tho your mail queues might be
> negatively impacted. You might want to investigate replication, for
> how to recover from a failed backend.
>> If I understand also correct I’ll need 1 Murder master and then 1
>> or multiple Murder Front-end and back-end servers ?
> More or less. It's pretty reasonable to have one of the frontends
> act as the murder master, particularly in a low-load environment.
More information about the Info-cyrus