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 <[email protected]> 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 > [email protected] > >> On Mar 24, 2017, at 12:50 AM, Wolfgang Hennerbichler <[email protected]> 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 <[email protected]> wrote: >>> >>> Ugh, sorry for the formatting. Not sure what happened when it sent through >>> the list. Trying again >>> >>> Blessings, >>> Rob Archibald >>> CTO, EndFirst LLC >>> [email protected] >>> >>> >>> -----Original Message----- >>> From: dovecot [mailto:[email protected]] On Behalf Of Rob >>> Archibald >>> Sent: Wednesday, March 22, 2017 3:55 PM >>> To: 'Wolfgang Hennerbichler'; [email protected] >>> 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 >>> [email protected] >>> >>> -----Original Message----- >>> From: dovecot [mailto:[email protected]] On Behalf Of Wolfgang >>> Hennerbichler >>> Sent: Wednesday, March 22, 2017 2:11 PM >>> To: [email protected] >>> 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 >
