Percona XtraDB Cluster - HA scalable solution for MySQL

Make the pid detection in init script work with relative paths

Reported by Phil Bayfield on 2013-06-26
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraDB Cluster
Undecided
Raghavendra D Prabhu

Bug Description

Upgrading XtraDB Cluster server fails on Ubuntu 12.04 as the init script hangs indefinitely:

Setting up percona-xtradb-cluster-server-5.5 (5.5.31-23.7.5-438.precise) ...
 * Stopping MySQL (Percona XtraDB Cluster) mysqld [ OK ]

 * Percona Server is distributed with several useful UDF (User Defined Function) from Percona Toolkit.
 * Run the following commands to create these functions:

 mysql -e "CREATE FUNCTION fnv1a_64 RETURNS INTEGER SONAME 'libfnv1a_udf.so'"
 mysql -e "CREATE FUNCTION fnv_64 RETURNS INTEGER SONAME 'libfnv_udf.so'"
 mysql -e "CREATE FUNCTION murmur_hash RETURNS INTEGER SONAME 'libmurmur_udf.so'"

 * See http://www.percona.com/doc/percona-server/5.5/management/udf_percona_toolkit.html for more details

 * Starting MySQL (Percona XtraDB Cluster) database server mysqld
 * SST in progress, setting sleep higher mysqld

The same thing happens if I kill the upgrade and try and start the server directly from the init script, the server does start successfully regardless of the init script hanging.

I presume this node is SST/IST-ing?

The logic in place there is that when SST/IST happens, the init script
checks for a file called $datadir/sst_in_progress and if that file
exists (that file is created by wsrep_sst*) it sleeps for 100s than 1s
per iteration, iteration in which it checks whether mysqld is up and if
not, it goes to sleep. Hence, the delay otherwise shouldn't be more than
100s. Did you see delay higher than that? (You can also probably put
'set -x' in init script and see what it does).

Also, note that to see if mysqld is up or not, it checks for PID file,
so check init script logs to check if they are detected or not.

Phil Bayfield (philio) wrote :

I've spent a little time playing with it and it turns out that it's related to my pid file config definitions.

This used to work fine (and is considered valid by the mysql daemon, pid file is created in the data dir):

pid-file=mysqld.pid

However with the updated init script it loops until the pid file is created and it only checks that the pid file is set to a value, not that the value is correct.

I changed it to full path and it worked:

pid-file=/var/lib/mysql/mysqld.pid

A simple fix but the init script should perhaps mimic the behaviour of mysql?

@Phil, yes, I will make it so that it checks the relative path as well. Thanks for reporting.

Changed in percona-xtradb-cluster:
milestone: none → 5.5.32-24
status: New → Triaged
assignee: nobody → Raghavendra D Prabhu (raghavendra-prabhu)
summary: - Server hangs indefinitely on startup following upgrade
+ Make the pid detection in init script work with relative paths
Changed in percona-xtradb-cluster:
status: Triaged → Fix Committed
Changed in percona-xtradb-cluster:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers