[ZODB-Dev] Horizon for highly-available ZODB storage?

[Toby Dickenson]

On Thu, 3 Jan 2002 20:04:58 -0200, Fabiano Weimar dos Santos
<fabiano@x3ng.com.br> wrote:

>Em Qui 03 Jan 2002 19:46, sean.upton@uniontrib.com escreveu:
>> This is an interesting idea;

I considered this before writing ReplicatedFileStorage.

>>the nice thing about a replicated block device
>> is that it should replicate data rather quickly, though, if I =
understand
>> correctly, the FS has to be unmounted until the backup node takes =
over.
>
>Yes and No. The master file system is mounted and the slave is umounted.=
 If=20
>the master fail, the HEARTBEAT and IPMON will mount the slave as a =
master via=20
>nfs until the master come back to run.

Another nice advantage is that switching mastery from one node to
another can happen very quickly. This is important for Sean's high
availability requirements, but less so for me. (I am interested in
storage reliability, and a few days of downtime after a failure is not
a problem)

>> Are there any issues with corruption of a FileStorage Data.fs that =
have to
>> be dealt with as the result of an incomplete replication of data =
blocks via
>> DRBD, if for example, there is a sudden power outage on the primary =
node?
>
>Because of this kind of problem that we have to use a journaled file =
system.=20
>Thus, data loss is very hard.

I looked closely at this, and didnt get a warm cosy feeling. I am most
familiar with the reiser Journaled filesystem... it assumes that block
writes will always complete in order. However the current state of
play with NBD is that it can intorduce up to four blocks of
reordering. Does this make a difference? Its hard to tell. I found
numerous "it works for me" posts, but nothing sufficiently definite to
convice me that this was a trustworthy HA solution.



Toby Dickenson
tdickenson@geminidataloggers.com