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 = http://example.com/foo http://example.net/bar
http:%2F%2Fexample.com%2Fbaz = 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 http://example.com/baz 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.
-Damien
