On 22.9.2013, at 0.02, Timo Sirainen <tss@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 (??)