On 3/21/16, 9:10 AM, "pgsql-general-owner@xxxxxxxxxxxxxx on behalf of Rakesh Kumar" <pgsql-general-owner@xxxxxxxxxxxxxx on behalf of rakeshkumar464a3@xxxxxxxxx> 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@xxxxxxxxxxxxxx) >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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
