Re: [Monotone-devel] Setting up a "cluster" of monotone servers

[Timothy Brownawell]

On Mon, 2007-01-29 at 10:06 +0100, Richard Levitte - VMS Whacker wrote:

>  2. Propagation of changes.  The way things look right now,
>     propagating changes could easily be done by having all servers
>     keep a mirror of the database and sync all changes to all the
>     other servers (or in whatever topology you desire).  The trouble
>     with this is, of course, latency.  The users may or may not
>     experience that the changes they just pushed aren't quite there,
>     that they need to push more than once if they're impatient, and so
>     on.

This is pretty much what webhost does for keeping the viewmtn dbs up to
date -- the note_netsync_end hook forks a client that pulls from the
server to update the other db.

>     A different solution could be to make it possible for a server to
>     initiate a sync with another server, and have that done directly
>     after there's been anything happening that changes the contents of
>     the database.  This would probably just need a little bit of
>     hackery of the netsync code to have an appropriate trigger point
>     that starts the netsync, and a hook that returns a list of other
>     servers to communicate with.

You probably don't want to have it actually run a standard netsync
session, that'd just make our cpu usage even worse (refinement is
moderately expensive). What might be good would be a 'mirror'
connection, that starts as a normal netsync but instead of closing when
transfer is done, it stays open. Then whenever new data comes in on
another netsync, it just gets sent across the mirror connection
(probably after asking the other side if it has it already, in case
there's a bunch of servers all mirroring eachother).

-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net