High availability email server...
Daniel Eckl
deckl at nero.com
Wed Aug 2 03:24:19 EDT 2006
Well, as far as I know, the mailboxes.db and other databases are only
opened and modified by the master process. But I'm not sure here.
But as your assumption sounds correct and because this seems to work
with cluster (and I fully believe you here, no question), your
assumption regarding the DBs somewhat must be correct.
Thanks!
I would be glad if some list member who has in depth knowledge here
could comment!
Best,
Daniel
Andrew Morgan schrieb:
> On Tue, 1 Aug 2006, Daniel Eckl wrote:
>
>> Well, I don't have cluster knowledge, and so of course I simply
>> believe you that a good cluster system will never have file locking
>> problems.
>> I already stated this below!
>>
>> But how will the cluster affect application level database locking?
>> That was my primary question and you didn't name this at all.
>>
>> A database file which is in use is practically always inconsistent
>> until it's being closed by the database application.
>>
>> That's why databases can be corrupt after an application crash and
>> have to be reconstructed.
>>
>> When you have two applications changing the same database file, you
>> have a never ending fight, because every application thinks, the
>> database is inconsistent, but it's just in use by another application.
>> And every app will try to reconstruct it and so break it for the other
>> app(s).
>>
>> It's like letting two cyrus master run on the same single node! It
>> will break in my opinion.
>>
>> Can you shed some light on this subject?
>
> I think the point here is that the situation you describe already occurs
> all the time on a stand-alone Cyrus server. There are multiple imapd
> processes accessing the mailboxes.db database concurrently. If you are
> using Berkeley DB, it has an API to manage concurrent access. I assume
> the same is true of skiplist and the other backend formats. I don't
> know enough about the Berkeley DB internals to explain how it actually
> works, but it does. :)
>
> Andy
More information about the Info-cyrus
mailing list