Re: On "multi-master" - Mailing list pgsql-general

From Alex Turner
Subject Re: On "multi-master"
Date
Msg-id 33c6269f0510140649h610d22ect19ff383b624e6dbe@mail.gmail.com
Whole thread Raw
In response to Re: On "multi-master"  (Chris Travers <chris@metatrontech.com>)
List pgsql-general
 <snip>
>multi-master.  It provides a certain amount of scaling, but nothing
>I've seen or heard suggests that the license cost couldn't just as
>easily and effectively be thrown at larger hardware for better
>scaling.  The really big reason to use RAC is five-nines situations:
>you're trying to make sure that even unlikely failures of your
>machines never cause the database to stop working (for suitably
>lawyer-understood values of "stop".  RAC remastering is not a
>zero-cost, nor even invisible, operation.  But from an application
>perspective, it can be made to look like "database is slow" as
>opposed to "database crashed").
>
>
So this is basically a multimaster synchronous replication solution
utilizing a shared disk architecture.  I generally agree with your
assessment that the license costs could be better spent on redundant
hardware and more scalable hardware.  Also if the shared disk fails, you
may lose everything after your last backup.


Of course thats highly unlikely because in Oracle you have _two_ complete copies of your active database from your last backup with archive redo logs, so in reality you would have to loose your _entire_ disk cluster, which if you have things organised by the book, you would have archive redo on a seperate controller, and preferably on a seperate array for that very reason.

Oracle though this out pretty well ;)
 

<snip>

pgsql-general by date:

Previous
From: "John D. Burger"
Date:
Subject: Equivalent queries and the planner
Next
From: "Magnus Hagander"
Date:
Subject: Re: Using LISTEN/NOTIFY in C#.NET