Master-Master replication question

[William L. Thomson Jr.]

On Monday, July 11, 2016 05:38:20 PM Remko Lodder wrote:
> > On 11 Jul 2016, at 17:21, William L. Thomson Jr. <wlt-ml at o-sinc.com>
> > wrote:
> > 
> > You are not alone!
> 
> Hello,
> 
> Now that’s a relief!

Maybe if I had a solution, but I guess knowing others suffer the same can be reliving.

> One of the things that I described and observed is that it seems that
> serverB is not seeing the email (or at least there is no connection that
> when an email is send and stored on the mailserver that the services see
> them and notify the other end). With tcpdump there is no traffic at all,
> until there is a sync the other way around.

I really have not had a chance to debug this. I was under the impression one side thought it 
had synced. Since both sides tend to show fast sync, but its the full sync I have been curious 
about. When I run the manual command, it seems to do a full sync. Also not clear if emails 
are supposed to be on both or if one has reference to emails on the other. When I do a 
manual sync via command line, it seems to make  both have the same emails, but different 
file names.

The manual syncing I think it triggers another issue with duplicate emails. Another started a 
topic on duplicate emails from dsync, which I suffer from as well when I try to force syncing, 
or as a result of syncing at times. That as well I have not had a chance to debug.

> As said both systems are identical in hardware setup and use puppet to
> obtain their configuration, which is the same for both hosts (except the IP
> adresses and hostname);

Same here, I literally cloned my 2nd one as both are VMs. I use Ansible to make them 
identical configuration wise. Only thing that is different is the data, email that arrives on 
one or the other. 

> But since we are with at least two, we might have better luck in getting
> some help with this. I currently do not have an idea on where to look and
> how to investigate this properly.

It seems there might have been a few regressions, maybe or hopefully. Things seemed to 
get better and/or go away entirely for a month or so after a past updated. I commented 
about that on list. Though it seems to have regressed with 2.2.24. I haven't upgraded to 
2.2.25 yet. Seems that might have other regressions not sure or maybe fixes.

> Any pointers from the list are welcome!

Beyond running the manual sync via command line, not sure at this time. The manual sync 
via cli seemed to stop working a few updates back.

Just as I type that, I went to run the command again so I could get errors to pass along and 
it worked. I know I tried to run it the other day and it failed. Something about unable to 
lookup UID or switch to the users. I had cron running it every 15 minutes to force things to 
sync. I stopped when I started getting emails of errors when it ran every 15 minutes.

I think error is similar for the use case for the dsync wrapper script for root, mentioned here. 
When I get the error it seems root has a problem changing to another UID. Which seems 
that is what the script does, wrap users for root.
http://wiki.dovecot.org/Replication

Just odd that it works sometimes and not others.  I thought it stopped working during an 
update. Now I think it is related to the syncing. Maybe when syncing is not working, if I run 
that command I will get the errors. Not sure if it will shed any light on syncing. At least I 
know that is not related to an update or regression. I will see about replicating the manual 
sync errors, and see if regular syncing is broken at the same time.

Beyond that, I am open to any input from the list as well... Though need to do my part and 
try to debug a bit more.

-- 
William L. Thomson Jr.
Obsidian-Studios, Inc.
http://www.obsidian-studios.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://dovecot.org/pipermail/dovecot/attachments/20160711/52e97c99/attachment.sig>