2. It seems like there's a point at which explicit 1-1 replication
starts to be an administrative nightmare. Some kind of publish-
subscribe or multi-cast update model seems needed.
Would the new continuous replication feature be what you need? With
this all changes to A get automatically replicated to B, if I get
things right here...
Well it's more of, when I change A, I want the changes to propagate
to B through Z (or "all") - with some sort of multi-cast addressing
rather than having to identify every node explicitly.
Hm, I guess you would have to create/write/program a custom layer on
top of each CouchDB instance. Maybe an adpted version of the couchdb-
proxy [1] that would listen on the multicast address. With this you
could notice new instances being up and the replication from the
master machines would be handled by the proxy, i.e. the proxy would
send the replication commands to the master. You could then even do
this in layers of proxies and CouchDBs...
But: while writing the above lines I notice that you may be want to
have a look at Zookeeper [2] !?
ZooKeeper is a centralized service for maintaining configuration
information, naming, providing distributed synchronization, and
providing group services.
You could basically wrap the start script and write additional
information (like the CouchDB URL) into Zookeeper. One node could then
periodically read the info about existing CouchDB instances and
trigger or configure the replications...
Daniel
[1]: http://github.com/benoitc/couchdbproxy
[2]: http://hadoop.apache.org/zookeeper/
