On Aug 12, 2009, at 12:41 AM, Chris Anderson wrote:
I think a view of _local docs would be ideal. I've been wishing for
this or a long time, glad to see we're getting close to it.
I was thinking just a single _local_docs view, but it sounds like you
might have grander plans. I assume any view on _local docs will have
to a built-in one.
* 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.
I think trying to keep them in sync is a smell. The replication
manager can perhaps just use a group view of replication history to
list all the potential replication targets.
I don't think it's so bad. We can use the same function that
generates the replication ID from the POST body to add a _local_id
reserved field to the doc in the _replication DB. It's just like a
_rev.
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.
What kind of _local doc artifacts does continuous replication leave in
the current implementation - maybe a _local view can give us
everything we need.
I'm worried about saving source and target values with authentication
information in _local docs that are world readable and saved on both
servers. It would be nice to see some info on replications triggered
from other servers, though, and viewing _local docs allows for that.
Anyway, to answer your question ...
CouchDB deterministically generates a replication ID from the server
hostname and the source and target values in the body of the POST. It
saves a _local document with this ID on both source and target that
looks like
{
"session_id": uuid(),
"source_last_seq": integer(),
"history": array()
}
The history is capped at 50 entries, each of which looks like
{
"session_id": uuid(), % for the head of the list this is the same
as above
"recorded_seq": integer(), % for the head this is the same as
source_last_seq
"start_time": rfc1123_date(),
"end_time": rfc1123_date(),
"start_last_seq": integer(),
"end_last_seq": integer(), % might be different from recorded_seq
if a server restarted during replication
"missing_checked": integer(),
"missing_found": integer(),
"docs_read": integer(),
"docs_written": integer(),
"doc_write_failures": integer()
}
On Aug 12, 2009, at 5:08 AM, Simon Metson wrote:
Why not have a reserved _named database for each configuration
section? Depending on what the _config eventually evolves to hold
you might find it getting hit frequently - you don't want your
replication settings getting screwed up by settings for other
components. You also may want replication settings to be "public"
but other parts to be top secret, I'd say that's easier to manage at
a per database level than not.
I wouldn't completely replace the current .ini configuration files
with a database -- I think there's real value in being able to change
some settings without the server running.
Given that how about _replication for a name?
Cheers
Simon
I like it.
On Aug 12, 2009, at 10:45 AM, Randall Leeds wrote:
fwiw, I can see it being very useful to be able to replicate a _config
database or a _replication database.
Just thinking about all the implications makes me nervous! I think
managing server configurations is probably best left to configuration
management tools like Opscode Chef and its ilk. I could be wrong
though. If we wanted to support this I think it would be easy enough
to do for _replication. Obviously for _config we'd need something
like what Simon proposed.
---
I'll push forward on the _replication DB for configuring continuous
replications, but I'm still not sure of the best path forward on
viewing/managing one-off replications. I'm torn between auto-saving a
document into the _replication DB, adding additional info to the
_local docs, or doing both (full info in the _replication DB, "public"
info in the _local doc). Best,
Adam
