Cluster Imap is quite resource intensive. This requires to share the load between multiple hosts. Another goal is being fault tolerant and to have a fail-over strategy. This means not having 99.999% availability. This could be done using a cluster capable RDBMS. At the best this would mean that you can setup your IMAP servers like accessing one single database.
Partition of Mailboxes The first option is to distribute the mailboxes among different repositories. E.g. one DB host for user mailboxes, one for shared mailboxes and one for news. You could even put the user mailboxes on different hosts. One limitation this introduces it that quotas cannot span multiple repositories. There are performance issues when copying/moving between different repositories. Although the setup is quite simple it will always take some time to administer when e.g. migrating mailboxes from one repository to the other. Multiple IMAP Servers Setting up multiple IMAP severs should also not be too complicated when using standard RDBMS as backends. Requests could be shared between the servers randomly using DNS or other techniques that involve load balancing. The only thing the repository implementation on the IMAP server has to provide is caching uids, flags, and message numbers for the session lifetime and delivering events when it detects changes on the database. The client should cope with a failing message retrieval in the case it has been deleted by another session. If the mailboxes are distributed in a sufficient way, multiple IMAP servers accessing multiple RDBMS could be able to deal with a high volume of traffic and a high volume of stored messages Fail-Over RDBMS like MySQL support master/slave replication. When the master fails a slave starts to do his job. IMAP servers could be externally redirected to the new master by e.g. dynamic DNS. But maybe we should add a possibility to allow changing target server for a repository online. An unanswered question to me is the following situation: The master crashes but its hard-disks are okay and the slave is a few seconds late with receiving log data. If I would change the slave to master now, I would lost statements that are already written to the masters hard-disk. Write To Master, Read From Slave This is suggested in the MySQL replication FAQ. An unanswered question for now is: The slave maybe a few seconds late. When I write to the master and afterwards read from the slave I may not find what I've just written there. That would be quite confusing for the client. First it would require checking how late the slave is. If it is more than x seconds late I should read from the master directly. Second I would have to cache what I've written to the master to be able to give the right responses to the client. A realistic and not too complicated approach would be the following. Fortunately IMAP does not allow to change message or header content. When I want to edit a message e.g. in the Drafts folder, it would be deleted first and gets a new uid. So it would be no problem to list messages and retrieve flags from the master and load message and header content from the slave(s). If retrieving the message from the slave fails, because it its out of sync (quite unlikely) the IMAP server could fall back reading it from the master. Because listing messages and retrieving flags is quite inexpensive and retrieving message content could be quite expensive, this solution could scale very well. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
