Interesting feedback.
It strikes me that, for many sorts of databases, multimaster synchronous
replication is not the best solution for the reasons that Scott, Jan, et.
al. have raised. I am wondering how commercial RDBMS's get arround this
problem? There are several possibilities that I can think of-- have a write
master, and many read-only slaves (available at the moment, iirc).
Replication could then occur at the tuple level using linked databases,
triggers, etc. Rewrite rules could then allow one to use the slaves to
"funnel" the queries back up to the master. It seems to me that latency
would be a killer on this sort of solution, though everything would
effectively occur on all databases in the same order, but recovering from a
crash of the master could be complicated and result in additional
downtime...
The other solution (still not "guaranteed" to work in all cases) is that
every proxy could be hardwired to attempt to contact databases in a set
order. This would also avoid deadlocks. Note that if sufficient business
logic is built into the database, one would be guaranteed that a single
"consistent" view would be maintained at any given time (conflicts would
result in the minority of up to 50 percent of the servers needing to go
through the recovery process-- not killing uptime, but certainly killing
performance).
However, it seems to me that the only solution for many of these databases
is to have a "cluster in a box" solution where you have a system comprised
entirely of redundent, hot-swapable hardware so that nearly anything can be
swapped out if it breaks. In this case, we should be able to just run
PostgreSQL as is....
