Trouble restoring backup - v2.1.3

[dchicks]

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

[mixa]

@dchicks;10431

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).

[dchicks]

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.

[mixa]

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

$ 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:

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
...

[dchicks]

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.