This update fixes the following issues with xtrabackup:
- bnc#838543: version 2.0.8
* Percona XtraBackup would assume the table has been dropped if the tablespace was renamed after it was scanned by Percona XtraBackup on startup and before Percona XtraBackup attempted to copy it.
* Orphaned xtrabackup_pid file left inside tmpdir could cause SST to fail.
* During the backup process loading tablespaces was started before the log copying, this could lead to a race between the datafiles state in the resulting backup and xtrabackup_logfile. Tablespace created at a sensitive time would be missing in both the backup itself and as the corresponding log record in xtrabackup_logfile, so it would not be created on innobackupex --apply-log either.
* innobackupex automatic version detection did not work correctly for latest Percona Server and MySQL 5.1 releases which could cause innobackupex to fail.
* Difference in behavior between InnoDB 5.5 and 5.6 codebases in cases when a newly created tablespace has uninitialized first page at the time when Percona XtraBackup opens it while creating a list of tablespaces to backup would cause assertion error.
* Percona XtraBackup would stop in case log block numbers had to wrap around, which only happens once per 1 GB of log writes, and the wrap-around point was between the last checkpoint and the current log tail at the time the backup starts.
* Under some circumstances Percona XtraBackup could fail on a backup prepare with innodb_flush_method=O_DIRECT when XFS filesystem was being used.
* Percona XtraBackup didn’t recognize checkpoint #0 as a valid checkpoint on xtrabackup --prepare which would cause an error.
* xtrabackup --stats option would not work with server datadir if the server isn’t running and logs were in a separate directory.