On 09/26/2012 01:02 AM, md@rpzdesign.com wrote:
> John:
>
> Who has the money for oracle RAC or funding arrogant bastard Oracle
> CEO Ellison to purchase another island?
>
> Postgres needs CHEAP, easy to setup, self healing,
> master-master-master-master and it needs it yesterday.
>
> I was able to patch the 9.2.0 code base in 1 day and change my entire
> architecture strategy for replication
> into self healing async master-master-master and the tiniest bit of
> sharding code imaginable
Tell us about the compromises you had to make.
It is an established fact that you can either have it replicate fast and
loose or slow and correct.
In the fast and loose case you have to be ready to do a lot of
mopping-up in case of conflicts.
> That is why I suggest something to replace OIDs with ROIDs for
> replication ID. (CREATE TABLE with ROIDS)
> I implement ROIDs as a uniform design pattern for the table structures.
>
> Synchronous replication maybe between 2 local machines if absolutely
> no local
> hardware failure is acceptable, but cheap, scaleable synchronous,
Scaleable / synchronous is probably doable, if we are ready to take the
initial performance hit of lock propagation.
> TRANSACTIONAL, master-master-master-master is a real tough slog.
>
> I could implement global locks in the external replication layer if I
> choose, but there are much easier ways in routing
> requests thru the load balancer and request sharding than trying to
> manage global locks across the WAN.
>
> Good luck with your HA patch for Postgres.
>
> Thanks for all of the responses!
>
> You guys are 15 times more active than the MySQL developer group,
> likely because
> they do not have a single db engine that meets all the requirements
> like PG.
>
> marco
>
> On 9/25/2012 5:10 PM, John R Pierce wrote:
>> On 09/25/12 11:01 AM, md@rpzdesign.com wrote:
>>>
>>>
>>> At some point, every master - slave replicator gets to the point
>>> where they need
>>> to start thinking about master-master replication.
>>
>> master-master and transactional integrity are mutually exclusive,
>> except perhaps in special cases like Oracle RAC, where the masters
>> share a coherent cache and implement global locks.
>>
>>
>>
>>
>>
>
>
>
