On Aug 11, 2009, at 5:57 PM, Chris Anderson wrote:
4. How can we configure replications that survive a server restart?
I think I'd like to see a replication config database, and a constant
replicator config process that reads the config info at server
start and
starts the continuous replications. It monitors the config db for
changes
and as new settings are written spawns, restarts or shuts down
replication
tasks.
I think this is a great idea. The Futon interface for configuring this
will probably take a lot of the mystery out of replication for our
users.
Sure, we were just using a [replication] block in an .ini file for
this purpose internally for a while now, but a DB is obviously much
more flexible. couch_rep_sup can easily monitor the config DB for
changes and take the appropriate action(s).
The next question I have is whether there ought to be any
correspondence between the doc in the configuration DB for a
particular replication and the _local doc in the DB itself that we use
to record replication history. Some thoughts:
* we don't expose a view of _local docs, so currently users just have
to guess the right ID to see the history.
* we could automatically add a field to the config document that
identifies the corresponding _local doc ID. We'd have to use
something like the new _update handler to validate this field on every
update, as a change in authentication information means a change in
the corresponding _local doc ID.
* replication history can get updated very frequently, so for users'
sanity we probably don't want to actually save the history in the
configuration document.
A thought -- what if one-off POSTs to /_replicate automatically saved
a config document as well, but with a "continuous":false field? Then
it would be easy to view all the replications that ever originated on
the server, and admins could make certain ones continuous just by
flipping a bit.
And most importantly, what do we call this DB? :-P Couch has always
used _underscored reserved names, but now we've got a "users" DB. Best,
Adam