What flags should I supply to cyr_expire in a replication configuration when I have expire annotations in use?
I have a replication relationship from a 2.5.12 machine (in the process of being replaced, but currently the master) to a 3.0.8-6+deb10u4 (as replica). I have had problems with old messages not being deleted on the replica, and found I was not running cyr_expire on the replica. I have configured it, so I have: master: cmd="cyr_expire -E 7 -X 3 -D 3" at=0100 slave: cmd="cyr_expire -E 7 -X 3 -D 3" at=0300 Since I installed this, I have had periodic replication failures. What seems to happen is this: MAILBOX received NO response: IMAP_SYNC_CHECKSUM Checksum Failure CRC failure on sync for user.igb.routine, trying full update SYNCNOTICE: highestmodseq higher on replica user.igb.routine, updating 49317 => 49321 SYNCERROR: guid mismatch user.igb.routine 46708 (890a6db331aaccd8c423bbff598bb81bc3c19146 87fb316dea9c9dbbed691d11759b7b1e000d5487) FETCH received NO response: IMAP_PROTOCOL_BAD_PARAMETERS SYNCNOTICE: failed to prepare update for user.igb.routine: The remote Server(s) denied the operation do_folders(): update failed: user.igb.routine 'The remote Server(s) denied the operation' MAILBOX received NO response: IMAP_SYNC_CHECKSUM Checksum Failure CRC failure on sync for user.igb.routine, trying full update SYNCERROR: guid mismatch user.igb.routine 46708 (890a6db331aaccd8c423bbff598bb81bc3c19146 87fb316dea9c9dbbed691d11759b7b1e000d5487) FETCH received NO response: IMAP_PROTOCOL_BAD_PARAMETERS SYNCNOTICE: failed to prepare update for user.igb.routine: The remote Server(s) denied the operation do_folders(): update failed: user.igb.routine 'The remote Server(s) denied the operation' IOERROR: The remote Server(s) denied the operation Error in do_sync(): bailing out! The remote Server(s) denied the operation The synchronisation continues to do this, making no progress. The clean-up is straightforward: I delete all the files in user.igb.routine on the replica, reconstruct -G -U user.igb.routine on replica, sync_client -m user.igb.routine on the master. It then runs for a few days, and then goes bang again: suggestively, always in the early but not too early hours of the morning. What’s going wrong, and what’s needed to fix it properly? user.igb.routine is the only mailbox I have which both (a) is relatively high traffic and (b) has the expire annotation. My hypothesis (I only have 8 days of searchable logs, so this is n=small) is that the failure happens as we replicate the first message to be delivered to user.igb.routine after 0300. My supposition is that a trap is set by the delivery of a message into user.igb.routine between 0100 and 0300. 3 (the value of the “expire” annotation) days later at 0300, that message is deleted on the replica (as it is >(86400*3) seconds old) but was not deleted on the master (because when expire ran on the master, at 0100, the message was _not_ >(86400*3) seconds old). Something bad happens during the replication run, and bad things then continue to ensue. To test this theory my original thought was to run expire on the slave at the same time it runs on the master, making the race condition much smaller. But I see that in 3.0.8 there is a “-a” flag to cyr_expire which suppresses processing of the expire annotation, which I assume deals with this case. Am I thinking along the right lines? ian
---- 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
