Percona Server with XtraDB

Percona server upgrade recreates test database from invocation of mysql_install_db

Reported by jahor on 2011-01-31
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
MySQL Server
Unknown
Unknown
Percona Server
Status tracked in 5.6
5.1
Medium
Alexey Bychko
5.5
Medium
Alexey Bychko
5.6
Medium
Laurynas Biveinis
Percona XtraDB Cluster
Status tracked in Trunk
5.6
Undecided
Unassigned
Trunk
Undecided
Unassigned

Bug Description

Upgrading of MySQL-server-percona-highperf recreates db test. this db was removed after previous instll/upgrade.

after tracking the issue i found, that the followin code is not in install condition
  # ----------------------------------------------------------------------
  # Initiate databases
  # ----------------------------------------------------------------------
  /usr/bin/mysql_install_db --rpm --user=mysql

the problem is, that mysql_install_db contains the follovin code:
  # Create database directories
  for dir in $ldata $ldata/mysql $ldata/test

possible sollution could be for example
  * patching /usr/bin/mysql_install_db (i think this is not optimal and will be different from upstream)
  * move the "Initiate database" in POSTIN to conditioned part for new install only

i don't know now that moving to conditioned part will have some sideeffects.

upstream mysql-server packages have very simple, conditioned POSTIN and calling mysql_install_db lies on the user, percona has more logic in the POSTIN and solves many production problems.

Stewart Smith (stewart) wrote :

This should be either instantly verifiable or not by looking at what we use to generate RPMs.

Changed in percona-server:
assignee: nobody → Ignacio Nin (ignacio-nin)
importance: Undecided → Low
tags: added: low-hanging-fruit
tags: added: pkg
summary: - upgrade of rpm (MySQL-server-percona-highperf) recreates db "test"
+ Percona server upgrade recreates test database from invocation of
+ mysql_install_db

Percona Server post-installation script invokes mysql_install_db unconditonally which installs test database again (among other things, some which are not required for upgrade).

Also, the post-installation script is not in sync with upstream one as the reporter described.

The upstream one has:

# ----------------------------------------------------------------------
# Initiate databases if needed
# ----------------------------------------------------------------------
if ! grep '^MySQL RPM upgrade' $STATUS_FILE >/dev/null 2>&1 ; then
        # Fix bug#45415: no "mysql_install_db" on an upgrade
        # Do this as a negative to err towards more "install" runs
        # rather than to miss one.
        /usr/bin/mysql_install_db --rpm --user=mysql
fi

So, we will need to fix our post installation script and/or sync it with the upstream one.

The upstream fix was in http://bugs.mysql.com/bug.php?id=45415

When this is ported to 5.6, bug 1168437 should be avoided.

Joshua Prunier (joshua-prunier) wrote :

I do not believe this bug has been fixed in 5.5.30-30.2 (and possibly 5.1.68-14.6 but I have not tested it) as the test database directory still gets created during an upgrade.

The following code snippet from rpm -qp --scripts Percona-Server-server-55-5.5.30-rel30.2.500.rhel6.x86_64.rpm will recreate the test directory if it is not there when the rpm is installed.

if [ $1 -eq 1 ]; then
# ----------------------------------------------------------------------
# Create data directory if needed, check whether upgrade or install
# ----------------------------------------------------------------------
if [ ! -d $mysql_datadir ] ; then mkdir -m 755 $mysql_datadir; fi
if [ -f $STATUS_FILE ] ; then
        SERVER_TO_START=`grep '^SERVER_TO_START=' $STATUS_FILE | cut -c17-`
else
        SERVER_TO_START=''
fi
# echo "Analyzed: SERVER_TO_START=$SERVER_TO_START"
if [ ! -d $mysql_datadir/mysql ] ; then
        mkdir $mysql_datadir/mysql;
        echo "MySQL RPM installation of version $NEW_VERSION" >> $STATUS_FILE
else
        # If the directory exists, we may assume it is an upgrade.
        echo "MySQL RPM upgrade to version $NEW_VERSION" >> $STATUS_FILE
fi
if [ ! -d $mysql_datadir/test ]; then
        mkdir $mysql_datadir/test;
fi
/usr/bin/mysql_install_db --rpm --user=mysql
fi

Running mysql_install_db will create the test directory if it is not there which makes the test directory check and creation unnecessary. A possible fix could be to check the existence of the test directory prior to mysql_install_db being invoked and then $mysql_datadir/test removed if an upgrade is being performed and the test database did not exist prior to installing the rpm.

Something like:

if [ $1 -eq 1 ]; then
# ----------------------------------------------------------------------
# Create data directory if needed, check whether upgrade or install
# ----------------------------------------------------------------------
if [ ! -d $mysql_datadir ] ; then mkdir -m 755 $mysql_datadir; fi
if [ -f $STATUS_FILE ] ; then
        SERVER_TO_START=`grep '^SERVER_TO_START=' $STATUS_FILE | cut -c17-`
else
        SERVER_TO_START=''
fi
# echo "Analyzed: SERVER_TO_START=$SERVER_TO_START"
if [ ! -d $mysql_datadir/mysql ] ; then
        mkdir $mysql_datadir/mysql;
        echo "MySQL RPM installation of version $NEW_VERSION" >> $STATUS_FILE
else
        # If the directory exists, we may assume it is an upgrade.
        echo "MySQL RPM upgrade to version $NEW_VERSION" >> $STATUS_FILE

        if [ ! -d $mysql_datadir/test ] ; then
             RMTEST=1
        else
             RMTEST=0
        fi
fi

/usr/bin/mysql_install_db --rpm --user=mysql

if [ $RMTEST = 1 ] ; then
     rm -rf $mysql_datadir/test;
fi
fi

Alexey Kopytov (akopytov) wrote :

Thanks, reported as a separate bug #1169522.

This has been committed to 5.6 PXC separately. This commit broke installation and was fixed in lp:1170024, hence, the complete fix has been ported.

no longer affects: percona-xtradb-cluster/trunk
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.