[Dovecot] Dsync replication

[list at airstreamcomm.net]

On 7/5/12 10:08 PM, Костырев Александр Алексеевич wrote:
> use the search, Luke)
>
> http://www.dovecot.org/list/dovecot/2012-March/064512.html
> this thread was all that I needed to setup replication for testing.
>
>
>
> -----Original Message-----
> From: dovecot-bounces at dovecot.org [mailto:dovecot-bounces at dovecot.org] On Behalf Of list at airstreamcomm.net
> Sent: Friday, July 06, 2012 3:28 AM
> To: dovecot at dovecot.org
> Subject: [Dovecot] Dsync replication
>
> I have been loosely following discussions dsync replication, but I am
> wondering if this tool still in a testing phase or has it been committed
> as a production part of Dovecot?  I would like to do some testing with
> the protocol to see if it's capable of handling the change rate our mail
> service generates, which has about 23,000 active users.  We are trying
> to find solutions for a two site setup where mail processing is either
> being done at the primary data center A and fails over to a hot standby
> cluster at the secondary data center B, or where both data centers are
> doing active processing.  I have been unable to find documentation on
> dsync replication on the wiki, so if there is any documentation
> available on how to setup dsync replication I would appreciate a nudge
> in the right direction.
>
>
>
Thanks, that certainly helps identify the configuration options. However 
I am more concerned about the experiences of others who have actually 
used the replication.  What is the rate of change on your mail cluster, 
how many concurrent users do you support with replication enabled, do 
you use synchronous or asynchronous replication, are you using it in an 
active/active or active/passive state, is it possible to have a cluster 
with multiple servers at each site hosting the same mail data, does 
dysnc replication scale well (10,000 -> 100,000 -> 1,000,000 users)?  
Just trying to get a good feel for whether dsync replication is capable 
of handling the use case I am proposing before investing too much time 
in testing it.