William Yu wrote:
Another tidbit I'd like to add. What has helped a lot in implementing
high-latency master-master replication writing our software with a
business process model in mind where data is not posted directly to
the final tables. Instead, users are generally allowed to enter
anything -- could be incorrect, incomplete or the user does not have
rights -- the data is still dumped into "pending" tables for people
with rights to fix/review/approve later. Only after that process is
the data posted to the final tables. (Good data entered on the first
try still gets pended -- validation phase simply assumes the user who
entered the data is also the one who fixed/reviewed/approved.)
In this case, why have multimaster replication at all?
Why not have the people who have rights to review this all write to the
master database and have that replicated back? It seems like latency is
not really an issue. Replication here is only going to complicate
things. If it were me, I would be having my approval app pull data from
*all* of the databases independently and not rely on the replication for
this part. The replication could then be used to replicate *approved*
data back to the slaves.
There may be a delay for the user if he/she is working on a server
that doesn't have rights to post his data. However, the pending->post
model gets users used to the idea of (1) entering all data in large
swoop and validating/posting it afterwards and (2) data can/will sit
in pending for a period of time until it is acted upon with
somebody/some server with the proper authority. Hence users aren't
expecting results to pop up on the screen the moment they press the
submit button.
I still don't understand the purpose of replicating the pending data...
Best Wishes,
Chris Travers
Metatron Technology Consulting
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
