Version-Check output is mingled with streaming backup output

Bug #1342323 reported by Bill Karwin
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Confirmed
Undecided
Unassigned
2.1
Confirmed
Undecided
Unassigned
2.2
Confirmed
Undecided
Unassigned

Bug Description

User of Percona XtraBackup reports that streaming tar backups are not viable. This does not happen every time, sometimes the backups are viable. The variation occurs on the same server with the same MySQL instance.

Investigating the contents of the tar file, we find that the tar file is not recoverable:

--------%<--------
$ tar -xivf backup.tar.gz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
--------%<--------

It appears that lines of Version-Check message text are prepended to the stream:

--------%<--------
$ zcat backup.tar.gz | head

# A software update is available:
# * Security vulnerability. See http://www.mysqlperformanceblog.com/2012/09/10/introducing-the-version-check-feature-in-percona-toolkit/

./backup-my.cnf0000644000000000000000000000040712361250757012302 0ustar rootroot# This MySQL options file was generated by innobackupex.

# The MySQL server
[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_files_in_group=2
. . .
--------%<--------

Examining the code in innobackupex.pl, I see that the version-check outputs to stdout:

--------%<--------
if ( $advice ) {
         PTDEBUG && _d('Advice:', Dumper($advice));
         if ( scalar @$advice > 1) {
            print "\n# " . scalar @$advice . " software updates are "
               . "available:\n";
         }
         else {
            print "\n# A software update is available:\n";
         }
         print join("\n", map { "# * $_" } @$advice), "\n\n";
      }
};
--------%<--------

So it's not surprising that this output would become mingled with a streaming backup.

Since version-check only checks once every 24 hours, it's not surprising that some backups are viable, and some contain the version-check messages and are not viable.

The workaround is to invoke innobackupex with the --no-version-check option as a matter of course.

Revision history for this message
Nilnandan Joshi (nilnandan-joshi) wrote :

Checked both the versions 2.1.9 and 2.2.3, got the same thing in code.

if ( $advice ) {
         PTDEBUG && _d('Advice:', Dumper($advice));
         if ( scalar @$advice > 1) {
            print "\n# " . scalar @$advice . " software updates are "
               . "available:\n";
         }
         else {
            print "\n# A software update is available:\n";
         }
         print join("\n", map { "# * $_" } @$advice), "\n\n";
      }
};

Revision history for this message
Alexey Kopytov (akopytov) wrote :

The report does not specify PXB version, but I believe this is a duplicate of bug #1256942, which was fixed in 2.1.7 and 2.2.1-alpha.

As of PXB 2.1.7 innobackupex.pl does the following trick to make sure all VersionCheck output goes to STDERR:

        # Redirect STDOUT to STDERR, as VersionCheck prints alerts to STDOUT
        select STDERR;

        VersionCheck::version_check(
                                    force => 1,
                                    instances => [ {
                                                    dbh => $mysql{dbh},
                                                    dsn => $mysql{dsn}
                                                   }
                                                 ]
                                    );
        # Restore STDOUT as the default filehandle
        select STDOUT;

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.