Bug #269 Replication fails on interrupted temporary table processes
Submitted: 10 Apr 2003 8:51 Modified: 10 Apr 2003 14:27
Reporter: [ name withheld ] Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:3.23.52 OS:Linux (Linux/Suse)
Assigned to: CPU Architecture:Any

[10 Apr 2003 8:51] [ name withheld ]
Description:
Replication fails, the master sends a command in the binary log to drop temporary tables, which never existed on the replication hosts. It appears (to a novice), that whatever function reaps temporary tables from killed processes drops the tables without flagging the command not to be replicated.

How to repeat:
Create a temporary table from a select on the master, using a long-running query. On another connection to the master, find the connection creating that temporary table, and kill it. Within a minute or so, you will get a DROP TABLE command sent to the slave, for a table the slave never knew about, and the slave will fail.

Suggested fix:
Commands related to temporary tables should never be replicated.
[10 Apr 2003 14:27] Guilhem Bichot
Thank you for your bug report. This issue has been fixed in the latest
development tree for that product. You can find more information about
accessing our development trees at 
    http://www.mysql.com/doc/en/Installing_source_tree.html

Hi,

Thanks for your bug report. This is known and is fixed in
MySQL 4.0.13 (not released yet). Since 4.0.5, the automatic
DROP TABLE is instead DROP TEMPORARY TABLE. Since 4.0.13,
the slave silently translates
DROP TEMPORARY TABLE
to
DROP TEMPORARY TABLE IF EXISTS
so you don't get a "table doesn't exist" error anymore.
[6 Jan 2005 22:45] Ted Cui
This bug comes back at least for 4.0.18.