GET 24/7 LIVE HELP NOW

Announcement

Announcement Module
Collapse
No announcement yet.

Trouble restoring backup - v2.1.3

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

  • Trouble restoring backup - v2.1.3

    I recently upgraded MySQL servers from 5.5 to 5.6.11. In the process, I discovered that I needed to upgrade XtraBackup to the 2.0+ release family. Now that I'm using 2.1.3 to do backups, I'm unable to restore a backup functionally on a different machine.

    The target machine is of the exact same operating system level, MySQL version, and XtraBackup version. My process for testing went like this...

    1) Make a backup of the current system: innobackupex --user=xxxxx --pasword=xxxxx --no-timestamp --no-lock /backup/mybackup
    2) Go into the /backup/mybackup directory and apply the log: innobackupex --user=xxxxx --password=xxxxxxx --apply-log .
    3) Copy the resulting directory to the new MySQL server using "rsync -avprP -e ssh" (as describing in the docs about making a slave)
    4) Set the file ownerhips for the whole directory.
    5) Attempt to start MySQL.

    At this point, I got an error from the startup script indicating a startup error with regard to the PID file. However, I discoverd that the service started anyway. When I connect to the server and attempt to select information from the tables, I get the error "table xxxx doesn't exist".

    What am I doing wrong?
    thanks!
    Dave

  • #2
    Originally posted by dchicks View Post
    At this point, I got an error from the startup script indicating a startup error with regard to the PID file. However, I discoverd that the service started anyway. When I connect to the server and attempt to select information from the tables, I get the error "table xxxx doesn't exist".
    Hi Dave,
    Can you please paste here full error log and listing a content of your datadir (by default it's: ls -al /var/lib/mysql).

    Comment


    • #3
      I believe I discovered the cause of my table issues. It appears that there is an old directive in the /etc/my.cnf file that places the innodb files in a subdirectory of /var/lib/mysql. I think this is supposed to be no longer supported? But, in the 5.6 system, there are no complaints about the directive. Looks like I have two copies of the innodb tablespaces and log files. I'll have to figure out how to reconcile that.

      Still not sure why I have startup problems, though. The complaint about the pid file makes no sense to me.

      My datadir would be rather large to publish here. It's a pretty sizeable database that I'm working with.

      Comment


      • #4
        Sorry for being unclear Dave
        I wanted listing of files, like this one:

        Code:
        $ ls -al /var/lib/mysql
        total 54748
        drwxr-xr-x  5 mysql mysql      142 2013-05-28 20:18 .
        drwxr-xr-x 50 root  root      4096 2013-05-28 12:06 ..
        -rw-rw----  1 mysql mysql  1518250 2013-05-28 20:18 host.err
        -rw-rw----  1 mysql mysql        6 2013-05-28 20:18 host.pid
        ...
        Check permissions please.
        And I would like to still ask you to paste here content of error log, like this one:

        Code:
        sudo tail -100 /var/lib/mysql/host.err
        130528 20:18:48 InnoDB: Compressed tables use zlib 1.2.3
        130528 20:18:48 InnoDB: Using Linux native AIO
        130528 20:18:48 InnoDB: Initializing buffer pool, size = 12.0G
        130528 20:18:49 InnoDB: Completed initialization of buffer pool
        130528 20:18:49 InnoDB: highest supported file format is Barracuda.
        130528 20:18:49  InnoDB: Error: page 7 log sequence number 112551166
        ...

        Comment


        • #5
          Sorry about the late reply. I figured out what my problem was. The server I took the backup from is still using a "innodb_data_home_dir", which I believe is now deprecated. Not sure how 5.6 is allowing that to happen. Anyway, once I straightened out the locations of the innodb tablespaces and log files, I was able to recover just fine. ::whew!::

          Thanks for the input.

          Comment

          Working...
          X