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