On 3/21/16, 9:10 AM, "pgsql-general-ow...@postgresql.org on behalf of Rakesh 
Kumar" <pgsql-general-ow...@postgresql.org on behalf of 
rakeshkumar46...@gmail.com> wrote:


>On 03/21/2016 10:57 AM, Thomas Kellerer wrote:
>
>> So - at least as far as I can tell - it's usually only used where 
>> high-availability is really important, e.g. where zero-downtime is required.
>> If you can live with a short downtime, a hot standby is much cheaper and 
>> probably not that much slower.
>
>Even the above statement can be challenged , given the rising popularity 
>of nosql databases which are all based on
>eventual consistency (aka async replication).
>
>A PG with BDR and an application designed to read/write only
>one node via connection mapping can match the high availability
>requirement of RAC.
>
>BTW disk is a single point of failure in RAC.
>
>
>-- 
>Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-general

Disk is only a single point of failure in RAC if you configure non-redundant 
storage. In general, Oracle recommends triple mirroring to protect against disk 
failures, as they have had many experiences over the years where customers with 
mirrored disks would see consecutive disk failures within short periods of time.

And RAC is widely used by Oracle’s larger customers, not only for HA, but also 
in some cases for scale-out. Having said that, it’s very true that any 
application running on Oracle RAC must be configured to avoid hot block 
contention across RAC nodes, so it’s not a completely transparent solution for 
scale out.

-KJ (original product manager for Oracle Parallel Server, the distant ancestor 
of RAC)

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to