Percona RPM corrupt/crash database

I don’t think it’s a good idea to make the RPM installation shutdown mysql, especially if it’s a large database (2TB+).
But what i did was first shutting down mysql, then upgrading using the RPMs, for some reason it tried to start the database, and run something over it, this thing caused mysql never to start again.
The ugprade was from 5.1.58 to 5.1.61 (Percona).
Lucky, this server is backed up, but i don’t feel safe upgrading my database any more, especially using Percona RPM.
This total crashed a 2TB+ database.
My workaround is to build the RPMs alone, i think you guys should put more care on the packaging side, it can really screw up a database.

120303 21:24:28 mysqld_safe Starting mysqld daemon with databases from /mysql-data/mysql
120303 21:24:28 [Note] Flashcache bypass: disabled
120303 21:24:28 [Note] Flashcache setup error is : ioctl failed

120303 21:24:28 [Note] Plugin ‘FEDERATED’ is disabled.
^G/usr/sbin/mysqld: Can’t find file: ‘./mysql/plugin.frm’ (errno: 13)
120303 21:24:28 [ERROR] Can’t open the mysql.plugin table. Please run mysql_upgrade to create it.
InnoDB: Warning: innodb_log_block_size has been changed from default value 512. (###EXPERIMENTAL### operation)
InnoDB: The log block size is set to 4096.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
120303 21:24:28 InnoDB: Initializing buffer pool, size = 25.0G
120303 21:24:30 InnoDB: Completed initialization of buffer pool
InnoDB: Notice: innodb_doublewrite_file is specified.
InnoDB: This is for expert only. Don’t use if you don’t understand what is it ‘WELL’.
InnoDB: ### Don’t specify older file than the last checkpoint ###
InnoDB: otherwise the older doublewrite buffer will break your data during recovery!
120303 21:24:30 InnoDB: highest supported file format is Barracuda.
InnoDB: doublewrite file ‘/log/mysql-misc/idb_doublewrite’ is used.
120303 21:24:31 Percona XtraDB ( 1.0.17-13.2 started; log sequence number 13304824073318
120303 21:24:31 [Note] Recovering after a crash using /log/mysql-misc/logs/mysql-bin
120303 21:24:31 [Note] Starting crash recovery…
120303 21:24:31 [Note] Crash recovery finished.
120303 21:24:31 [ERROR] /usr/sbin/mysqld: Can’t find file: ‘./mysql/host.frm’ (errno: 13)
120303 21:24:31 [ERROR] Fatal error: Can’t open and lock privilege tables: Can’t find file: ‘./mysql/host.frm’ (errno: 13)
120303 21:24:31 mysqld_safe mysqld from pid file /var/run/mysqld/ ended

The big problem is that i am running mysql as user “mysqld” and not the normal “mysql”, i do have it in my.cnf, it’s seems like the init script is ignoring it, it simply changed permissions to some of the dirs under “/mysql-data/mysql” to user “mysql”.
This does not happen with MySQL from (Oracle).

So basically if I interpret what you are saying and what the error log is saying is that:
“corrupt/crash database”
actually means that the RPM upgrade just changed ownership of the grant tables to the standard mysql account instead of your non-standard mysqld account.

What happened when you just changed the ownership of those files back to your own mysqld user with chown?

sterin71 wrote on Sun, 04 March 2012 18:17

sorry for the late response.
I didn’t have the change to test it because i imported the database back.
but it looks like it’s running mysql_install_db using the parameters in /etc/my.cnf.
This is very dangerous!! and it’s not a standard rpm behavior, especially when upgrading.