xtrabackup_slave_info does not contain GTID purge lists

Bug #1239670 reported by Sheeri K. Cabral
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Fix Released
High
Alexey Kopytov
2.0
Won't Fix
Undecided
Unassigned
2.1
Fix Released
High
Alexey Kopytov
2.2
Fix Released
High
Alexey Kopytov

Bug Description

xtrabackup_slave_info does not contain any GTID information. Shouldn't it contain the purge list(s)? Otherwise master_auto_position will not work properly.

Version info:
xtrabackup version 2.1.3 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 608)

(xtrabackup_binlog_info does have GTID position, but xtrabackup_slave_info does not)

Tags: gtid

Related branches

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

Sheeri,

I don't' understand this report, but my GTID knowledge is limited. Can you provide any examples of cases where master_auto_position would not work when cloning a slave, and what GTID information could fix that?

Thanks!

Changed in percona-xtrabackup:
status: New → Incomplete
Revision history for this message
Sheeri K. Cabral (awfief) wrote :

master_auto_position relies on GTIDs to know what transactions have been applied and what transactions have not, so they are essential to be able to actually use a cloned slave to replicate. GTIDs are a replacement for binlog and position, which spells out which transactions have been applied. Thus, MySQL knows that it does not need to apply those transactions, but will apply everything else not in the purge list.

So here's an example:

master -> slave1

If you want to spin up slave2, but don't want to take up resources on the master, you would run innobackupex --slave-info against slave1, and restore to slave2. However, without the GTID information, slave2 would try to reapply ALL the transactions in the master's binary logs, because there is nothing in the purge list. This will cause duplicate key errors and duplicate data when there are no unique keys on data.

In summary - think of it as like not having binlog information - you have a good clone, but you can't easily figure out where to start replication from.

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

Sheeri,

Thanks for clarifications.

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

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

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.