One way dsync replication with dsync -R

[Rob Archibald]

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