On 01/02/13 16:42, Adam Tauno Williams wrote: > > A modseq is very much like an etag or a ctag in HTTP/WebDAV. It is a > value that gets incremented with every change. So the the modseq on the > slave is greater than the modseq on the master... something is out of > sync. I guessed that's what it was. thanks for clearing that up for me. >> On the master: >> sync_client[5197]: MAILBOX received NO response: IMAP_MAILBOX_CRC >> Checksum Failure >> sync_client[5197]: CRC failure on sync for user.myuser, trying full update >> sync_client[5197]: SYNCNOTICE: record mismatch with replica: user.myuser >> more recent on master > Aren't you connecting to the slave and making changes? That would make > sense then, the master and the replica are constantly getting > out-of-sync. Replication is one-way. Yes. My original server became the master and the new one became the replica. I then switched off main retrieval on the master and enabled it on the replica so that would naturally become ahead. If I understand correctly the replication isn't designed to work that way (although it does an admirable job of doing so). I need to configure the "ahead" server as the master and the other as the replica (e.g. switch the replication direction around). I'll do that over the weekend. >> Despite these messages, my replication appears to be working but I can't >> as yet be 100% sure. I'd like to understand the above and try and stop >> them if I can... > Because it is constantly recovering, as these messages indicate. 2.4.x > replication is quite reliable and recovers from inconsistencies most of > the time. It works very well. If I understand from your earlier comments, when 2.5 comes out will this support bi-directional replication along the lines of what I am trying to do ? Meanwhile I'll stop updating the replica except via the sync client/server. ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
