pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedHeartbeat + pacemaker configuration for PostgreSQL log shipping
6+ messages / 5 participants
[nested] [flat]
* Heartbeat + pacemaker configuration for PostgreSQL log shipping
@ 2011-02-21 17:26 Jody McIntyre <jodym@trustcentric.com>
2011-02-22 00:55 ` Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping Selva manickaraja <mavles78@gmail.com>
2011-02-22 03:00 ` Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping Fujii Masao <masao.fujii@gmail.com>
2011-02-22 20:15 ` Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping Isabella Ghiurea <isabella.ghiurea@nrc-cnrc.gc.ca>
0 siblings, 3 replies; 6+ messages in thread
From: Jody McIntyre @ 2011-02-21 17:26 UTC (permalink / raw)
To: pgsql-admin
Has anyone successfully configured heartbeat + pacemaker (or any other HA
package for that matter) to control PostgreSQL in log shipping mode? All
the examples I've found use drbd.
My current thinking is to start/stop the database as in a non HA setup
(using upstart, since this is Ubuntu), and write a custom pacemaker resource
agent such that:
- "start" on the secondary creates a trigger file and waits for recovery to
complete before returning success. "stop" does nothing (returns success.)
Pacemaker would be configured for manual failback.
- "start" and "stop" on the primary does nothing. We would STONITH the
primary before taking over the database.
Does this sound reasonable? Has anyone else tried this?
Thanks,
Jody
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping
2011-02-21 17:26 Heartbeat + pacemaker configuration for PostgreSQL log shipping Jody McIntyre <jodym@trustcentric.com>
@ 2011-02-22 00:55 ` Selva manickaraja <mavles78@gmail.com>
2 siblings, 0 replies; 6+ messages in thread
From: Selva manickaraja @ 2011-02-22 00:55 UTC (permalink / raw)
To: Jody McIntyre <jodym@trustcentric.com>; +Cc: pgsql-admin
Hi,
Your email just came in time. We are planning to build a heartbeat but have
not decided on the right approach. Maybe we can work together.
Thank you.
Warmest Regards,
Selvam
On Tue, Feb 22, 2011 at 1:26 AM, Jody McIntyre <jodym@trustcentric.com>wrote:
> Has anyone successfully configured heartbeat + pacemaker (or any other HA
> package for that matter) to control PostgreSQL in log shipping mode? All
> the examples I've found use drbd.
>
> My current thinking is to start/stop the database as in a non HA setup
> (using upstart, since this is Ubuntu), and write a custom pacemaker resource
> agent such that:
>
> - "start" on the secondary creates a trigger file and waits for recovery to
> complete before returning success. "stop" does nothing (returns success.)
> Pacemaker would be configured for manual failback.
> - "start" and "stop" on the primary does nothing. We would STONITH the
> primary before taking over the database.
>
> Does this sound reasonable? Has anyone else tried this?
>
> Thanks,
> Jody
>
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping
2011-02-21 17:26 Heartbeat + pacemaker configuration for PostgreSQL log shipping Jody McIntyre <jodym@trustcentric.com>
@ 2011-02-22 03:00 ` Fujii Masao <masao.fujii@gmail.com>
2011-02-22 14:53 ` Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping Jody McIntyre <jodym@trustcentric.com>
2 siblings, 1 reply; 6+ messages in thread
From: Fujii Masao @ 2011-02-22 03:00 UTC (permalink / raw)
To: Jody McIntyre <jodym@trustcentric.com>; +Cc: pgsql-admin
On Tue, Feb 22, 2011 at 2:26 AM, Jody McIntyre <jodym@trustcentric.com> wrote:
> Has anyone successfully configured heartbeat + pacemaker (or any other HA
> package for that matter) to control PostgreSQL in log shipping mode? All
> the examples I've found use drbd.
>
> My current thinking is to start/stop the database as in a non HA setup
> (using upstart, since this is Ubuntu), and write a custom pacemaker resource
> agent such that:
>
> - "start" on the secondary creates a trigger file and waits for recovery to
> complete before returning success. "stop" does nothing (returns success.)
> Pacemaker would be configured for manual failback.
> - "start" and "stop" on the primary does nothing. We would STONITH the
> primary before taking over the database.
>
> Does this sound reasonable?
The resource agents for MySQL and DRBD have been implemented as
master/slave ones. So I think that the resource agent for PostgreSQL also
should be done the same way, i.e., you should implement only "start" and
"stop" but also "promote" and "demote".
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping
2011-02-21 17:26 Heartbeat + pacemaker configuration for PostgreSQL log shipping Jody McIntyre <jodym@trustcentric.com>
2011-02-22 03:00 ` Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping Fujii Masao <masao.fujii@gmail.com>
@ 2011-02-22 14:53 ` Jody McIntyre <jodym@trustcentric.com>
2011-02-22 17:22 ` Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping Cédric Villemain <cedric.villemain.debian@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Jody McIntyre @ 2011-02-22 14:53 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: pgsql-admin
On Mon, Feb 21, 2011 at 10:00 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> The resource agents for MySQL and DRBD have been implemented as
> master/slave ones. So I think that the resource agent for PostgreSQL also
> should be done the same way, i.e., you should implement only "start" and
> "stop" but also "promote" and "demote".
>
The trouble with postgres is there's no easy way to "demote" a master
machine to a slave. You need to create a new master, back up its database,
and restore it onto the slave before starting it. This seems difficult to
implement, and pacemaker is already very complicated as it is.
We are seriously considering writing our own tool that simply tests the
master from the slave, and runs a very simple shell script to take over if
necessary.
Cheers,
Jody
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping
2011-02-21 17:26 Heartbeat + pacemaker configuration for PostgreSQL log shipping Jody McIntyre <jodym@trustcentric.com>
2011-02-22 03:00 ` Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping Fujii Masao <masao.fujii@gmail.com>
2011-02-22 14:53 ` Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping Jody McIntyre <jodym@trustcentric.com>
@ 2011-02-22 17:22 ` Cédric Villemain <cedric.villemain.debian@gmail.com>
0 siblings, 0 replies; 6+ messages in thread
From: Cédric Villemain @ 2011-02-22 17:22 UTC (permalink / raw)
To: Jody McIntyre <jodym@trustcentric.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; pgsql-admin
2011/2/22 Jody McIntyre <jodym@trustcentric.com>:
> On Mon, Feb 21, 2011 at 10:00 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>
>> The resource agents for MySQL and DRBD have been implemented as
>> master/slave ones. So I think that the resource agent for PostgreSQL also
>> should be done the same way, i.e., you should implement only "start" and
>> "stop" but also "promote" and "demote".
>
> The trouble with postgres is there's no easy way to "demote" a master
> machine to a slave. You need to create a new master, back up its database,
> and restore it onto the slave before starting it. This seems difficult to
> implement, and pacemaker is already very complicated as it is.
>
> We are seriously considering writing our own tool that simply tests the
> master from the slave, and runs a very simple shell script to take over if
> necessary.
>
We have some work in progress in repmgr for that. And it offers
stronger choice when you have several standby and want to pick the
most up to date to become a new master.
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Heartbeat + pacemaker configuration for PostgreSQL log shipping
2011-02-21 17:26 Heartbeat + pacemaker configuration for PostgreSQL log shipping Jody McIntyre <jodym@trustcentric.com>
@ 2011-02-22 20:15 ` Isabella Ghiurea <isabella.ghiurea@nrc-cnrc.gc.ca>
2 siblings, 0 replies; 6+ messages in thread
From: Isabella Ghiurea @ 2011-02-22 20:15 UTC (permalink / raw)
To: pgsql-admin
Hi,
we spend some time looking to use heartbeat Pg 9.0 and warm standby
replication option to configure a "master/slave" system. At the end we
have implemented DRBD and STONITH for a master Pg server, DRBD is been
used for for all Pg db directories the only exception is the Pg software and
backup directory, so far we like that the fail over procedure is very
simple and time efficient , Pg is in consistency state always after a clean
or "immediate/fast" shutdown ; the downside : this solution is protecting us
only from hardware issues not software/Pg issues aka :Pg data, log files
corruption.
Hope this may help with your decision,
Isabella
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Heartbeat-pacemaker-configuration-for-PostgreSQL-log-shippin...
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2011-02-22 20:15 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-02-21 17:26 Heartbeat + pacemaker configuration for PostgreSQL log shipping Jody McIntyre <jodym@trustcentric.com>
2011-02-22 00:55 ` Selva manickaraja <mavles78@gmail.com>
2011-02-22 03:00 ` Fujii Masao <masao.fujii@gmail.com>
2011-02-22 14:53 ` Jody McIntyre <jodym@trustcentric.com>
2011-02-22 17:22 ` Cédric Villemain <cedric.villemain.debian@gmail.com>
2011-02-22 20:15 ` Isabella Ghiurea <isabella.ghiurea@nrc-cnrc.gc.ca>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox