[ClusterLabs] Pacemaker PostgreSQL cluster

[Salvatore D'angelo]

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/Pacemaker_Explained/ap-upgrade.html <http://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html/Pacemaker_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? 
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?
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/+build <https://launchpad.net/ubuntu/+source/pacemaker/1.1.18-0ubuntu2/+build>
>> /14818856
>> 
>> It’s not clear to me why pacemaker 1.1.18 is available on
>> launchpad.net <http://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 dalibo.
>>> 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 <mailto:Users at clusterlabs.org>
>> https://lists.clusterlabs.org/mailman/listinfo/users <https://lists.clusterlabs.org/mailman/listinfo/users>
>> 
>> Project Home: http://www.clusterlabs.org <http://www.clusterlabs.org/>
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch <http://www.clusterlabs.org/doc/Cluster_from_Scratch>.
>> pdf
>> Bugs: http://bugs.clusterlabs.org <http://bugs.clusterlabs.org/>
> -- 
> Ken Gaillot <kgaillot at redhat.com <mailto:kgaillot at redhat.com>>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org <mailto:Users at clusterlabs.org>
> https://lists.clusterlabs.org/mailman/listinfo/users <https://lists.clusterlabs.org/mailman/listinfo/users>
> 
> Project Home: http://www.clusterlabs.org <http://www.clusterlabs.org/>
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf <http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf>
> Bugs: http://bugs.clusterlabs.org <http://bugs.clusterlabs.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180530/1757ecf3/attachment-0002.html>