On Tue, Oct 19, 2010 at 04:55:48PM -0400, Michael D. Sofka wrote: > I have a new 2.3.16 back-end server and a replication server. (For > those following my saga, I decided to upgrade the to-be-retired 2.2.12 > rsync backup server to 2.3.16. I did this so I could test replication. > Turns out this server was previously built with source RPMs, and the > upgrade was a breeze. A big Thank You to Simon!) Yay Simon! > In testing replication I discovered that partition names must match. > That is, the replication server has a single 1T default partition, while > the new back-end server has a series of .5T partitions. > > As an experiment I configured the replication server thus: > > partition-default: /var/spool/imap > defaultpartition: default > partition-par1: /var/spool/imap > > That is, both default and par1 pointing to /var/spool/imap. And, this > works! > > Is there any reason I should not do this? Should be fine. There's actually explicit checks for this situation in the code to make sure we don't do anything stupid when moving mailboxes around. In my perfect world[tm] this partition name matching requirement would not exist, but that's a long way off. I've talked about it to lots of people now, but it's a lot of work. Unified murder/replication. It will rock. Gotta find some spare cycles to write and test the damn thing though. > Note, this machine will be both the rsync server from the current 2.2.12 > backend, and the replication server for the new 2.3.16 backend during > the transition. Once all the mailboxes are moved to the new back end > I'll have a free machine I can upgrade (OS, disks and Cyrus) to be the > new replication server. (As an aside, it would no doubt be more cost > effective to buy new hardware, but that's not going to happen.) > > A simple question, how does guid_mode: sha1 work? Does it need to be > set on both master and replication server, and will it, for example, > affect the unique ids returned by pop3? We have too many pop3 users. Yes, set it on both. No, it doesn't affect the UIDL for pop3, which will still be UIDVALIDITY.UID. It works by calculating the sha1 of the rfc822 message both (i.e. the file stored on disk) and embedding it in the index record. This allows efficient de-duplication of copies on the replica, because the messages have the same GUID. In Cyrus 2.4, sha1 GUID is the only supported mode, and is required, and is checked for correctness during replication, so you can't accidentally replicate bogus information. Bron. ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
