Created by Sergei Glushchenko on 2012-01-30 and last modified on 2012-09-18
Get this branch:
bzr branch lp:~sergei.glushchenko/percona-xtrabackup/bug711166_part-1.6
Only Sergei Glushchenko can upload to this branch. If you are Sergei Glushchenko please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Recent revisions

348. By Sergei Glushchenko on 2012-09-18

Partitioned tables are not correctly handled by the --databases, --include,
--tables-file options of innobackupex, and by the --tables and
--tables-file options of xtrabackup.
Solution is to remove partition suffix (#P#...) before doing filtering.
Testcases cover variants of using filtering options with MyISAM and
InnoDB tables (to test both innobackupex and xtrabackup) with either stream
mode turned on and turned off.

347. By Stewart Smith on 2012-07-31

merge Bug #1021954: XtraBackup on MultiInstance server connects to default instance for slave info

346. By Stewart Smith on 2012-07-06

merge Stewart's test fix cleanups

345. By Stewart Smith on 2012-07-04

merge test suite support for MySQL 5.0

344. By Alexey Kopytov on 2012-06-19

Bug #996483: False positive testsuite failures with grep 2.10

The problem was in spurious test failures on Ubuntu 12.04 due to the
mentioned grep version being buggy: grepping a file and redirecting the
output to the same file would fail with an error even when the -q switch
is used, i.e. no output is actually generated.

Fixed by implementing a workaround with the grep output always
redirected to a pipe and then cat redirecting it back to standard
output, i.e. the original file, if the standard output was redirected.

343. By Alexey Kopytov on 2012-06-12

Implemented "port locking" in free port selection code. It's still
racey, but it's the best thing you can do in bash.

342. By Alexey Kopytov on 2012-06-08

Bug #977101: --safe-slave-backup results in incorrect binlog info

The fundamental problem is in the way innobackupex talks to the
server. All queries are sent using the mysql command line client, then
the response is stored to file that is common for all queries. Then it
parses that file to figure out what might look as a response to the
specific query that was last issued. In this specific case, when
--safe-slave-backup was present, innobackupex confused the response from

Since refactoring or deprecating innobackupex is not on our short-term
plans, fixed the bug by changing the SHOW MASTER STATUS output to the
vertical format and improving the parsing code so that we at least
capture the SHOW MASTER STATUS output rather than something else.

Added a test case using the new replication support in the test suite.

341. By Alexey Kopytov on 2012-06-04

BP replicatiin-support-in-test-suite

Added initial replication support to the XtraBackup test suite. It's now
possible to start multiple servers with the start_sever_with_id
function, and setup a server as a slave of another one with the
setup_slave function.

340. By Alexey Kopytov on 2012-05-28

Bug #713267: xtrabackup binary leaks file descriptors on --backup

The problem was that the xtrabackup_copy_datafile() called
fil_space_get_zip_size() with the only purpose to determine the
compressed page size for a tablespace. That function opens the tablespace
file to read its flags. But xtrabackup never closed that file, which was
the reason for the file descriptor leak.

Since we already have a file descriptor for the tablespace to be copied,
the bug was fixed duplicating a part of fil_node_open_file() in a
separate function that reads flags from a given tablespace file and then
converts them to the page size. The existing file descriptor is reused
this way, so no leak occurs.

339. By Alexey Kopytov on 2012-05-22

Bug #1002688: innobackupex incremental apply-log copies to wrong

The problem was that the copy_dir_recursively() routine relied on both
the source path and the target one to be in the canonical format,
i.e. not having any trailing slashes. However, when copying files after
merging an incremental backup to the full backup directory, the target
path (i.e. the full backup directory) was always in the canonical
format, because innobackupex calls File::Spec->rel2abs() on it in
check_args(), but the source path (i.e. the --incremental-directory
value) might not be in the canonical format in case the user specified
it with a trailing slash.

Fixed by canonizing both source and the target directories in
copy_dir_recursively() so it does not rely on the arguments format.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
This branch contains Public information 
Everyone can see this information.