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

[Howard Spindel]

I rarely post responses here because I'm retired for a while and you 
guys are all so much sharper and current on technology than I am.

But it seems to me that redundant or high-performance servers are a 
general problem to be solved for multiple applications, and that a 
monotone-specific solution perhaps exceeds monotone's scope.

In other words, users who want redundancy/high-performance should 
build it into their underlying infrastructure and monotone rides on 
top of that like any other service provided by the infrastructure.

I am not sure if Richard's goal is redundancy or higher performance.

Am I off?  If so, feel free to dismiss the ramblings of an old fogey. :-)

Howard

At 01:06 AM 1/29/2007, Richard Levitte - VMS Whacker wrote:
> Hi,
>
> For a while, I've been thinking about what would be required to have
> more than one server respond as if they were one.  One of the goals
> with this effort is to be able to have a monotone host name (such as
> mtn.lp.se) have more than one A record (in other words, point at more
> than one server) and work seemlessly.
>
> The problem is really two-fold:
>
>  1. Keys, permissions and hooks.  These need to be the same on all
>     servers, or there will be trouble, either with having users
>     suddenly be presented with a different server key, and monotone
>     putting up big warnings, or with netsync rights varrying depending
>     in which server you happen to hit, or other variations depending
>     on the hooks.
>     For now, such things can be solved by having a separate set of
>     servers for administrative data, with very tight trust settings.
>     It's quite possible (I don't know yet) that the future policy
>     branches could solve the problem more or less automagically.
>
>  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.
>     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.
>
> Thoughts?  Ideas?  Criticism?  Is this at all possible?
>
> Cheers,
> Richard
>
> -----
> Please consider sponsoring my work on free software.
> See http://www.free.lp.se/sponsoring.html for details.
>
> --
> Richard Levitte                         address@hidden
>                                         http://richard.levitte.org/
>
> "When I became a man I put away childish things, including
>  the fear of childishness and the desire to be very grown up."
>                                                 -- C.S. Lewis
>
>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel