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

Reply via email to