Обсуждение: Heartbeat + pacemaker configuration for PostgreSQL log shipping
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
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
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
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
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
On Mon, Feb 21, 2011 at 10:00 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
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
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
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
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-shipping-tp3394494p3396099.html Sent from the PostgreSQL - admin mailing list archive at Nabble.com.