[ClusterLabs] Pacemaker PostgreSQL cluster

[Ken Gaillot]

On Wed, 2018-05-30 at 09:31 +0200, Salvatore D'angelo wrote:
> Hi,
> 
> Last question. In order to migrate pacemaker with minimum downtime
> the option I see are Rolling (node by node) and Disconnect Reattach
> http://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html/Pacemak
> er_Explained/ap-upgrade.html
> 
> What I want to do is first migrate pacemaker manually and then
> automate it with some scripts.
> 
> According to what Ken Gaillot said:
> 
> "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.”
> 
> if I implement a set of scripts based on Rolling upgrade to migrate
> from 1.1.14 to 1.1.18/2.0.0 the risk is that in the future if there
> will be an upgrade with major number change I should rewrite my
> automation script to support another type of migration (probably
> Detach and Reattach). My question is, if I want to avoid this extra
> work in the future, is the Detach Reattach procedure more adaptable
> to whatever version migration? 

Each approach has its advantages and disadvantages. Detach+reattach is
indeed more adaptable to version changes and even underlying cluster
layer changes. Its downsides are that you can't do it with Pacemaker
Remote nodes, and there is no HA during the upgrade.

BTW while it's hard to predict, I suspect there won't be another major
bump for another decade.

> My understanding is that with this procedure PostgreSQL will always
> be up and running and I only need detach pacemaker from them on the
> three nodes, migrate them and then Reattach. During this period What
> happen if PostgreSQL master goes down?

As you probably suspected, there will be no automatic recovery.

> Thanks again for support.
> 
> > On 30 May 2018, at 04:04, Ken Gaillot <kgaillot at redhat.com> wrote:
> > 
> > On Tue, 2018-05-29 at 22:25 +0200, Salvatore D'angelo wrote:
> > > Hi,
> > > 
> > > Regarding last question about pacemaker dependencies for Ubuntu I
> > > found this for 1.1.18:
> > > https://launchpad.net/ubuntu/+source/pacemaker/1.1.18-0ubuntu2/+b
> > > uild
> > > /14818856
> > > 
> > > It’s not clear to me why pacemaker 1.1.18 is available on
> > > launchpad.net and not on the official Ubuntu Search Packages
> > > website.
> > > However, can I assume 1.1.19 and 2.2.0 have the same dependencies
> > > list (considering they have only removed deprecated function and
> > > applied some bug fixes)?
> > 
> > Yes, the dependencies should be the same (when corosync 2 is used)
> > 
> > > Thanks again for answers
> > > 
> > > 
> > > > On 29 May 2018, at 17:41, Jehan-Guillaume de Rorthais <jgdr at dal
> > > > ibo.
> > > > com> wrote:
> > > > 
> > > > On Tue, 29 May 2018 14:23:31 +0200
> > > > Salvatore D'angelo <sasadangelo at gmail.com> wrote:
> > > > ...
> > > > > 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.
> > > > 
> > > > The 0ms upgrade is almost impossible. At some point, you will
> > > > have
> > > > to move the
> > > > master somewhere else.
> > > > 
> > > > Unless you have some session management that are able to wait
> > > > for
> > > > the
> > > > current sessions to finish, then hold the incoming sessions
> > > > while
> > > > you are
> > > > moving the master, you will have downtime and/or xact rollback.
> > > > 
> > > > Good luck anyway :)
> > > > 
> > > > -- 
> > > > Jehan-Guillaume de Rorthais
> > > > Dalibo
> > > 
> > > _______________________________________________
> > > Users mailing list: Users at clusterlabs.org
> > > https://lists.clusterlabs.org/mailman/listinfo/users
> > > 
> > > Project Home: http://www.clusterlabs.org
> > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scra
> > > tch.
> > > pdf
> > > Bugs: http://bugs.clusterlabs.org
> > -- 
> > Ken Gaillot <kgaillot at redhat.com>
> > _______________________________________________
> > Users mailing list: Users at clusterlabs.org
> > https://lists.clusterlabs.org/mailman/listinfo/users
> > 
> > Project Home: http://www.clusterlabs.org
> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratc
> > h.pdf
> > Bugs: http://bugs.clusterlabs.org
> 
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.
> pdf
> Bugs: http://bugs.clusterlabs.org
-- 
Ken Gaillot <kgaillot at redhat.com>