mysql_prn with LCMC

[Hillary Corney]

I have installed the mysql_prn intp /usr/lib/icf/resource.d/percona directory on a Ubuntu 13.04 LAMP Percona Master/Slave Cluster, doing my best to follow the documentation. Then I tried to install it using LCMC to manage the cluster. http://lcmc.sourceforge.net

Unfortunately when you select the mysql_prn agent it fails to display the user variables in the LCMC console and instead it displays "(null) null null" and any attempt to continue the installation causes the message to change to "gathering metadata" and it hangs.

I have looked at the content of the MySQL agent and compared it to the mysql_prm agent but I cant see why it won't work with LCMC. I would appreciate any insights you can offer.

Thanks

[Yves Trudeau]

Hi,
  I'll have to look at lcmc and see what it needs.  The meta-data should already be ok.  I am off for 3 weeks, I'll check after.

Regards,

Yves

--
You received this message because you are subscribed to the Google Groups "PRM-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prm-discuss...@googlegroups.com.
To post to this group, send email to prm-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/prm-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Hillary Corney]

Thank you Yves, Much appreciated.

[hillary]

Hi Yves, Hi List,

I am still learning about Pacemaker and Corosync and still experimenting with Percona agents.

I do hope to use the Percona Agents in a production environment along with Percona MySQL soon but first I had better understand the configuration and installation properly.

I did have a reasonably stable 2 node test cluster that appeared to mostly work. The slave occasionally failed to start but otherwise it appeared to be ok.

However on closer inspection I discovered that two MyQL Pid were running on the slave server one using about 10% of memory which fluctuated around 3% the second MySQL used 3.3% and that never varies. The pid of this second mysql instance changes every minute or so as if its being restarted.

I was concerned this was odd. I isolated it to the MySQL agent - remove the agent and the second 3.3% pid stops.

I noticed that a new version of the agent was released 13 days ago so I installed that, and the behaviour of the slave was more reliable and the second pid has disappeared.

However with a bit more investigation I discovered that the behaviour has reversed. With the later MySQL agent installed the master fails to start more often and the Master is now showing two mysql pid's like the slave was.

So the behaviour has swapped over. The only thing that was changed about the test cluster was the new Agent.

Any ideas?

Hillary
07919 488425
zen7...@zen.co.uk

[yves]

Hi,

    I made another release a few days ago following many issues introduced by the July release.   Also, I'd like to know what's the exact problem with the meta-data.

Regards,

Yves

[yves]

Hi,

   my answers are embedded.

Le mercredi 7 août 2013 13:20:47 UTC-4, Hillary Corney a écrit :

Hi Yves, Hi List,

I am still learning about Pacemaker and Corosync and still experimenting with Percona agents.

I do hope to use the Percona Agents in a production environment along with Percona MySQL soon but first I had better understand the configuration and installation properly.

I did have a reasonably stable 2 node test cluster that appeared to mostly work. The slave occasionally failed to start but otherwise it appeared to be ok.

However on closer inspection I discovered that two MyQL Pid were running on the slave server  one using about 10% of memory which fluctuated around 3% the second MySQL used 3.3% and that never varies. The pid of this second mysql instance changes every minute or so as if its being restarted.

Have disabled the automatique startup of MySQL?  Pacemaker will start MySQL from now, not init.  Either use chkconfig on redhat, update-rc.d on Ubuntu/Debian (older release) or edit /etc/default/mysql.

 

I was concerned this was odd. I isolated it to the MySQL agent - remove the agent and the second 3.3% pid stops.

I noticed that  a new version of the agent was released 13 days ago so I installed that, and the behaviour of the slave was more reliable and the second pid has disappeared.

However with a bit more investigation I discovered that the behaviour has reversed. With the later MySQL agent installed the master fails to start more often and the Master is now showing two mysql pid's like the slave was.

You need 1 pid, if you have 2, your config is wrong.

 

So the behaviour has swapped over. The only thing that was changed about the test cluster was the new Agent.

Any ideas?

Hillary
07919 488425
zen7...@zen.co.uk

Regards,

Yves