Hello. I am use xtrabackup 2.1.4 on FreeBSD 9.1.
When a make backup xtrabackup_56 --defaults-file=/etc/my.cnf --datadir=/var/db/mysql --target-dir=/home/backup/ --backup, in target directory I see only idb files.
After I make restore procedure like xtrabackup_56 --prepare --target-dir=/home/backup/, in target dir steel only idb files.
After that, I try to copy my restored data base to MySQL data dir, and change owner, and restart… but
mysql> use exchanger;
Database changed
mysql> show tables;
Empty set (0.00 sec)
mysql> exit
Backup file it is a xtrabackup_logfile ? My backup command is xtrabackup_56 --defaults-file=/etc/my.cnf --datadir=/var/db/mysql --target-dir=/home/backup/ --backup
Hi,
Sorry, previously i overlooked into it.
Xtrabackup copies only the InnoDB data and logs. It does not copy table definition files (.frm files). It’s docuemented. You can read more about it here [url]Percona XtraBackup
I suggest to use innobackupex which is wrapper script for the xtrabackup. It provides more functionality including copy of schema definitions. Check on the following link for the full documentation of innobackupex.
[url]Percona XtraBackup
Hi guys, I am also experiencing the same problem. I am actually using the innobackupex script and yet, it is still only copying the ibd files and it also seem to get stuck on "scanned up to log " entries and after 2 days of running on a 226Gb database it has not made any progress. I have searched every forum and link I can find but nothing seems to make a difference at all.
sorry just to clarify, the innobackupex scripts is run simply by invoking "innobackupex " , the scripts copied over all .ibd files and also scan logs.
problems I seem to be encountering is that there are no .frm files,etc… copied, nothing from the mysql database (system tables) are being copied, and after the ibd files are finished copying, the scanned logs goes into a continuous cycle until I manually delete the xtrabackup_suspended file.
machielr: your copy process may be blocked by large on-going transactions, that have to finish before the non-innodb bits are copied (mysql tables and .frms). There are some things that you can try, depending on the situation. First one, would be to avoid long open transactions while the last part of the backup happens (the non-transactional copy). Second, using --rsync (that will not avoid the locking but you may have copied most of the non-transactional bits before the locking, so if you cancel the copy, you may still save something, although in a non consistent way). You can use --no-lock, that will avoid the process to be blocked, but if you execute an ALTER TABLE or update a non-InnoDB table during the copy process, the backup may not be consistent.
The real solution will probably come by using the new features in the latest releases of xtrabackup: [url]Percona XtraBackup
with --lock-wait-timeout or --kill-long-query-type you can control the specific behaviour of the backup process: making it fail immediately and retry later or kill the offending queries to allow the backup to continue. Obviously, use both options with caution.