[Zope] Will ZEO solve my problem?

[Toby Dickenson]

Many replies in one message....

On Mon, 02 Jul 2001 09:44:43 -0500, "Kyler B. Laird"
<laird@ecn.purdue.edu> wrote:

> Now I also have it run a
>command.  It's essentially this.
>	tail -f -n +0 Data.fs | ssh proxyhost "cat >somepath/Data.fs"

Thats a low-cost trick I hadnt thought of before, however there is
still a small time in between:
a) data being synced onto the main server, and
   the transaction succeeding
b) data being written to the backup server.

Data can be lost if your main machine explodes at that point.

Another disadvantage to this solution; current versions of FileStore
are not purely loggging; *undo* will write a single byte in the middle
of the database file, which will corrupt your replica. A recent change
to FileStorage handles undo a different way, which  I guess that might
fix this problem... Ill ask over on the zodb-dev list.


On Mon, 2 Jul 2001 15:11:14 -0700 (PDT), Michel Pelletier
<michel@digicool.com> wrote:

>have you looked at Coda or Intermezzo?  Both distributed file systems,
>although I've used niether.

Ive looked at them as candidates for this task, but never used them.
Both of them replicate in the same 'direction' as ZEO, on reads rather
than on writes, so I dont think they are suitable for this task.


On 02 Jul 2001 12:13:03 -0600, Bill Anderson <bill@libc.org> wrote:

>If you are running the ZSS on Linux, you can use a network block device
>setup that establishes a raid1 over the netwrok, and have it do a split
>read/write such that it only reads from the primary, but writes over the
>raid.

Have you tried this with FileStorage? Testing this configuration is
approaching the top of my to-do list. I am a little worried that it
may not be entirely stable in high-write usage, such as during a pack.
(although at the moment that is just unsubstantiated FUD)


If the network block device doesnt work out, I am considering patching
=46ileStorage to distribute writes across the network, and only allow
the transaction commit to complete once data is consistent across
multiple remote mirrors. Of course replicated-ZEO would solve this and
many other problems, but I am hoping that by concentrating on just
this one use case I can develop something useful, sooner.

http://www.zope.org/Wikis/DevSite/Projects/ZEOReplicatedStorage/SurviveTo=
talLossOfStorage

I take it there would be willing beta testers for such a system?

Toby Dickenson
tdickenson@geminidataloggers.com