Chris Browne <cbbrowne@acm.org> writes:
> Well, what you clearly want/need is asynchronous multimaster...
I didn't catch anything in his description that answered whether he needs
multimaster or a simple single master with many slaves model would suffice.
> I'm involved with Slony-I, which is asynchronous but definitely,
> consciously, intentionally NOT multimaster.
>
> It seems to me that you might be able to usefully cannibalize
> components from Slony-I; the trigger functions that it uses to
> intercept updates seem likely to be useful. Some of the data
> structures would be useful, notably "sl_log_1", which is where the
> updates are collected.
A general purpose replication system is a lot trickier and more technical that
building an application-specific system. While all of the above is cool, if
you're able to design the application around certain design constraints you
can probably build something much simpler.
My first reaction to this description was to consider some sort of model where
the master database publishes text dumps of the master database which are
regularly downloaded and loaded on the slaves. The slaves treat those tables
as purely read-only reference tables.
If you need data to propagate from the clients back to the server then things
get more complicated. Even then you could side step a lot of headaches if you
can structure the application in specific ways, such as guaranteeing that the
clients can only insert, never update records.
--
greg