Inconsistent and unsafe FLUSH behavior in terms of replication

Bug #1736921 reported by Przemek on 2017-12-07
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MySQL Server
Unknown
Unknown
Percona Server moved to https://jira.percona.com/projects/PS
Status tracked in 5.7
5.6
Triaged
Medium
Unassigned
5.7
Triaged
Medium
Unassigned

Bug Description

Description:
Many of the FLUSH commands are bin-logged (but not all), and if GTID mode enabled, adding GTID sequence with local UUID.

These commands also do not respect super_read_only=1.

An example ones affected:
FLUSH SLOW LOGS
FLUSH HOSTS
FLUSH STATUS
FLUSH PRIVILEGES
FLUSH USER_RESOURCES
etc.

Not affected:
FLUSH LOGS
FLUSH ENGINE LOGS
FLUSH BINARY LOGS

This may cause replication problems later as the cluster becomes inconsistent.

Upstream report:
 https://bugs.mysql.com/bug.php?id=88720

Somewhat related bugs:
 https://bugs.mysql.com/bug.php?id=83232
 https://bugs.launchpad.net/percona-server/+bug/1631816

How to repeat:
 Test case seen in upstream report.

Suggested fix:
I don't see much sense in actually replicating these FLUSH commands at all, especially that most of them are related to local resources, which can be different on the slave side.

If though any of these *has* to be replicated/bin-logged for some reason, it should respect at least the super_read_only setting.

tags: added: upstream

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

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.