DROP TEMPORARY TABLE creates a transaction in binary log on read only server
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 |
Fix Released
|
Medium
|
Laurynas Biveinis | |||
5.7 |
Fix Released
|
Medium
|
Laurynas Biveinis |
Bug Description
If "DROP TEMPORARY TABLE..." gets executed on server with GTID enabled and read_only mode enabled, then 'DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `sometablename`' gets inserted in server binary log. This creates errant transaction, that other slaves in cluster might not have and can break replication if server with errant transaction gets promoted to master and this transaction is already deleted from binary logs.
Percona version tested: 5.6.35-80.0, Debian jessie
How to reproduce:
1. On any read-only server with non-privileged user execute "drop temporary table if exists `sometablename`", no need to actually create temporary table before dropping.
2. Check `show master status`, you'll find new gtid generated on slave in read-only mode
Thank you for the report.
Verified as described.