Re: Real application clustering in postgres.

Поиск
Список
Период
Сортировка
От Jeremy Schneider
Тема Re: Real application clustering in postgres.
Дата
Msg-id 89db5a96-9fc3-3ea9-bdc2-6cb2caaddbb0@ardentperf.com
обсуждение исходный текст
Ответ на Re: Real application clustering in postgres.  (Ron <ronljohnsonjr@gmail.com>)
Список pgsql-general
On 3/6/20 01:25, Ron wrote:
> On 3/5/20 6:07 AM, Laurenz Albe wrote:
>> On Thu, 2020-03-05 at 07:45 +0000, Daulat Ram wrote:
>>> Is there any possibility/options to setup a real application clustering in Postgres as in Oracle we have a  RAC
feature.
>> No, and as far as I know nobody feels interested in providing it.
>>
>> RAC is a complicated architecture that doesn't do much good, so most
>> people feel that it would be a waste of time and effort.
>>
>> RAC ist not really a scaling solution: because of the shared storage,
>> you can only scale for more CPUs; I/O remains the bottleneck.
>> RAC is not really a high availability solution: because of the shared
>> storage, it has a sibgle point of failure.
> 
> This is utter nonsense.  Dual redundant storage controllers connected to
> disks in RAID-10 configurations have been around for *at least* 25 years.
> 
> Oracle got it's clustering technology from DEC, and I *know* that
> works.  Cluster members, storage controllers and disks have all gone
> down, while the database and application keep on humming along.

Just want to point out that while the merits of RAC are considered as
universal truth in the Oracle marketing community, they are certainly
still debated and nuanced within the Oracle technical community.

Some great reading would be Mogens Norgaard's article "You Probably
Don't Need RAC" from 2003 (which is surprisingly hard to find on the
internet) and much of the ensuing discussion between then and now, for
example this recent message over on the oracle-l list:

https://www.freelists.org/post/oracle-l/Chuckleworthy-issue-of-the-NoCOUG-Journal,1

For my part, I spent many years running RAC clusters and solving the
usual handful of problems you bump into, and I definitely have a strong
bias now toward as simple of architectures as possible.  Regardless of
which parties participate in your operations, and regardless of who owns
the data center where your stack is running.  Note that I apply this to
all the new databases as well. I enjoy and appreciate the opportunities
I've had to work on some really interesting new technology - but I also
still see merit in simple, boring, mature, well-understood architectures
if they are doing the job. Complexity will find us all soon enough
driven by true business needs without being helped by the pursuit of
shiny things!

It seemed to me there was a major and well-funded effort to market and
sell cluster databases for many years, and as a result I suspect that
while there are certainly some good use cases, there are probably also
some people using RAC today who would do fine (or better) without it.

Seems I even touched on this all the way back in 2007 in an article on
my own blog...  https://ardentperf.com/2007/05/10/fidelity-case-study/

-Jeremy

-- 
http://about.me/jeremy_schneider



В списке pgsql-general по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Is it safe to rename an index through pg_class update?
Следующее
От: Ted Toth
Дата:
Сообщение: libpq and escaping array string literals