Re: [ClusterLabs] Upgrading an Ubuntu 18.04 failover System

[hajo . locke]

Hello,

 






> While the Pacemaker versions support rolling upgrades, those Corosync
> versions do not, so you'll have to do the detach-and-reattach method.

> The main reason to do a new cluster instead is if you want to do some
> testing before making it live.
> --
> Ken Gaillot 
 




 

thanks for your answer.  So upgrading detached nodes will result in downtime of haproxy and may disclose some  other surprises...

I think building a new cluster is the best way to avoid downtimes. In my case i could switch by DNS to new clusterservers and achive a mostly seemless transition of use.

 

Thank you,

Hajo

 

 
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/

Re: [ClusterLabs] Upgrading an Ubuntu 18.04 failover System

[Ken Gaillot]

On Wed, 2023-02-01 at 09:02 +0100, hajo.lo...@gmx.de wrote:
> Hello,
>  
> 
> 
> > While the Pacemaker versions support rolling upgrades, those
> Corosync
> > versions do not, so you'll have to do the detach-and-reattach
> method.
> 
> > The main reason to do a new cluster instead is if you want to do
> some
> > testing before making it live.
> > --
> > Ken Gaillot 
>  
>  
> thanks for your answer.  So upgrading detached nodes will result in
> downtime of haproxy and may disclose some  other surprises...
> I think building a new cluster is the best way to avoid downtimes. In
> my case i could switch by DNS to new clusterservers and achive a
> mostly seemless transition of use.
>  
> Thank you,
> Hajo

The DNS transition is a good plan since it gives you a chance to do
some testing beforehand. (It's a good idea to lower the TTLs on your
DNS records to something like 1 hour, at least as far ahead of time as
the current TTL value.)

However I don't think there would be any downtime with a detach-and-
reattach. Only Corosync and Pacemaker are stopped in that scenario, all
other services remain running in an unmanaged mode.
-- 
Ken Gaillot 

___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/

Re: [ClusterLabs] Problem with MariaDB cluster

[Thomas CAS]

Hello Reid,

What solution can I use while waiting for a fix for this bug?
Modify RA?

Thanks,
Best regards,

Thomas Cas  |  Technicien du support infogérance
PHONE : +33 3 51 25 23 26   WEB : 
www.ikoula.com/en
IKOULA Data Center 34 rue Pont Assy - 51100 Reims - FRANCE
Before printing this letter, think about the impact on the environment!

[Ikoula]
[Twitter] [Linkedin] 
  [Youtube] 
  [Pressroom]   
[Blog] 

De : Thomas CAS
Envoyé : vendredi 27 janvier 2023 11:28
À : Reid Wahl 
Cc : Cluster Labs - All topics related to open-source clustering welcomed 

Objet : RE: [ClusterLabs] Problem with MariaDB cluster

Reid,

I have activated the trace mode on the MYSQL resource on my lab and I rebooted 
Node2, after reboot:

+ echo Node1
+ tr -d
+ master_host=Node1
+ echo Node1
+ [ Node1 -a Node1 != Node2 ]
+ ocf_log info Changing MySQL configuration to replicate from 
zabbixmysqlmaster01.

I can see that the variable "master_host" is well filled.

In production, I did the same thing and variable "master_host" is not filled:

+ echo
+ tr -d
+ master_host=
+ [  -a  != Node2 ]
+ ocf_log info No MySQL master present - clearing replication state


That is why I would like to know concretely what the variable 
"$OCF_RESKEY_CRM_meta_notify_master_uname" does.
How is the master_host name retrieved?

Best regards,

Thomas Cas  |  Technicien du support infogérance
PHONE : +33 3 51 25 23 26   WEB : 
www.ikoula.com/en
IKOULA Data Center 34 rue Pont Assy - 51100 Reims - FRANCE
Before printing this letter, think about the impact on the environment!

[Ikoula]
[Twitter] [Linkedin] 
  [Youtube] 
  [Pressroom]   
[Blog] 

De : Reid Wahl mailto:nw...@redhat.com>>
Envoyé : vendredi 27 janvier 2023 09:32
À : Thomas CAS mailto:t...@ikoula.com>>
Cc : Cluster Labs - All topics related to open-source clustering welcomed 
mailto:users@clusterlabs.org>>
Objet : Re: [ClusterLabs] Problem with MariaDB cluster



On Fri, Jan 27, 2023 at 12:23 AM Thomas CAS 
mailto:t...@ikoula.com>> wrote:
Hello Reid,

Thank you so much for your answer and bug report.
If it is a bug, I do not understand why the problem is present in production 
but not on my lab which is identical?

That's a good question. I'm not sure, and I haven't worked much with this 
resource agent. Does the lab show interesting logs at all from the resource 
agent during startup? I wonder if it's hitting the same "No MySQL master 
present" issue but *not* the error that follows. That error is coming from 
mysql itself, not from the resource agent.

After the agent hits the "No MySQL master present" issue, it calls the 
unset_master() function. You can take a look at the agent script (in 
/usr/lib/ocf/resource.d/heartbeat/mysql by default) to see all the things that 
unset_master() is doing, and try to determine what's behaving differently in 
production vs. lab.

What does the "$OCF_RESKEY_CRM_meta_notify_master_uname" variable do? (which 
shell command is done through this variable)

Pacemaker sets it during a resource's notify operation. It's set to some 
information that's used only during a notify operation, and it's unset 
otherwise. You can see some other similar meta variables in the mysql_notify() 
function. The mysql_notify() function gets called during a notify operation, so 
those variables might be set. They won't be set when mysql_start() is called 
during a start operation.


Best regards,

Thomas Cas  |  Technicien du support infogérance
PHONE : +33 3 51 25 23 26   WEB : 
www.ikoula.com/en
IKOULA Data Center 34 rue Pont Assy - 51100 Reims - FRANCE
Before printing this letter, think about the impact on the environment!

[Ikoula]
[Twitter]

Re: [ClusterLabs] Problem with MariaDB cluster

[Valentin Vidić via Users]

On Tue, Jan 31, 2023 at 02:45:46PM +, Thomas CAS wrote:
> What solution can I use while waiting for a fix for this bug?
> Modify RA?

AFAICT this is not a bug in RA and notify variables are also set for
start/stop/promote/demote actions:

https://github.com/ClusterLabs/pacemaker/blob/9c4ea063f77e55b012c9f61e86052f2e6b270834/lib/pengine/pe_notif.c#L809

For example:

  

  


  


  

  

  

Is there any difference in the configuration, maybe meta option notify=true is
not set on the RA?

-- 
Valentin
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/