Inconsistent and unsafe FLUSH behavior in terms of replication
| 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:/
Somewhat related bugs:
https:/
https:/
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/
| tags: | added: upstream |
| Shahriyar Rzayev (rzayev-sehriyar) wrote | #1 |
Percona now uses JIRA for bug reports so this bug report is migrated to: https:/