On 22.9.2013, at 0.02, Timo Sirainen <t...@iki.fi> wrote: > The A and B node logs are exactly the same. I think you sent the same ones > for both? Anyway, one of the sides is enough. The interesting parts are: > > 1375808883.299424 O: NINBOX y 0314c806e3fa0052d26a0000736ac1b0 > 1375795939 24 > 1375808883.350378 I: NINBOX y 0314c806e3fa0052d26a0000736ac1b0 > 1375795939 23 > 1375808883.360216 I: Ce 22 6e2b7029b52c015258220000736ac1b0 > 1375808883.360972 O: Cs 23 ae42e400732d0152d3310000736ac1b0 > 59 1375808883 20 > > One side has uidnext=23 and the other side has uidnext=24. You're deleting > the last message with uid=22, so the uidnext=23 is correct. The other side > however thinks that the same mail's uid is 23. There must be something wrong > with the mail delivery, because both sides should have uid=22 and uidnext=23 > here. So replication rawlogs of a new mail delivery would be helpful..
Or there are some other strange things here also: The GUIDs are different for the mails, so it's as if the same mail was saved to both sides via LMTP instead of being copied to the other side via replication? Also the logs show an extra dsync run that seems to mess things up even further. The whole deletion operation did: - expunge uid=22 - copy uid=23 from A to B - expunge uid=21 (the message was there twice?) - copy uid=23 from B to back to A (??)
