GET 24/7 LIVE HELP NOW

Announcement

Announcement Module
Collapse
No announcement yet.

Percona RPM corrupt/crash database

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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 (http://www.percona.com) 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/mysqld.pid 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 mysql.com (Oracle).

  • #2
    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?

    Comment


    • #3
      sterin71 wrote on Sun, 04 March 2012 18:17
      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?
      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.

      Comment


      • #4
        I am not confident that you don't have something else going on with this system. However, if it is doing what you think, then it looks like a bug to me, so it would be good to file it on Launchpad and paste a link here.

        Comment

        Working...
        X