Re: [ClusterLabs] Pacemaker PostgreSQL cluster

2018-05-30 Thread 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  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  > > > ibo.
> > > > com> wrote:
> > > > 
> > > > On Tue, 29 May 2018 14:23:31 +0200
> > > > Salvatore D'angelo  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@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 
> > ___
> > Users mailing list: Users@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@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 
___
Users mailing list: Users@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

Re: [ClusterLabs] Pacemaker PostgreSQL cluster

2018-05-30 Thread 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
 


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  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 
>> 
>> /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 >> com> wrote:
>>> 
>>> On Tue, 29 May 2018 14:23:31 +0200
>>> Salvatore D'angelo  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@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 mailto:kgail...@redhat.com>>
> ___
> Users mailing list: Users@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 
___
Users mailing list: Users@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

Re: [ClusterLabs] Pacemaker PostgreSQL cluster

2018-05-29 Thread Ken Gaillot 
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
> /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  > com> wrote:
> > 
> > On Tue, 29 May 2018 14:23:31 +0200
> > Salvatore D'angelo  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@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 
___
Users mailing list: Users@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

Re: [ClusterLabs] Pacemaker PostgreSQL cluster

2018-05-29 Thread Salvatore D'angelo 
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/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)?
Thanks again for answers


> On 29 May 2018, at 17:41, Jehan-Guillaume de Rorthais  wrote:
> 
> On Tue, 29 May 2018 14:23:31 +0200
> Salvatore D'angelo  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@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

Re: [ClusterLabs] Pacemaker PostgreSQL cluster

2018-05-29 Thread Jehan-Guillaume de Rorthais 
On Tue, 29 May 2018 14:23:31 +0200
Salvatore D'angelo  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@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

Re: [ClusterLabs] Pacemaker PostgreSQL cluster

2018-05-29 Thread Ken Gaillot 
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
line.

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 
___
Users mailing list: Users@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