percona xtrabackup 2.2.4 innobackup FLUSH ENGINE LOGS

[sam]

when I backup mysql5.6.19 on slave with percona-xtrabackup 2.2.4，I find that innobackupex executes the command：
FLUSH ENGINE LOGS
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");
with
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

[Valerii Kravchuk (valerii-kravchuk)]

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?

[Denis Zhdanov (deniszhdanov)]

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 (http://www.percona.com/blog/2014/05/19/errant-transactions-major-hurdle-for-gtid-based-failover-in-mysql-5-6/) and blocks failover until we fix it.

[pako (pakonet)]

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:

FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS

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)]

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

https://bugs.launchpad.net/bugs/1394632