couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: permanent replications API discussion
Date Sat, 30 May 2009 22:11:52 GMT

On May 30, 2009, at 4:54 PM, Adam Kocoloski wrote:

> Hi all, one of the proposed features we've had in the pipeline is  
> the ability to set up permanent replications between two databases.   
> It's always been possible to do this with a bit of  
> update_notification work from a local source DB, but the new  
> _changes API makes it possible to set it up with a remote source.
> I'm happy to implement this feature (and have done a good bit of the  
> groundwork already), but I'd like to talk about the configuration  
> API.  My first crack at this was a config block that looked like
> [replications]
> dbname =
> = foo
> the first line tells the server to push all changes to "dbname" out  
> to the two remote URLs. The second line tells it to listen for  
> changes to and pull them into foo.  The URL  
> is encoded so that it works with the _config HTTP API.
> On IRC Damien suggested using a special DB for replication settings  
> instead.  I haven't thought that much about it.
> I'd like to get some feedback from others before committing  
> anything.  Thanks, Adam

Some random thoughts.

I think there should be a "server_name" setting in the ini file,  
that's either a DNS name or IP address for the server. Within an  
organization, all servers can share the same replication settings  
database. Each server gets it's settings by looking up it's settings  
using it's own name to find setting and replication documents.

There will likely be a document for each scheduled or persisted  
replication. There will be name of the server that is initiating the  
replication, the source database, and the target database. The  
document will have settings for things like when to replicate, how  
often to retry failed replications, use SSL, what proxy server and  
HTTP credentials to use, etc. The replication manager will look up  
these settings and initiate replications with the appropriate  
settings, as well as notice when the settings have changes and then  
relaunches the replicators.

In addition to the replications settings, the replicator may also want  
to write documents with the results of the last replication, to allow  
for monitoring the replication statuses by external processes (like  
daemon that listens for failures and sends a SMS). This could be the  
same database as the replication settings, or a new database that just  
keep the status of replications. Or the status all sorts of scheduled  
tasks. Hmmmm, maybe we need a generalized chron facility. Not sure.


View raw message