[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Time to create a monotone cluster?
From: |
Grahame Bowland |
Subject: |
Re: [Monotone-devel] Time to create a monotone cluster? |
Date: |
Sat, 31 Mar 2007 15:12:39 +0800 |
On 24/03/07, Richard Levitte - VMS Whacker <address@hidden> wrote:
In message <address@hidden> on Fri, 23 Mar 2007 13:42:46 +1100, Daniel Carosone
<address@hidden> said:
dan> On Fri, Mar 23, 2007 at 03:28:59AM +0100, Richard Levitte - VMS Whacker
wrote:
dan> > I believe I've just finished the framework for a simple
dan> > monotone cluster. It's all in the following scripts:
dan>
dan> Cool. No time to look at it just right now, but I'm happy to host
dan> a node.
Thanks.
I just saw that someone thought the monotone database was getting
clustered last night. There's currently no such effort underway, but
I'll confess to having thought of it. Before that, though, I'll do
some tests on my own servers.
Hi guys
It'd be great to get angrygoats.net (which runs viewmtn, but does not
currently run a monotone server) in the cluster. At the moment I'm
doing a pull from venge.net every fifteen minutes, it'd be good to
improve that to something event-driven
I can easily enough start running a public monotone server, but
there's one catch - can anyone think of a solution?
I've got viewmtn running, and a number of long-lived mtn processes
reading from the database. I've recently modified viewmtn to notice
when the db file mtime changes and restart the mtn processes.
The trouble is updates; these lock the database, and the readers can't
access it. People start getting error pages when accessing the web
page. What I'm currently doing is:
- copy the database file to a temporary file
- pull into that file
- do a atomic rename() to replace the old database file
This is quite transparent to any running mtn processes, as they just
keep using the old database until stopped. However, it's slow and more
than a little crude - and it will suck horribly when trying to deal
with regular updates.
I can't think of a better solution short of some sort of union
filesystem that allows me to have the temporrary db file be based upon
the original, removing the slowness of the copy. That could work, but
it's still pretty horrible for anyone else wanting to run a viewmtn
server..