Announcement

Announcement Module
Collapse
No announcement yet.

crash while attempting to drop database

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

  • crash while attempting to drop database

    Hello,

    We recently upgraded from MySQL 5.x to Percona Server 5.5

    The system is RHEL 5.3 x64 under Virtuozzo. The VE has no limits on hardware (it is the only VE running on host) and has 34 GB of RAM.

    The 'upgrade' was done via setting up new server (virtual machine, actually), and then transferring innoDB files via Xtrabackup and opying the appropriate .frm files/folders. It went flawlessly.



    However, I have experienced the following issue today while trying to drop a test DB (non-empty):

    Page directory corruption: infimum not pointed to

    followed by crash dump and restart of the server.
    This occurs no matter if dropping an old (migrated) database or new one, as long as it is not empty.
    Dropping a table from the DB produces the same result.

    creating, inserting, altering...everything else works as far as I have observed.

    Please help (or at least point me in the right direction)!

    Thanks,
    Marko

  • #2
    netcom wrote on Fri, 27 January 2012 17:07
    and opying the appropriate .frm files/folders. It went flawlessly.
    You do not have to copy anything, the innobackupex would've handled all the copying for you. I suspect some files got overwritten causing inconsistency.

    Checkout the recipes here for taking a full backup with innobackupex http://www.percona.com/doc/percona-xtrabackup/how-tos.html#r ecipes-ibk
    Our documentation has a lot of answers about common questions on Percona software, have you checked there before posting that question here? http://www.percona.com/forums/core/i...lies/smile.png

    Join us at the annual Percona Live MySQL Users Conference - http://www.percona.com/live/mysql-conference-2014/

    Comment


    • #3
      We have done it like this:
      http://www.percona.com/doc/percona-xtrabackup/howtos/recipes _xbk_restore.html

      I can go with the inconsistency scenario, but would that explain the same behaviour when I create a brand new DB and then drop it?

      Comment


      • #4
        Yes possibly - that recipe is only when you took the backup with xtrabackup binary not with innobackupex, try the one from the recipes I posted.
        Our documentation has a lot of answers about common questions on Percona software, have you checked there before posting that question here? http://www.percona.com/forums/core/i...lies/smile.png

        Join us at the annual Percona Live MySQL Users Conference - http://www.percona.com/live/mysql-conference-2014/

        Comment


        • #5
          Alas, we are already heavily in production on the new server. Since there was nothing noteworthy in error logs and the usual commands went quite ok, we decided that migration was successful.
          We have no performance hits and the server is so far very fast and stable (tested the number of workers under Apache and it decreased by 20%!)
          We used Xtrabackup, not innobackupex. We were using InnoDB backup tool until Oracle took hold of it, then switched to Xtrabackup (configuration was almost identical), so that's how we did the migration. But anyway, that backup/restore method should be valid as far as I know? Any way to investigate it further?

          Comment

          Working...
          X