Re: [ClusterLabs] Mysql upgrade in DRBD setup

On Thu, 2017-10-12 at 18:51 +0200, Attila Megyeri wrote: > Hi all, >   > What is the recommended mysql server upgrade methodology in case of > an active/passive DRBD storage? > (Ubuntu is the platform) If you want to minimize downtime in a MySQL upgrade, your best bet is to use MySQL native

Re: [ClusterLabs] Mysql upgrade in DRBD setup

Hi, This does not really answer my question. Placing the cluster into maintenance mode just avoids monitoring and restarting, but what about the things I am asking below? (data dir related questions) thanks From: Kristián Feldsam [mailto:ad...@feldhost.cz] Sent: Thursday, October 12, 2017

Re: [ClusterLabs] Mysql upgrade in DRBD setup

hello, you should put cluster to maintenance mode Sent from my MI 5On Attila Megyeri , Oct 12, 2017 6:55 PM wrote:Hi all, What is the recommended mysql server upgrade methodology in case of an active/passive DRBD storage?(Ubuntu is the platform) 1)      On the

[ClusterLabs] Mysql upgrade in DRBD setup

Hi all, What is the recommended mysql server upgrade methodology in case of an active/passive DRBD storage? (Ubuntu is the platform) 1) On the passive node the mysql data directory is not mounted, so the backup fails (some postinstall jobs will attempt to perform manipulations on

Re: [ClusterLabs] can't move/migrate ressource

On Wed, 2017-10-11 at 13:58 +0200, Stefan Krueger wrote: > Hello, > > when i try to migrate a ressource from one server to an other (for > example for maintenance), it don't work. > a single ressource works fine, after that I create a group with 2 > ressources and try to move that. > > my config

Re: [ClusterLabs] Debugging problems with resource timeout without any actions from cluster

On Thu, 2017-10-12 at 17:13 +0600, Sergey Korobitsin wrote: > Hello, > I experience some strange problem on MySQL resource agent from > Percona: > sometimes monitor operation for it killed by lrmd due to timeout, > like > this: > > Oct 12 12:26:46 sde1 lrmd[14812]:  warning: p_mysql_monitor_5000

Re: [ClusterLabs] corosync race condition when node leaves immediately after joining

On 12/10/17 11:54, Jan Friesse wrote: > Jonathan, > >> >> >> On 12/10/17 07:48, Jan Friesse wrote: >>> Jonathan, >>> I believe main "problem" is votequorum ability to work during sync >>> phase (votequorum is only one service with this ability, see >>> votequorum_overview.8 section VIRTUAL

Re: [ClusterLabs] trouble with IPaddr2

On Wed, Oct 11, 2017 at 02:36:24PM +0200, Valentin Vidic wrote: > AFAICT, it found a better interface with that subnet and tried > to use it instead of the one specified in the parameters :) > > But maybe IPaddr2 should just skip interface auto-detection > if an explicit interface was given in

Re: [ClusterLabs] corosync race condition when node leaves immediately after joining

On 12/10/17 07:48, Jan Friesse wrote: Jonathan, I believe main "problem" is votequorum ability to work during sync phase (votequorum is only one service with this ability, see votequorum_overview.8 section VIRTUAL SYNCHRONY)... Hi ClusterLabs, I'm seeing a race condition in corosync

Re: [ClusterLabs] corosync race condition when node leaves immediately after joining

Jonathan, I believe main "problem" is votequorum ability to work during sync phase (votequorum is only one service with this ability, see votequorum_overview.8 section VIRTUAL SYNCHRONY)... Hi ClusterLabs, I'm seeing a race condition in corosync where votequorum can have incorrect

[ClusterLabs] Regression in Filesystem RA

Hello, 2nd post in 10 years, lets see if this one gets an answer unlike the first one... One of the main use cases for pacemaker here are DRBD replicated active/active mailbox servers (dovecot/exim) on Debian machines. We've been doing this for a loong time, as evidenced by the oldest pair