Re: Replication sync-server and Delayed Delete
Actually, I was talking rubbish cyr_expire does find the deleted folders older than x days, I just got my dates wrong when looking into it. apologies, Gavin. On Thu, 16 Sep 2010, gavin.g...@ed.ac.uk wrote: > Hi there, > So is the side effect of deleted folders ending up on the default > partition when delayed delete is switched on on a replicant machine a known > issue for sync_server? A knock on effect of this seems to be that cyr_expire > on the replicant doesn't find these DELETED folders when it runs to do a > purge. > > Could you suggest a safe alternative to cyr_expire in order to purge these > misplace deleted folders? > > regards, > > Gavin Gray > > > On Wed, 15 Sep 2010, Bron Gondwana wrote: > >> On Wed, Sep 15, 2010 at 12:29:18PM +0100, Gavin Gray wrote: >>> Hi there, >>> >>> We have a cyrus murder using replication and we have a few questions >>> about the behaviour we are seeing on our system. >>> >>> 1. cyr_expire on the master doesn't cause any replication to happen. >>> Is that 'correct'? In other words if we want to delete folders from >>> the DELETED heirarchy on the replicant then we need to also run >>> cyr_expire on the replicant? >> >> Yeah, pretty much. >> >>> 2. We're also a little unclear about replication vis a vis the >>> delayed expunge and the unexpunge facility. Could you explain what >>> ought to happen in terms of replication when email is expunged and >>> then possibly unexpunged if anything? >> >> It's a bit messy. Unexpunge is a sin against IMAP by the way, and >> has been replaced with "generate new UID and promote" in 2.4. In >> which case it's just like a new append wit the same flags, and >> replicates like an append :) >> >> 2.3 replication ignores expunges - it's as if they don't exist! When >> the mailbox syncs, it nukes the records that aren't "alive" on the >> master from the replica. If you re-inject them with unexpunge, it >> should find them and sync_combine_commit() the result. I don't know >> if unexpunge inserts replication events though - somewhat doubt it. >> >>> 3. We are seeing a strange anomaly on the replication of deleting a >>> folder. >>>e.g a user deletes a folder >>>the folder goes into the DELETED heirarchy of the partition >>> the user's mailbox is on >>>the folder is also deleted from the replicant as we would expect >>>however the folder on the replicant goes into the DELETED >>> heirarchy on a different partition(the default partition as >>> specified in cyrus.conf). Is this normal? >> >> Replication and partitions is broken in some ways in 2.3. It should >> be better in 2.4 I believe, though I haven't tested it. I'm going to >> be releasing an alpha super-soon (it's been pushed to git.cyrusimap.org >> now!) >> >> Bron. >> >> > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > Gavin Gray Edinburgh University Information Services Rm 2013 JCMB Kings Buildings Edinburgh EH9 3JZ UK tel +44 (0)131 650 5987 email gavin.g...@ed.ac.uk -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Replication sync-server and Delayed Delete
Hi there, So is the side effect of deleted folders ending up on the default partition when delayed delete is switched on on a replicant machine a known issue for sync_server? A knock on effect of this seems to be that cyr_expire on the replicant doesn't find these DELETED folders when it runs to do a purge. Could you suggest a safe alternative to cyr_expire in order to purge these misplace deleted folders? regards, Gavin Gray On Wed, 15 Sep 2010, Bron Gondwana wrote: > On Wed, Sep 15, 2010 at 12:29:18PM +0100, Gavin Gray wrote: >> Hi there, >> >> We have a cyrus murder using replication and we have a few questions >> about the behaviour we are seeing on our system. >> >> 1. cyr_expire on the master doesn't cause any replication to happen. >> Is that 'correct'? In other words if we want to delete folders from >> the DELETED heirarchy on the replicant then we need to also run >> cyr_expire on the replicant? > > Yeah, pretty much. > >> 2. We're also a little unclear about replication vis a vis the >> delayed expunge and the unexpunge facility. Could you explain what >> ought to happen in terms of replication when email is expunged and >> then possibly unexpunged if anything? > > It's a bit messy. Unexpunge is a sin against IMAP by the way, and > has been replaced with "generate new UID and promote" in 2.4. In > which case it's just like a new append wit the same flags, and > replicates like an append :) > > 2.3 replication ignores expunges - it's as if they don't exist! When > the mailbox syncs, it nukes the records that aren't "alive" on the > master from the replica. If you re-inject them with unexpunge, it > should find them and sync_combine_commit() the result. I don't know > if unexpunge inserts replication events though - somewhat doubt it. > >> 3. We are seeing a strange anomaly on the replication of deleting a folder. >>e.g a user deletes a folder >>the folder goes into the DELETED heirarchy of the partition >> the user's mailbox is on >>the folder is also deleted from the replicant as we would expect >>however the folder on the replicant goes into the DELETED >> heirarchy on a different partition(the default partition as >> specified in cyrus.conf). Is this normal? > > Replication and partitions is broken in some ways in 2.3. It should > be better in 2.4 I believe, though I haven't tested it. I'm going to > be releasing an alpha super-soon (it's been pushed to git.cyrusimap.org > now!) > > Bron. > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Replication sync-server and Delayed Delete
On Wed, Sep 15, 2010 at 12:29:18PM +0100, Gavin Gray wrote: > Hi there, > > We have a cyrus murder using replication and we have a few questions > about the behaviour we are seeing on our system. > > 1. cyr_expire on the master doesn't cause any replication to happen. > Is that 'correct'? In other words if we want to delete folders from > the DELETED heirarchy on the replicant then we need to also run > cyr_expire on the replicant? Yeah, pretty much. > 2. We're also a little unclear about replication vis a vis the > delayed expunge and the unexpunge facility. Could you explain what > ought to happen in terms of replication when email is expunged and > then possibly unexpunged if anything? It's a bit messy. Unexpunge is a sin against IMAP by the way, and has been replaced with "generate new UID and promote" in 2.4. In which case it's just like a new append wit the same flags, and replicates like an append :) 2.3 replication ignores expunges - it's as if they don't exist! When the mailbox syncs, it nukes the records that aren't "alive" on the master from the replica. If you re-inject them with unexpunge, it should find them and sync_combine_commit() the result. I don't know if unexpunge inserts replication events though - somewhat doubt it. > 3. We are seeing a strange anomaly on the replication of deleting a folder. >e.g a user deletes a folder >the folder goes into the DELETED heirarchy of the partition > the user's mailbox is on >the folder is also deleted from the replicant as we would expect >however the folder on the replicant goes into the DELETED > heirarchy on a different partition(the default partition as > specified in cyrus.conf). Is this normal? Replication and partitions is broken in some ways in 2.3. It should be better in 2.4 I believe, though I haven't tested it. I'm going to be releasing an alpha super-soon (it's been pushed to git.cyrusimap.org now!) Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Replication sync-server and Delayed Delete
Hi there, We have a cyrus murder using replication and we have a few questions about the behaviour we are seeing on our system. 1. cyr_expire on the master doesn't cause any replication to happen. Is that 'correct'? In other words if we want to delete folders from the DELETED heirarchy on the replicant then we need to also run cyr_expire on the replicant? 2. We're also a little unclear about replication vis a vis the delayed expunge and the unexpunge facility. Could you explain what ought to happen in terms of replication when email is expunged and then possibly unexpunged if anything? 3. We are seeing a strange anomaly on the replication of deleting a folder. e.g a user deletes a folder the folder goes into the DELETED heirarchy of the partition the user's mailbox is on the folder is also deleted from the replicant as we would expect however the folder on the replicant goes into the DELETED heirarchy on a different partition(the default partition as specified in cyrus.conf). Is this normal? many thanks, Gavin Gray name : Cyrus IMAPD version: v2.3.15 2009/09/09 12:35:48 vendor : Project Cyrus support-url: http://cyrusimap.web.cmu.edu os : SunOS os-version : 5.11 environment: Built w/Cyrus SASL 2.1.23 Running w/Cyrus SASL 2.1.23 Built w/Berkeley DB 4.7.25: (May 15, 2008) Running w/Berkeley DB 4.7.25: (May 15, 2008) Built w/OpenSSL 0.9.8a 11 Oct 2005 (+ security fixes for: CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343 CVE-2007-3108 CVE-2007-4995 CVE-2007-5135 CVE-2008-5077 CVE-2009-0590) Running w/OpenSSL 0.9.8a 11 Oct 2005 (+ security fixes for: CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343 CVE-2007-3108 CVE-2007-4995 CVE-2007-5135 CVE-2008-5077 CVE-2009-0590) Built w/zlib 1.2.3 Running w/zlib 1.2.3 CMU Sieve 2.3 NET-SNMP mmap = shared lock = fcntl nonblock = fcntl idle = poll -- Gavin Gray Edinburgh University Information Services Rm 2013 JCMB Kings Buildings Edinburgh EH9 3JZ UK tel +44 (0)131 650 5987 email gavin.g...@ed.ac.uk -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
