mysql_install_db not working properly with percona server

[Jay Janssen]

I am installing Percona server on a clean Centos 6.4 VM that is i686 with yum from the Percona apt repo:

Running Transaction
  Installing : Percona-Server-shared-55-5.5.30-rel30.2.500.rhel6.i686 1/9
  Installing : 1:perl-Pod-Escapes-1.04-130.el6_4.i686 2/9
  Installing : 3:perl-version-0.77-130.el6_4.i686 3/9
  Installing : 1:perl-Module-Pluggable-3.90-130.el6_4.i686 4/9
  Installing : 4:perl-libs-5.10.1-130.el6_4.i686 5/9
  Installing : 1:perl-Pod-Simple-3.13-130.el6_4.i686 6/9
  Installing : 4:perl-5.10.1-130.el6_4.i686 7/9
  Installing : Percona-Server-client-55-5.5.30-rel30.2.500.rhel6.i686 8/9
  Installing : Percona-Server-server-55-5.5.30-rel30.2.500.rhel6.i686 9/9
chown: invalid user: `mysql'
Cannot change ownership of the database directories to the 'mysql'
user. Check that you have the necessary permissions and try again.
Percona Server is distributed with several useful UDF (User Defined Function) from Maatkit.
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://code.google.com/p/maatkit/source/browse/trunk/udf for more details
  Verifying : 1:perl-Pod-Escapes-1.04-130.el6_4.i686 1/9
  Verifying : Percona-Server-shared-55-5.5.30-rel30.2.500.rhel6.i686 2/9
  Verifying : 3:perl-version-0.77-130.el6_4.i686 3/9
  Verifying : 1:perl-Module-Pluggable-3.90-130.el6_4.i686 4/9
  Verifying : Percona-Server-server-55-5.5.30-rel30.2.500.rhel6.i686 5/9
  Verifying : Percona-Server-client-55-5.5.30-rel30.2.500.rhel6.i686 6/9
  Verifying : 1:perl-Pod-Simple-3.13-130.el6_4.i686 7/9
  Verifying : 4:perl-libs-5.10.1-130.el6_4.i686 8/9
  Verifying : 4:perl-5.10.1-130.el6_4.i686 9/9

Installed:
  Percona-Server-server-55.i686 0:5.5.30-rel30.2.500.rhel6

I get an error when I try to start mysql, because /var/lib/mysql/mysql does not have any system tables in it. I'm guessing the mysql_install_db failed here. Can anyone confirm this?

[Raghavendra D Prabhu (raghavendra-prabhu)]

Possible regression from:

revno: 463.1.1 [merge]
     fixes bug: https://launchpad.net/bugs/710799
     committer: Alexey Bychko <email address hidden>
     branch nick: bug710799-5.5
     timestamp: Thu 2013-03-07 19:45:40 +0700
     message:
       fix for bug 710799, version 5.5
       [-] disabled uncongitional manual creation of /var/lib/mysql/*
       [+] added conditional call of mysql_install_db, only for clean installation, but not for upgrade
       [+] added debug possibility for %post
     diff:
     === modified file 'build/percona-server.spec'
     --- build/percona-server.spec 2013-02-26 16:40:25 +0000
     +++ build/percona-server.spec 2013-03-07 12:45:40 +0000
     @@ -710,13 +710,16 @@
      fi

      %post -n Percona-Server-server%{product_suffix}
     -
     +if [ X${PERCONA_DEBUG} == X1 ]; then
     + set -x
     +fi
      # ATTENTION: Parts of this are duplicated in the "triggerpostun" !

      mysql_datadir=%{mysqldatadir}
      NEW_VERSION=%{mysql_version}-%{release}
      STATUS_FILE=$mysql_datadir/RPM_UPGRADE_MARKER

     +if [ $1 -eq 1 ]; then
      # ----------------------------------------------------------------------
      # Create data directory if needed, check whether upgrade or install
      # ----------------------------------------------------------------------
     @@ -734,8 +737,11 @@
         # 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
     +if [ ! -d $mysql_datadir/test ]; then
     + mkdir $mysql_datadir/test;
     +fi
     +%{_bindir}/mysql_install_db --rpm --user=%{mysqld_user}
     +fi
      # ----------------------------------------------------------------------
      # Make MySQL start/shutdown automatically when the machine does it.
      # ----------------------------------------------------------------------
     @@ -761,26 +767,19 @@
      usermod -g %{mysqld_group} %{mysqld_user} 2> /dev/null || true

      # ----------------------------------------------------------------------
     +# Initiate databases if needed
     +# ----------------------------------------------------------------------
     +# ----------------------------------------------------------------------
     +# Upgrade databases if needed would go here - but it cannot be automated yet
     +# ----------------------------------------------------------------------
     +
     +# ----------------------------------------------------------------------
      # Change permissions so that the user that will run the MySQL daemon
      # owns all database files.
      # ----------------------------------------------------------------------
      chown -R %{mysqld_user}:%{mysqld_group} $mysql_datadir

      # ----------------------------------------------------------------------
     -# Initiate databases if needed
     -# ----------------------------------------------------------------------
     -
     -# ----------------------------------------------------------------------
     -# Upgrade databases...

[Raghavendra D Prabhu (raghavendra-prabhu)]

The bug is:

=================================================================

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
%{_bindir}/mysql_install_db --rpm --user=%{mysqld_user}
fi
# ----------------------------------------------------------------------
# Make MySQL start/shutdown automatically when the machine does it.
# ----------------------------------------------------------------------
# NOTE: This still needs to be debated. Should we check whether these links
# for the other run levels exist(ed) before the upgrade?
# use chkconfig on Enterprise Linux and newer SuSE releases
if [ -x /sbin/chkconfig ] ; then
        /sbin/chkconfig --add mysql
# use insserv for older SuSE Linux versions
elif [ -x /sbin/insserv ] ; then
        /sbin/insserv %{_sysconfdir}/init.d/mysql
fi

# ----------------------------------------------------------------------
# Create a MySQL user and group. Do not report any problems if it already
# exists.
# ----------------------------------------------------------------------
groupadd -r %{mysqld_group} 2> /dev/null || true
useradd -M -r -d $mysql_datadir -s /bin/bash -c "MySQL server" \
  -g %{mysqld_group} %{mysqld_user} 2> /dev/null || true
# The user may already exist, make sure it has the proper group nevertheless
# (BUG#12823)
usermod -g %{mysqld_group} %{mysqld_user} 2> /dev/null || true

=======================================================================================

when %{_bindir}/mysql_install_db --rpm --user=%{mysqld_user} is called

the user won't exist since it is a clean install.

It should be moved to its original position.

[Raghavendra D Prabhu (raghavendra-prabhu)]

The workaround would be to manually do

groupadd -r %{mysqld_group} 2> /dev/null || true
useradd -M -r -d $mysql_datadir -s /bin/bash -c "MySQL server" \
  -g %{mysqld_group} %{mysqld_user} 2> /dev/null || true
# The user may already exist, make sure it has the proper group nevertheless
# (BUG#12823)
usermod -g %{mysqld_group} %{mysqld_user} 2> /dev/null || true

before doing yum install (in case of clean install)

[Raghavendra D Prabhu (raghavendra-prabhu)]

As per the reporter,

doing :

mysql_install_db --user=mysql + service mysql start

manually should also do.

[Raghavendra D Prabhu (raghavendra-prabhu)]

This is because the users/groups are created anyways, only the mysql_install_db fails.

[Raghavendra D Prabhu (raghavendra-prabhu)]

Fix released in Percona-XtraDB-Cluster 5.5.30-23.7.4.404

[Alexey Kopytov (akopytov)]

Apparently the fix doesn't work as intended or is incomplete, see bug #1174426.

[Roel Van de Paar (roel11)]

Does this bug require further followup for 5.6 GA? Setting 56qual ftm until we're sure.

[Ignacio Nin (ignacio-nin)]

Not reproducible in 5.6, setting to Invalid as is fixed in all other versions.

[Ernestas (ernetas)]

I amm able to reproduce this for Percona 5.6 on clean Ubuntu 12.04.3 virtual machines.

[Raghavendra D Prabhu (raghavendra-prabhu)]

Ernestas,

Can you provide more details of this - logs etc.? The bug was reported for
CentOS/RPM and was due to regression from https://launchpad.net/bugs/710799. Also, 710799 was not ported to PS 5.6 (but it is in PXC 5.6 though, along with fix of 710799), so this issue is not there for RPM either (for PS5.6).

[Valerii Kravchuk (valerii-kravchuk)]

Waiting for more details (including exact 5.6.x version used) from Ernestas.

[Roel Van de Paar (roel11)]

Closing out this open bug for 5.6 by s/incomplete/invalid/ until counter proof is shown.

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-923

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-2939