Cyrus, clusters, GFS - HA yet again

[Janne Peltonen]

On Wed, Nov 01, 2006 at 05:03:43PM -0500, Scott Adkins wrote:
> >And that's precisely what I'm trying to find out: since there are people
> >that have succeeded in running Cyrus in an enviroment that's essentially
> >the same as mine, I'd like to know how they have found their way around
> >the DB error and other obstacles mentioned on this list in earlier
> >posts.
[...]
> I can say that I solved the above problem by dumping BerkeleyDB. :) Even
> though it is not recommended to use (at least the last time I remember
> the recommendation to be) Skiplist for mailboxes.db, that is exactly what
> I use.  The performance hit for using Skiplist is negligible to the amount
> of problems I saw when using various versions of BerleleyDB on Tru64.  I
> don't necessarily believe it is BerkeleyDB that is fully the problem, but
> maybe BerkeleyDB's interaction with Tru64 that is the problem.
> 
> In any case, I have been MUCH happier dumping BerkeleyDB across the board.

Thanks a lot. I ended up recompiling Cyrus without-bdb, and got rid of
the error. Weird, though: (see below)

>  # Database Formats
>  annotation_db: skiplist
>  duplicate_db: skiplist
>  mboxlist_db: skiplist
>  ptscache_db: skiplist
>  quota_db: quotalegacy
>  seenstate_db: skiplist
>  subscriptions_db: flat
>  tlscache_db: skiplist

...ok, I had in fact forgot to explicitely set tlscache_db to skiplist,
and it does default to bdb-nosync. But - when I tried to run Cyrus again
with "tlscache_db: skiplist" (and all old databases purged) I still got
the DB ERROR. I tried hunting around the db4 code for a while, but
couldn't get a lot out of it; would require a longer while.

Getting completely rid of BDB does the job. Weird.

> However, turning off duplicate suppression breaks sieve, so I had to
> modify the code to allow sieve to continue using the duplicate_db,
> even when duplicate suppression has been turned off.  So, we still
> use the database a little bit, but that is it... Which, makes skiplist
> just fine for that.

And it all works? Nice.

> Anyways, if there are any questions you have about our environment, feel
> free to e-mail off-list and ask me.  I will do my best to help.  As I
> eluded to above, we are a Tru64 show and their CFS has worked wonders
> for us.  We have an e-mail project under way that will migrate Cyrus off
> Tru64 into Linux (RedHat) with Polyserve as the cluster filesystem.  We
> have Polyserve purchased but not deployed.  I will be happy to share our
> deployment document once we have completed the project (which is likely
> at least in the next summer timeframe).

I read the article about CASPUR and PolyServe, and its performance was
impressive. On the other hand, the email service here is abt an
order of magnitude smaller than in the Italian project, so I thought GFS
would be up to the job. But it's nice to know about commercial
alternatives, if GFS doesn't work out after all.


--Janne