One way dsync replication with dsync -R

Wolfgang Hennerbichler wogri at wogri.com
Fri Mar 24 10:45:47 EET 2017


Correct. Even with only connecting to one node I see the issue. Interesting, are you willing to share your dovecot -n output? 

> On Mar 24, 2017, at 09:43, Rob Archibald <rob at robarchibald.com> wrote:
> 
> So, even with a particular user only connecting to one node in the pair, you still see the issue? I'm not seeing that in my setup. I only see it when concurrently connecting the same user to two different nodes in the pair.
> 
> Blessings,
> Rob Archibald
> CTO, EndFirst LLC
> rob at robarchibald.com
> 
>> On Mar 24, 2017, at 12:50 AM, Wolfgang Hennerbichler <wogri at wogri.com> wrote:
>> 
>> Rob, 
>> 
>> Unfortunately I don’t think the director will solve this problem. I have a director in front of my setup and it is configured to point every client to one server. It didn’t change anything in its behavior. 
>> I also have a setup without a director where the clients are only allowed to talk to one host (DNS entries control this) - same thing. 
>> 
>> Wolfgang
>> 
>>> On Mar 22, 2017, at 23:58, Rob Archibald <rob at robarchibald.com> wrote:
>>> 
>>> Ugh, sorry for the formatting. Not sure what happened when it sent through the list.  Trying again
>>> 
>>> Blessings,
>>> Rob Archibald
>>> CTO, EndFirst LLC
>>> rob at robarchibald.com
>>> 
>>> 
>>> -----Original Message-----
>>> From: dovecot [mailto:dovecot-bounces at dovecot.org] On Behalf Of Rob Archibald
>>> Sent: Wednesday, March 22, 2017 3:55 PM
>>> To: 'Wolfgang Hennerbichler'; dovecot at dovecot.org
>>> Subject: RE: One way dsync replication with dsync -R
>>> 
>>> I'm using dsync successfully to keep two nodes synchronized, but I have the same problems as you. When I first set it up, I purposely had my phone connected to one node and my desktop connected to the other node. This allowed me to watch for the very issues you're referring to. I ran into them enough that I quit using it that way. But, what I also found was that it was just a timing issue. If they weren't synchronized, I could wait a bit and they would get synched up. Obviously that doesn't work too great if you're sending clients to both nodes through a load balancer though. But, since it was just a timing issue, it also made me feel plenty comfortable using 2-way sync. I've been able to verify that whichever node is the "master" that the other node will be in sync soon thereafter. It just doesn't work great if you're logged into both at the same time. 
>>> 
>>> How does that help you may ask? Well, my plan is to setup Dovecot Director on each of my node pairs to enable load balancing that way instead of through some other load balancer. Director should ensure that all clients of a single user will be directed to the same node. Since I haven't set that up yet, I can't guarantee it'll work, but based on my testing and reading, I think it should be fine. 
>>> 
>>> The benefits I'm expecting are:
>>> 1. Redundant and reliable storage with data always in 2 places at once 
>>> 
>>> 2. All devices of a single user always go to the same server so that there is no risk of synchronization delays between devices 
>>> 
>>> 3. Local storage connections for Dovecot so hopefully a lot fewer index corruption issues compared to NFS 
>>> 
>>> 4. Redundant compute nodes so if one server goes down, clients can still connect
>>> 
>>> 
>>> At a high level, my complete setup that I'm building is to 1. Shard users into separate server pairs using Dovecot Proxy, 2. Load-balance them within the server pair using Dovecot Director. Hopefully my attempt to explain will come out well in ASCII:
>>> 
>>> Server sharding (however many pairs needed to support users. 4 users each obviously only for illustration purposes) ========================= 
>>> 
>>> Server pair 1 (servers A & B) Users 1-4
>>> 
>>> Server pair 2 (servers C & D) Users 5-8
>>> 
>>> User connections
>>> =============
>>> User 1 device 1 ---> Load balancer ---> Dovecot proxy A --->  Send to Server A running Director ---> Connect on Server A 
>>> 
>>> User 2 device 1 ---> Load balancer ---> Dovecot proxy B --->  Send to Server A running Director ---> Connect on Server B 
>>> 
>>> User 5 device 1 ---> Load balancer ---> Dovecot proxy C --->  Send to Server C running Director ---> Connect on Server C 
>>> 
>>> User 1 device 2 ---> Load balancer ---> Dovecot proxy D --->  Send to Server A running Director ---> Connect on Server A 
>>> 
>>> User 7 device 1 ---> Load balancer ---> Dovecot proxy A --->  Send to Server C running Director ---> Connect on Server D 
>>> 
>>> User 6 device 1 ---> Load balancer ---> Dovecot proxy B --->  Send to Server C running Director ---> Connect on Server C 
>>> 
>>> User 3 device 1 ---> Load balancer ---> Dovecot proxy C --->  Send to Server A running Director ---> Connect on Server B 
>>> 
>>> User 8 device 1 ---> Load balancer ---> Dovecot proxy D --->  Send to Server C running Director ---> Connect on Server D 
>>> 
>>> User 3 device 2 ---> Load balancer ---> Dovecot proxy A --->  Send to Server A running Director ---> Connect on Server B 
>>> 
>>> User 5 device 3 ---> Load balancer ---> Dovecot proxy B --->  Send to Server C running Director ---> Connect on Server C 
>>> 
>>> User 5 device 2 ---> Load balancer ---> Dovecot proxy C --->  Send to Server C running Director ---> Connect on Server C 
>>> 
>>> User 4 device 1 ---> Load balancer ---> Dovecot proxy D --->  Send to Server A running Director ---> Connect on Server A 
>>> 
>>> User 5 device 4 ---> Load balancer ---> Dovecot proxy A --->  Send to Server C running Director ---> Connect on Server C 
>>> 
>>> User 1 device 3 ---> Load balancer ---> Dovecot proxy B --->  Send to Server A running Director ---> Connect on Server A 
>>> 
>>> User 1 device 4 ---> Load balancer ---> Dovecot proxy C --->  Send to Server A running Director ---> Connect on Server A 
>>> 
>>> User 6 device 2 ---> Load balancer ---> Dovecot proxy D --->  Send to Server C running Director ---> Connect on Server C 
>>> 
>>> User 2 device 2 ---> Load balancer ---> Dovecot proxy A --->  Send to Server A running Director ---> Connect on Server B
>>> 
>>> Results
>>> ===========
>>> User 1, 4 - Server A
>>> User 2, 3 - Server B
>>> User 5, 6 - Server C
>>> User 7, 8 - Server D
>>> 
>>> I would love to hear if others have gotten something like this working.
>>> 
>>> Blessings,
>>> Rob Archibald
>>> CTO, EndFirst LLC
>>> rob at robarchibald.com
>>> 
>>> -----Original Message-----
>>> From: dovecot [mailto:dovecot-bounces at dovecot.org] On Behalf Of Wolfgang Hennerbichler
>>> Sent: Wednesday, March 22, 2017 2:11 PM
>>> To: dovecot at dovecot.org
>>> Subject: One way dsync replication with dsync -R
>>> 
>>> Hi dovecot users, 
>>> 
>>> I’ve found the -R parameter for dsync. Does this enable one-way syncing if enabled on the slave in replication_dsync_parameters? The documentation doesn’t mention much what happens if I enable this on the “replciation slave”. 
>>> 
>>> Before you ask: Two way synchronisation causes issues in my installation (see the unanswered thread here: http://www.dovecot.org/list/dovecot/2017-March/107431.html), it causes unread, deleted messages to re-appear. I would hope that one-way synchronisation would avoid this, but I’d also like to know if the -R parameter is safe to use. 
>>> I am also still wondering if anybody has a perfectly working 2-way-synchronised dovecot installation (and I’m interested in your dovecot -n). 
>>> 
>>> wogri
> 



More information about the dovecot mailing list