percona xtrabackup 2.2.4 innobackup FLUSH ENGINE LOGS

Bug #1384140 reported by sam on 2014-10-22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to

Bug Description

when I backup mysql5.6.19 on slave with percona-xtrabackup 2.2.4,I find that innobackupex executes the command:
this command will be record to slave binlog,which leads to inconsistency between master and slave

NOw,I have update the innobackupex file ,as follows:
replace the line :
mysql_query(\%mysql, "FLUSH ENGINE LOGS");
mysql_query(\%mysql, "FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS");

I have test it,and now do not record "FLUSH ENGINE LOGS" to slave binlog

that 'all,thank you
Tags: None

I wonder why this bug is marked as "Private" and should it remain private? Also, what inconsistency extra FLUSH ENGINE LOGS may cause, for real data?

Changed in percona-xtrabackup:
status: New → Incomplete
information type: Private Security → Public
Denis Zhdanov (deniszhdanov) wrote :

Of course, it will create "inconsistency is in the binary log" and not in data - it creates new transaction on slave which become errant transaction instantly ( and blocks failover until we fix it.

pako (pakonet) wrote :

We have exactly the same problem. We cannot use Xtrabackup 2.3.1-beta1 on a MySQL slave in a GTID enabled replication setup. Executing:


adds an errant transaction and we start getting notifications from our monitoring system. At this point we have to fix the "Executed_Gtid_Set" value on the slave or inject empty transactions on all other servers. This is not easy to do, so for now we decided against using Xtrabackup on MySQL slaves.

pako (pakonet) wrote :

I can confirm that the problem was fixed as mentioned in this bug report:

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

Other bug subscribers