https://github.com/dalibo/pgsql-resource-agent
Simple Pacemaker OCF Agent for two PostgreSQL servers in streaming replication
https://github.com/dalibo/pgsql-resource-agent
Last synced: about 1 year ago
JSON representation
Simple Pacemaker OCF Agent for two PostgreSQL servers in streaming replication
- Host: GitHub
- URL: https://github.com/dalibo/pgsql-resource-agent
- Owner: dalibo
- License: other
- Created: 2013-01-25T13:06:03.000Z (over 13 years ago)
- Default Branch: master
- Last Pushed: 2016-03-16T08:24:42.000Z (over 10 years ago)
- Last Synced: 2025-03-27T07:51:31.610Z (about 1 year ago)
- Language: Shell
- Size: 179 KB
- Stars: 11
- Watchers: 27
- Forks: 5
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
__WARNING__
After leaving in this repository for some time, the multistate agent ``pgsqlms``
has acquired its own identity! See: https://github.com/dalibo/PAF
The development effort is currently geared towards PAF and activity on
``pgsql-resource-agent`` is reduced to the minimum. We recommend you to use PAF
in priority.
# pgsql-resource-agent
Simple Pacemaker OCF Agent for PostgreSQL servers in streaming replication.
This resource agent is stateless (do not know what is a master or slave
resource) from the Pacemaker point of view. It is very limited, simple,
allowing only one failover then wait for an administrator action. It only shows
Pacemaker where the master instance is located. Should a failover occurs, it
will promote the slave on the designated node.
Supports PostgreSQL 9.0 and more.
## Description
This agent, called ``pgsqlsr``, suppose PostgreSQL instances are already set up
for replication: one master and N standby.
It has been designed to forbid more than **one** failover, so only one failover
could be automated. After a failover, an administrator action is required to
cleanup the situation.
Because this agent is stateless, Pacemaker does not monitor slaves and has no
clue about their situation. There is no logic whatsoever in case of
failover. Should a failover occurs, the agent is not able to hint Pacemaker
about the best standby to promote. The comportment is unpredictable.
That is why this resource agent is best used in two nodes clusters. With more
than 1 standby, the administrator is in charge to make sure the best standby
will be elected (using location constraints, synchronous replication,
cascading, ...).
To forbid more than one failover, the resource parameter ``startable`` is set to
the hostname of the promoted standby. As soon as this parameter is created and
set, the only instance able to start will be the one designated there.
After a failover, you will have to:
* rebuild your standby(s) if needed (eg. rebuild the old master as a slave)
* start PostgreSQL on standby(s)i
* cleanup your Pacemaker ressources, eg.: ``crm resource cleanup pgsqld``,
``crm resource cleanup pgsql-ip``
* check that everything works fine
* Allow a new automated failover: ``crm_resource --resource pgsqld --delete-parameter startable``
## Installation
Just copy the file ``pgsqlsr`` to your OCF_ROOT folder (usually
``/usr/lib/ocf/resource.d/heartbeat/``). Make sure the file has the executable
right and its owner is the same than the other scripts there.
## Configuration
This agent has been written to give to the administrator the maximum control
over their PostgreSQL configuration and architecture. Thus, you are 100%
responsible for the master/slave creations and their configuration. The agent
will NOT edit your setup. You just have to follow these pre-requisites:
* you __must__ give the location of your master during your cluster setup
* the cluster resource manager is responsible to start and stop your
PostgreSQL instances.
When setting up the resource in Pacemaker, here are the available parameters you
can set:
* ``bindir``: location of the PostgreSQL binaries (default: ``/usr/bin``)
* ``pgdata``: location of the PGDATA of your instance (default:
``/var/lib/pgsql/data``)
* ``system_user``: the system owner of your instance's processus (default:
postgres)
* ``trigger_file``: the trigger file to use to promote the slave instance.
This one is useful only for PostgreSQL 9.0, where ``pg_ctl promote`` does
not exists.
## Cluster setup example
Here is a cluster setup example, based on CentOS 5.x, using the ``crm`` command:
```
crm <