xtrabackup_info binlog_pos GTID splitting to multiple lines

[Sterling Cox]

Getting a snapshot from a database in a Percona server (configured for Fabric) results in a "binlog_pos = GTID of the last change" that breaks up into multiple lines when there are multiple GTID ranges specified.

Specifically, running a snapshot using the following command:

    innobackupex --host=127.0.0.1 --user=root --password=$p --rsync --safe-slave-backup --slave-info /var/backups/mysql/daily_snapshot 2>&1 | egrep "innobackupex|xtrabackup" | tee -a /var/log/daily_snapshot_$sdate.log
    sdir=$(ls -1 | egrep "^$sdate")
    innobackupex --host=127.0.0.1 --user=root --password=$p --apply-log /var/backups/mysql/daily_snapshot/$( ls -1 /var/backups/mysql/daily_snapshot/ | grep $sdir) 2>&1 | egrep "innobackupex|xtrabackup" | tee -a /var/log/daily_snapshot_$sdate.log

the resulting xtrabackup_info file contains these 2 lines:

    binlog_pos = GTID of the last change 'f43a8a6b-c136-11e4-b41c-f23c9133c356:1-219456761,
    f465b62d-f288-11e4-b5b8-f23c91189be4:1-39'

-note that the white-space after the comma has been reinterpreted as a carriage return, only in xtrabackup_info.

In xtrabackup_slave_info the resulting quoted value makes more sense:

    SET GLOBAL gtid_purged='f43a8a6b-c136-11e4-b41c-f23c9133c356:1-219456761, f465b62d-f288-11e4-b5b8-f23c91189be4:1-39';

-versions:

Percona Server Release 72.1 Revision 0503478

xtrabackup version 2.2.10 based on MySQL server 5.6.22 Linux (x86_64) (revision id: )

innobackupex version: InnoDB Backup Utility v1.5.1-xtrabackup

[Sterling Cox (sterlingcox)]

It should be added that the snapshot works fine after setting GTID_purged to

'f43a8a6b-c136-11e4-b41c-f23c9133c356:1-219456761, f465b62d-f288-11e4-b5b8-f23c91189be4:1-39'

and that the machine it was generated on was an active slave receiving transactions at that time.

[Sterling Cox (sterlingcox)]

Goddamned 'autocorrect': bingo_pos up above should read binlog_pos ...

[Valerii Kravchuk (valerii-kravchuk)]

This is probably related to the way SHOW MASTER STATUS formats the content of its Executed_Gtid_Set column. This is where this value is taken from.

[Jericho Rivera (jericho-rivera)]

Confirmed as described for all latest PXB versions.

Sample:
binlog_pos = filename 'mysql-bin.000003', position 26223248, GTID of the last change '94af60cc-0233-11e7-a68b-00163e28e6e3:1-27392,
b7a1b9a2-0232-11e7-a686-00163e865f14:1-43481'

mysql> show master status\G
*************************** 1. row ***************************
             File: mysql-bin.000003
         Position: 26223248
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set: 94af60cc-0233-11e7-a68b-00163e28e6e3:1-27392,
b7a1b9a2-0232-11e7-a686-00163e865f14:1-43481
1 row in set (0.00 sec)

Also seen in xtrabackup_binlog_info file:
mysql-bin.000003 26223248 94af60cc-0233-11e7-a68b-00163e28e6e3:1-27392,
b7a1b9a2-0232-11e7-a686-00163e865f14:1-43481

[Sterling Cox (sterlingcox)]

Actually, starting from the first single quote after "GTID of the last change" and reading through to the next single quote works fine, which I did not even consider when filing the "bug" - given that working around the multi-line GTID list is so easy, I don't know if I would even declare it as a bug at this point, but I cannot seem to retract it by closing it myself.

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-727