On 2/4/2005 5:56 AM, Mike Nolan wrote:
>> If you have so much update load that one server cannot accomodate that
>> load, then you should wonder why you'd expect that causing every one
>> of these updates to be applied to (say) 3 servers would "diminish"
>> this burden.
>
> The update/query load isn't the real issue here, it's that these two
> servers will be 800 miles apart and there are some advantages in having
> each office connect to its local database rather than having one of
> them connect to the remote master.
You do realize that any multimaster replication system, that is designed
to avoind complex business process structure based conflict resolution
mechanisms, necessarily has to be based on 2 phase commit or similar? So
your global write transaction throughput will be limited by the latency
of your WAN, no matter what bandwidth you have. And as per RFC 1925: No
matter how hard you push and no matter what the priority, you can't
increase the speed of light.
I think what you are really looking for is an application internal
abstraction layer based multmaster replication approach.
Jan
>
> The Slony-1 approach will work, assuming I've got suffient network
> bandwidth to support it plus the traffic from the remote office plus
> exixting outside traffic from our public website.
>
> That's one of those things you just don't know will work until you
> have it built, so I'm looking for other options now while I have time
> to consider them. Once I get on-site in two weeks it'll a lot more hectic.
> --
> Mike Nolan
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
