"FLUSH TABLE" is written to the binary log
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona XtraBackup moved to https://jira.percona.com/projects/PXB |
Fix Released
|
Medium
|
Sergei Glushchenko | ||
2.2 |
Fix Released
|
Medium
|
Sergei Glushchenko | ||
2.3 |
Fix Released
|
Medium
|
Sergei Glushchenko |
Bug Description
The latest release of Xtrabackup issues a FLUSH TABLE before the FTWRL.
While it will help the backups in some situation, it also implies that
FLUSH TABLE will be written to the binary log.
While this situation is okay most of the time, it is not in MariaDB 10.0
with GTID enabled. If the backup is taken on the Slave, then the FLUSH
TABLE statement is still written to the binary log. This alters the GTID
of that slave and XtraBackup does not see the "correct" GTID anymore.
It is then impossible to see the GTID of the backup, because we would
only see the "wrong" GTID that was written to the binary log.
To avoid that, we have to issue the flush command with the
NO_WRITE_TO_BINLOG option.
Side note 1:
Our setup: MariaDB 10.0; GTID Replication, with GTID strict mode, and
log-slave-
Side note 2:
There is no problem with the FTWRL because it is never written to the
binlog.
Fix is in https:/ /github. com/percona/ percona- xtrabackup/ pull/72