innobackupex does not record binlog file and pos when GTID is enabled

[Jervin R]

percona-xtrabackup-debuginfo-2.2.10-1.el6.x86_64
percona-xtrabackup-2.2.10-1.el6.x86_64

When GTID is enabled, innobackupex output does not include binlog fiel and pos anymore. Although it makes sense to use GTID only on xtrabackup_binlog_info having the binlog file and pos is still useful in some cases.

3120c3120
< # if ($mariadb_gtid || !$mysql_gtid) {
---
> if ($mariadb_gtid || !$mysql_gtid) {
3123c3123
< # }
---
> }

[Sergei Glushchenko (sergei.glushchenko)]

This change was intentional as part of the fix for bug 1391041.

    Bug 1391041: innobackupex should skip GTID output is GTID_MODE is OFF

    For MySQL:

    1. If GTID_MODE is ON print only GTID of the last change
    2. If GTID_MODE is OFF print filename and position

    For MariaDB always print filename, position and GTID.

From MySQL manual:

When GTIDs are in use, the slave has no need for any nonlocal data, such as the name of a file on the master and a position within that file. All necessary information for synchronizing with the master is obtained directly from the replication data stream. From the perspective of the database administrator or developer, GTIDs entirely take the place of the file-offset pairs previously required to determine points for starting, stopping, or resuming the flow of data between master and slave. This means that, when you are using GTIDs for replication, you do not need (or want) to include MASTER_LOG_FILE or MASTER_LOG_POS options in the CHANGE MASTER TO statement used to direct a slave to replicate from a given master; in place of these options, it is necessary only to enable the MASTER_AUTO_POSITION option introduced in MySQL 5.6.5.

Could you please describe your use case when you need both binlog coordinates and GTID?

[Jervin R (revin)]

Sergei,

Thanks for the explanation. When we take backups and stream remotely, compressing at the same time we do not have a way to determine binlog file and position from xtrabackup_binlog_info or xtrabackup_slave_info since they are part of the compressed backup.

For this particular use case, we use the STDERR output to get the binary log filename to automatically tie backups with binary log streaming with mysqlbinlog on 5.6 on https://github.com/dotmanila/pyxbackup/blob/master/pyxbackup

I don't think we need the file based info on xtrabackup_binlog_info and xtrabackup_slave_info but we need it to be included in the STDERR output.

I hope that is sufficient use case and also the change is very minor? :)

[Sergei Glushchenko (sergei.glushchenko)]

https://github.com/percona/percona-xtrabackup/pull/58
https://github.com/percona/percona-xtrabackup/pull/59

[Shahriyar Rzayev (rzayev-sehriyar)]

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