[ClusterLabs] Pacemaker PostgreSQL cluster

Ken Gaillot kgaillot at redhat.com
Tue May 29 11:22:59 EDT 2018

On Tue, 2018-05-29 at 14:23 +0200, Salvatore D'angelo wrote:
> Hi All,
> I am new to this list. I am working on a project that uses a cluster
> composed by 3 nodes (with Ubuntu 14.04 trusty) on which we run
> PostgreSQL managed as Master/slaves.
> We uses Pacemaker/Corosync to manage this cluster. In addition, we
> have a two node GlusterFS where we store backups and Wal files.
> Currently the versions of our components are quite old, we have:
> Pacemaker 1.1.14
> Corosync 2.3.5
> and we want to move to a new version of Pacemaker but I have some
> doubts.
> 1. I noticed there is 2.0.0 candidate release so it could be
> convenient for us move to this release. When will be published the
> final release? Is it convenient move to 2.0.0 or 1.1.18?

2.0.0 will hopefully be out in the next couple of weeks.

1.1.19 will be released shortly after that, containing bug fixes from
2.0.0 backported to the 1.1 line. Since there were some regressions in
1.1.18, I'd use 1.1.17 or wait for 1.1.19, if staying with the 1.1

The main goal of 2.0 is to remove deprecated functionality, so it
should not make a big difference in your case which one you choose.

> 2. I read some documentation about upgrade and since we want 0 ms
> downtime I think the Rolling Upgrade (node by node) is the better
> approach. We migrate a node and in the meantime the other two nodes
> are still active. The problem is that I do not know if I can have a
> mix of 1.1.14 and 1.1.18 (or 2.0.0) nodes. The documentation does not
> clarify it or at least it was not clear to me. Is this possible?
> http://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html/Pacemak
> er_Explained/ap-upgrade.html
> https://wiki.clusterlabs.org/wiki/Upgrade

Rolling upgrades are always supported within the same major number line
(i.e. 1.anything to 1.anything). With the major number change, rolling
upgrades will not always be supported. In the case of 2.0.0, we are
supporting rolling upgrades from 1.1.11 or later on top of corosync 2
or later. You should be fine whichever you choose.

You do want to keep a rolling upgrade window as short as practical.
Besides avoiding potential bugs in an inherently difficult to test
setup (i.e. we can't test all possible combinations of rolling
upgrades), once an older node in a mixed-version cluster is stopped, it
cannot rejoin the cluster until it is upgraded.

> 3. I need to upgrade pacemaker/corosync on Ubuntu 14.04. I noticed
> for 1.1.18 there are Ubuntu packages available. What about 2.0.0? Is
> it possible create Ubuntu packages in some way?

Debian will eventually pick up 2.0.0 in one of its releases, and then
Ubuntu will take it from there.

It's not too hard to build it from source yourself, but follow a
Debian-specific guide because there are differences from the vanilla
upstream release.

Using Ubuntu's 1.1.18 is probably the easiest and best way for you to
go -- I'm guessing the regression fixes were already backported into
those packages.

> 4. Where I can find the list of (ubuntu) dependencies required to
> pacemaker/corosync for 1.1.18 and 2.0.0?
> Thanks in advance for your help.
Ken Gaillot <kgaillot at redhat.com>

More information about the Users mailing list