Cyrus with a NFS storage. random DBERROR

[Paul Dekkers]

Hi,

Dmitriy Kirhlarov wrote:
> Michael Menge wrote:
>   
>> after the problem with the wiki was solved, i added a summery about
>> CyrusCluster 
>> http://cyrusimap.web.cmu.edu/twiki/bin/view/Cyrus/CyrusCluster .
>>     
> Could you, please, describe more detailed problems with replication:
> CyrusReplication: ... The replication is asynchrony so you might lose 
> some mails.
>
> I test this functionality and doesn't find problem.
> If sync_client lost connection to sync_server (link down, firewalls 
> drops tcp sessions, etc) I just run 'sync_client -u username' for fixing 
> problem. It's enough.
>   

... but asynchronous. It is possible that a message is delivered to your
master, not yet (or not properly) synchronized to the backup, and the
master fails (beyond repair). You can replace the master with the backup
server, but you'll lose the unsynchronized messages (or other recent
transactions).
And when folders are not properly synchronized for some reason (that's
why you need to check frequently with for instance make_md5*) you can
lose more than just the most recent messages.

Not necessarily a big problem, but just something to be aware of. It's
not that your transaction is finished after the synchronization is done
(would be slower, but more reliable): the synchronization is done
asynchronously based on a log.

While NFS (more reliable storage) might be an option for us now I
figured out that it works with -o nolock or seperate metadata, I still
think I'd add replication. It's very nice to have synchronization in the
application, in a way that even allows for geographic separation. (And
right now I'd trust it more than shared storage.)

Paul

* I'm still not fully using make_md5 myself. Still need to write a
script, that walks through the files, and only compares the messages
that are in both folders. If I run make_md5, it's never working on a
folder on both servers at the same time, so there's always a gap. So the
files aren't always equal, I think. Oh well.