Inconsistent and unsafe FLUSH behavior in terms of replication

[Przemek]

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.

[Shahriyar Rzayev (rzayev-sehriyar)]

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