From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Tim Uckun <timuckun(at)gmail(dot)com> |
Cc: | Serge Fonville <serge(dot)fonville(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL clustering with DRBD |
Date: | 2009-03-03 22:30:40 |
Message-ID: | dcc563d10903031430o311226beod0132c8d0ed09164@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Mar 3, 2009 at 3:57 AM, Tim Uckun <timuckun(at)gmail(dot)com> wrote:
>
>>
>>
>> Again, this is a lot of work to avoid master / slave with failover.
>> Are you sure it's really needed for your situation?
>>
>
> What is the most straightforward and simple way to achieve master slave with
> failover?
We use Slony at work, which has a pretty easily run command to
failover. We initiate failover at the application level when a
majority of the servers agree that the primary is no longer
responding.
> Preferably a solution that would have decent monitoring, alerting and
> failback capacity.
We had to write out own alerting and such back in the day. Nagios can
definitely keep you apprised of things happening. So can a collection
of shell scripts. I'm afraid I know of no pre-made pre-wrapped
packages to do what you want. Then again, each solution needs to fit
the needs of the user, so it's hard to just have one size fit all
here.
> It would be also nice if you could use the standby as a read only database
> for reporting or something.
That works wonderfully well with Slony. We actually have one master,
one failover slave that would take over in the case of the master
going down, and x read slaves that read from that machine for the web
app to read. Allows pretty good scalability and redundancy.
The problem with multi-master is that you can either have good
performance or good redundancy, but it's hard to get both. And don't
hold up RAC as an example of great multi-master. It's overly complex,
tends to fail individual nodes a lot and costs an arm and a leg. And
performance wise it's definitely a meh grade solution for most
applications.
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2009-03-03 22:37:59 | Re: how to use pg_dump to dump tables whose owner is me |
Previous Message | Gregory Stark | 2009-03-03 20:51:09 | Re: Strange behavior: row won't delete |